Adjusting out device-driver Here we complete the job of modifying our ‘nicf.c’ Linux driver to support ‘raw’ packet-transfers

Our experiment We set for ourselves the goal of crafting a character-mode Linux device-driver which would allow an unprivileged application to transmit and receive ‘raw’ Ethernet frames For fast development, we proposed to just modify our earlier ‘nicf.c’ device-driver, but abandon its attempt to simulate a ‘stream’ and just support simple datagrams instead

Driver’s ‘write()’ method

Driver’s ‘read()’ method

Specific example We had proposed writing an application (named ‘arpdemo.cpp’) which would send an ARP REQUEST, then try to receive an ARP REPLY We had left it as an exercise for students to implement the necessary modifications in our ‘nicf.c’ device-driver, renaming the resulting device-driver ‘nicraw.c’

ARP packet (Type 0x0806) Ethernet Header ARP Protocol Header Data (optional) 14 bytes 28 bytes

Ethernet Header

Host’s hardware-address If an application is going to send a ‘raw’ Ethernet packet, it will need to supply a source Hardware MAC-Address, which normally an application would not know We can implement an ‘ioctl()’ service in our device-driver which will deliver that piece of information to our application

Driver’s ‘fops’

Driver’s ‘ioctl()’ method

ARP packet-header Hardware TypeProtocol Type Hardware Length Operation (1=request, 2=reply) Sender Hardware Address (upper 4 octets) Sender Protocol Address (LSW) Sender Hardware Address (lower 2 octets) Sender Protocol Address (MSW) Target Hardware Address (lower 4 octets) Protocol Length Target Hardware Address (upper 2 octets) 32 bits For Ethernet: Hardware Type = 0x0001, Hardware Length = 0x06 For Internet: Protocol Type = 0x0800, Protocol Length = 0x04 Target Protocol Address

ARP Header

Host’s IP-address If an application is going to send an ARP Request packet, it will need the sender’s IP-address (as well as its MAC-address) But that piece of information can be found using existing functions which are part of the standard C runtime libraries, so it’s not necessary for our device-driver to deliver (or even to know) its host’s IP-address

Target’s IP-address The IP-address for the target machine to which an ARP Request will be sent would need to be included in the ‘raw’ packet’s fields, but for this item of information we can let our application look for it among command-line arguments, delegating to our human user the job of providing it: $./arpdemo

Testing our results You will need two stations for this testing, both on the same local network segment (i.e., either two classroom stations, or else two anchor-cluster stations) One station will use our ‘nicraw.c’ driver and will execute our ‘arpdemo’ program The other station, using Intel’s driver and normal TCP/IP protocol stack, will reply

ARP protocol $./arpdemo $ Using Intel’s ‘e1000e.c’ driver no IP-address Using our ‘nicraw.c’ driver ARP REQUEST ARP REPLY Our application will ‘write()’ a raw Ethernet packet to the ‘/dev/nic’ device-file, which the Linux kernel will relay to our ‘nicraw.c’ device-driver’s ‘write’ method for the 82573L network interface controller to transmit as a ‘broadcast’ message; this message will be received by the ‘eth1’ interface and relayed to the kernel’s network subsystem on the target machine, which will respond by sending back an ARP Reply which our device driver’s ‘read’ method will receive and deliver to our application’s buffer when it tries to ‘read()’ from the ‘dev/nic’ device-file.

In-class exercise Download the ‘nicraw.c’ driver-module and the ‘arpdemo.cpp’ application and compile them in your local directory Then try performing the proposed test on a pair or classroom or anchor machines: –Install ‘nicraw.ko’ on the machine where you will be running our ‘arpdemo’ application –Use ‘ifconfig’ to assign an IP-address to the other machine’s ‘eth1’ interface