1 / 17

Adjusting out device-driver

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

anja
Télécharger la présentation

Adjusting out device-driver

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related