DOS Wireless Networking, Continued

As I recently mentioned, wireless networking is extra difficult when the access point reboots itself at the slightest hint of heavier traffic. The faulty TP-Link router was temporarily replaced with a Netgear WG602 of similar vintage. The Netgear has been solid and has no trouble transferring tens of megabytes without a glitch.

I should note that although the TP-Link turned out to be bad, it has nicer diagnostics than the Netgear and it is slightly more tweakable. But a working AP wins out any day.

The next project was getting IBM’s TCP/IP 2.1 working wirelessly. The protocol stack is almost completely dynamically loadable and unloadable, and comes with a decent NFS client. I had previously got IBM TCP/IP going in a DOS VM without much difficulty, but convincing it to work with a Cisco Aironet 350 turned out to be surprisingly tricky.

Wireless IBM TCP/IP

The IBM TCP/IP stack was designed to coexist with other products and can use either NDIS or ODI drivers. On first try, I could not get either working at all. The NDIS driver refused to bind, and the Cisco ODI driver failed to be recognized by the TCPODI component of IBM TCP/IP.

The failure was rather odd. Although everything seemed to be configured properly, TCPODI kept saying “ERROR: Unknown adaptor transmission media.” That was not particularly enlightening, since the Aironet CSCODI driver should look like regular Ethernet to software.

Using Novell documentation, I went so far as to write a small utility which finds the LSL, queries all MLIDs, and dumps information about all the logical boards it finds. I still could not spot anything suspicious.

The only oddity was that CSCODI reported the line speed as 1 Mbps, which is actually unexpected because 802.11b should really be faster than that (11 Mbps theoretical maximum); even Aironet’s older ARLAN devices were faster than 1 Mbps, although the 2.4 GHz models did use 1 Mbps as a fallback transmission rate. On a hunch, I patched the MLID configuration table within CSCODI.COM driver to report 10 Mbps line speed (one byte changed from 1 to 10). Lo and behold, suddenly TCPODI decided that everything checked out and the TCP/IP stack loaded!

But it still did not work. More specifically, although traffic seemed to be going out, and packets were coming in, ARP was not working. Without that, nothing really works. And I wasn’t desperate enough to manually manage the ARP tables.

When running ‘TCPODI -i’ I noticed that ARP statistics showed zero packets processed and zero packets dropped, but a number of packets filtered. I failed to find out from IBM’s documentation what “filtered” really means. However, later I noticed that TCPODI also has an -a switch whose function is to “disable ARP filtering”.

So I tried starting TCPODI with the -a switch and… it worked! I could ping other machines, I could run FTP, and most importantly, I could mount NFS exports. A victory of mind over software, I suppose.

Return to ORiNOCO

With a reliable router in place, it was time to go back to the ORiNOCO wireless card. First I wanted to try IBM TCP/IP again since there’s an ODI driver for the ORiNOCO, and there would be no need for shims introducing additional points of failure.

TCPODI again refused to load, but this time I knew what to look for—the WVLAN43.COM driver reports the line speed as 11 Mbps (very sensibly) and that trips up TCPODI just like the 1 Mbps reported speed did with the Cisco Aironet 350. Same trick, patch one byte from 11 to 10, problem solved.

And again that wasn’t enough, because the TCP/IP stack started but there was no traffic, yet the green LED indicated that the station was associated with the AP. Then I remembered that I’d seen a similar problem before… the ODI NET.CFG syntax is tricky, and while strings do not have to be quoted, they will be uppercased if they’re not enclosed in quotes. And that’s a problem for WEP keys in ASCII format (and for SSIDs).

Added quotes to the keys, et voilà—ORiNOCO TCP/IP worked! FTP, NFS, the works.

Then it was time to revisit the Microsoft network client which uses ODI via the ODINSUP shim, and which I was previously unable to get working. As I suspected, the problem turned out to be the same as with TCP/IP—WEP keys in ASCII format needed to be properly quoted in NET.CFG. When the ODI driver was configured properly, the MS Networks Client 3.0 worked without a hitch.

Results

In the end I was able to get both the Cisco Aironet 350 and the Agere ORiNOCO PC Cards working to my satisfaction.

To get some sense of how slow 802.11b WiFi actually is, I copied a random roughly 42MB file over the wireless network in both directions between the ThinkPad 760XL and my NAS. The copying was done using the NDOS (4DOS) COPY command, with SMARTDRV loaded and write caching enabled. Here are the numbers:

	To Laptop	From Laptop
ORiNOCO, MS Net	258.0 KB/s	130.5 KB/s
ORiNOCO, IBM NFS	321.5 KB/s	402.7 KB/s
Aironet 350, MS Net	297.2 KB/s	126.7 KB/s
Aironet 350, IBM NFS	422.5 KB/s	439.7 KB/s

A couple of things jump out. When copying files from the laptop to the NAS, the Microsoft network client is really slow. The IBM NFS client is faster than the MS Network Client; in the (arguably less interesting) laptop-to-NFS case massively so. The Microsoft network client has to go through the ODINSUP shim in the ORiNOCO case, but looking at the Cisco Aironet results, the shim must have negligible impact on performance. The Cisco Aironet 350 was faster, but not hugely so.

Real world file copy speeds were about 400 KB/s, which doesn’t sound like much, but filling up a hard disk with a size on the order of 1 gigabyte does not take terribly long at that rate. It also bears saying that although the 802.11b theoretical maximum rate is 11 Mbps, practical user data transfer rates are nowhere near that and values closer to 5 Mbps are to be expected under good conditions. The 400+ KB/s rates are actually not at all bad considering the host hardware (166 MHz Pentium MMX, a slow laptop hard disk). 440 KB/s is more or less exactly 3.6 Mbps, but that does not include any protocol overhead. Without testing some good bus-mastering Fast Ethernet CardBus card in the same laptop, I have to assume that even DOS can get reasonably close to the practical maximum 802.11b is capable of.

For my purposes, i.e. copying a few megabytes every now and then, any of the solutions (ORiNOCO or Aironet, MS Network Client or NFS) is perfectly acceptable. Overall, both the Cisco Aironet 350 and the Lucent/Agere ORiNOCO cards did the job. In both cases, setting them up was somewhat painful, and significantly more difficult than setting up wired Ethernet, but they did work in the end.

I slightly prefer the Aironet adapter, primarily because it does not require an extra driver in CONFIG.SYS, and it does not hurt that at least in my case it’s a little bit faster as well. But if I started out with a working ORiNOCO setup, I probably wouldn’t look for an alternative.