Description of problem: When you make a VLAN interface on a physical NIC interface, and change the MAC address of the VLAN interface, you cannot receive packets throught the VLAN interface. Version-Release number of selected component (if applicable): The problem occurs with RHEL5.6 kernel-2.6.18-238 with igb-2.1.0-k2-1 inbox NIC driver. The problem does not occur with RHEL5.4 kernel-2.6.18-164 with igb-1.3.16-k2 inbox NIC driver. How reproducible: Make a VLAN interface, and change the MAC address of it, and try to communicate using the interface. You need to configure the LAN switch and the other host correctly to handle tagged 802.1q VLAN packets. Steps to Reproduce: 1. # ifconfig eth0 up 2. # vconfig add eth0 100 3. # ifconfig eth0.100 hw ether 22:22:22:22:22:22 4. # ifconfig eth0.100 192.168.100.10 netmask 255.255.255.0 5. # ping 192.168.100.11 (ping to another host) assuming eth0 as the igb port, and another host has IP address of 192.168.100.11. Actual results: The communication (ping in the above repro steps) fails. Expected results: The communication (ping) should be complete successfuly. Additional info: Capturing packets on the network showed that an ARP request packet (with changed source MAC address) with configured VLAN ID is sent out to network, and an ARP reply packet with the VLAN ID is returned to the NIC. But after that the ping (ICMP echo request) packet is not send out, so the driver and/or networking stack does not receive the ARP reply packet correctly. If you do not change the MAC address of the VLAN interface, the problem does not occur. RHEL5.6 has the problem. RHEL5.4 does not have the problem. RHEL5.5 is not tested.
This bug does not occur on RHEL 6.2, kernel 2.6.32-156.el6.i686 driver: igb version: 3.0.6-k2 firmware-version: 1.5-1 bus-info: 0000:05:00.0
This bug occurs on RHEL 5.7 Beta, [root@dell-pet410-02 ~]# uname -a Linux dell-pet410-02.lab.bos.redhat.com 2.6.18-268.el5PAE #1 SMP Tue Jun 14 18:30:19 EDT 2011 i686 i686 i386 GNU/Linux [root@dell-pet410-02 ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.7 Beta (Tikanga)
Tested on ixgbe,be2net & bnx2 driver, they do **not** have this issue. bnx2x & igb have this issue. Tested on 2.6.18-268.el5.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Patch(es) available in kernel-2.6.18-283.el5 You can download this test kernel (or newer) from http://people.redhat.com/jwilson/el5 Detailed testing feedback is always welcomed.
*** Bug 723765 has been marked as a duplicate of this bug. ***
bnx2x driver tested with kernel-2.6.18-284.el5 - the issue disappeared. thanks.
Hi Jarod, please let us know - 1. What was causing this issue and how did it get fixed 2. Comment #6 suggests that only bnx2x and igb showed this issue. Wanted to understand why is it specific to these drivers and not happening with ixgbe,be2net & bnx2. Hi Dmitry, On bnx2x, could you please share details on what has fixed this issue ?
(In reply to comment #14) > > On bnx2x, could you please share details on what has fixed this issue ? The fix is common to all drivers that call vlan_gro_receive() to process packets with vlan tag. The fix is replacing skb->pkt_type value PACKET_OTHERHOST with PACKET_HOST if destination mac matches vlan device mac address.
For the record, when asking about what a patch does or how to test, you want either the patch submitter (the bug assignee) or the QA contact, not the person who simply commits the patches after they've been vetted.
(In reply to comment #15) > (In reply to comment #14) > > > > On bnx2x, could you please share details on what has fixed this issue ? > > The fix is common to all drivers that call vlan_gro_receive() to process > packets with vlan tag. The fix is replacing skb->pkt_type value > PACKET_OTHERHOST with PACKET_HOST if destination mac matches vlan device mac > address. Hi Dimitry, thank you for sharing the details. Just so that i understand, this fix is in the VLAN core and not in the driver then. This issue has been reported by one of our teams and they saw the issue with bcm57712 device on RHEL 5.5 Hi Weiping, Could you please share the patch on this BZ ?
(In reply to comment #16) > For the record, when asking about what a patch does or how to test, you want > either the patch submitter (the bug assignee) or the QA contact, not the person > who simply commits the patches after they've been vetted. Thanks for pointing out. Sorry, that was by mistake.
(In reply to comment #17) > (In reply to comment #15) > > (In reply to comment #14) > > > > > > On bnx2x, could you please share details on what has fixed this issue ? > > > > The fix is common to all drivers that call vlan_gro_receive() to process > > packets with vlan tag. The fix is replacing skb->pkt_type value > > PACKET_OTHERHOST with PACKET_HOST if destination mac matches vlan device mac > > address. > > Hi Dimitry, thank you for sharing the details. Just so that i understand, this > fix is in the VLAN core and not in the driver then. This issue has been > reported by one of our teams and they saw the issue with bcm57712 device on > RHEL 5.5 > > Hi Weiping, Could you please share the patch on this BZ ? Sure. The cause of this bug is that when eth0 receives a packet, it calls eth_type_trans(), since the MAC of eth0.100 is different from eth0, so skb->pkt_type is set with PACKET_OTHERHOST. As for RHEL5.7, some drivers, like ixgbe, be2net and bnx2, call vlan_hwaccel_do_receive() directly to correct skb->pkt_type, so they do not have this bug. While some other drivers, like bnx2x and igb, call vlan_gro_receive() directly, but vlan_gro_receive() doesn't correct skb->pkt_type, so they have this bug. So I modify vlan_gro_receive() to correct skb->pkt_type, replacing PACKET_OTHERHOST with PACKET_HOST if its destination MAC matches vlan device MAC address, so upper layer will handle this packet normally.
Hi Weiping, thank you for the detailed explanation. I installed the src rpm from comment #11. Please correct me if i am wrong. The fix went to the function '__vlan_hwaccel_rx' which modifies the skb->pkt_type in the else part. So any driver issuing 'vlan_gro_receive' can receive packets. It seems like RHEL 6.1 also has this issue.
(In reply to comment #20) > It seems like RHEL 6.1 also has this issue. In RHEL 6.1 vlan_hwaccel_do_receive should perform this in correct way; Have you tested with RHEL 6.1 kernel?
(In reply to comment #21) > (In reply to comment #20) > > It seems like RHEL 6.1 also has this issue. > In RHEL 6.1 vlan_hwaccel_do_receive should perform this in correct way; > Have you tested with RHEL 6.1 kernel? Hi Dmitry, thanks. I misread the code. You meant ' __vlan_hwaccel_rx' results in a call to '__netif_receive_skb' and 'vlan_hwaccel_do_receive' which corrects the packet type. I have requested the team who reported this issue to test this on RHEL 6.1.
Hi, the testing has confirmed that issue was not seen on RHEL 6.1.
Verified on kernel 2.6.18-284.el5 with bnx2x cards. Set verified.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2012-0150.html