hardware address filtering n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Hardware-address filtering PowerPoint Presentation
Download Presentation
Hardware-address filtering

Loading in 2 Seconds...

play fullscreen
1 / 15

Hardware-address filtering - PowerPoint PPT Presentation


  • 82 Views
  • Uploaded on

Hardware-address filtering. How can we send packets to just one node on our ‘anchor’ cluster?. Privacy, please!. Our ‘nic.c’ device-driver transmits all of its packets to every node on the segment -- and it receives every packet sent out by any of the other nodes on that segment!

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

PowerPoint Slideshow about 'Hardware-address filtering' - frisco


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
hardware address filtering

Hardware-address filtering

How can we send packets to just one node on our ‘anchor’ cluster?

privacy please
Privacy, please!
  • Our ‘nic.c’ device-driver transmits all of its packets to every node on the segment -- and it receives every packet sent out by any of the other nodes on that segment!
  • Is this what we really want to happen?

anchor16

anchor01

anchor07

anchor02

anchor06

anchor03

anchor05

anchor04

receive address filtering
Receive-address filtering
  • Nowadays any network interface controller has a “filtering” capability which allows any packet NOT to be received by nodes that the packet’s sender didn’t intend it to go to

Transmit

FIFO

to/from

LAN

Receive

buffer

filtering

engine

Receive

FIFO

Network Interface Controller

Host memory

our new nicf c module
Our new ‘nicf.c’ module
  • This device-driver combines the ‘write()’ and ‘read()’ methods from our character-mode device-driver ‘nic.c’, but it adds an ‘ioctl()’ method that lets applications setup any ethernet-packet’s destination-address, as is illustrated in our companion program (named ‘sendto.cpp’) which finds a node’s hardware-address in our ‘ethers’ database
the sendto algorithm
The ‘sendto’ algorithm
  • Here are the steps which our ‘sendto.cpp’ demo-program performs:

Find the destination’s node-name on the command-line

Search our ‘ethers’ file for a line with that node’s name

Convert that node’s MAC-address from ascii to numeric

Open the ‘/dev/nic’ device-file

Call our driver’s ‘ioctl()’ method to setup packets’ destination

Write our application’s test-message to the ‘/dev/nic’ device-file

Print a message confirming this destination and bytes written

notes on library functions
Notes on library functions
  • Use ‘fopen()’ to open the ‘ethers’ textfile, so you can use the ‘fgets()’ function to read in its contents one-line-at-a-time:

#include <stdio.h> // for fopen(), fgets(), puts()

#include <string.h> // for strstr()

int main( int argc, char *argv[ ] )

{

if ( argc == 1 ) exit(1); // command-line argument is absent

FILE *fd = fopen( “ethers”, “ro” );

if ( fd == NULL ) exit(1); // file not present in current directory

char line[ 80 ];

while ( fgets( line, 80, fd ) ) if ( strstr( line, argv[1] ) puts( line );

/* additional processing goes here */

}

ascii to numeric
‘ascii-to-numeric’
  • Use ‘strstr( string, substring )’ to find line in ‘ethers’ file with name of specified node
  • Use ‘strtol( string, NULL, 16 )’ to convert a hexadecimal digit-string to a numeric value

unsigned char dst[ 6 ]; // storage for 6-byte MAC-address

// loop converts colon-formatted hex-string to array of numbers

for (int i = 0; i < 6; i++) dst[ i ] = strtol( line+3*i, NULL, 16 );

our ioctl function
Our ‘ioctl()’ function
  • Our ‘nicf.c’ driver implements an ‘ioctl()’ service allowing a user-program to setup the network hardware-address that will be used in the destination-field of any packet that the driver’s ‘write()’ function transmits

// open the network interface controller’s device-file

int fp = open( “/dev/nic”, O_RDWR );

if ( fp < 0 ) { perror( “/dev/nic” ); exit(1); }

// setup packet-destination to be used when transmittting

if ( ioctl( fp, 1, dst ) < 0 ) { perror( “ioctl” ); exit(1); }

ID-number for the ioctl-request

driver s ioctl function
Driver’s ‘ioctl()’ function

char mac[ 6 ]; // packet source-address gets filled in by ‘module_init()’

char dst [ 6 ]; // packet destination-address gets filled in by our ‘ioctl()’

int my_ioctl( struct inode *, struct file*, unsigned int cmd, unsigned long address )

{

unsigned char *addr = (unsigned char *)address;

switch ( cmd )

{

case 0: // get the driver’s ethernet-packet destination-address

if ( copy_to_user( addr, dst, 6 ) ) return –EFAULT;

return 0; //SUCCESS

case 1: // set the driver’s ethernet-packet destination-address

if ( copy_from_user( dst, addr, 6 ) ) return –EFAULT;

return 0; //SUCCESS

}

return –EINVAL; // the requested command is not implemented

}

change in init
Change in ‘init()’
  • To prevent reception of Ethernet packets whose destination-address doesn’t match our device’s address, we need to alter the way we program our nic’s RCTL register:

31 26 22 15 8 4 3 2 1 0

0001 0100 0100 0000 1000 0010 00000110

RCTL

(0x0100)

DPF (Discard Pause Frames)

RDMTS (Rx-Desc Min Thresh Size)

FLEXBUF BAM (Broadcast Accept Mode)

SECRC (Strip Ethernet CRC) MPE (Multicast Promiscuous Enable)

UPE (Unicast Promiscuous Enable)

SBP (Store Bad Packets)

EN (Enable receive engine)

is 00 00 00 00 00 00 legal
Is 00:00:00:00:00:00 legal?
  • If you comment out all the lines of code in our ‘sendto.cpp’ application that precede the ‘open()’ statement, then our driver’s ‘dstn[ 6 ]’ array will remain all zeros, and hence packets will be sent with a ‘zero’ destination-address (normally not legal)
  • EXERCISE: Try this out and see if your test-message gets received any nodes
receive filter array
Receive-filter Array

quadword (64-bits)

0x5400

0x5408

0x5410

0x5418

0x5420

0x5428

0x5430

0x5438

1

Filter-address 0

0

Filter-address 1

The NIC’s own unique

hardware-address

gets programmed into

this initial array-entry

during initialization

Other addresses may

be added later by

driver software

Filter-address 2

0

0

Filter-address 3

Filter-address 4

0

0

Filter-address 5

Filter-address 6

0

Filter-address 7

0

‘valid’-bit (1=yes, 0=no)

in class exercise 1
In-class exercise #1
  • Apply your knowledge of the Intel 82573L ‘Receive-filter Array’ to add the quadword 0x8000000000000000 at offset 0x5408 in the NIC’s i/o-memory space
  • Then test your modified ‘sendto.cpp’ code to see if you can ‘receive’ a packet which has ‘zero’ as its destination MAC-address
multicast mac addresses
Multicast MAC-addresses
  • Recall that there is a multicast IP-address (namely 224.0.0.1) which all the systems on a local subnet are expected to listen to
  • The corresponding hardware multicast address would be: 01:00:5E:00:00:01
  • Does our ‘nicf.c’ device-driver allow a nic to ‘hear’ messages sent to this address?
in class exercise 2
In-class exercise #2
  • Add the quadword 0x80000100005E0001 to your nic’s ‘Receive-filter Array’ at offset 0x5410 in its i/o-memory space, and then modify the initialization the ‘dst[ 6 ]’ array in your ‘sendto.cpp’ application, like this:

unsigned char dst[ 6 ] = { 0x01, 0x00, 0x5E, 0x00, 0x00, 0x01 };

  • Is your nic now able to receive a packet sent to this hardware ‘multicast’ address?