public inbox for netdev@vger.kernel.org 
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash•net>
To: Ben Greear <greearb@candelatech•com>
Cc: andrei radulescu-banu <iubica2@yahoo•com>,
	linux-kernel@vger•kernel.org,
	Linux Netdev List <netdev@vger•kernel.org>
Subject: Re: Linux, tcpdump and vlan
Date: Thu, 19 Jul 2007 02:19:27 +0200	[thread overview]
Message-ID: <469EAE0F.5090607@trash.net> (raw)
In-Reply-To: <469EA9BF.4040603@candelatech.com>

Ben Greear wrote:
> Patrick McHardy wrote:
> 
>> Its actually more a problem on the RX path. VLAN acceleration
>> works (at least with some drivers) by enabling HW header striping
>> and using the VLAN ID for an immediate lookup in the VLAN devices
>> configured on that device. So if the VLAN is not configured on the
>> real device but something like macvlan, it will get the packet
>> without a header and without any indication that this was a VLAN
>> packet. This is also what causes the tcpdump problem.
>>   
> 
> This reminded me of something:
> 
> If we are using VLAN HW-Accel, then the skb hits the mac-vlan check with
> the skb->dev == vlan-device.
> So, in this case, we can put mac-vlans on top of 802.1Q VLANs.
> 
> But, if we are not using VLAN hw-accel, the skb hits the mac-vlan check
> with skb->dev == ethernet-device.
> In this case, we could NOT have the mac-vlan on top of the 802.1Q VLAN,
> but we can have a MAC-VLAN
> on the raw ethernet and we could add 802.1Q vlans on top of the
> mac-vlan.  This is because the
> .1Q vlan will only be found once we go into the protocol handler logic,
> which is necessarily after the
> MAC-VLAN check logic.
> 
> Unless I am confused in my conjecture above, this is likely to confuse
> others who try to mix and
> match MAC-VLANs and 802.1Q VLANs.


The current code doesn't use hardware acceleration and works fine
in all combinations where only vlan *or* macvlan devices are used
on the underlying device.

If you mix them macvlan won't get to see vlan headers anymore,
same as for tcpdump, bridge devices, or anything else that
might care. A bridge eating VLAN headers should be a clearer
indication of a bug than an inaccurate tcpdump ..

The real problem is that the device removes the header for all
vlans, not only for those that are configured on the device.
This is a result of how the hardware works. But since we don't
have the data available later, we can't even fix it up in
software.


  reply	other threads:[~2007-07-19  0:20 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <878246.51044.qm@web56608.mail.re3.yahoo.com>
2007-07-18 22:57 ` Linux, tcpdump and vlan Patrick McHardy
2007-07-18 23:22   ` Ben Greear
2007-07-18 23:34     ` Patrick McHardy
2007-07-19  0:01       ` Ben Greear
2007-07-19  0:19         ` Patrick McHardy [this message]
2007-07-19 13:28   ` Krzysztof Halasa
2007-07-19 13:41     ` Stephen Hemminger
2007-07-19 14:00       ` Patrick McHardy
2007-07-19 14:23       ` Krzysztof Halasa
2007-07-19 15:00         ` Stephen Hemminger
2007-07-19 15:45           ` Krzysztof Halasa
2007-07-19 15:20         ` Stephen Hemminger
2007-07-19 15:47 andrei radulescu-banu
2007-07-19 16:21 ` Stephen Hemminger
2007-07-19 16:33 ` Patrick McHardy
2007-07-19 16:47 ` Ben Greear
  -- strict thread matches above, loose matches on Subject: below --
2007-07-19 16:02 andrei radulescu-banu
2007-07-20 19:58 ` Krzysztof Halasa
2007-07-20 20:34   ` Ben Greear
2007-07-21 11:32     ` Krzysztof Halasa
2007-07-21 17:57       ` Ben Greear
2007-07-21 21:15         ` Krzysztof Halasa
2007-07-19 17:46 andrei radulescu-banu
2007-07-19 18:20 andrei radulescu-banu
2007-07-19 19:28 ` Stephen Hemminger
2007-07-19 21:38 andrei radulescu-banu
2007-07-19 23:38 ` Ben Greear
2007-07-20 20:19   ` Krzysztof Halasa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=469EAE0F.5090607@trash.net \
    --to=kaber@trash$(echo .)net \
    --cc=greearb@candelatech$(echo .)com \
    --cc=iubica2@yahoo$(echo .)com \
    --cc=linux-kernel@vger$(echo .)kernel.org \
    --cc=netdev@vger$(echo .)kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox