Recent Entries: |
|
|
|
|
|
|
Ubuntu Rules, Fedora Drools
|
Hopefully, nobody really noticed, but Jonah and I finally moved our aging Red Hat server to the very friendly Ubuntu Linux distribution. Previously, Luggle had been hosted on Fedora Core, and unfortunately, it was really starting to show its age. If you haven't heard of Ubuntu, you really should take a peak at what Mark Shuttleworth and company have put together. In a nutshell, Ubuntu is built around Debian with a focus on being user-friendly. (If you're unfamiliar with Debian, it is Linux with a focus on easy upgrades.)
I have many opinions about using Linux as a desktop installation, and while I still think that the whole experience isn't quite ready for the 'average joe', I do believe that Ubuntu has advanced the cause considerably. I even went so far as to try my litmus test, which you can read about here.
Well, that's about it for tonight. Cheers!
-Jon
|
Submitted by bosshogg on Sunday the 24th of July 2005, at 09:45 pm
|
Follow On Article About Retrieving Assigned IP Addresses
|
In a
previous post about inspecting network connection settings on the PalmOS, I presented one piece of very incorrect/misleading information of particular interest to developers working on networked applications. I presented a code snippet to retrieve the assigned IP address when connecting via DHCP to a server. (Giving credit where credit is due, my error was very kindly pointed out to me by Henk Jonas.)
In my previous article, the snippet showed that you could retrieve the assigned IP address simply by querying the netIFSettingActualIPAddr using NetLibSettingGet(). In fact, the problem is slightly more complicated. The method that Henk pointed me to is implemented by looping through the NetLib interfaces after a connection has been established. While looping through the interfaces, you must look for the ones that are up and that are not the loopback interface. Once you have found an interface that is up, only then can you query netIFSettingActualIPAddr using NetLibIFSettingGet(). Here is one way to implement this:
UInt16 index = 0;
Err err = errNone;
while (err == errNone)
{
UInt16 idx;
UInt32 creatorID;
UInt16 instance;
//Retrieve the creator ID and instance of the indexed Interface
err = NetLibIFGet(netLibRefNum, index, &creatorID, &instance);
if (err == errNone)
{
//Check to see if the interface is up
UInt8 isUp = false;
UInt16 size = sizeof(isUp);
NetLibIFSettingGet(netLibRefNum,
creatorID,
instance,
netIFSettingUp,
&isUp,
&size);
//Make sure the interface is up and is not the
//loopback interface
if (isUp && creatorID != 'loop')
{
//Once we get here, it's simply a matter of
//grabbing the IP address
UInt32 address;
size = sizeof(address);
NetLibIFSettingGet(netLibRefNum,
creatorID,
instance,
netIFSettingActualIPAddr,
&address,
&size);
//Once you get here, you have to do something
//with the IP address. Do you just get the
//first one and stop, or do you want all the
//assigned IP addresses of Up Interfaces?
//That determines whether or not you want to
//break out of this loop. I leave that as an
//exercise for the reader. -Jon
}
//Go on to the next Interface
index++;
}
}
As always, I hope this helps you in your endeavors, and if you feel like it, I'd love to hear about it!
-Jon
|
Submitted by bosshogg on Saturday the 09th of July 2005, at 07:21 pm
|
WiFi-Where Now Supports the Lifedrive and Gets a User Review
|
As a more practical follow up to my previous posting, I have updated WiFi-Where to support the Lifedrive. On a related note, WiFi-Where is now available for purchase on Palmgear as well as Handango. I hope to write up my experiences dabbling in the world of shareware authors soon. (Suffice it to say, I won't be quitting my day job anytime soon.) However, I did get my first review on Handango and they gave me 5 stars!!!
"This is one of the best appz that I have on my TC, it easily beat´s Netchaser. With this program I have ploted the open wifi-points in my homecity and shared them with my friend. He has done the same in the city he life in for easy wifi access...."
Nice!
-Jon
|
Submitted by bosshogg on Thursday the 07th of July 2005, at 12:09 am
|
The Lifedrive and the NetServices Library
|
The NetServices library is used on both the Tungsten C and the WiFi SD card from palmOne to control the 802.11 radio. The new Lifedrive from palmOne also sports an 802.11 radio and when I finally got my hands on one the other day, I was pleased to see that it also supports the NetServices API. However, as I played with it, I discovered a few differences that I will share here.
The first difference is that the NetServicesProfile structure (used to retrieve and store specific settings related to establishing a connection) is now larger than the one that is currently documented. The structure is documented/defined in PalmNetServices.h, however, the size of the structure that is written to by the NetServicesProfileRead function is larger. To illustrate this, the following code doesn't work on the Lifedrive because it corrupts the stack:
Example 1:
NetServicesProfile profile;
NetServicesProfileRead(netServicesLib, 0, &profile);
The proper way to use the NetServicesProfile structure is to query its size using NetServicesProfileGetInfo() which will fill a NetServicesProfileInfo structure with general information about profiles on a device. The NetServicesProfileInfo structure then contains the size of the NetServicesProfile structure in the profileEntrySize member. As I write that, I realize it probably is a little unclear, so here is a little sample code to illustrate the proper way to do this:
Example 2:
NetServicesProfile* profile;
NetServicesProfileInfo profileInfo;
NetServicesProfileGetInfo(netServicesLib, &profileInfo);
profile=(NetServicesProfile*)MemPtrNew(profileInfo.profileEntrySize);
NetServicesProfileRead(netServicesLib, 0, profile);
//Use profile here...
MemPtrFree(profile);
In retrospect, this is the way that I should have been using NetServicesProfileRead all along, however, I must say that the very sparse documentation on the NetServices API didn't help my cause. If you know what the new definition of the NetServicesProfile structure is, I'd love to know!
The second major difference that I found relates to the RSSI (receiver signal strength indicator) values that are returned from a WiFi scan. Previously, the RSSI values ranged from 0 to -100 where 0 is the theoretically best RSSI value. On the Lifedrive, however, the returned values ranged from between 250 and 350. Now, these values aren't documented anywhere that I could find and are values that I discovered only through experimentation so your results may vary. Because of these differences, I had to change my WiFi-Where code to normalize the returned RSSI values. For reference, here's my implementation:
Example 3:
Int32 NormalizeRSSI(NetBssInfoType* info)
{
Int32 rssi;
BssInfoRssi(info, &rssi);
UInt32 deviceID = 0xFFFFFFFF;
if (errNone != FtrGet(sysFtrCreator,
sysFtrNumOEMDeviceID,
&deviceID))
{
deviceID = 0xFFFFFFFF;
}
if (deviceID == 'TunX')
{
//LifeDrive = 250-350 normalized to 10% - 70%
rssi -= 150;
rssi *= 70;
rssi /= 100;
}
else
{
//Put value into the positive range...
rssi += 100;
}
return rssi;
}
So far, these are the only major differences that I could find. I'm sure that there are others that I simply haven't stumbled upon yet. I will update as I discover more. If you have found other differences in the NetServices implementation, or can fill in the backstory behind these differences, I'd love to hear about it!
-Jon
|
Submitted by bosshogg on Monday the 04th of July 2005, at 11:42 pm
|
|
 
|
|