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
14 bytes
ARP
Protocol Header
28 bytes
Data (optional)
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
32 bits
Hardware Type
Hardware
Length
Protocol
Length
Protocol Type
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
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 192.168.1.102
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
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
$ ./arpdemo 192.168.1.102
Using Intel’s ‘e1000e.c’ driver
ARP REQUEST
$
ARP REPLY
no IP-address
192.168.1.102
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