Intel E1G44ET NICs would drop this kind of "invalid" packet in the promisc mode, because length field in the packet is set to 846 but the packet length on the wire is actually 842.
In addition, Broadcom NICs did not allow the packets either, but raised an error flag that pushed onto the Wireshark, packets #2, 9, ... on the Broadcom capture. Please check the "Expert Info" under "Length", the packet is reported with error message " Length field goes past the end of the payload". I hope that clarified the issue. If desired, we could provide you a patch with slight driver modifications that you could use to fix or verify the issue. Thank you, ~Akeem -----Original Message----- From: CLOSE Dave [mailto:[email protected]] Sent: Monday, June 20, 2011 1:03 PM To: Abodunrin, Akeem G Subject: Re: Filtering of "special" multicast MAC addresses > I would like to help on this issue... > Please send me your tcpdump and lspci log. > > -----Original Message----- > From: CLOSE Dave [mailto:[email protected]] > Sent: Thursday, June 16, 2011 4:45 PM > To: [email protected] > Subject: [E1000-devel] Filtering of "special" multicast MAC addresses > > Intel E1G44ET installed in Dell R410 running Fedora with kernel 2.6.32 > x86_64 and driver igb 3.0.22 built from Intel source code. > > The interface should be receiving multicast Ethernet (not IP) packets > addressed to MAC 01:80:C2:00:00:0F, once per second. When sent to the > motherboard Broadcom NICs, the packets are received. When sent to one > of the Intel ports, the packets do not appear. The ports are working > well otherwise. > > The test conducted is to run tcpdump on each port independently. With > the cable from the sending system connected to an Intel port, observe > that the multicast packets are not seen. Move the cable to a > motherboard port, observe that the packets are seen. The sending > system is not altered or touched during the test. Switch back and > forth as often as desired, the packets only appear when the wire is > attached to a motherboard port. Other traffic appears correctly when > the cable is attached to either port. There is no switch between the > sending system and the system under test. > > Background: This is a valid multicast MAC address. Broadcom switches > use addresses in this range for management and treat such packets in a > non-standard way. However, as a valid packet with a valid address, the > packets should traverse other parts of a network unhindered. > > This smells like a driver configuration issue (most likely) or a > driver bug. However, I have not seen any driver configuration > parameter that seems relevant. Suggestions appreciated. Attached is the output of lspci and two capture logs, one for eth0 and one for eth2. eth0 is a motherboard Broadcom NIC; eth2 is the first port on the Intel E1G44ET. Note packets #2, 9, ... on the Broadcom capture. These are multicast packets addressed to 01:80:c2:00:00:0f. No packets like this appear in the Intel capture. If it would help to discuss this subject by phone, please call the number below. -- Dave Close, Thales Avionics, Irvine California USA cell +1 949 394 2124, [email protected] I don't send HTML email and I prefer not to receive it. HTML email is ugly and a significant security exposure. ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 _______________________________________________ E1000-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
