adjusting out device driver n.
Skip this Video
Loading SlideShow in 5 Seconds..
Adjusting out device-driver PowerPoint Presentation
Download Presentation
Adjusting out device-driver

Loading in 2 Seconds...

play fullscreen
1 / 17

Adjusting out device-driver - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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
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
specific example
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)




Protocol Header

Data (optional)

14 bytes 28 bytes

host s hardware address
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
arp packet header
ARP packet-header

32 bits

Hardware Type

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

host s ip address
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
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
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
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




no IP-address

in class exercise
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