Originally published in the February 1995 issue of Advanced Systems.

PC Networking 101

Our new column takes a detailed look at PC-to-Unix connectivity starting with the hardware and network interface layer.

Take a look out there -- all those pleading eyes, users of personal computers in your organization begging for connectivity beyond their desktop. How can you deny them? They want worldwide e-mail. They want inter-, not just intra-, departmental shared files and workgroups. They want to gain a competitive edge by running custom Unix apps without giving up their Windows systems. They want the enterprise at their fingertips on the desktop -- and the sooner the better. And as the Unix professional, you are uniquely positioned to answer their pleas.

This is the premier of a new Advanced Systems column that will give the Unix professional insights into the place of personal computers in the New Unix Enterprise, as well as technical details to help you create and exploit the Unix-to-PC connection.

Because of the great demand among our readers and the complexity of the subject, we focus on connectivity to PCs in the early columns, leaving connectivity to other kinds of systems for another day. When we talk about PCs, we refer in general to personal computer systems including IBM-compatible Intel-based PCs (especially those running Microsoft Windows), Apple Macintoshes, and PowerPC systems, all running non-Unix, non-NT operating systems. These represent most user's desktops, not soon to be displaced. We're fighting them by joining them, offering the extra power, features, flexibility, and tools available only in advanced 32- and 64-bit operating environments.

We'll also examine the emergent enterprise desktop -- the PC's "advancing" hardware, network, and system software, and enterprise-enabling technologies. These near-future, post-adolescent personal systems' technologies will soon connect your desktops to the world, let alone within your organization.

But first, the basics. We'll lay a solid technical foundation for PC-to-Unix connectivity by taking a detailed look at the technologies and products that can bring enterprisewide applications and data to today's personal desktop. We'll try to talk about PCs in terms Unix professionals can understand.

PC-connectivity basics
Connecting personal systems to Unix involves four main layers: the network interface card, device drivers (principally for Ethernet networking), a TCP/IP stack, and applications.

