#355 Intel Corporation 82599EB based 10gbe SFP+ card does not see VLANed traffic in promiscuous mode

closed
Emil Tantilov
None
standalone_driver
5
2014-08-25
2012-08-23
Mark Carey
No

The most recent edition of the ixgbe driver is not capturing ethernet frames when put into promiscuous mode if the input traffic is tagged in 802.1q mode.

I have confirmed this by enabling promiscuous mode on the card, watching the counters increment rapidly (this is on a tap port), and then using "tcpdump -s 0 -ni eth6" to view traffic. The traffic that arrives is no the amount or expected type of traffic (only a 1 SNAP ethernet frame every 6 or 10 seconds, while the counters increment at about 1.2 GB/s).

I have created a vlan device using "vconfig add eth6 80" and then a "tcpdump -s 0 -ni eth6.80" and observing a large quantity of traffic of the expected type.

My understanding is that in promiscuous mode, the card should disable the rxvlan filters and simply pass all traffic to the host. If this is the intended behavior, then I suspect that there is a bug present. I've looked over the code in ixgbe_main.c and looked at the register setting methods for the VLAN filter stuff and it appears correct to me, so I'm kicking it up to the masters. I've also confirmed that the vlan registers both show disabled in "ethtool -d eth6", with the below results:

0x05080: FCTRL (Filter Control register) 0x00000400
Broadcast Accept: enabled
Unicast Promiscuous: enabled
Multicast Promiscuous: enabled
Store Bad Packets: disabled
<snip>
0x05088: VLNCTRL (VLAN Control register) 0x40008100
VLAN Mode: disabled
VLAN Filter: disabled

Additionally, here's the "lspci -v" output for the device in question:

08:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01)
Subsystem: Intel Corporation Ethernet Server Adapter X520-2
Flags: bus master, fast devsel, latency 0, IRQ 202
Memory at d9900000 (64-bit, prefetchable) [size=512K]
I/O ports at bcc0 [size=32]
Memory at d98f8000 (64-bit, prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
Capabilities: [70] MSI-X: Enable+ Count=64 Masked-
Capabilities: [a0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 90-e2-xx-xx-xx-xx-xx-xx
Capabilities: [150] Alternative Routing-ID Interpretation (ARI)
Capabilities: [160] Single Root I/O Virtualization (SR-IOV)
Kernel driver in use: ixgbe
Kernel modules: ixgbe

Thanks for all that you do folks, it's a great service, and not an easy job.
-Mark.

Related

Bugs: #355

Discussion

1 2 > >> (Page 1 of 2)
  • Emil Tantilov
    Emil Tantilov
    2012-08-23

    Thanks for the report. Your assumption is correct - the driver disables vlan filtering when in promisc mode. This is also confirmed by the output from ethtool you provided.

    I was not able to reproduce this issue however. I tested with recent net-next branch and also the latest driver from SF - 3.10.16.

    You mention that you see the counters increment, but are not observing the packets in tcpdump is that correct? If so - which counters are incrementing? If you see rx_packets/bytes go up then by all means the adapter is receiving the packets. You can easily test this by enabling/disabling promisc mode:

    1. Enable promisc mode.
    2. Start Tx of vlan packets from secondary system.
    3. Check stats via ethtool -S ethX - rx_packets/bytes should increment.
    4. Disable promisc mode.
    5. Check stats via ethtool -S ethX - rx_packets/bytes should NOT increment.
     
    Last edit: Emil Tantilov 2012-08-23
  • Mark Carey
    Mark Carey
    2012-08-23

    Hi Emil,
    we're running additional tests with the second port and failing that, a second card. I'm suspecting that the hardware enable bit is stuck somewhere below the register on the card in question, which would explain the issue. I'll be back to you with a final set of results shortly.

    The test you describe I've already done (yesterday).

    When promisc is enabled, the counters all increment, when it's disabled, it will not increment.

    I'm strongly suspecting that the card is defective (namely that the harware vlan rx filtering is stuck "on" at some point below the control register). If this is the case, we should pick it up when the new card (known good) install.

    I'll keep you posted. If you would want the card for testing (assuming that we get this working with the second card), I may be able to send it to you for anomaly testing if you think it would be beneficial.

    Thanks,
    -Mark.
    

    On Aug 23, 2012, at 12:17 PM, Emil Tantilov emiltan@users.sf.net wrote:

    Thanks for the report. Your assumption is correct - the driver disables vlan filtering when in promisc mode. This is also confirmed by the output from ethtool you provided.

    I was not able to reproduce this issue however. I tested with recent net-next branch and also the latest driver from SF - 3.10.16.

    You mention that you see the counters increment, but are not observing the packets in tcpdump is that correct? If so - which counters are incrementing? If you see rx_packets/bytes go up then by all means the adapter is receiving the packets. You can easily test this by enabling/disabling promisc mode:

    Enable promisc mode.
    Start Tx of vlan packets from secondary system.
    Check stats via ethtool -S ethX - rx_packets/bytes should increment.
    Disable promisc mode.
    Check stats via ethtool -S ethX - rx_packets/bytes should increment.
    bugs:355 Intel Corporation 82599EB based 10gbe SFP+ card does not see VLANed traffic in promiscuous mode

    Status: open Created: Thu Aug 23, 2012 02:16 AM UTC by Mark Carey Last Updated: Thu Aug 23, 2012 02:16 AM UTC Owner: nobody

    The most recent edition of the ixgbe driver is not capturing ethernet frames when put into promiscuous mode if the input traffic is tagged in 802.1q mode.
    I have confirmed this by enabling promiscuous mode on the card, watching the counters increment rapidly (this is on a tap port), and then using "tcpdump -s 0 -ni eth6" to view traffic. The traffic that arrives is no the amount or expected type of traffic (only a 1 SNAP ethernet frame every 6 or 10 seconds, while the counters increment at about 1.2 GB/s).
    I have created a vlan device using "vconfig add eth6 80" and then a "tcpdump -s 0 -ni eth6.80" and observing a large quantity of traffic of the expected type.
    My understanding is that in promiscuous mode, the card should disable the rxvlan filters and simply pass all traffic to the host. If this is the intended behavior, then I suspect that there is a bug present. I've looked over the code in ixgbe_main.c and looked at the register setting methods for the VLAN filter stuff and it appears correct to me, so I'm kicking it up to the masters. I've also confirmed that the vlan registers both show disabled in "ethtool -d eth6", with the below results:

    0x05080: FCTRL (Filter Control register) 0x00000400
    Broadcast Accept: enabled
    Unicast Promiscuous: enabled
    Multicast Promiscuous: enabled
    Store Bad Packets: disabled

    0x05088: VLNCTRL (VLAN Control register) 0x40008100
    VLAN Mode: disabled
    VLAN Filter: disabled

    Additionally, here's the "lspci -v" output for the device in question:

    08:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01)
    Subsystem: Intel Corporation Ethernet Server Adapter X520-2
    Flags: bus master, fast devsel, latency 0, IRQ 202
    Memory at d9900000 (64-bit, prefetchable) size=512K
    I/O ports at bcc0 size=32
    Memory at d98f8000 (64-bit, prefetchable) size=16K
    Capabilities: 40 Power Management version 3
    Capabilities: 50 MSI: Enable- Count=1/1 Maskable+ 64bit+
    Capabilities: 70 MSI-X: Enable+ Count=64 Masked-
    Capabilities: a0 Express Endpoint, MSI 00
    Capabilities: 100 Advanced Error Reporting
    Capabilities: 140 Device Serial Number 90-e2-xx-xx-xx-xx-xx-xx
    Capabilities: 150 Alternative Routing-ID Interpretation (ARI)
    Capabilities: 160 Single Root I/O Virtualization (SR-IOV)
    Kernel driver in use: ixgbe
    Kernel modules: ixgbe

    Thanks for all that you do folks, it's a great service, and not an easy job.
    -Mark.

    Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/e1000/bugs/355/

    To unsubscribe from further messages, please visit https://sourceforge.net/auth/prefs/

     
  • Mark Carey
    Mark Carey
    2012-08-25

    Hi Emil,
    we've replaced the card with a brand new card and are seeing identical results.

    A bit more detail about the setup may be in order.

    We've got a incoming SFP+ connection that has 802.1q tagged VLAN traffic on it. It's running at a high rate of packet flow and should show a lot of traffic in promiscuous mode. When we set promisc with ifconfig we see the counters increment, but get nothing out of tcpdump. We know the traffic is arriving, but it never gets passed up the stack (with tags). When we set untagged mode (on an identical setup elsewhere) we see all the traffic without issue.

    This is a bit baffling to me, since the driver should be passing traffic up the stack, but is not. Is there a way to setup the VLAN matching array to actually match on all VLANs in hardware, even if the control register is theoretically off? From my limited understanding of the driver and hardware, there is a 4096 x 4 bit array which controls the acceptance of VLAN traffic by the hardware filter. Can we insert a simple for loop to set all of these to on when promisc is enabled in the driver? I realize this is not a production solution, but I am most curious to see if it would resolve the issue and diagnose a sticky VLAN hardware filter register.

    I don't know about you, but this has certainly piqued my curiosity.

    Thanks Emil,
    -Mark.
    

    On Aug 23, 2012, at 4:02 PM, Mark Carey phork42@users.sf.net wrote:

    Hi Emil,
    we're running additional tests with the second port and failing that, a second card. I'm suspecting that the hardware enable bit is stuck somewhere below the register on the card in question, which would explain the issue. I'll be back to you with a final set of results shortly.

    The test you describe I've already done (yesterday).
    When promisc is enabled, the counters all increment, when it's disabled, it will not increment.
    I'm strongly suspecting that the card is defective (namely that the harware vlan rx filtering is stuck "on" at some point below the control register). If this is the case, we should pick it up when the new card (known good) install.
    I'll keep you posted. If you would want the card for testing (assuming that we get this working with the second card), I may be able to send it to you for anomaly testing if you think it would be beneficial.
    Thanks,
    -Mark.
    On Aug 23, 2012, at 12:17 PM, Emil Tantilov emiltan@users.sf.net wrote:

    Thanks for the report. Your assumption is correct - the driver disables vlan filtering when in promisc mode. This is also confirmed by the output from ethtool you provided.

    I was not able to reproduce this issue however. I tested with recent net-next branch and also the latest driver from SF - 3.10.16.

    You mention that you see the counters increment, but are not observing the packets in tcpdump is that correct? If so - which counters are incrementing? If you see rx_packets/bytes go up then by all means the adapter is receiving the packets. You can easily test this by enabling/disabling promisc mode:

    Enable promisc mode.
    Start Tx of vlan packets from secondary system.
    Check stats via ethtool -S ethX - rx_packets/bytes should increment.
    Disable promisc mode.
    Check stats via ethtool -S ethX - rx_packets/bytes should increment.
    bugs:355 Intel Corporation 82599EB based 10gbe SFP+ card does not see VLANed traffic in promiscuous mode

    Status: open Created: Thu Aug 23, 2012 02:16 AM UTC by Mark Carey Last Updated: Thu Aug 23, 2012 02:16 AM UTC Owner: nobody

    The most recent edition of the ixgbe driver is not capturing ethernet frames when put into promiscuous mode if the input traffic is tagged in 802.1q mode.
    I have confirmed this by enabling promiscuous mode on the card, watching the counters increment rapidly (this is on a tap port), and then using "tcpdump -s 0 -ni eth6" to view traffic. The traffic that arrives is no the amount or expected type of traffic (only a 1 SNAP ethernet frame every 6 or 10 seconds, while the counters increment at about 1.2 GB/s).
    I have created a vlan device using "vconfig add eth6 80" and then a "tcpdump -s 0 -ni eth6.80" and observing a large quantity of traffic of the expected type.
    My understanding is that in promiscuous mode, the card should disable the rxvlan filters and simply pass all traffic to the host. If this is the intended behavior, then I suspect that there is a bug present. I've looked over the code in ixgbe_main.c and looked at the register setting methods for the VLAN filter stuff and it appears correct to me, so I'm kicking it up to the masters. I've also confirmed that the vlan registers both show disabled in "ethtool -d eth6", with the below results:

    0x05080: FCTRL (Filter Control register) 0x00000400
    Broadcast Accept: enabled
    Unicast Promiscuous: enabled
    Multicast Promiscuous: enabled
    Store Bad Packets: disabled

    0x05088: VLNCTRL (VLAN Control register) 0x40008100
    VLAN Mode: disabled
    VLAN Filter: disabled

    Additionally, here's the "lspci -v" output for the device in question:

    08:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01)
    Subsystem: Intel Corporation Ethernet Server Adapter X520-2
    Flags: bus master, fast devsel, latency 0, IRQ 202
    Memory at d9900000 (64-bit, prefetchable) size=512K
    I/O ports at bcc0 size=32
    Memory at d98f8000 (64-bit, prefetchable) size=16K
    Capabilities: 40 Power Management version 3
    Capabilities: 50 MSI: Enable- Count=1/1 Maskable+ 64bit+
    Capabilities: 70 MSI-X: Enable+ Count=64 Masked-
    Capabilities: a0 Express Endpoint, MSI 00
    Capabilities: 100 Advanced Error Reporting
    Capabilities: 140 Device Serial Number 90-e2-xx-xx-xx-xx-xx-xx
    Capabilities: 150 Alternative Routing-ID Interpretation (ARI)
    Capabilities: 160 Single Root I/O Virtualization (SR-IOV)
    Kernel driver in use: ixgbe
    Kernel modules: ixgbe

    Thanks for all that you do folks, it's a great service, and not an easy job.
    -Mark.

    Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/e1000/bugs/355/

    To unsubscribe from further messages, please visit https://sourceforge.net/auth/prefs/

    bugs:355 Intel Corporation 82599EB based 10gbe SFP+ card does not see VLANed traffic in promiscuous mode

    Status: open Created: Thu Aug 23, 2012 02:16 AM UTC by Mark Carey Last Updated: Thu Aug 23, 2012 06:17 PM UTC Owner: nobody

    The most recent edition of the ixgbe driver is not capturing ethernet frames when put into promiscuous mode if the input traffic is tagged in 802.1q mode.
    I have confirmed this by enabling promiscuous mode on the card, watching the counters increment rapidly (this is on a tap port), and then using "tcpdump -s 0 -ni eth6" to view traffic. The traffic that arrives is no the amount or expected type of traffic (only a 1 SNAP ethernet frame every 6 or 10 seconds, while the counters increment at about 1.2 GB/s).
    I have created a vlan device using "vconfig add eth6 80" and then a "tcpdump -s 0 -ni eth6.80" and observing a large quantity of traffic of the expected type.
    My understanding is that in promiscuous mode, the card should disable the rxvlan filters and simply pass all traffic to the host. If this is the intended behavior, then I suspect that there is a bug present. I've looked over the code in ixgbe_main.c and looked at the register setting methods for the VLAN filter stuff and it appears correct to me, so I'm kicking it up to the masters. I've also confirmed that the vlan registers both show disabled in "ethtool -d eth6", with the below results:

    0x05080: FCTRL (Filter Control register) 0x00000400
    Broadcast Accept: enabled
    Unicast Promiscuous: enabled
    Multicast Promiscuous: enabled
    Store Bad Packets: disabled

    0x05088: VLNCTRL (VLAN Control register) 0x40008100
    VLAN Mode: disabled
    VLAN Filter: disabled

    Additionally, here's the "lspci -v" output for the device in question:

    08:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01)
    Subsystem: Intel Corporation Ethernet Server Adapter X520-2
    Flags: bus master, fast devsel, latency 0, IRQ 202
    Memory at d9900000 (64-bit, prefetchable) size=512K
    I/O ports at bcc0 size=32
    Memory at d98f8000 (64-bit, prefetchable) size=16K
    Capabilities: 40 Power Management version 3
    Capabilities: 50 MSI: Enable- Count=1/1 Maskable+ 64bit+
    Capabilities: 70 MSI-X: Enable+ Count=64 Masked-
    Capabilities: a0 Express Endpoint, MSI 00
    Capabilities: 100 Advanced Error Reporting
    Capabilities: 140 Device Serial Number 90-e2-xx-xx-xx-xx-xx-xx
    Capabilities: 150 Alternative Routing-ID Interpretation (ARI)
    Capabilities: 160 Single Root I/O Virtualization (SR-IOV)
    Kernel driver in use: ixgbe
    Kernel modules: ixgbe

    Thanks for all that you do folks, it's a great service, and not an easy job.
    -Mark.

    Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/e1000/bugs/355/

    To unsubscribe from further messages, please visit https://sourceforge.net/auth/prefs/

     
    • Emil Tantilov
      Emil Tantilov
      2012-08-27

      Mark,

      The driver does not drop packets. If you are seeing the counters increment - meaning the HW is receiving the traffic - perhaps you should look at other aspects of your setup. Do you have a firewall running (iptables -L)?

      Since I am not able to reproduce the issue you are describing and the register settings you provided are correct, I will need more information about your setup, such as link partner, type of traffic etc.

      Forcing the vlan filters is not a bad idea. You need to set the VFTA register. If you have not done so already - I would encourage you to look at the 82599 datasheet. You can download it from this location:
      http://www.intel.com/products/ethernet/resource.htm#s1=all&s2=all&s3=Datasheet

      Select "10GB Ethernet" -> "82599EB/ES" -> "Datasheet"

      Section 7.0 contains a lot of the information you are looking for including a detailed diagram about the path of the packets on Rx and the various checks related to vlans.

       
  • Mark Carey
    Mark Carey
    2012-08-27

    Hi Emil,
    I've made a patch to the driver which enabled untagged reception across all VLANs on the 10 Gbit card. I'm not sure this is desirable in all cases, and that it's what the driver design intends when in promiscuous mode, but I figured you'd want to see it anyway.

    If this is a valid way to do things, please let me know, and if not, also, please let me know.

    Thanks again for all your help Emil,
    -Mark.

    Source snippet from ixgbe_main.c follows:

    --------------8<--------------
    void ixgbe_set_rx_mode(struct net_device netdev)
    {
    struct ixgbe_adapter
    adapter = netdev_priv(netdev);
    struct ixgbe_hw *hw = &adapter->hw;
    u32 fctrl, vmolr = IXGBE_VMOLR_BAM | IXGBE_VMOLR_AUPE;
    u32 vlnctrl;
    int count;

        /* Check for Promiscuous and All Multicast modes */
        fctrl = IXGBE_READ_REG(hw, IXGBE_FCTRL);
        vlnctrl = IXGBE_READ_REG(hw, IXGBE_VLNCTRL);
    
        /* set all bits that we expect to always be set */
        fctrl |= IXGBE_FCTRL_BAM;
        fctrl |= IXGBE_FCTRL_DPF; /* discard pause frames when FC enabled */
        fctrl |= IXGBE_FCTRL_PMCF;
    
        /* clear the bits we are changing the status of */
        fctrl &= ~(IXGBE_FCTRL_UPE | IXGBE_FCTRL_MPE);
        vlnctrl  &= ~(IXGBE_VLNCTRL_VFE | IXGBE_VLNCTRL_CFIEN);
    
        if (netdev->flags & IFF_PROMISC) {
                u16 vid;
                u32 newfeatures = 0;
                u32 i = 0;
    
                hw->addr_ctrl.user_set_promisc = true;
                fctrl |= (IXGBE_FCTRL_UPE | IXGBE_FCTRL_MPE);
                vmolr |= IXGBE_VMOLR_MPE;
    
                // There be much hackery here.
                // We are enabling ALL VLANs in the hardware filter here in order to work arround
                // what appears to be some form of firmware bug that does NOT enabled reception of
                // tagged frames in promisc mode. -Mark.
                for (vid = 0; vid < VLAN_N_VID; vid++) {
                        ixgbe_vlan_rx_add_vid(netdev, vid);
                }
        // Disable hardware vlan assists.
                for (i = 0; i < adapter->num_rx_queues; i++) {
                        u8 reg_idx = adapter->rx_ring[i]->reg_idx;
                        vlnctrl = IXGBE_READ_REG(hw, IXGBE_RXDCTL(reg_idx));
                        vlnctrl &= ~IXGBE_RXDCTL_VME;
                        IXGBE_WRITE_REG(hw, IXGBE_RXDCTL(reg_idx), vlnctrl);
                }
                printk("ixgbe: ixgbe_set_rx_mode: promiscuous mode enable without vlan tags complete.\n");
    
        } else {
                if (netdev->flags & IFF_ALLMULTI) {
                        fctrl |= IXGBE_FCTRL_MPE;
                        vmolr |= IXGBE_VMOLR_MPE;
                } else {
    

    --------------8<--------------

    On Aug 25, 2012, at 1:01 PM, Mark Carey phork42@users.sf.net wrote:

    Hi Emil,
    we've replaced the card with a brand new card and are seeing identical results.

    A bit more detail about the setup may be in order.

    We've got a incoming SFP+ connection that has 802.1q tagged VLAN traffic on it. It's running at a high rate of packet flow and should show a lot of traffic in promiscuous mode. When we set promisc with ifconfig we see the counters increment, but get nothing out of tcpdump. We know the traffic is arriving, but it never gets passed up the stack (with tags). When we set untagged mode (on an identical setup elsewhere) we see all the traffic without issue.
    This is a bit baffling to me, since the driver should be passing traffic up the stack, but is not. Is there a way to setup the VLAN matching array to actually match on all VLANs in hardware, even if the control register is theoretically off? From my limited understanding of the driver and hardware, there is a 4096 x 4 bit array which controls the acceptance of VLAN traffic by the hardware filter. Can we insert a simple for loop to set all of these to on when promisc is enabled in the driver? I realize this is not a production solution, but I am most curious to see if it would resolve the issue and diagnose a sticky VLAN hardware filter register.
    I don't know about you, but this has certainly piqued my curiosity.

    Thanks Emil,
    -Mark.
    On Aug 23, 2012, at 4:02 PM, Mark Carey phork42@users.sf.net wrote:

    Hi Emil,
    we're running additional tests with the second port and failing that, a second card. I'm suspecting that the hardware enable bit is stuck somewhere below the register on the card in question, which would explain the issue. I'll be back to you with a final set of results shortly.

    The test you describe I've already done (yesterday).
    When promisc is enabled, the counters all increment, when it's disabled, it will not increment.
    I'm strongly suspecting that the card is defective (namely that the harware vlan rx filtering is stuck "on" at some point below the control register). If this is the case, we should pick it up when the new card (known good) install.
    I'll keep you posted. If you would want the card for testing (assuming that we get this working with the second card), I may be able to send it to you for anomaly testing if you think it would be beneficial.
    Thanks,
    -Mark.
    On Aug 23, 2012, at 12:17 PM, Emil Tantilov emiltan@users.sf.net wrote:

    Thanks for the report. Your assumption is correct - the driver disables vlan filtering when in promisc mode. This is also confirmed by the output from ethtool you provided.

    I was not able to reproduce this issue however. I tested with recent net-next branch and also the latest driver from SF - 3.10.16.

    You mention that you see the counters increment, but are not observing the packets in tcpdump is that correct? If so - which counters are incrementing? If you see rx_packets/bytes go up then by all means the adapter is receiving the packets. You can easily test this by enabling/disabling promisc mode:

    Enable promisc mode.
    Start Tx of vlan packets from secondary system.
    Check stats via ethtool -S ethX - rx_packets/bytes should increment.
    Disable promisc mode.
    Check stats via ethtool -S ethX - rx_packets/bytes should increment.
    bugs:355 Intel Corporation 82599EB based 10gbe SFP+ card does not see VLANed traffic in promiscuous mode

    Status: open Created: Thu Aug 23, 2012 02:16 AM UTC by Mark Carey Last Updated: Thu Aug 23, 2012 02:16 AM UTC Owner: nobody

    The most recent edition of the ixgbe driver is not capturing ethernet frames when put into promiscuous mode if the input traffic is tagged in 802.1q mode.
    I have confirmed this by enabling promiscuous mode on the card, watching the counters increment rapidly (this is on a tap port), and then using "tcpdump -s 0 -ni eth6" to view traffic. The traffic that arrives is no the amount or expected type of traffic (only a 1 SNAP ethernet frame every 6 or 10 seconds, while the counters increment at about 1.2 GB/s).
    I have created a vlan device using "vconfig add eth6 80" and then a "tcpdump -s 0 -ni eth6.80" and observing a large quantity of traffic of the expected type.
    My understanding is that in promiscuous mode, the card should disable the rxvlan filters and simply pass all traffic to the host. If this is the intended behavior, then I suspect that there is a bug present. I've looked over the code in ixgbe_main.c and looked at the register setting methods for the VLAN filter stuff and it appears correct to me, so I'm kicking it up to the masters. I've also confirmed that the vlan registers both show disabled in "ethtool -d eth6", with the below results:

    0x05080: FCTRL (Filter Control register) 0x00000400
    Broadcast Accept: enabled
    Unicast Promiscuous: enabled
    Multicast Promiscuous: enabled
    Store Bad Packets: disabled

    0x05088: VLNCTRL (VLAN Control register) 0x40008100
    VLAN Mode: disabled
    VLAN Filter: disabled

    Additionally, here's the "lspci -v" output for the device in question:

    08:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01)
    Subsystem: Intel Corporation Ethernet Server Adapter X520-2
    Flags: bus master, fast devsel, latency 0, IRQ 202
    Memory at d9900000 (64-bit, prefetchable) size=512K
    I/O ports at bcc0 size=32
    Memory at d98f8000 (64-bit, prefetchable) size=16K
    Capabilities: 40 Power Management version 3
    Capabilities: 50 MSI: Enable- Count=1/1 Maskable+ 64bit+
    Capabilities: 70 MSI-X: Enable+ Count=64 Masked-
    Capabilities: a0 Express Endpoint, MSI 00
    Capabilities: 100 Advanced Error Reporting
    Capabilities: 140 Device Serial Number 90-e2-xx-xx-xx-xx-xx-xx
    Capabilities: 150 Alternative Routing-ID Interpretation (ARI)
    Capabilities: 160 Single Root I/O Virtualization (SR-IOV)
    Kernel driver in use: ixgbe
    Kernel modules: ixgbe

    Thanks for all that you do folks, it's a great service, and not an easy job.
    -Mark.

    Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/e1000/bugs/355/

    To unsubscribe from further messages, please visit https://sourceforge.net/auth/prefs/

    bugs:355 Intel Corporation 82599EB based 10gbe SFP+ card does not see VLANed traffic in promiscuous mode

    Status: open Created: Thu Aug 23, 2012 02:16 AM UTC by Mark Carey Last Updated: Thu Aug 23, 2012 06:17 PM UTC Owner: nobody

    The most recent edition of the ixgbe driver is not capturing ethernet frames when put into promiscuous mode if the input traffic is tagged in 802.1q mode.
    I have confirmed this by enabling promiscuous mode on the card, watching the counters increment rapidly (this is on a tap port), and then using "tcpdump -s 0 -ni eth6" to view traffic. The traffic that arrives is no the amount or expected type of traffic (only a 1 SNAP ethernet frame every 6 or 10 seconds, while the counters increment at about 1.2 GB/s).
    I have created a vlan device using "vconfig add eth6 80" and then a "tcpdump -s 0 -ni eth6.80" and observing a large quantity of traffic of the expected type.
    My understanding is that in promiscuous mode, the card should disable the rxvlan filters and simply pass all traffic to the host. If this is the intended behavior, then I suspect that there is a bug present. I've looked over the code in ixgbe_main.c and looked at the register setting methods for the VLAN filter stuff and it appears correct to me, so I'm kicking it up to the masters. I've also confirmed that the vlan registers both show disabled in "ethtool -d eth6", with the below results:

    0x05080: FCTRL (Filter Control register) 0x00000400
    Broadcast Accept: enabled
    Unicast Promiscuous: enabled
    Multicast Promiscuous: enabled
    Store Bad Packets: disabled

    0x05088: VLNCTRL (VLAN Control register) 0x40008100
    VLAN Mode: disabled
    VLAN Filter: disabled

    Additionally, here's the "lspci -v" output for the device in question:

    08:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01)
    Subsystem: Intel Corporation Ethernet Server Adapter X520-2
    Flags: bus master, fast devsel, latency 0, IRQ 202
    Memory at d9900000 (64-bit, prefetchable) size=512K
    I/O ports at bcc0 size=32
    Memory at d98f8000 (64-bit, prefetchable) size=16K
    Capabilities: 40 Power Management version 3
    Capabilities: 50 MSI: Enable- Count=1/1 Maskable+ 64bit+
    Capabilities: 70 MSI-X: Enable+ Count=64 Masked-
    Capabilities: a0 Express Endpoint, MSI 00
    Capabilities: 100 Advanced Error Reporting
    Capabilities: 140 Device Serial Number 90-e2-xx-xx-xx-xx-xx-xx
    Capabilities: 150 Alternative Routing-ID Interpretation (ARI)
    Capabilities: 160 Single Root I/O Virtualization (SR-IOV)
    Kernel driver in use: ixgbe
    Kernel modules: ixgbe

    Thanks for all that you do folks, it's a great service, and not an easy job.
    -Mark.

    Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/e1000/bugs/355/

    To unsubscribe from further messages, please visit https://sourceforge.net/auth/prefs/

    bugs:355 Intel Corporation 82599EB based 10gbe SFP+ card does not see VLANed traffic in promiscuous mode

    Status: open Created: Thu Aug 23, 2012 02:16 AM UTC by Mark Carey Last Updated: Thu Aug 23, 2012 06:17 PM UTC Owner: nobody

    The most recent edition of the ixgbe driver is not capturing ethernet frames when put into promiscuous mode if the input traffic is tagged in 802.1q mode.
    I have confirmed this by enabling promiscuous mode on the card, watching the counters increment rapidly (this is on a tap port), and then using "tcpdump -s 0 -ni eth6" to view traffic. The traffic that arrives is no the amount or expected type of traffic (only a 1 SNAP ethernet frame every 6 or 10 seconds, while the counters increment at about 1.2 GB/s).
    I have created a vlan device using "vconfig add eth6 80" and then a "tcpdump -s 0 -ni eth6.80" and observing a large quantity of traffic of the expected type.
    My understanding is that in promiscuous mode, the card should disable the rxvlan filters and simply pass all traffic to the host. If this is the intended behavior, then I suspect that there is a bug present. I've looked over the code in ixgbe_main.c and looked at the register setting methods for the VLAN filter stuff and it appears correct to me, so I'm kicking it up to the masters. I've also confirmed that the vlan registers both show disabled in "ethtool -d eth6", with the below results:

    0x05080: FCTRL (Filter Control register) 0x00000400
    Broadcast Accept: enabled
    Unicast Promiscuous: enabled
    Multicast Promiscuous: enabled
    Store Bad Packets: disabled

    0x05088: VLNCTRL (VLAN Control register) 0x40008100
    VLAN Mode: disabled
    VLAN Filter: disabled

    Additionally, here's the "lspci -v" output for the device in question:

    08:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01)
    Subsystem: Intel Corporation Ethernet Server Adapter X520-2
    Flags: bus master, fast devsel, latency 0, IRQ 202
    Memory at d9900000 (64-bit, prefetchable) size=512K
    I/O ports at bcc0 size=32
    Memory at d98f8000 (64-bit, prefetchable) size=16K
    Capabilities: 40 Power Management version 3
    Capabilities: 50 MSI: Enable- Count=1/1 Maskable+ 64bit+
    Capabilities: 70 MSI-X: Enable+ Count=64 Masked-
    Capabilities: a0 Express Endpoint, MSI 00
    Capabilities: 100 Advanced Error Reporting
    Capabilities: 140 Device Serial Number 90-e2-xx-xx-xx-xx-xx-xx
    Capabilities: 150 Alternative Routing-ID Interpretation (ARI)
    Capabilities: 160 Single Root I/O Virtualization (SR-IOV)
    Kernel driver in use: ixgbe
    Kernel modules: ixgbe

    Thanks for all that you do folks, it's a great service, and not an easy job.
    -Mark.

    Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/e1000/bugs/355/

    To unsubscribe from further messages, please visit https://sourceforge.net/auth/prefs/

     
    • Emil Tantilov
      Emil Tantilov
      2012-08-27

      The patch looks OK. You can replace the second section with:
      ixgbe_vlan_stripping_disable(adapter);

      Or just use ethtool -K ethX rxvlan on/off instead.

       
  • Bryan Tong
    Bryan Tong
    2013-04-03

    Here is a proper patch based off the above.

    I tried subbing the stripping_disable but I couldnt get it working.

    I had to apply the same patch to get it working. Maybe we can find a more correct way to handle this? The ethtool command just disabled the offloading not the filter which is the problem.

    root@a118:/usr/src/ixgbe-3.14.5/src# cat ixgbe_main.c.patch
    --- ixgbe_main.c.orig   2013-04-02 20:57:18.482334300 -0700
    +++ ixgbe_main.c        2013-04-02 21:15:33.930334269 -0700
    @@ -4623,9 +4623,30 @@
            vlnctrl  &= ~(IXGBE_VLNCTRL_VFE | IXGBE_VLNCTRL_CFIEN);
    
            if (netdev->flags & IFF_PROMISC) {
    -               hw->addr_ctrl.user_set_promisc = true;
    -               fctrl |= (IXGBE_FCTRL_UPE | IXGBE_FCTRL_MPE);
    -               vmolr |= IXGBE_VMOLR_MPE;
    +           u16 vid;
    +           u32 newfeatures = 0;
    +           u32 i = 0;
    +
    +           hw->addr_ctrl.user_set_promisc = true;
    +           fctrl |= (IXGBE_FCTRL_UPE | IXGBE_FCTRL_MPE);
    +           vmolr |= IXGBE_VMOLR_MPE;
    +
    +           // There be much hackery here.
    +           // We are enabling ALL VLANs in the hardware filter here in order to work arround
    +           // what appears to be some form of firmware bug that does NOT enabled reception of
    +           // tagged frames in promisc mode. -Mark.
    +           for (vid = 0; vid < VLAN_N_VID; vid++) {
    +                   ixgbe_vlan_rx_add_vid(netdev, vid);
    +           }
    +            // Disable hardware vlan assists.
    +           for (i = 0; i < adapter->num_rx_queues; i++) {
    +                   u8 reg_idx = adapter->rx_ring[i]->reg_idx;
    +                   vlnctrl = IXGBE_READ_REG(hw, IXGBE_RXDCTL(reg_idx));
    +                   vlnctrl &= ~IXGBE_RXDCTL_VME;
    +                   IXGBE_WRITE_REG(hw, IXGBE_RXDCTL(reg_idx), vlnctrl);
    +           }
    +           printk("ixgbe: ixgbe_set_rx_mode: promiscuous mode enable without vlan tags complete.\n");
    +
            } else {
                    if (netdev->flags & IFF_ALLMULTI) {
                            fctrl |= IXGBE_FCTRL_MPE;
    

    Just a little bit more information.

    I applied this patch against 3.14.5

    When I tried the stripp_disable method I got the following.

    [91552.898180] ixgbe: Unknown symbol ixgbe_vlan_stripping_disable

    So maybe we can clean this patch up a bit with some help or add some kind of mod opt and make it official.

    The only other solution I have found is downgrading the driver which is not desirable.

    Thanks

     
    Last edit: Bryan Tong 2013-04-03
  • Emil Tantilov
    Emil Tantilov
    2013-04-03

    Hi Bryan,
    The issue described in this bug I was never able to reproduce in our lab. That is I can see vlan packets coming in without issues when the interface is in promisc mode. If you are seeing a problem please describe your setup and provide steps to reproduce it. Based on the info Mark provided the HW is setup correcly and since we were not able to reproduce it we cannot make changes to the driver for an issue that we are not seeing, nor do we have a root cause for it.

    If there was an older driver that worked for you can you trace it down to the version that first introduced the issue for you?

     
  • Todd Fujinaka
    Todd Fujinaka
    2013-07-09

    • status: open --> closed
     
  • Todd Fujinaka
    Todd Fujinaka
    2013-07-09

    Closing due to inactivity.

     
  • Bryan Tong
    Bryan Tong
    2013-07-09

    I can supply logins to the box in question off list and you can try different driver versions.

    It could be a Motherboard / Card combo causing this.

    Sorry I did not see the notifications sooner.

    Thanks!

     
    Last edit: Bryan Tong 2013-07-09
  • Todd Fujinaka
    Todd Fujinaka
    2013-07-09

    • status: closed --> open
     
  • Todd Fujinaka
    Todd Fujinaka
    2013-07-09

    It looks like no one has replied to this for a whole year. Have you tried different drivers to make sure you're seeing the same behavior?

     
  • Bryan Tong
    Bryan Tong
    2013-07-09

    Been about 3 months it seems to me :p.

    Anyhow trying the latest driver now.

    Ill get back with the results.

     
  • Bryan Tong
    Bryan Tong
    2013-07-10

    Just tried with 3.16.1 and the same issue appears.

    The traffic coming to the card is tagged in vlans there is no direct traffic as this is purely for sniffing.

    root@a118:~# tcpdump -i eth3 -nvv vlan and ip
    tcpdump: listening on eth3, link-type EN10MB (Ethernet), capture size 65535 bytes
    

    Nothing shows up but I see about 460Mbps of traffic in dstat.

    I am going to try patching the 3.16.1 driver and see what I get.

    Ill get back.

     
  • Greg Rose
    Greg Rose
    2013-07-10

    I've just replied to this. Not sure if the reply is getting relayed though.

    • Greg

    From: Bryan Tong [mailto:nullivex@users.sf.net]
    Sent: Tuesday, July 09, 2013 4:53 PM
    To: [e1000:bugs]
    Subject: [e1000:bugs] #355 Intel Corporation 82599EB based 10gbe SFP+ card does not see VLANed traffic in promiscuous mode

    Been about 3 months it seems to me :p.

    Anyhow trying the latest driver now.

    Ill get back with the results.


    [bugs:#355]http://sourceforge.net/p/e1000/bugs/355/ Intel Corporation 82599EB based 10gbe SFP+ card does not see VLANed traffic in promiscuous mode

    Status: open
    Created: Thu Aug 23, 2012 02:16 AM UTC by Mark Carey
    Last Updated: Tue Jul 09, 2013 11:37 PM UTC
    Owner: nobody

    The most recent edition of the ixgbe driver is not capturing ethernet frames when put into promiscuous mode if the input traffic is tagged in 802.1q mode.

    I have confirmed this by enabling promiscuous mode on the card, watching the counters increment rapidly (this is on a tap port), and then using "tcpdump -s 0 -ni eth6" to view traffic. The traffic that arrives is no the amount or expected type of traffic (only a 1 SNAP ethernet frame every 6 or 10 seconds, while the counters increment at about 1.2 GB/s).

    I have created a vlan device using "vconfig add eth6 80" and then a "tcpdump -s 0 -ni eth6.80" and observing a large quantity of traffic of the expected type.

    My understanding is that in promiscuous mode, the card should disable the rxvlan filters and simply pass all traffic to the host. If this is the intended behavior, then I suspect that there is a bug present. I've looked over the code in ixgbe_main.c and looked at the register setting methods for the VLAN filter stuff and it appears correct to me, so I'm kicking it up to the masters. I've also confirmed that the vlan registers both show disabled in "ethtool -d eth6", with the below results:

    0x05080: FCTRL (Filter Control register) 0x00000400
    Broadcast Accept: enabled
    Unicast Promiscuous: enabled
    Multicast Promiscuous: enabled
    Store Bad Packets: disabled

    0x05088: VLNCTRL (VLAN Control register) 0x40008100
    VLAN Mode: disabled
    VLAN Filter: disabled

    Additionally, here's the "lspci -v" output for the device in question:

    08:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01)
    Subsystem: Intel Corporation Ethernet Server Adapter X520-2
    Flags: bus master, fast devsel, latency 0, IRQ 202
    Memory at d9900000 (64-bit, prefetchable) [size=512K]
    I/O ports at bcc0 [size=32]
    Memory at d98f8000 (64-bit, prefetchable) [size=16K]
    Capabilities: [40] Power Management version 3
    Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
    Capabilities: [70] MSI-X: Enable+ Count=64 Masked-
    Capabilities: [a0] Express Endpoint, MSI 00
    Capabilities: [100] Advanced Error Reporting
    Capabilities: [140] Device Serial Number 90-e2-xx-xx-xx-xx-xx-xx
    Capabilities: [150] Alternative Routing-ID Interpretation (ARI)
    Capabilities: [160] Single Root I/O Virtualization (SR-IOV)
    Kernel driver in use: ixgbe
    Kernel modules: ixgbe

    Thanks for all that you do folks, it's a great service, and not an easy job.
    -Mark.


    Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/e1000/bugs/355/

    To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

     

    Related

    Bugs: #355

  • Greg Rose
    Greg Rose
    2013-07-10

    "My understanding is that in promiscuous mode, the card should disable the rxvlan filters and simply pass all traffic to the host."

    Only if you're not running with SR-IOV enabled. If you have SR-IOV enabled with virtual functions then the rxvlan filters are left enabled to prevent an exploit.

    • Greg

    From: Bryan Tong [mailto:nullivex@users.sf.net]
    Sent: Tuesday, July 09, 2013 4:35 PM
    To: [e1000:bugs]
    Subject: [e1000:bugs] #355 Intel Corporation 82599EB based 10gbe SFP+ card does not see VLANed traffic in promiscuous mode

    I can supply logins to the box in question off list and you can try different driver versions.

    I could be a Motherboard / Card combo causing this.

    Sorry I did not see the notifications sooner.

    Thanks!


    [bugs:#355]http://sourceforge.net/p/e1000/bugs/355/ Intel Corporation 82599EB based 10gbe SFP+ card does not see VLANed traffic in promiscuous mode

    Status: closed
    Created: Thu Aug 23, 2012 02:16 AM UTC by Mark Carey
    Last Updated: Tue Jul 09, 2013 11:07 PM UTC
    Owner: nobody

    The most recent edition of the ixgbe driver is not capturing ethernet frames when put into promiscuous mode if the input traffic is tagged in 802.1q mode.

    I have confirmed this by enabling promiscuous mode on the card, watching the counters increment rapidly (this is on a tap port), and then using "tcpdump -s 0 -ni eth6" to view traffic. The traffic that arrives is no the amount or expected type of traffic (only a 1 SNAP ethernet frame every 6 or 10 seconds, while the counters increment at about 1.2 GB/s).

    I have created a vlan device using "vconfig add eth6 80" and then a "tcpdump -s 0 -ni eth6.80" and observing a large quantity of traffic of the expected type.

    My understanding is that in promiscuous mode, the card should disable the rxvlan filters and simply pass all traffic to the host. If this is the intended behavior, then I suspect that there is a bug present. I've looked over the code in ixgbe_main.c and looked at the register setting methods for the VLAN filter stuff and it appears correct to me, so I'm kicking it up to the masters. I've also confirmed that the vlan registers both show disabled in "ethtool -d eth6", with the below results:

    0x05080: FCTRL (Filter Control register) 0x00000400
    Broadcast Accept: enabled
    Unicast Promiscuous: enabled
    Multicast Promiscuous: enabled
    Store Bad Packets: disabled

    0x05088: VLNCTRL (VLAN Control register) 0x40008100
    VLAN Mode: disabled
    VLAN Filter: disabled

    Additionally, here's the "lspci -v" output for the device in question:

    08:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01)
    Subsystem: Intel Corporation Ethernet Server Adapter X520-2
    Flags: bus master, fast devsel, latency 0, IRQ 202
    Memory at d9900000 (64-bit, prefetchable) [size=512K]
    I/O ports at bcc0 [size=32]
    Memory at d98f8000 (64-bit, prefetchable) [size=16K]
    Capabilities: [40] Power Management version 3
    Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
    Capabilities: [70] MSI-X: Enable+ Count=64 Masked-
    Capabilities: [a0] Express Endpoint, MSI 00
    Capabilities: [100] Advanced Error Reporting
    Capabilities: [140] Device Serial Number 90-e2-xx-xx-xx-xx-xx-xx
    Capabilities: [150] Alternative Routing-ID Interpretation (ARI)
    Capabilities: [160] Single Root I/O Virtualization (SR-IOV)
    Kernel driver in use: ixgbe
    Kernel modules: ixgbe

    Thanks for all that you do folks, it's a great service, and not an easy job.
    -Mark.


    Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/e1000/bugs/355/

    To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

     

    Related

    Bugs: #355

  • Bryan Tong
    Bryan Tong
    2013-07-10

    Okay,

    I patched the 3.16.1 driver and expected functionality has returned.

    root@a118:~# tcpdump -i eth3 -nvv vlan and ip
    tcpdump: listening on eth3, link-type EN10MB (Ethernet), capture size 65535 bytes
    17:27:01.750398 IP (tos 0x0, ttl 111, id 30314, offset 0, flags [DF], proto TCP (6), length 40)
        xx.205.119.55.51400 > 199.87.237.102.80: Flags [.], cksum 0xd37b (correct), seq 322172116, ack 2305031200, win 64240, length 0
    17:27:01.750400 IP (tos 0x0, ttl 55, id 10457, offset 0, flags [DF], proto TCP (6), length 64)
        xx.38.37.87.64120 > xx.87.237.86.80: Flags [.], cksum 0x6449 (correct), seq 1016177551, ack 686091872, win 65535, options [nop,nop,TS val 382856202 ecr 1073090044,nop,nop,sack 1 {26065:114393}], length 0
    (TRUNCATED)
    

    Tons of output after that.

    Here is the patch, this one might be a bit dirtier.

    root@a118:/usr/src/ixgbe-3.16.1/src# diff -u ixgbe_main.c.orig ixgbe_main.c
    --- ixgbe_main.c.orig   2013-05-30 10:44:09.000000000 -0700
    +++ ixgbe_main.c        2013-07-09 17:25:55.082584352 -0700
    @@ -4505,16 +4505,39 @@
            fctrl &= ~(IXGBE_FCTRL_UPE | IXGBE_FCTRL_MPE);
            vlnctrl  &= ~(IXGBE_VLNCTRL_VFE | IXGBE_VLNCTRL_CFIEN);
            if (netdev->flags & IFF_PROMISC) {
    -               hw->addr_ctrl.user_set_promisc = true;
    -               fctrl |= (IXGBE_FCTRL_UPE | IXGBE_FCTRL_MPE);
    -               vmolr |= IXGBE_VMOLR_MPE;
    +               //hw->addr_ctrl.user_set_promisc = true;
    +               //fctrl |= (IXGBE_FCTRL_UPE | IXGBE_FCTRL_MPE);
    +               //vmolr |= IXGBE_VMOLR_MPE;
                    /* Only disable hardware filter vlans in promiscuous mode
                     * if SR-IOV and VMDQ are disabled - otherwise ensure
                     * that hardware VLAN filters remain enabled.
                     */
    -               if ((adapter->flags & (IXGBE_FLAG_VMDQ_ENABLED |
    -                                      IXGBE_FLAG_SRIOV_ENABLED)))
    -                       vlnctrl |= (IXGBE_VLNCTRL_VFE | IXGBE_VLNCTRL_CFIEN);
    +               //if ((adapter->flags & (IXGBE_FLAG_VMDQ_ENABLED |
    +               //                     IXGBE_FLAG_SRIOV_ENABLED)))
    +               //      vlnctrl |= (IXGBE_VLNCTRL_VFE | IXGBE_VLNCTRL_CFIEN);
    +               u16 vid;
    +               u32 newfeatures = 0;
    +               u32 i = 0;
    +
    +               hw->addr_ctrl.user_set_promisc = true;
    +               fctrl |= (IXGBE_FCTRL_UPE | IXGBE_FCTRL_MPE);
    +               vmolr |= IXGBE_VMOLR_MPE;
    +        // There be much hackery here.
    +        // We are enabling ALL VLANs in the hardware filter here in order to work arround
    +        // what appears to be some form of firmware bug that does NOT enabled reception of
    +               // tagged frames in promisc mode. -Mark.
    +        for (vid = 0; vid < VLAN_N_VID; vid++) {
    +                       ixgbe_vlan_rx_add_vid(netdev, vid);
    +        }
    +        // Disable hardware vlan assists.
    +        for (i = 0; i < adapter->num_rx_queues; i++) {
    +                       u8 reg_idx = adapter->rx_ring[i]->reg_idx;
    +                       vlnctrl = IXGBE_READ_REG(hw, IXGBE_RXDCTL(reg_idx));
    +                       vlnctrl &= ~IXGBE_RXDCTL_VME;
    +                       IXGBE_WRITE_REG(hw, IXGBE_RXDCTL(reg_idx), vlnctrl);
    +               }
    +               printk("ixgbe: ixgbe_set_rx_mode: promiscuous mode enable without vlan tags complete.\n");
    +
            } else {
                    if (netdev->flags & IFF_ALLMULTI) {
                            fctrl |= IXGBE_FCTRL_MPE;
    

    I think the scenario here is what is unique.

    We are using this card to sniff traffic across our entire network almost like a fiber tap and we use it to detect incoming DDoS, Abuse, etc. Which we use libpcap to capture the traffic.

    The problem like what Greg said. The card is filtering the VLAN traffic which it should not in promiscuous mode.

    The patch I am submitting is basically loading the RXVLAN filter with all the VLANs so that it will see all the the traffic. I do not believe this is the right way to accomplish the desired result but it works for us.

    As I said before I would be able to provide access to the machine I am working on to the devs here offlist of course.

    However, I do not believe this can be closed as it is not fixed.

    Thanks

     
  • Todd Fujinaka
    Todd Fujinaka
    2013-07-10

    • assigned_to: Emil Tantilov
     
  • Todd Fujinaka
    Todd Fujinaka
    2013-07-10

    I think Emil is working on a fix for this, and it may do what you want it to do, but if you need to do something that is unique then you may have to carry forward your own custom patch outside of the tree.

    Closed doesn't always mean fixed, by the way, so if people quit responding then issues will be closed. The usual timeout for our direct customers, for example, is less than two weeks.

     
  • Bryan Tong
    Bryan Tong
    2013-07-10

    Sorry I didnt mean you thought it was fixed. I was just saying its still relevant.

    As far as being unique, I do not believe so; this works fine on all the other NICs we have used and I believe promiscuous mode means the NIC should by default see all traffic hitting the interface whether tagged or not.

    The current issue is that the RXVLAN filter is still on even when the NIC is in promiscuous mode. It appears the stock driver attempts to disable the filter but I believe a problem on the Intel side might not be accepting this instruction. The patch Mark and I came up with simply adds all VLAN's to the RXVLAN filter when the NIC is in promiscuous mode. I still believe there is a better way to do it. However, I am not a driver developer and that's about as far as I can go.

     
    Last edit: Bryan Tong 2013-07-10
  • Emil Tantilov
    Emil Tantilov
    2013-07-10

    There are different situations in which the vlan packets or the vlan tags may not be seen in promisc mode with the ixgbe driver that are by design:

    1. vlan filtering is not disabled in promisc mode when the driver has virtualization enabled. In this case the vlan traffic will not be seen unless there is a vlan with the same tag already configured on the interface.

    2. For kernels < 2.6.36 ixgbe strips the vlan tags by default in order to be able to process 802.1p packets (vlan tag 0). The effect of this is that the vlan packets will show up in tcpdump, but the vlan tag will be missing. Kernels starting with 2.6.36 will add the vlan tag to the packet and for those kernels you should see the vlan tags and the packets in promisc mode regardless of whether the vlan tag stripping is enabled or not. Similar issue was discussed in SF#375:
      https://sourceforge.net/p/e1000/bugs/375/

    If the issue you are seeing does not fall into the above please let me know and we can investigate further.

     
  • Todd Fujinaka
    Todd Fujinaka
    2013-08-09

    Any feedback? Can we close this bug?

     
  • Bryan Tong
    Bryan Tong
    2013-08-09

    Im upgrading my system in question to Debian Wheezy and will try the latest driver and let you know if the issue is still present.

    If so someone may use the patches presented in this thread against Squeeze.

    I do believe this situation is outside of what Emil has said above. This driver should act similar to the e1000 driver in promiscuous mode and disable all VLAN filters. The patches we presented is a dirty workaround that just adds all the VLAN's to the filters when put into promiscuous mode.

    I am still convinced there is a code issue here that should be addressed.

    I will post my results of the upgrade in a moment.

    Thanks

     
  • Bryan Tong
    Bryan Tong
    2013-08-09

    Well I have upgraded to Debian Wheezy and the latest ixgbe driver and still not receiving any traffic on the interface.

    Here is some output.

    root@a118:~# lspci | grep -i x540
    01:00.0 Ethernet controller: Intel Corporation Ethernet Controller 10-Gigabit X540-AT2 (rev 01)
    01:00.1 Ethernet controller: Intel Corporation Ethernet Controller 10-Gigabit X540-AT2 (rev 01)
    root@a118:~# lsmod | grep ixgbe
    ixgbe                 216285  0
    dca                    13240  1 ixgbe
    root@a118:~# ls -lah /usr/src/ixgbe-3.17.3^C
    root@a118:~# uname -a
    Linux a118 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux
    root@a118:~# ifconfig eth3
    eth3      Link encap:Ethernet  HWaddr a0:36:9f:0a:18:ce
              inet addr:169.254.0.1  Bcast:169.254.255.255  Mask:255.255.0.0
              inet6 addr: fe80::a236:9fff:fe0a:18ce/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:3624805 errors:0 dropped:0 overruns:0 frame:0
              TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000
              RX bytes:648968522 (618.9 MiB)  TX bytes:468 (468.0 B)
    
    root@a118:~# ethtool eth3
    Settings for eth3:
            Supported ports: [ TP ]
            Supported link modes:   100baseT/Full
                                    1000baseT/Full
                                    10000baseT/Full
            Supports auto-negotiation: Yes
            Advertised link modes:  100baseT/Full
                                    1000baseT/Full
                                    10000baseT/Full
            Advertised pause frame use: No
            Advertised auto-negotiation: Yes
            Speed: 10000Mb/s
            Duplex: Full
            Port: Twisted Pair
            PHYAD: 0
            Transceiver: external
            Auto-negotiation: on
            MDI-X: Unknown
            Supports Wake-on: d
            Wake-on: d
            Current message level: 0x00000007 (7)
                                   drv probe link
            Link detected: yes
    root@a118:~# tcpdump -i eth3 -nvv vlan and ip
    tcpdump: listening on eth3, link-type EN10MB (Ethernet), capture size 65535 bytes
    
    ^C
    0 packets captured
    625 packets received by filter
    417 packets dropped by kernel
    root@a118:~# ethtool -K eth3 rxvlan off
    root@a118:~# ethtool -K eth3 txvlan off
    root@a118:~# tcpdump -i eth3 -nvv vlan and ip
    tcpdump: listening on eth3, link-type EN10MB (Ethernet), capture size 65535 bytes
    
    ^C
    0 packets captured
    728 packets received by filter
    538 packets dropped by kernel
    

    I will post and updated patchfile for the new version.

     
    Last edit: Bryan Tong 2013-08-09
1 2 > >> (Page 1 of 2)