capturing vlan on 2.6.18

capturing vlan on 2.6.18

[Pavel Krauz]

Hello 
I am running Centos 5.0 with kernel 2.6.18-8.el5 and I have the following problem with tcpdump and VLAN.
When I replay the traffic that contains VLAN I do not see VLAN headers with tcpdump - they are removed
and I cannot filter for example on VLAN id.
My program which uses PCAP also does not see the VLAN headers, and cannot filter on them!

When I replay locally to the same interface (not from different machine) I see VLAN without problems. When
I replay from different machine I do not see VLAN!

The 2.4.20 kernel works as expected - shows VLAN headers.

Is this a kernel bug or am I supposed to set something?
Thanks & best regards
Pavel Krauz

Re: capturing vlan on 2.6.18

[Benny Amorsen]

Pavel Krauz <krauz@cncz.cz> writes:

> Is this a kernel bug or am I supposed to set something?

It's an unfortunate side effect of hardware VLAN acceleration. It
can't be turned off (apart from patching the driver to not advertise
VLAN acceleration support).

Yes, it's annoying.


/Benny

Re: capturing vlan on 2.6.18

[Pavel Krauz]

>> Is this a kernel bug or am I supposed to set something?
> It's an unfortunate side effect of hardware VLAN acceleration. It
> can't be turned off (apart from patching the driver to not advertise
> VLAN acceleration support).

For our ethernet monitoring this is a fatal problem. I have a traffic which
contains both the packets without VLAN and packets with different 
VLAN ids over single ethernet interface, and I am unable do distinguish
them now.
Also all our applications from 2.4 kernel expecting VLAN tag are unable
to filter on VLAN or get the information about VLAN tags for the user.

If we want to use 2.6 kernel we would have to patch drivers ourselfs
which we do not like to do at all for production system. And it will not be
available if we use Redhat AS for those who want a support.

I think that enabling VLAN tags shall be at least kernel run-time or boot time
 configurable option.

For a test I have tried to enable VLAN tags in the Broadcom NX2 network driver (drivers/net/bnx2.c)
and I got the VLAN back. Can you tell me if this is the correct way:

--- bnx2.c.bak  2008-02-28 11:47:29.000000000 +0100
+++ bnx2.c      2008-02-28 11:47:43.000000000 +0100
@@ -2039,6 +2039,7 @@
 #endif
        if (dev->flags & IFF_PROMISC) {
                /* Promiscuous mode. */
+               rx_mode |= BNX2_EMAC_RX_MODE_KEEP_VLAN_TAG;
                rx_mode |= BNX2_EMAC_RX_MODE_PROMISCUOUS;
                sort_mode |= BNX2_RPM_SORT_USER0_PROM_EN;
        }


I also tried to comment out the   dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX 
but the driver stopped working
if I undefined BCM_VLAN and made it compile, the VLAN was not present.

Thanks
Pavel

Re: capturing vlan on 2.6.18

[Pekka Pietikainen]

On Thu, Feb 28, 2008 at 12:26:08PM +0100, Pavel Krauz wrote:
> >> Is this a kernel bug or am I supposed to set something?
> > It's an unfortunate side effect of hardware VLAN acceleration. It
> > can't be turned off (apart from patching the driver to not advertise
> > VLAN acceleration support).
> I think that enabling VLAN tags shall be at least kernel run-time or boot time
>  configurable option.
> 
> For a test I have tried to enable VLAN tags in the Broadcom NX2 network driver (drivers/net/bnx2.c)
> and I got the VLAN back. Can you tell me if this is the correct way:
> 
> --- bnx2.c.bak  2008-02-28 11:47:29.000000000 +0100
> +++ bnx2.c      2008-02-28 11:47:43.000000000 +0100
> @@ -2039,6 +2039,7 @@
>  #endif
>         if (dev->flags & IFF_PROMISC) {
>                 /* Promiscuous mode. */
> +               rx_mode |= BNX2_EMAC_RX_MODE_KEEP_VLAN_TAG;
>                 rx_mode |= BNX2_EMAC_RX_MODE_PROMISCUOUS;
>                 sort_mode |= BNX2_RPM_SORT_USER0_PROM_EN;
>         }
> 
Oh, the no VLAN tags with bnx2 is a slightly different matter,
I've used the patch

#ifdef BCM_VLAN
        if (!bp->vlgrp && !(bp->flags & ASF_ENABLE_FLAG))
                rx_mode |= BNX2_EMAC_RX_MODE_KEEP_VLAN_TAG;
#else

->
        if (!bp->vlgrp) // && !(bp->flags & ASF_ENABLE_FLAG))
                rx_mode |= BNX2_EMAC_RX_MODE_KEEP_VLAN_TAG;

Apparently there's a DOS tool that can be used to disable the ASF bit
(It's some enterprise management thing that I haven't ever figured out what
it's even useful for) permanently, 
http://www.broadcom.com/support/ethernet_nic/netxtremeii.php

Since I need lots of ports on my monitoring boxes anyway, I just use
external dual-port e1000's for monitoring and use the on-board bnx2 for
managment. Much easier :-)

Re: capturing vlan on 2.6.18

[Pavel Krauz]

> On Tuesday 04 March 2008 12:18, Pekka Pietikainen wrote:
> On Thu, Feb 28, 2008 at 12:26:08PM +0100, Pavel Krauz wrote:
> > >> Is this a kernel bug or am I supposed to set something?
> > > It's an unfortunate side effect of hardware VLAN acceleration. It
> > > can't be turned off (apart from patching the driver to not advertise
> > > VLAN acceleration support).
> > I think that enabling VLAN tags shall be at least kernel run-time or boot time
> >  configurable option.
> Oh, the no VLAN tags with bnx2 is a slightly different matter,
> I've used the patch
> 
> #ifdef BCM_VLAN
>         if (!bp->vlgrp && !(bp->flags & ASF_ENABLE_FLAG))
>                 rx_mode |= BNX2_EMAC_RX_MODE_KEEP_VLAN_TAG;
> #else

Thanks,
I have found out that by disabling the ASF/management firmware through Broadcom 
diagnostic utility I get VLAN tags in the packets. I think that it shall be at least documented
in the driver/help. I have no idea for what the ASF is used for in linux.
There shall be a tool or option how to disable it from user space or at boot time or in driver.

Pavel