Section 9.4. Packet Drivers

9.4. Packet Drivers

Crynwr Software came into its own with packet drivers. A packet driver allowed the sharing of an Ethernet card between two protocol stacks. For about a year, the only possible way to get Novell network clients on the Internet was by using a packet driver. Also, a packet driver would hide the differences among Ethernet cards.

Unlike video boards, which are at least compatible at the VGA level, Ethernet boards have never been compatible.

Back before packet drivers existed, there were network clients and serverslargely Novell NetWare. The manufacturer-written network driver was linked to Novell's code in a single executable. The resultant program had no API for an external program to send or receive an Ethernet packet, which was very bad for any competition to NetWare. Maybe Novell planned it that way, but I doubt the company was that Machiavellian.

Anybody wanting to send packets other than NetWare's had a problem.

The 3Com 3C501 was the market leader, but it was a very insufficient card. It had one buffer shared between transmit and receive, so a packet could be lost if it arrived when the buffer had not been emptied, cleaned, and turned around. However, everybody had drivers for it. Novell, in an attempt to improve the state of the art, took National's 8390 demo board and put it into production as the NE1000 (and later as the NE2000). This board had sufficient memory with separate transmit and receive buffers.

Just about then, other Ethernet controllers were coming on the market. People were using the Intel 82586, the AMD LANCE, and the National 8390 (in non-NE2000-compatible ways). Only NetWare included a device driver development solution. It had a driver development kit (DDK), and a certification house (Novell Labs).

Other protocol stack vendors were doing the same thingproducing drivers linked into their own products. No vendor had a driver that could be shared, however. While Novell and Microsoft pondered, little FTP Software (now owned by NetManage) had the same problem as everyone else: too much hardware and too few drivers. It came up with its own specification for a shared Ethernet driver and, unlike other vendors, published it as an open standard.

I was working for Clarkson University at the time, and we had the same problem as everyone else: how to support multiple pieces of software and hardware at the same time. I was using Phil Karn (KA9Q)'s NOS, and he had packet driver support. So, I wrote packet drivers for the two Ethernet adapters in use at Clarkson (the 3c501 and Racal-Interlan NI5210) and published them as open source software.

A number of fellow Internet users contributed drivers, and before long, we had covered a considerable portion of the industry. This led to more support from TCP/IP vendors, and a group at Brigham Young University wrote a NetWare driver that could use a packet driver. We really got the ball rolling then, because anyone with a NetWare network could put it on the Internet.

There were some holdouts, notably Microsoft and Novell, both of whom started promoting their own standards: NDIS and ODI, respectively. The NDIS document was published from the start, but there were no sample drivers, and no base of code from which to build. ODI documentation was available only with an expensive DDK purchase. A packet driver distinguishes itself by coming with source code, by having a simple, approachable API, and by being small in size. The typical driver was 5K of executable, compared to 20K for ODI, and 40K for NDIS.

By the mid-1991, I realized there was money to be made providing packet driver programming and certification servicesthe latter for drivers not written by Crynwr. So I left Clarkson and, after a five-month placeholder stint at a local PBX company, I started Crynwr Software. Up until 1998, Crynwr's main source of income was from packet drivers.