Anywhere Computing with Laptops. Making Mobile Easier

In the previous example I took you through the setup of an ad hoc network from beginning to end where there were no problems. And with a modern Centrino-based mobile computer you should have the same experience I had in writing up this exampleeasy and straightforward, it just works. But you know, and I know, that sometimes the unexpected happens and you have to cope with it. Here are a few tips and tricks to help you move beyond some problems in getting computers talking to each other in an ad hoc network.

Be forewarned that this information is fairly technical. So if reading about the inner workings of 802.11 protocols and TCP/IP addressing is not your cup of tea, you can skip this section, or get a geeky friend to read it and she can help you sort out any problems you might have with an ad hoc network.

If you are trying to connect your Centrino mobile computer to an older computer running an earlier version of Windows (98, Me, or 2000) in theory ad hoc networking should work, but there are some issues you need to know about. Even an older computer upgraded to Windows XP, but with an early model 802.11 card can have difficulties.

The 802.11 standard for ad hoc networking evolved from a more primitive form to the implementation in use now. The early kind of ad hoc networking (called ad hoc demo mode or AHDM) is not interoperable with the final standard for ad hoc networking called IBSS (for independent basic service set).

I was unfortunate enough to have an older 802.11 card and wasted four hours trying to make the darn thing work only to finally discover it was using the old AHDM set of ad hoc protocols. Lesson learned: If the ad hoc network does not come up immediately, and you have an older computer with an early 802.11 interface, give it up. Don't waste your time.

One of the enormous advantages of a new Centrino-based laptop is the maturity of the technology. All the kinks and quirks have been ironed out and the products just work. You won't waste your time fiddling with this and that, trying to coax it into behaving nicely.

Not all problems with ad hoc networking are as severe as the interoperability problem between AHDM and IBSS. Here are a couple tricks you can try if you are having trouble getting your Centrino-based mobile computer to communicate in an ad hoc network with an older computer (or even a new one that is not Centrino based).

Some 802.11 wireless interfaces are capable of setting special properties that affect how the interface functions. Figure 14.10 shows some of the settings for the Intel PRO/Wireless 2200BG Network Connection. In particular note the setting called Ad Hoc Channel that is set to a value of 11. This setting tells the interface which of the 11 or so 802.11 channels to broadcast on when advertising an ad hoc network. It is also the first channel this interface will use when trying to locate an ad hoc network. It is not necessary to change this setting to get Centrino-based laptops talking to each other because they scan all available channels to find ad hoc networks. But that might not be the case with an older interface. So one tip is to make the ad hoc channel setting on all the wireless adapters the same.

The final piece of advice has to do with TCP/IP network addressing. Most computers today get their numeric TCP/IP network address from a dynamic host configuration protocol (DHCP) server. Whether your computer connects to a wired network or a wireless one, the first thing it does is send out a message requesting an address. The process works so well, almost no one knows or cares to change TCP/IP address settings anymore.

In an ad hoc network there is no DHCP server to give an address. Your Centrino-based Windows XP mobile computer is still going to try to get an address when it connects to an ad hoc network, but after about 60 seconds or so when it doesn't hear back from a DHCP server it gives up and Windows Automatic Private IP Addressing (APIPA) takes over. Windows XP generates its own semi-random address of 169.254.xxx.xxx, where the xxx represents a number picked at random between 1 and 254.

Windows XP systems work just fine with the APIPA-generated addresses. You can refer to the computers by their human readable names (Nomad instead of 169.254.252.12), browse files, and even print to a printer if one is attached. But not all computers are as forgiving as Windows XP. So for these less flexible systems you will need to assign a consistent set of TCP/IP addresses in the same subnet.

Windows XP has an extremely nice facility that enables you to have your cake and eat it too when it comes to network addressing. Figure 14.11 shows the Alternate Configuration tab on the Internet Protocol (TCP/IP) Properties dialog. You can use this setting to override the APIPA mechanism and specify any address you want when no DHCP server is present. However, when your computer does get a response from a DHCP server (like when you are on your home or office network) it will prefer that and take the dynamically assigned address instead. This way, setting up addressing for an ad hoc network doesn't interfere with the configuration you want for your home or office.

It is a TCP/IP addressing convention that IP addresses of 192.168.xxx.xxx are for private networks. You can see that I specified 192.168.50.1 for the computer in Figure 14.11. So following this example I would start at 192.168.50.1 and give each computer its own address incrementing by one for each system (192.168.50.1, 192.168.50.2, 192.168.50.3, and so on).

If you are going to shut off APIPA and assign your own addresses, you should be aware this is an all-or-nothing proposition. Either all the systems in your ad hoc network are Windows machines that use APIPA-generated addresses, or all of them use IP addresses that you manually assigned. It's not possible to have a mixture of some systems with APIPA and some with manually assigned addresses (not if you want them all to communicate with each other).