accelerated vlan gives pcap tagged packets untagged

accelerated vlan gives pcap tagged packets untagged

[Pierre Ossman]

[-- Attachment #1: Type: text/plain, Size: 2266 bytes --]

Hi,

I'm having some problems with r8169 and vlans. The basic problem is
that pcap on eth1 gives me tagged packets, but in a form where it is
impossible to tell it is tagged. This is causing problems for dhcpd:

Feb  6 20:04:22 asgard dhcpd: DHCPDISCOVER from 00:15:00:08:98:1f via eth1.2
Feb  6 20:04:22 asgard dhcpd: DHCPDISCOVER from 00:15:00:08:98:1f via eth1
Feb  6 20:04:23 asgard dhcpd: DHCPOFFER on 10.8.2.230 to 00:15:00:08:98:1f via eth1.2
Feb  6 20:04:23 asgard dhcpd: DHCPOFFER on 10.8.0.128 to 00:15:00:08:98:1f via eth1
Feb  6 20:04:23 asgard dhcpd: DHCPREQUEST for 10.8.2.230 (10.8.2.254) from 00:15:00:08:98:1f via eth1.2
Feb  6 20:04:23 asgard dhcpd: DHCPACK on 10.8.2.230 to 00:15:00:08:98:1f via eth1.2
Feb  6 20:04:23 asgard dhcpd: DHCPREQUEST for 10.8.2.230 (10.8.2.254) from 00:15:00:08:98:1f via eth1: wrong network.
Feb  6 20:04:23 asgard dhcpd: DHCPNAK on 10.8.2.230 to 00:15:00:08:98:1f via eth1

I assume this is because the hardware supports vlans and handles all
the tag stripping.

(I've confirmed with tcpdump that the packets lack tags when they are
presented to userspace)

From what I can tell, I cannot fix this without rebuilding the kernel
and removing the acceleration support from the r8169 driver. Is there
some method I've overlooked?

Preferably, I'd like the kernel to expose to pcap what's on the wire
(i.e. accelerated vs non-accelerated looks the same from userspace). If
that means too much processing to be desirable, the next best thing
would be to simply not show tagged packets on the raw interface. The
ability to turn vlan acceleration on and off in the latter case would
also be desirable for network debugging.


Possibly related, all docs state that header reordering is disabled by
default. But it is on by default here. This might be because of the
acceleration, but the docs need some type of update either way. :)

Thanks
-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  rdesktop, core developer          http://www.rdesktop.org

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: accelerated vlan gives pcap tagged packets untagged

[Francois Romieu]

Pierre Ossman <drzeus-list@drzeus.cx> :
[...]
> I assume this is because the hardware supports vlans and handles all
> the tag stripping.

Partly.

> (I've confirmed with tcpdump that the packets lack tags when they are
> presented to userspace)
> 
> From what I can tell, I cannot fix this without rebuilding the kernel
> and removing the acceleration support from the r8169 driver. Is there
> some method I've overlooked?
>
> Preferably, I'd like the kernel to expose to pcap what's on the wire
> (i.e. accelerated vs non-accelerated looks the same from userspace). If
> that means too much processing to be desirable, the next best thing
> would be to simply not show tagged packets on the raw interface.

Your issue seems to be related to the commit below:

commit bc1d0411b804ad190cdadabac48a10067f17b9e6
Author: Patrick McHardy <kaber@trash.net>
Date:   Mon Jul 14 22:49:30 2008 -0700

    vlan: deliver packets received with VLAN acceleration to network taps
    
    When VLAN header stripping is used, packets currently bypass packet
    sockets (and other network taps) completely. For locally existing
    VLANs, they appear directly on the VLAN device, for unknown VLANs
    they are silently dropped.
    
    Add a new function netif_nit_deliver() to deliver incoming packets
    to all network interface taps and use it in __vlan_hwaccel_rx() to
    make VLAN packets visible on the underlying device.
    
    Signed-off-by: Patrick McHardy <kaber@trash.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>

