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 vi=
a 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 vi=
a 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)

=46rom 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
--=20
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  rdesktop, ...
[ message continues ]

Pierre Ossman <drzeus-list@drzeus.cx> :


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
--

[ message continues ]

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

I've been wondering about that myself :)
--

[ message continues ]

On Mon, 09 Feb 2009 14:23:01 +0100

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
--=20
     -- 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.
[ message continues ]

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

[ message continues ]

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


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
--

[ message continues ]

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


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

[ message continues ]

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

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
--

[ message continues ]