DOC PREVIEW
USF CS 635 - Hardware-address filtering

This preview shows page 1-2-3-4-5 out of 15 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Hardware-address filteringPrivacy, please!Receive address filteringOur new ‘nic.c’ moduleThe ‘sendto’ algorithmNotes on library functions‘ascii-to-numeric’Our ‘ioctl()’ functionDriver’s ‘ioctl()’ functionChange in ‘write()’Change in ‘init()’A change in memory-usageIs 00:00:00:00:00:00 legal?Receive-filter ArrayIn-class exerciseHardware-address filteringHow can we send packets to just one node on our ‘anchor’ cluster?Privacy, please!•Our ‘xmit1000.c’ driver transmits all of its packets to every node on our LAN, and our ‘recv1000.c’ driver receives all of the packets transmitted by any of the nodes!•Is this what we really want to happen?anchor01anchor02anchor03anchor04anchor05anchor06anchor07anchor00Receive 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 toReceivebufferHost memoryTransmitFIFOReceiveFIFONetwork Interface Controllerto/from LANfilteringengineOur new ‘nic.c’ module•This device-driver combines the ‘write()’ and ‘read()’ methods from our ‘xmit1000.c’ and ‘recv1000.c’ modules, 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’ databaseThe ‘sendto’ algorithm•Here are the steps which our ‘sendto.cpp’ demo-program performs:Find the destination’s node-name on the command-lineSearch our ‘ethers’ file for a line with that node’s nameConvert that node’s MAC-address from ascii to numericOpen the ‘/dev/nic’ device-file Call our driver’s ‘ioctl()’ method to setup packets’ destinationWrite our application’s test-message to the ‘dev/nic’ device-filePrint a message confirming the destination and bytes writtenNotes 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); // missing command-line argumentFILE *fd = fopen( “ethers”, “ro” );if ( fd == NULL ) exit(1); // file not found in current directorychar line[ 80 ];while ( fgets( line, 80, fd ) ) if ( strstr( line, argv[1] ) puts( line );/* additional processing goes here */}‘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 valueunsigned char dstn[ 6 ]; // storage for 6-byte MAC-address// loop converts colon-formatted hex-string to array of numbersfor (int i = 0; i < 6; i++) dstn[ i ] = strtol( line+3*i, NULL, 16 );Our ‘ioctl()’ function•Our ‘nic.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, 0, dstn ) < 0 ) { perror( “ioctl” ); exit(1); }Driver’s ‘ioctl()’ functionchar mac[ 6 ]; // packet source-address gets filled in by ‘module_init()’char dstn[ 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 *from = (unsigned char *)address;switch ( cmd ){case 0: // set the driver’s ethernet-packet destination-addressif ( copy_from_user( dstn, from, 6 ) ) return –EFAULT;return 0; //SUCCESSdefault: break;}return –EINVAL; // requested command not implemented}Change in ‘write()’•Our device-driver’s ‘write()’ method needs only a tiny change in order to make use of the user-supplied destination-address:ssize_t my_write( struct file *file, char *buf, size_t len, loff_t *pos ){int tail = ioread32( io + E1000_TDT ); // next tx-ring indexchar *packet = phys_to_virt( txdesc[ tail ].base_addr );// memset( packet+0, 0xFF, 6 ); // broadcast-address (NO!)memcpy( packet+0, dstn, 6 ); // user-supplied MAC-address memcpy( packet+6, mac, 6 ); // source MAC-address (ours!) /* other processing same as before */}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:0000 0100 0000 0000 1000 0000 0000 0110 RCTL(0x0100)31 26 15 4 3 2 1 0 SECRC (Strip Ethernet CRC) BAM (Broadcast Accept Mode) MPE (Multicast Promiscuous Enable) UPE (Unicast Promiscuous Enable) SBP (Store Bad Packets) EN (Enable receive engine)A change in memory-usageRxBuf0RxBuf1RxBuf2RxBuf3RxBuf4RxBuf5RxBuf6RxBuf7TxBufRXDESCTXDESC4 pages of kernel memoryphysaddr descaddr Eight receive-buffers (0x600 bytes each) One ‘shared’ transmit-buffer (0x600 bytes) Eight receive-descriptors (0x80 bytes) Eight transmit-descriptors (0x80 bytes)When we “merged” the code from our two previous device-drivers, we needed to make sure that receive-buffers and transmit-buffers do not overlap, and likewise that the Rx and Tx descriptor-queues occupy distinct regions within the allocated kernel-memory regionIs 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’ destinatin-address (normally not legal)•EXERCISE: Try this out and see if your test-message gets received any nodeReceive-filter ArrayFilter-address 0Filter-address 1Filter-address 2Filter-address 3Filter-address 4Filter-address 5Filter-address 6Filter-address 70x54000x54080x54100x54180x54200x54280x54300x5438 quadword (64-bits)10000000‘valid’-bit (1=yes, 0=no)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…In-class


View Full Document

USF CS 635 - Hardware-address filtering

Download Hardware-address filtering
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Hardware-address filtering and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Hardware-address filtering 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?