I have no idea what could be the right solution. Patrick ?

-- 
Ueimor

Re: accelerated vlan gives pcap tagged packets untagged

[Patrick McHardy]

Pierre Ossman wrote:
> I'm having some problems with r8169 and vlans. The basic problem is
> that pcap on eth1 gives me tagged packets, but in a form where it is
> impossible to tell it is tagged. This is causing problems for dhcpd:
> 
> Feb  6 20:04:22 asgard dhcpd: DHCPDISCOVER from 00:15:00:08:98:1f via eth1.2
> Feb  6 20:04:22 asgard dhcpd: DHCPDISCOVER from 00:15:00:08:98:1f via eth1
> Feb  6 20:04:23 asgard dhcpd: DHCPOFFER on 10.8.2.230 to 00:15:00:08:98:1f via eth1.2
> Feb  6 20:04:23 asgard dhcpd: DHCPOFFER on 10.8.0.128 to 00:15:00:08:98:1f via eth1
> Feb  6 20:04:23 asgard dhcpd: DHCPREQUEST for 10.8.2.230 (10.8.2.254) from 00:15:00:08:98:1f via eth1.2
> Feb  6 20:04:23 asgard dhcpd: DHCPACK on 10.8.2.230 to 00:15:00:08:98:1f via eth1.2
> Feb  6 20:04:23 asgard dhcpd: DHCPREQUEST for 10.8.2.230 (10.8.2.254) from 00:15:00:08:98:1f via eth1: wrong network.
> Feb  6 20:04:23 asgard dhcpd: DHCPNAK on 10.8.2.230 to 00:15:00:08:98:1f via eth1
> 
> I assume this is because the hardware supports vlans and handles all
> the tag stripping.
> 
> (I've confirmed with tcpdump that the packets lack tags when they are
> presented to userspace)
> 
> From what I can tell, I cannot fix this without rebuilding the kernel
> and removing the acceleration support from the r8169 driver. Is there
> some method I've overlooked?
> 
> Preferably, I'd like the kernel to expose to pcap what's on the wire
> (i.e. accelerated vs non-accelerated looks the same from userspace). If
> that means too much processing to be desirable, the next best thing
> would be to simply not show tagged packets on the raw interface. The
> ability to turn vlan acceleration on and off in the latter case would
> also be desirable for network debugging.

Current kernel version (I think starting with 2.6.28) relay the
VLAN tag information to userspace through packet sockets. The
current libpcap release from tcpdump.org (or the one Dave keeps
in a git tree on kernel.org) supports reconstructing the tags.

> Possibly related, all docs state that header reordering is disabled by
> default. But it is on by default here. This might be because of the
> acceleration, but the docs need some type of update either way. :)

I've been wondering about that myself :)

Re: accelerated vlan gives pcap tagged packets untagged

[Pierre Ossman]