Current Macintosh and future PowerPC Reference Platform (PReP)-compliant systems use standardized system components and protocols that make all these layers rather easy to implement. The much more prolific IBM-compatible PCs, on the other hand, generally lack plug-and-play networking components (though that's coming soon), so you need to patch together a disparate collection of hardware and software, each complete with its own slew of installation and configuration problems.

Let's start at the very bottom layer, the hardware and network interface.

Unlike our systems, PCs don't come with built-in networking. Instead, a smorgasbord of add-on PC Ethernet hardware network interface cards (NIC) has arisen that works with the variety of PC peripheral-bus architectures. The Etherlink III-series from 3Com and Western Digital's 80x3 family are among the best known for ISA (Industry Standard Architecture, otherwise known as the AT bus, an 8-MHz 8- or 16-bit bus) and EISA (Extended Industry Standard Architecture, which is a 32-bit version). The high-performance PCI (Peripheral Component Interface -- 32 bits and 33 MHz) will soon replace the older buses in most PCs, especially for higher-demand peripherals.

When evaluating interfaces, besides matching the bus type, you also need to notice how -- with hardware switches or with software -- you set the interface's interrupt request (IRQ) number, wire media type (AUI, 10BaseT, coaxial BNC), I/O address, and the base memory address range. Each of these have popular settings and configurations, but you may need to customize them for your current or future systems and network. Before you start modifying your system, you should record the settings you currently have in case you have to undo any changes to the system. There are useful tools that can analyze your system setup and save this description, such as QAPlus by Diagsoft or PC-Tools by Symantec.

Interrupt processing
All devices on ISA- and EISA-based PC systems use interrupts (or IRQs) to gain the PC's undivided attention for their input/output tasks. Some devices require the services of the CPU to process the interrupt. Others have direct-memory access (DMA) and move their information to and from memory without the main processor's involvement. Even with DMA transfers of data, the adapter card still needs to send an interrupt to the PC to call the CPU's attention to the data so applications may be notified.

Some device IRQ number settings are fixed or reserved by convention, such as IRQ 2 or 5 for a mouse and IRQ 5 or 7 for sound cards. An NIC can usually pick and choose from several available IRQs, usually between the numbers 2 and 12. IRQs 3 or 5 are popular for the Etherlink III family; 3, 5, 7, or 9 can be used with the WD-80x3. (Some cards limit you in the IRQ numbers you can select.) Hardware IRQs cannot be shared amongst cards, so you need to find a free IRQ setting. Locating a free IRQ setting is a hit-and-miss process if you have an ISA system. You should look through the CONFIG.SYS (boot-time configuration file) and AUTOEXEC.BAT (boot-time execution) files to see what drivers are loaded and which IRQ settings they reserve for themselves, if any. If you have an IRQ sensing tool (as available with the Etherlink III configuration utility), you can choose different IRQs for your card, and the system will tell you which ones have a conflict.

On some NICs, such as the WD family, you have to manually set the IRQ with jumpers or dip switches; the Etherlink III family (even the ISA-card versions) can be configured by software. EISA-based adapters can be automatically configured with special software utilities, usually provided with the system.

In addition to an IRQ, you also need an I/O address for the card. This is a slice of the memory space of the system that is used as a communications port between the NIC and the system for service routines and signals. There is a commonly used range of addresses for all cards, namely 220h to 380h (hexadecimal). Select one by a jumper or dip switch on the board itself or by using the configuration program supplied with the card. You can check that the I/O address is not already in use with the configuration program; however, if you have to perform a manual setting, then it becomes a hunt through the system unless you have a package like QAPlus.

Finally, you assign a base memory range -- usually 2,000 sections in the range C0000h through DFFFFh -- to the NIC for the temporary storage of data. This area is used constantly to collect the data coming over the wire before it is sent to the memory area of specific network applications. This address range must not be used by any other device or by the system, otherwise your system will intermittently hang. If the PC uses an extended-memory manager, such as Microsoft's EMM386 or Quarterdeck's QEMM, you may also need to tell its driver to exclude this range of addresses from other general use. Extended memory managers are called in the CONFIG.SYS file, and most allow range exclusion with special flags (for example, EMM386 uses the 0x flag, as in -X=C0000-CFFFF). DMA cards also need a direct-memory access channel for data throughput. Most PC Ethernet cards use DMA channel 1 or 2.

Driving on the net
With the hardware card in place, you now need a device driver for the network interface. They come in an assortment of types, including the Microsoft Network Driver Interface Specification (NDIS), the Novell Open Datalink Interface (ODI), and the Packet Driver Specification from 3Com and FTP Software. These network device drivers accomplish similar tasks, but in different ways. Some network programs work with only one type of driver, while others work with any or all driver types. And some network applications come with their own built-in drivers.

The OSI (open systems interconnection) network layer model specifies only one layer for the Datalink portion of the system, which is responsible for accepting data from the Network Layer (i.e., IP packets from the IP layer, or IPX packets from the IPX layer), creating an Ethernet frame containing the data and sending it over the Physical media.

ODI and NDIS drivers have multiple sublayers that fit into this single Datalink layer. The sublayer at the very bottom that talks directly to the NIC is known as the Media Access Control (MAC) layer. This is directly associated with the specific NIC you have on your PC. You may have more than one NIC in a multihosted PC that links to two different Ethernet networks, such as a PC acting as a gateway or a server; each NIC will need its corresponding MAC driver.

Since there may be multiple MAC drivers and multiple NICs, protocol stacks need a method to access individual interfaces and hence the MACs. This is handled by the Protocol Multiplexing sublayer. This sublayer also allows emulation of other driver family types for stacks or applications that require these other types; for example, this allows ODI to emulate NDIS and Packet driver interfaces when necessary.

Next month -- stacks and apps
In coming issues, we will conclude our survey of drivers, then delve further into the wild and woolly world of PC IP with a look at protocol stacks and application layers. Meanwhile, if you have questions or suggestions for topics and issues, don't hesitate to e-mail me at rawn.shah@advanced.com.

About the author
Rawn Shah is a Unix and PC systems consultant with RTD Systems & Networking of Tucson, AZ. He is also author of the PC-Mac TCP/IP & NFS FAQ on the World Wide Web (http://www.rtd.com/pcnfsfaq/faq.html).

[Copyright 1995 Web Publishing Inc.]

If you have problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/asm-02-1995/asm-02-connectivity.html
Last updated: 1 February 1995