Wireless networking has a long history, longer than most people realize. NCR’s WaveLAN was available in 1990 and of course supported DOS. But WaveLAN was only the precursor to IEEE 802.11 and it is completely incompatible with IEEE-standard networking equipment.
The IEEE 802.11b standard came out in 1999, specified a 11 Mbps signaling rate, and it’s about the oldest not totally obsolete wireless networking standard. The trouble is that IEEE 802.11b equipment appeared when DOS was almost gone from home and corporate PCs, although it still survived as a “pre-boot” environment for running Norton Ghost, Partition Magic, Drive Image, and similar products. The upshot is that until the early 2000s, there was demand for DOS networking drivers for then-current hardware.
My need was seemingly simple: I set up an old ThinkPad 760XL (166 MHz Pentium MMX) running DOS for my son to play 1990s games on, especially but not exclusively Sierra and LucasArts adventures; for that purpose, the laptop is quite suitable, it has a decent ESS sound chip and a CD-ROM. Moving data to the laptop on a CF card with a PCMCIA adapter is not difficult, but it gets old; it would be really handy to have the laptop on the network, accessing the home NAS via either SMB or NFS.
The laptop is of course old enough that it has no built-in Ethernet or WiFi, although it has two PCMCIA/CardBus (at least I believe they’re also functional as CardBus) slots. But the laptop is portable, and it’s in a corner of the house where there’s no Ethernet socket nearby. So WiFi would be really great. But is it even possible to get a DOS laptop on a WiFi network in 2019?
The short answer is “yes, but”. The long answer follows.
To begin with, I had to research what hardware might have functioning DOS drivers (yeah, the laptop could dual boot to Windows 98, but that would be much more hassle than the CF card). There appear to be two families of WiFi PC Cards with DOS drivers: Cisco Aironet 350 (or possibly 340 and even older models), and Lucent/Agere/Proxim ORiNOCO. The latter can be found in many OEM products, with the usual headache of identifying what the heck is inside a given PC Card and how the OEM might have mangled the reference design to break generic drivers.
I was unable to find any CardBus WiFi equipment with DOS drivers (wired CardBus Ethernet adapters would be a different story), and that means no IEEE 802.11g (54 Mbps). The Aironet and ORiNOCO chips both support only 802.11b (11 Mbps) and they’re both PC Cards (i.e. ISA), not CardBus (PCI). But hey, if it works, 11 Mbps is a lot better than nothing, and a good deal faster than a floppy at any rate.
In the end I decided to go for a Cisco Aironet PCM-352 first because Cisco still has relevant documentation and because I was able to dig up the drivers on 3rd party sites (Cisco might still have them, but not freely available). I found a “new” Aironet PC Card on eBay for a reasonable price (under 20 Euro), sold as tested and updated to the latest firmware.
Then I realized that there’s a serious problem: The old WiFi cards don’t support WPA, let alone WPA2, only WEP—which is practically as insecure as an open network. At any rate, my router won’t even do WEP, and I’m certainly not going to turn off encryption on my house WiFi.
Actually the above is not entirely correct: At least the Cisco Aironet 350, and I believe ORiNOCO as well, does support WPA… but only in Windows. WPA (TKIP mode) was explicitly designed such that it could be implemented on existing WEP-capable hardware with RC4 encryption, but it does require updated firmware and drivers. The last Aironet 350 DOS drivers are from 2002, obviously pre-dating WPA. In other words, no WPA on DOS.
So I went to the basement and grabbed an old TP-LINK access point that supports IEEE 801.11n (advertised up to 150 Mbps). That hardware is old enough to support WEP. Initially I had no luck with Cisco’s WEPDOS utility and was not able to program the WEP keys into the card. That’s perhaps worth expanding on: Although WEP can use software-managed keys, the Aironet hardware is also capable of programming the keys into NVRAM. This approach also allows the card to work in devices which may have no user interface to set the WEP keys.
At least for purposes of experimentation, I set up the AP to create a separate wireless network and disabled all encryption on it. This network does not broadcast its SSID and it only allows specific MAC addresses to connect. Now, this is not truly secure, because someone snooping on the network traffic can still read the SSID and see the MAC address, which can be spoofed. Then again, 99.9% of the time there is absolutely no traffic on the “special” wireless network, so there’s nothing to snoop on. In fact I keep the AP turned off most of the time, and that is secure.
For the moment the question was, could I get on the home network from the 760XL laptop? Cisco provided an NDIS driver, ODI driver (NetWare!), and a packet driver. I started with the NDIS driver and Microsoft’s final Network Client 3.0, which is notable for supporting NetBIOS over TCP/IP and DHCP.
The driver requires some manual configuration: The PROTOCOL.INI file needs to be edited to at minimum add the SSID (forget roaming!), and potentially change various settings. The driver should be able to either use Socket Services or an Intel 365SL style controller (which the ThinkPad 760XL has, but I have Socket Services installed anyway).
To my surprise, the Cisco Aironet driver worked the first time. DHCP, attach to a NAS SMB share, and poof, files can fly in both directions over the air. Not super fast, but it works.
Later, when digging through Cisco’s firmware release notes and old user complaints, I realized that the firmware on the card (version 5.60.21) that the seller so kindly updated might not be fully compatible with the DOS drivers. I found a set of older drivers and firmware images and grabbed an old Sony Vaio laptop with Windows XP on it. I installed the ACU (Aironet Client Utility) package and downgraded the firmware to version 4.25.23. Lo and behold, when the Aironet 350 card was back in the 760XL, the WEPDOS utility worked and I was able to program the WEP keys into it! Then I just needed to update PROTOCOL.INI to set the authentication mode to open WEP (AuthType=”WEPOPEN”), flip the AP to enable WEP, and I was on the wireless network with WEP encryption… infinitesimally better than an open network. The problem with the firmware is no doubt that the newer firmware supports WPA, and that interferes with WEP operation.
The bottom line is: Yes, it’s possible to get DOS onto a WiFi network, though it cannot be done very securely–caveat emptor!
To recap, there are two families of IEEE 802.11b PC Card hardware with DOS support: Cisco Aironet 340/350 series, and Lucent/Agere/Proxim ORiNOCO. Both are easy to find; Cisco was the only vendor of the Aironet 340/350 gear, while ORiNOCO chips were used by numerous OEM cards and may be difficult to identify. However, Agere or Proxim branded ORiNOCO PC Cards should be a safe bet (but careful: There are CardBus ORiNOCO adapters as well).
For both the Aironet and ORiNOCO adapters, there are variants with 64-bit encryption or 128-bit encryption RC4, an artifact of contemporary US export regulations.
In the ORiNOCO case, those are the Silver/Gold models for 64-bit/128-bit encryption. In the Aironet case, models 341/351 support 64-bit encryption and models 342/352 can also handle 128-bit encryption.
Rumor has it that ORiNOCO Silver cards can be flashed to the Gold firmware with some trickery, because of course Lucent didn’t develop two hardware variants but just limited the encryption strength via firmware.
In both the Aironet and ORiNOCO cases, cards may need older firmware to work with DOS drivers; on the Aironet side, 5.x series firmware appears to be a no go for WEP, but 4.x firmware works.
The two chip families both offer packet drivers and Novell ODI drivers. Curiously, it appears that only Aironet also had NDIS drivers, as confirmed by official documentation. Note that there were older pre-IEEE WaveLAN NDIS drivers (going back at least as far as 1994) but no confirmation could be found that those work with IEEE 802.11b ORiNOCO cards.
As an aside, the ORiNOCO cards were initially called WaveLAN/IEEE. The WaveLAN legacy is clearly visible in the driver names (“WVLAN43” etc.), and the documentation likewise often refers to “WaveLAN”.
The drivers for both the Aironet and ORiNOCO families can directly program an Intel 365-style controller or use Socket Services. The ORiNOCO software requires a WVLANCAD.SYS driver to be loaded in order to use either the ODI or packet driver; the Aironet drivers are “all-in-one” and don’t require drivers in CONFIG.SYS. I find Cisco’s approach much preferable, especially because the WVLANCAD.SYS driver likes to hang when the card is not inserted.
Getting either driver set working is somewhat painful and depends on the PC Card controller hardware and, if used, Socket Services software. On the ThinkPad 760XL with IBM’s PCMCIA drivers, I simply could not get the Aironet drivers working without Socket Services, and the ORiNOCO drivers working with Socket Services (SS), even though both driver sets are supposed to work with or with out SS. YMMV.
There is an interesting difference in WEP key management between the cards. As explained above, Aironet programs the keys into NVRAM and a DOS utility is provided for that purpose, while ORiNOCO has the keys in configuration files. Both approaches have advantages—the ORiNOCO configuration files are easier to set up, but there’s one file for a packet driver and a another for the ODI driver, and users might need multiple NET.CFG files for the ODI driver stack, which greatly complicates the configuration management.
The Aironet approach is less obvious (and it’s easy to forget where the keys are, let alone what they are), but it works well when the keys don’t need to change and I can see how it would be much easier for a centrally managed wireless network.
As mentioned above, my default networking software is the Microsoft Networks Client 3.0 with NetBIOS over TCP/IP and DHCP. This network client is also not fun to work with, just like Microsoft’s standard LAN Manager clients, for two reasons: It eats a ton of memory (forget 400KB free conventional memory if you need TCP/IP) and it cannot be dynamically unloaded.
The latter is extra annoying when debugging any startup problems because if a driver fails to load, the machine needs to be rebooted before another attempt. And compared to a wired network, the number of things that can go wrong with WiFi is significantly higher.
While I was able to get Microsoft-style file sharing going with the Aironet card, I have so far been unable to convince the ORiNOCO to work, quite likely in part due to the lack of an NDIS driver. I did set up the networking client to use an ODI driver and Novell’s ODINSUP shim, but I had no luck actually getting to any file shares. Configuring the network client was not trivial (PROTOCOL.INI needs to be manually changed it would seem) and ODINSUP in fact worked with the Aironet card which does not need it, but not with the ORiNOCO.
The ORiNOCO card is definitely not broken because with a packet driver and appropriate software (e.g. NCSA Telnet or mTCP) I can communicate with machines on my network. But there is far too much opportunity to get things wrong, and the DOS networking stacks are merciless—if you, for example, get the SSID (wireless network name) with the wrong case, it won’t connect and you will have no idea why (but checking the AP statistics can give a clue). It is actually quite useful that the ORiNOCO card has a green LED which is continuously lit when it’s associated with a wireless network; the Aironet LEDs are not as easy to read.
When I tried copying files using the Microsoft Networks client and Aironet 350, the performance was sub-par. Now, 11Mbps is not that fast but the copies took far too long even for that. Eventually (it took me much longer than it should have) I realized that it’s because the Access Point is randomly rebooting! The AP is a TP-LINK TL-WA701N and I don’t trust it at all. I don’t know if the hardware is flaky (possible) or if the firmware is junk (also entirely possible). The AP seems to spontaneously reboot after some hours of uptime, but any kind of sustained traffic reliably reboots it too, which is… not helpful.
Conclusion, Sort of
This is an area of ongoing research. Yes, it is possible to get a laptop running DOS onto a wireless network, as long as one can live with the fact that the network must be more or less unsecured.
Next I need to try a different AP, probably an older AP which would have worked with 802.11b equipment. Then I will continue experimenting further. I am also increasingly tempted to try NetWare style file sharing because the Novell clients have some significant advantages over Microsoft’s, like being able to dynamically load and unload and not eating gobs of memory.
At the moment, the Aironet equipment appears to be the better choice, at least for those who need an NDIS driver. However, the ORiNOCO also works satisfactorily if only a packet driver is required.
References: This paper by Kevin Benton provides a brief overview of IEEE wireless standards up to 2010 and an in-depth discussion of the implementation and weaknesses of 802.11b (WEP) security, along with an explanation of how WPA and WPA2 works.
I suppose the way to “work around” the lack of wireless security would be to have the unsecured AP firewalled from the rest of the network and only allow secure, authenticated protocols through. I know there are reasonably competent SSH/SCP clients for DOS which should make basic file access possible, but lack of multitasking would prevent any SOCKS-over-SSH type solutions for “general” network use.
I doubt there’s any sort of secure VPN client (i.e. so you could “VPN” from the unsecured wifi into the network proper) that runs under DOS and would work with the Microsoft client, so SCP is probably about it for secure file access.
Yes, that also occurred to me. Ideally have the AP also be a router with a firewall and only let through a minimum of traffic and ssh would take care of the crypto (not sure how fast on a Pentium MMX, but hey). Then again, I wonder if today’s hackers would know what to do with IPX and Novell file sharing packets!
The “enterprise” Cisco gear might actually be able to do something reasonably secure even on top of WEP. They had a number of extensions but I haven’t investigated those in depth, and it would almost certainly require a Cisco AP.
What about MAC whitelisting? Hiding the SSID may help, but that’s more obscurity…
It does not help, or only marginally, because if someone can snoop on the traffic, they will see the whitelisted MAC address and can fake it. Same with a hidden SSID, though I believe on a largely quiet network hiding the SSID really does help, because with no traffic there’s simply nothing to snoop on. When the SSID is not hidden then as long as the AP is active, the SSID will be visible.
On my home network hiding the SSID would do extremely little because there are constant broadcast and multicasts from chatty devices. On the “vintage” wireless network there’s mostly absolutely nothing.
I know it’s not exactly what you want, but another approach would be to have an access point act in bridge mode for local wired connections. That would bring a wired connection to be used by the laptop and other devices to the far room with full security over the wireless portion.
+1 on the wireless bridge. You can stick with period Ethernet adapters with ample driver support and still have network security.
Regarding the DOS memory woes, I just skipped the mess and ran WfW 3.11 when needing to access network shares. No worries about conventional memory and it usually just “works”. Driver support is pretty good and there are “shims” for ODI and packet drivers as well.
Wireless bridge — not a bad idea, but only works as long as the laptop stays in one place, which hasn’t quite been the case. But yeah it allows using modern WiFi gear with old Ethernet equipment. I have used wireless bridges in the past but was never quite happy with them, things never seemed to work 100% (just 98% or so). Maybe better hardware would fix that.
As for WfW 3.11, that’s probably no help in my case because the Cisco and ORiNOCO wireless gear has no NDIS3 drivers, so it would mean more shims and more ways for things to go wrong. But I can see how that would work if you have an NDIS3 driver and only occasionally need to copy stuff over.
There are very small WiFi-to-ethernet bridges that are intended to be moved with the computer (most have the option to power from USB, and I’ve seen some that can take power from PS/2 port). I’ll check if I can remember the brand that our client uses for connecting ECG machines (which have an official USB WiFi adapter, but it’s 802.11b/g only, and costs 600€, because medical).
What ender said, this VOGONS.org poster pointed out the PQI Air Pen Express, a small lipstick-sized USB-powered wireless access point that can be turned into a wireless bridge.
I wonder if it is possible to write a WfW 3.11 driver for a 802.11g card with a Win16 WPA supplicant.
I don’t see why it wouldn’t be technically possible. It should be even doable for DOS, with some kind of a supplicant TSR. Is anyone going to do that… very doubtful 🙂
I’ve had good result using DOS NDIS drivers with a Xircom parallell port dongle ethernet adapter, with Windows 98. Not sure but I assume that WFWG3.11 also supports running DOS NDIS drivers while still running the actual network client/server in Windows. That would eat up memory for the NDIS driver, probably not unloadable, but at least not for the rest of the client.
On the other hand, with EMM386 you can get at least a decent amount of free “conventional memory” under DOS. EMM386 enabling UMB does eat some performance though and might interfere with 32-bit DOS games.
Btw have you done any experiments with protocol wrappers? Not sure which wrappers exist and if they are any good, but in general there seems to be wrappers available to run a client requiring one kind of klient with a network card that only has another kind of driver.
Re the TP-LINK router: At least some of them used some version/clone/fork of DD-WRT, which should make the software rock solid. You might want to take it apart and have a look at the hardware, for example to see if it seems to contain bad capacitors or if something seems to overheat. It could also have gone bad due to lightning/thunderstorms and then it unfortunitely is goodbye. It crashing under load leads me to believe it’s capacitor / overheat related though.
I’m pretty sure the TP-LINK AP hardware is flaky, it used to be stable and the firmware didn’t change. I should open it and have a look.
I did use one protocol wrapper, ODINSUP (plugs into NDIS protocol stack, uses ODI hardware drivers). And it does work.
I have one of the Xircom parallel port doohickeys and yes it does work, not blazingly fast but decent (it depends quite a bit on the parallel port hardware). But if I wanted to use cabled Ethernet, I’d probably use a PC Card anyway.
EMM386 UMBs help a lot. But with PC Card drivers and a network stack loaded, there just isn’t enough room. A more modern network stack like Novell’s Client32 would probably make a big difference, but I don’t have a NetWare file server. Though I’ve been thinking about it more and more, since the NetWare DOS support just seems much better than anything Microsoft ever had.
I wonder if specialized emm like Helix Netroom could help recover more ram.
That question crossed my mind too. I suspect it won’t work terribly well on a laptop, but on a generic desktop it should be able to provide more UMB space, maybe even significantly more.