Adjusting out device-driver

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

2. 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

3. Driver’s ‘write()’ method

4. Driver’s ‘read()’ method

5. 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’

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

7. Ethernet Header

8. 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

9. Driver’s ‘fops’

10. Driver’s ‘ioctl()’ method

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

12. ARP Header

13. 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

14. 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 192.168.1.102

15. 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

16. ARP protocol 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. Using our ‘nicraw.c’ driver Using Intel’s ‘e1000e.c’ driver $ ./arpdemo 192.168.1.102 $ ARP REQUEST ARP REPLY no IP-address 192.168.1.102

17. 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