[-- Attachment #1: Type: text/plain, Size: 921 bytes --]

On Mon, 09 Feb 2009 14:23:01 +0100
Patrick McHardy <kaber@trash.net> wrote:

> 
> Current kernel version (I think starting with 2.6.28) relay the
> VLAN tag information to userspace through packet sockets. The
> current libpcap release from tcpdump.org (or the one Dave keeps
> in a git tree on kernel.org) supports reconstructing the tags.
> 

Ah. This is a Fedora 10 machine so it's running a 2.6.27 kernel. I'll
see if I can do a test with an updated kernel.

Do you know if dhcpd also uses libpcap so that it will stop seeing
packets it shouldn't?

Rgds
-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  rdesktop, core developer          http://www.rdesktop.org

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: accelerated vlan gives pcap tagged packets untagged

[Patrick McHardy]

Pierre Ossman wrote:
> On Mon, 09 Feb 2009 14:23:01 +0100
> Patrick McHardy <kaber@trash.net> wrote:
> 
>> Current kernel version (I think starting with 2.6.28) relay the
>> VLAN tag information to userspace through packet sockets. The
>> current libpcap release from tcpdump.org (or the one Dave keeps
>> in a git tree on kernel.org) supports reconstructing the tags.
>>
> 
> Ah. This is a Fedora 10 machine so it's running a 2.6.27 kernel. I'll
> see if I can do a test with an updated kernel.
> 
> Do you know if dhcpd also uses libpcap so that it will stop seeing
> packets it shouldn't?

I believe it depends on compilation options (but usually does on
modern distributions).

Re: accelerated vlan gives pcap tagged packets untagged

[Malcolm Scott]

(apologies for reviving an ancient thread, but I've hit this problem myself)

On Mon, 9 Feb 2009, Patrick McHardy wrote:

> Pierre Ossman wrote:
>> I'm having some problems with r8169 and vlans. The basic problem is
>> that pcap on eth1 gives me tagged packets, but in a form where it is
>> impossible to tell it is tagged. This is causing problems for dhcpd:
>> 
>> Feb  6 20:04:22 asgard dhcpd: DHCPDISCOVER from 00:15:00:08:98:1f via 
>> eth1.2
>> Feb  6 20:04:22 asgard dhcpd: DHCPDISCOVER from 00:15:00:08:98:1f via eth1
>> Feb  6 20:04:23 asgard dhcpd: DHCPOFFER on 10.8.2.230 to 00:15:00:08:98:1f 
>> via eth1.2
>> Feb  6 20:04:23 asgard dhcpd: DHCPOFFER on 10.8.0.128 to 00:15:00:08:98:1f 
>> via eth1
>> Feb  6 20:04:23 asgard dhcpd: DHCPREQUEST for 10.8.2.230 (10.8.2.254) from 
>> 00:15:00:08:98:1f via eth1.2
>> Feb  6 20:04:23 asgard dhcpd: DHCPACK on 10.8.2.230 to 00:15:00:08:98:1f 
>> via eth1.2
>> Feb  6 20:04:23 asgard dhcpd: DHCPREQUEST for 10.8.2.230 (10.8.2.254) from 
>> 00:15:00:08:98:1f via eth1: wrong network.
>> Feb  6 20:04:23 asgard dhcpd: DHCPNAK on 10.8.2.230 to 00:15:00:08:98:1f 
>> via eth1
>> 
>> I assume this is because the hardware supports vlans and handles all
>> the tag stripping.
>> 
>> (I've confirmed with tcpdump that the packets lack tags when they are
>> presented to userspace)
>> 
>> From what I can tell, I cannot fix this without rebuilding the kernel
>> and removing the acceleration support from the r8169 driver. Is there
>> some method I've overlooked?
>> 
>> Preferably, I'd like the kernel to expose to pcap what's on the wire
>> (i.e. accelerated vs non-accelerated looks the same from userspace). If
>> that means too much processing to be desirable, the next best thing
>> would be to simply not show tagged packets on the raw interface. The
>> ability to turn vlan acceleration on and off in the latter case would
>> also be desirable for network debugging.
>
> Current kernel version (I think starting with 2.6.28) relay the
> VLAN tag information to userspace through packet sockets. The
> current libpcap release from tcpdump.org (or the one Dave keeps
> in a git tree on kernel.org) supports reconstructing the tags.

So to clarify: as of 2.6.28, an app (e.g. dhcpd) listening on eth0 will by 
default see packets from all VLANs with tags removed; if it wishes to do 
otherwise, it should query the kernel for the VLAN tag of every packet and 
discard those with a tag?

Unless I misunderstand, this seems like absolutely the wrong behaviour: 
untagged packets are expected to be treated as from another VLAN just like 
any other, and should be kept separate (from userspace's perspective) from 
all tagged packets.  Prior to 2.6.28 this was indeed the case (on my NICs at 
least -- tg3 and others): listening on eth0, one would see the tagged 
packets with the tags still in place, so these would be correctly ignored by 
apps which were not specifically able to handle tagged packets.

In my case, this is manifesting as the DHCP misbehaviour which Pierre 
mentioned.  (ISC dhcp3d does not use libpcap, and does not query the packet 
socket for the VLAN tag, so it treats every VLAN's packets as for the 
default VLAN.)

-- 
Malcolm Scott
University of Cambridge Computer Laboratory

Re: accelerated vlan gives pcap tagged packets untagged

[Patrick McHardy]

Malcolm Scott wrote:
> (apologies for reviving an ancient thread, but I've hit this problem
> myself)
> 
> On Mon, 9 Feb 2009, Patrick McHardy wrote:
> 
>> Pierre Ossman wrote:
>>> I'm having some problems with r8169 and vlans. The basic problem is
>>> that pcap on eth1 gives me tagged packets, but in a form where it is
>>> impossible to tell it is tagged. This is causing problems for dhcpd:
>>>
>>> Feb  6 20:04:22 asgard dhcpd: DHCPDISCOVER from 00:15:00:08:98:1f via
>>> eth1.2
>>> Feb  6 20:04:22 asgard dhcpd: DHCPDISCOVER from 00:15:00:08:98:1f via
>>> eth1
>>> Feb  6 20:04:23 asgard dhcpd: DHCPOFFER on 10.8.2.230 to
>>> 00:15:00:08:98:1f via eth1.2
>>> Feb  6 20:04:23 asgard dhcpd: DHCPOFFER on 10.8.0.128 to
>>> 00:15:00:08:98:1f via eth1
>>> Feb  6 20:04:23 asgard dhcpd: DHCPREQUEST for 10.8.2.230 (10.8.2.254)
>>> from 00:15:00:08:98:1f via eth1.2
>>> Feb  6 20:04:23 asgard dhcpd: DHCPACK on 10.8.2.230 to
>>> 00:15:00:08:98:1f via eth1.2
>>> Feb  6 20:04:23 asgard dhcpd: DHCPREQUEST for 10.8.2.230 (10.8.2.254)
>>> from 00:15:00:08:98:1f via eth1: wrong network.
>>> Feb  6 20:04:23 asgard dhcpd: DHCPNAK on 10.8.2.230 to
>>> 00:15:00:08:98:1f via eth1
>>>
>>> I assume this is because the hardware supports vlans and handles all
>>> the tag stripping.
>>>
>>> (I've confirmed with tcpdump that the packets lack tags when they are
>>> presented to userspace)
>>>
>>> From what I can tell, I cannot fix this without rebuilding the kernel
>>> and removing the acceleration support from the r8169 driver. Is there
>>> some method I've overlooked?
>>>
>>> Preferably, I'd like the kernel to expose to pcap what's on the wire
>>> (i.e. accelerated vs non-accelerated looks the same from userspace). If
>>> that means too much processing to be desirable, the next best thing
>>> would be to simply not show tagged packets on the raw interface. The
>>> ability to turn vlan acceleration on and off in the latter case would
>>> also be desirable for network debugging.
>>
>> Current kernel version (I think starting with 2.6.28) relay the
>> VLAN tag information to userspace through packet sockets. The
>> current libpcap release from tcpdump.org (or the one Dave keeps
>> in a git tree on kernel.org) supports reconstructing the tags.
> 
> So to clarify: as of 2.6.28, an app (e.g. dhcpd) listening on eth0 will
> by default see packets from all VLANs with tags removed; if it wishes to
> do otherwise, it should query the kernel for the VLAN tag of every
> packet and discard those with a tag?

No, exactly the opposite. Starting with 2.6.28 and a recent libpcap,
VLAN tags are present in userspace independant of whether the driver
uses VLAN acceleration or not.

> Unless I misunderstand, this seems like absolutely the wrong behaviour:
> untagged packets are expected to be treated as from another VLAN just
> like any other, and should be kept separate (from userspace's
> perspective) from all tagged packets.  Prior to 2.6.28 this was indeed
> the case (on my NICs at least -- tg3 and others): listening on eth0, one
> would see the tagged packets with the tags still in place, so these
> would be correctly ignored by apps which were not specifically able to
> handle tagged packets.

This depends on the driver implementation.

> In my case, this is manifesting as the DHCP misbehaviour which Pierre
> mentioned.  (ISC dhcp3d does not use libpcap, and does not query the
> packet socket for the VLAN tag, so it treats every VLAN's packets as for
> the default VLAN.)

It needs to get the VLAN tag from the auxilliary data.

Re: accelerated vlan gives pcap tagged packets untagged

[Malcolm Scott]

At 18:35 yesterday, Patrick McHardy wrote:

> Malcolm Scott wrote:
>
>> So to clarify: as of 2.6.28, an app (e.g. dhcpd) listening on eth0 will
>> by default see packets from all VLANs with tags removed; if it wishes to
>> do otherwise, it should query the kernel for the VLAN tag of every
>> packet and discard those with a tag?
>
> No, exactly the opposite. Starting with 2.6.28 and a recent libpcap,
> VLAN tags are present in userspace independant of whether the driver
> uses VLAN acceleration or not.

Sorry, I meant that the 802.1q header is removed from the packet, not 
discarded entirely.

>> In my case, this is manifesting as the DHCP misbehaviour which Pierre
>> mentioned.  (ISC dhcp3d does not use libpcap, and does not query the
>> packet socket for the VLAN tag, so it treats every VLAN's packets as for
>> the default VLAN.)
>
> It needs to get the VLAN tag from the auxilliary data.

Right.  But backwards compatibility with older apps is the issue.  An app 
which doesn't go looking for a VLAN tag in the auxiliary data -- because it 
didn't have to do so prior to 2.6.28 -- will start seeing packets from all 
VLANs rather than just the untagged ones.

Perhaps what's actually needed is another interface which sees _just_ the 
untagged packets, e.g. eth0.0 (0 being a reserved VLAN ID meaning 'no VLAN', 
i.e. equivalent to no 802.1q tag).

Malcolm

-- 
Malcolm Scott
University of Cambridge Computer Laboratory

Re: accelerated vlan gives pcap tagged packets untagged

[Pierre Ossman]

[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]

Reviving a really old thread.

On Fri, 24 Jul 2009 17:50:26 +0100 (BST)
Malcolm Scott <linux-netdev@malc.org.uk> wrote:

> At 18:35 yesterday, Patrick McHardy wrote:
> 
> > Malcolm Scott wrote:
> >
> >> In my case, this is manifesting as the DHCP misbehaviour which Pierre
> >> mentioned.  (ISC dhcp3d does not use libpcap, and does not query the
> >> packet socket for the VLAN tag, so it treats every VLAN's packets as for
> >> the default VLAN.)
> >
> > It needs to get the VLAN tag from the auxilliary data.
> 
> Right.  But backwards compatibility with older apps is the issue.  An app 
> which doesn't go looking for a VLAN tag in the auxiliary data -- because it 
> didn't have to do so prior to 2.6.28 -- will start seeing packets from all 
> VLANs rather than just the untagged ones.
> 
> Perhaps what's actually needed is another interface which sees _just_ the 
> untagged packets, e.g. eth0.0 (0 being a reserved VLAN ID meaning 'no VLAN', 
> i.e. equivalent to no 802.1q tag).
> 

Has any progress been made on this front? I'm running kernel 2.6.32 and
dhcpd 4.1.1 and that combination is still getting very upset by these
stray packages.

Rgds
-- 
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by FRA, a
  Swedish intelligence agency. Make sure your server uses
  encryption for SMTP traffic and consider using PGP for
  end-to-end encryption.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 230 bytes --]