Ethernet Packet Driver MLID Introduction ------------ PDEther.Exe is an ODI to Packet Driver adaptor. It provides an ODI interface for an arbitrary Ethernet Packet Driver. This allows ODI access to any Ethernet board which has a Packet Driver and also allows Packet Driver applications and ODI applications using different network layer protocols to coexist in the same DOS system. Using PDEther ------------- In Packet Driver terms, PDEther is an application. In ODI terms, it is a LAN driver, also know as a "link driver" or "MLID". The loading sequence will be something like this: 1. Load the packet driver supporting your card. 2. Load LSL. 3. Load PDEther. 4. Load IPXODI, Net3, and/or other ODI applications. Like all good ODI modules, PDEther reads Net.Cfg for configuration information. The Link Driver section of that file for PDEther is described in the next section of this document. Net.Cfg ------- This Link Driver's name is PDEther; it reads the section of the Net.Cfg file which starts with the unindented text "Link Driver PDEther". As is normal in the Net.Cfg file, the section continues until the next unindented line. (In other words, all lines in the Link Driver section should be indented by one or more spaces or tabs.) PDEther ignores case, extra white space, and comments when reading Net.Cfg. Comments begin with "#" and continue to the end of the current line. The Link Driver section of the Net.Cfg file supports three keywords: INT The INT line specifies the software interrupt of the Packet Driver the MLID should use. The value is a hex number between 60 hex and 80 hex. The number may optionally be preceeded by "0x" to indicate a hex number, but the number is read in hex whether or not the "0x" is present. If PDEther sees no INT line, it uses the Packet Driver at software interrupt 60 hex. FRAME Ethernet_II This is just the standard frame type parameter that all MLIDs support. Since this driver only supports Ethernet, only "Ethernet_II" is accepted. For the same reason, this line is entirely optional. PROTOCOL Ethernet_II This is the standard protocol identification line. The protocol name (case insensitive) identifies the protocol to LSL. E-type is a hex number indicating the Ethernet type value for this protocol. (Again, it may be preceeded by "0x", but it is always interpretted in hex.) The media name is Ethernet_II. Again, Ethernet_II is the only media supported, so contrary to standard Net.Cfg practice, specifying Ethernet_II is optional. *ALL* protocols this driver is to support must be specified in the Link Driver section, since the MLID must be able to tell the Packet Driver specifically about any protocols the MLID wants to receive. There is one typical Novell exception: IPX is set up automatically if it is not specified explicitly. Here are some example lines. By the way, if you are using an ODI TCP/IP protocol stack, you will need these protocol lines in your Net.Cfg file to tell PDEther about the IP protocols. Int 60 Frame Ethernet_II Protocol IP 800 Ethernet_II Protocol ARP 806 Ethernet_II Protocol RARP 8035 Ethernet_II Loading a Packet Driver ----------------------- PDEther supports the 1.09 Packet Driver specification. I assume later Packet Driver interface versions will also work. In addition, I have no particular reason to think it wouldn't work on older Packet Driver interfaces, since it uses no features flagged as new in 1.09, but i've only been using 1.09. Release 7 of the Clarkson Packet Drivers support version 1.09 of the spec. These are also the first Packet Drivers which support the "raw" 802.3 IPX framing convention via "-n" switch described below. The details of loading a Packet Driver should be provided with your Packet Driver and are beyond the scope of this document. Generally, you tell the packet driver which software interrupt to use and how to talk to the hardware through parameters on the command line. Standard Packet Drivers take *all* input in decimal by default, although you may specify hex by using the "0x" prefix. This is counter-intuitive, since almost all parameters to any packet driver are numbers which make little or no sense in decimal. Standard Packet Drivers take the software interrupt as the first argument. The software interrupt *must* agree with the INT parameter in the Link Driver PDEther section of the Net.Cfg file. (But again, remember to prefix the packet driver parameter with "0x". The INT parameter in Net.Cfg is always interpreted as a hex number.) If your network uses the popular "Ethernet_802.3" frame type (the illegal Novell "raw" 802.3 framing type) for IPX traffic, give the Packet Driver the "-n" switch to get that framing for IPX traffic. This tells the Standard Packet Drivers to send IPX traffic in the "raw" 802.3 format. The "-n" switch does not affect other protocols. The default IPX protocol ID (8137 hex) *must* be used so the Packet Driver can identify IPX packets. Note that when using the "-n" switch, you continue to specify "Ethernet_II" in the Net.Cfg file; you do *not* indicate the frame type Ethernet_802.3 as you would in a normal ODI Link Driver. The "raw" 802.3 framing is handled by the Packet Driver without PDEther's knowledge. Here's an example of a typical packet driver command line which loads a Packet Driver on software interrupt 60 hex to support an NE2000 ethernet card on hardware interrupt 5, port 340 hex, using normal Ethernet framing. ne2000 0x60 5 0x340 To load the same Packet Driver but have it send IPX packets using Novell's default Ethernet_802.3 framing instead of the more proper Ethernet_II, use a command line like this: ne2000 -n 0x60 5 0x340 Limitations ----------- Packet Driver support for 802.3/802.2 and 802.3/802.2/SNAP is scarce, so this MLID does not support those two framing types. If implemented later, i recommend implementing them as separate MLIDs, *not* as extentions to PDEther. Some of the less important features of the Packet Driver are not supported. For example, it cannot deal with a Packet Driver supporting multiple boards. Each protocol (except IPX) must be explicitly listed in the PDEther's Link Driver section. Although "normal" from the point of view of the Net.Cfg design, it is quite abnormal in practice. Novell's TCPIP for ODI, for example, will automatically add the TCP/IP protocol IDs if they are not present, but THIS DOES *NOT* HELP PDEther which must find them in its section of Net.Cfg. This is unfortunate. Failure to list the protocols in the Net.Cfg file is not a detectable error so all the software will be satisfied, but no arriving packets will be delivered to IP. Bibliography ------------ FTP Software, "PC/TCP Packet Driver Specification", version 1.09, September, 1989. Novell, "Open Data-Link Interface LAN Driver Developer's Guide for DOS", PRELIMINARY, November, 1990. Conclusion ---------- Let me know if you have any problems. don provan donp@novell.com 1/15/91