Logged in as Guest   Sun, Oct. 21st, 7:33 AM.      
 
 
Web hazelware.luggle.com
 

My Journey With the NetServices SDK
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 Wednesday the 31st 1970f December 1969, at 04:00

 
Recent Entries:
I'm BACK!!!!!!
Code Monkey
Cool 3D Code Snippet From My Former Life
YouTube: The Revival of the Internet Time Killer
WhereMate Released
Palmasaurus Released As Freeware
VM-Plus Beta
Handspring Undocumented APIs
Posting Malaise
PhoneShield Released!!!

Archive:
October - 2007
August - 2007
July - 2007
June - 2007
May - 2007
April - 2007
December - 2006
November - 2006
September - 2006
August - 2006
July - 2006
March - 2006
February - 2006
January - 2006
December - 2005
November - 2005
October - 2005
September - 2005
August - 2005
July - 2005
June - 2005
May - 2005
April - 2005
February - 2005
January - 2005
December - 2004
November - 2004
October - 2004
September - 2004
August - 2004
July - 2004
June - 2004
May - 2004
April - 2004
March - 2004