Linux Device Drivers

Address Resolution

One of the most compelling issues of Ethernet communication is the association between hardware addresses (the interface’s unique id) and IP numbers. Most protocols have a similar problem, but I’m going to pinpoint only the Ethernet-like case here. I’ll try to offer a complete description of the issue, so I’m going to show three situations: ARP, Ethernet headers without ARP (like plip), and non-Ethernet headers.

Using ARP with Ethernet

The usual way to deal with address resolution is by using ARP, the Address Resolution Protocol. Fortunately, ARP is managed by the kernel, and an Ethernet interface doesn’t need to do anything special to support ARP. As long as dev->addr and dev->addr_len are correctly assigned at open time, the driver doesn’t need to worry about resolving IP numbers to physical addresses; ether_setup assigns the correct device methods to dev->hard_header and dev->rebuild_header.

When a packet is built, the Ethernet header is laid out by dev->hard_header, and it is filled later by dev->rebuild_header, which uses the ARP protocol to map unknown IP numbers to addresses. The driver writer doesn’t need to know the details of this process to build a working driver.

Overriding ARP

Simple point-to-point network interfaces like plip might benefit from using Ethernet headers, while avoiding the overhead of sending ARP packets back and forth. The sample code in snull falls into this class of network devices. snull cannot use ARP because the driver ...