ChaOS Diary Jul 2010

ChaOS Home ChaOS Source Notes ChaOS Source Index ChaOS Downloads CTPP Home

Diary to Jun 2010 Diary to Mar 2010 Diary to Dec 2009 Diary to Aug 2009 Diary to Apr 2009 Diary to Nov 2008

ChaOS Diary - monoblog and links to reference documents

Many golden nuggets lie herein. Trademarks are acknowledged as copyright of their respective owners

29/7/2010 Realtek Multicast Programming Tried a few times in the past to understand Ethernet Multicast hashing, but the subject has always beaten me, I never really understood why frame rejection by an imperfect filter could be of much use, until I considered how slow computers were twenty years ago. Neither could I fathom the method used to calculate the correct hash bit from a MAC address. Setting the MAR registers to 0xffffffff causes a network card to receive all multicasts and a software filter achieves the same result, but this week I decided to crack this nut once and for all.

The Multicast bit in an ethernet frame destination address is the first bit placed on the wire by a network transmitter, therefore is the first bit decoded the receivers. So a mechanism exists for rejecting an incoming frame after just ONE BIT. Correct use of the Multicast hash allows a network card to occupy multiple incoming MAC addresses. Though random multicast addresses may hash to the same bit and cause a network interrupt, this can massively reduce the number of receiver interrupts generated for cards attached to a busy wire, and the random frames are easily dropped by software in the next network layer.

Solving the hash bit algorithm was a challenge, as it requires understanding of ethernet crc32 checksums and the way they relate to the local hardware, particularly whether the checksum is accumulated by working the data bits left-to-right or right-to-left. The Multicast hash index may end up in the top or the bottom 6 bits of the crc32. For the RTL network cards 8029/8136/8100 working on Intel architecture which I am currently programming the hash index appears in reverse bit order. Placing the hash bit correctly in one of two 32-bit integers (in preparation for a 32-bit port write) is elegantly performed by:

      mar[hash>>5] |= 1 << (hash&0x1f);

Worthy of note is that The MAR registers on the RTL8100 PCIE card are in reverse order MAR7-MAR0, on the RTL8139 they appear as MAR0-MAR7, just one more trap for the unwary. The bytes are easily reversed by casting to the ChaOS compiler type UM (unsigned 32-bit Motorola integer):

      outpd(port+0x08,mar[0]);                   //for RTL8139
      outpd(port+0x0c,mar[1]);

      outpd(port+0x08,*(UM*)&mar[1]);     //for RTL8100
      outpd(port+0x0c,*(UM*)&mar[0]);

Testing to prove the above was fun, using the ChaOS debugger to edit the live broadcast MAC address of one computer running CTPPNET, whilst running the same MAC address through the hashing algorithm on a second computer running CTPPNET with broadcasts disabled, multicasts enabled. Seeing the frame arrive with only one bit set in MAR0-7 is impressive. Also worthy of note is that Multicast addresses have bit 0 of byte 0 set to 1. The MAC address burned into a network card always has this bit set to zero.