Date:	Thu, 23 Jul 2009 18:35:37 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Malcolm Scott <linux-netdev@...c.org.uk>
CC:	Pierre Ossman <drzeus-list@...eus.cx>,
	Francois Romieu <romieu@...zoreil.com>, netdev@...r.kernel.org
Subject: Re: accelerated vlan gives pcap tagged packets untagged

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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists