Logged in as Guest Fri, Mar. 12th, 4:26 AM.
|
|
|
|
|
Breaking from the normal Tech postings, I wanted to let people know that my dad is headed off to Sri Lanka to help with the disaster relief from the tsunamis. For those of you that don't know, he works for Northwest Medical Teams, and he was telling me last night that NWMT is in a unique spot in their history because they already had five teams active in Africa when the tsunamis hit. Because of that, they are really, really strapped for medical supplies and equipment. I was at their headquarters yesterday, and the volunteers that were packing the equipment were commenting that the teams are heading out without a lot of supplies that they really should have. Regardless, five teams of doctors, nurses and paramedics have come forward to travel on their own time and money, and NWMT has committed to sending them to the tsunami disaster areas. If you have the ability, I encourage you to give even a small amount to help them. As of this writing, the official death toll is 116,000, and is expected to rise still higher. That is almost unfathomable to my mind. If you want to contact my dad about the trip or NWMT, you can contact him via email. |
|
| Submitted by bosshogg on Thursday the 30th of December 2004, at 03:06 pm | |
|
|
|
|
Wow! I have gotten a lot of responses from my first post on the NetServices SDK. (Thanks to Ben for the link.) In fact, I've gotten so much of a response that I need to write part 2 of it. Here it is for your reading pleasure: It my previous post, I detailed what I had to go through in order to figure out what AP the TungstenC was connected to. I got a great email from Catherine Ruggles who worked on the Boingo client. Her question was why I didn't use netIFSetting80211ESSID to query what AP the WiFi radio was connected to. I realized that my previous post didn't even mention that IF setting. Catherine is absolutely correct that if the WiFi radio is already connected to an AP, you can use the netIFSetting80211ESSID setting to find out which one. However, my particular problem was such that I needed to know what AP my device was associated with before the network connection was established. Using netIFSetting80211ESSID is too late for my particular problem. The problem that I was trying to solve was that I needed to be able to force the WiFi radio to connect to an AP that I specified. It took a lot of searching and digging, but eventually I was able to slog through it. Thanks to Catherine's reminder of the netIFSetting80211ESSID setting, I ended up modifying my original function to use netIFSetting80211ESSID. Because of that, it ultimately ended up being a more robust solution than the one that I had originally implemented. To save other people time and headaches, here is how my final implementation works: 1. Initiate a scan of APs in the vicinity. 2. Check the results of the scan to see if the AP we want to force a connection to is in the list. If it isn't then return an error. 3. Check to see if the Network Library is open. 4. If it is open, call NetLibIFSettingGet with netIFSetting80211ESSID to query the SSID of the AP we are connected to. 5. If we are connected, and the SSID doesn't match the SSID of the one we're trying to force a connection to, force the network library to shutdown immediately. 6. Call NetServicesProfileGetOrder and NetServicesProfileRead to find out the SSID of the 'preferred' AP. 7. Move the profile ID of the AP we are trying to force a connection to be the first (0 order) profile with NetServicesProfileSetOrder. 8. Open the network library (NetLibOpen, etc.) and let the SmartConnect do it's thing. 9. After NetLibOpen returns, call NetLibIFSettingGet with netIFSetting80211ESSID again to query the SSID of the AP we actually connected to. 10. If the AP that we connected to isn't the one that we're trying to force a connection with, close the network connection and return an error. Incidentally, Catherine explained to me that this is approximately how the Boingo client works. So if you use this method, rest assured that you're not the only one! I am always on the lookout for better ways of doing things. If you know of a better way of doing this, let me know. |
|
| Submitted by bosshogg on Tuesday the 14th of December 2004, at 01:41 am | |
|
|
|
|
Well, ever since hazelware got linked by Ben Combee, I have actually been getting traffic! So, I figured I should at least pull out some new content... ;-) Anyway, if you've ever had a PalmOS device that you KNEW had functionality to do something, but there wasn't a documented API, then you'll enjoy browsing through Jake's hack and slash session with his Samsung I-300. The article and the device are a little old, but the techniques and the technology still apply. He even gives you his sample code. Here's the link. |
|
| Submitted by bosshogg on Monday the 13th of December 2004, at 12:55 pm | |
|
|
|
|
Recently in the PalmOS developer forums, the question has come up regarding what devices are capable of what particular functionality. The response that arose was that there really isn't any central repository for this information. I'm not sure why PalmSource wouldn't have this in a knowledge base article somewhere, but apparently they don't. Anyway, here are a few pages that you could cobble together your own information if you wanted to: http://deeptec.com/palmevolution/palmtree.html http://homepage.mac.com/alvinmok/palm/codenames.html http://www.palmos.com/dev/tech/hardware/compare.html http://www.mobilegeographics.com/dev/devices.php If you know of more, please let me know and I'll add it to my list. |
|
| Submitted by bosshogg on Monday the 13th of December 2004, at 12:44 pm | |
|
|
|
|
I have done quite a bit of work in the past with the NetServices library on the PalmOS (see WiFi-Where), but I recently have been challenged with forcing the TungstenC (or a PDA with the new palmOne WiFi SD card) to connect to a specific 802.11 access point. What I have found has been quite interesting. The biggest challenge that I discovered is that there doesn't appear to be a simple way to programatically tell what (if any) access point a device is connected to. My first inclination was that there would be an interface(IF) setting that I could query. I was able to find the netIFSetting80211AccessPointBSSID setting in NetMgr.h. Unfortunately, that particular setting isn't supported by the TungstenC. In fact, I have come to discover that most of the 802.11 IF settings that are defined in NetMgr.h aren't implemented/supported. I wonder why they're even there at all if no one is using them? Anyway, my next bright idea was to perform a scan of all of the available APs, and store their MAC address and ESSID (ESSID = name). My thought was that I could then take that list of MAC addresses and compare that with some query value in the NetServices API. I quickly discovered that such a function doesn't exist. Not to be undone by missing functions, I thought that perhaps the NetLibMaster function from the standard NetLibrary (which is used for trace information) could return me a MAC address to compare with. Sadly, I was shut-out there as well. It was at that point that I remembered that there was a separate .h file for some of the 'less documented' features of the NetServices library: PalmWiFiCommon.h. So, I jumped over to that file and discovered the WiFiCustomIFSettings enum and a whole slew of potential IF settings to query. The most promising setting was the netIFSetting80211StationName value. However, I was again frustrated to find that no matter when I queried this value, it seemed to be always static. Ugh. At this point, I reverted to my trusty Palm hacking tool, Palmasaurus. Now, my favorite feature about Palmasaurus is that I can search for a string throughout the entire PDA. It can take a while to search through every database on the device, but if I'm looking for something specific (like an AP name) I can generally find it. The only thing that I found was a database named 'WiFiDB'. It appears that the last record in this database is the name of the last AP that your device connected to. So, now that I had an idea where this value was stored, I tried connecting to see how this value changed. The strange thing was that when I tried to connect to the network with NetLibOpen, it tried to connect first to the AP that was named in that DB. When that failed, it then went systematically through almost every AP that I had ever connected with. So, I headed back to Palmasaurus to see where this list was stored. However, my search came up with no results. In other words, the names of these APs either aren't stored in the standard databases or they aren't stored in plain text. Very strange indeed. If anyone knows where this list is stored, I would love to know. Well, that shook my confidence quite a bit in the WiFiDB. Clearly, I wasn't going to be able to poke into that DB every time I wanted to know what AP I connected to. So, I looked in the last place that I could think of: the NetServicesProfileXXX calls. I had a suspicion all along that my answer might be there, but I am not exaggerating when I say that this family of function calls is one of the most poorly documented in all of the PalmOS. Well, after poking around and plodding through it I did find a somewhat hack-ish way to determine what AP if any a device is connected to. Here's how I did it: 1. Detect if the Network library is open using NetLibConnectionRefresh 2. If the network library is open detect if the WiFi interface is up by querying the netIFSettingUp setting with NetLibIFSettingGet. If either step 1 or 2 fail, then the device isn't connected and the check can terminate. 3. Get the ordered list of AP profiles by calling NetServicesProfileGetOrder 4. Use NetServicesProfileRead to read the profile of the first (0 based) index in the list of APs returned in step 3. The profile returned from the read function will contain the ESSID (name) of the AP. Whew! What a journey. And this is the condensed versions. I have spared all of the gory details of slogging fruitlessly through the telephony API and the useless newsgroup searches and the endless googling, etc. In my next post, I will detail my continued journey with how I was able to 'force' the PDA to connect to a particular AP. Stay tuned! |
|
| Submitted by bosshogg on Friday the 10th of December 2004, at 12:27 pm | |
|
|
|
|
Well, I've been pretty slow to get on the RSS bandwagon, and while I still am not totally convinced that it lives up to the hype, I have been convinced to implement an RSS feed for Hazelware. Overall, it was almost trivial to implement. It took me longer to remember how to use chmod than anything. If you are interested in these kinds of things, it is a 2.0 compliant feed and, you can find it at /rss.xml. Thanks to Ben Combee for providing the impetus. No thanks to Jonah for changing the server's PHP parser. |
|
| Submitted by bosshogg on Monday the 06th of December 2004, at 10:09 am | |
