lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 06 Nov 2007 21:08:21 +0100
From:	Krzysztof Halasa <>
To:	Ben Greear <>
Cc:	Patrick McHardy <>,
	David Miller <>,,,,,,,
Subject: Re: [PATCH 1/2] NET: Re-add VLAN tag for devices incapable of keeping it

Ben Greear <> writes:

> Bridging eth0 to eth1 should not pay attention to VLAN tags
> at all (if the pkt comes in on VLAN 7, it should go out on VLAN 7),
> in my opinion.  If the NIC is stripping the VLAN header, then this
> cannot work unless something re-builds the VLAN header.  If the stripped
> VLAN header is placed into the skb, then any code that does need to
> rebuild it can do so.  It may be less efficient, but users can just
> not use that NIC hardware for high-end solutions, and at any rate,
> less efficient is better than broken.

That is all true. The problem arises when you receive a tagged frame
on eth0, the chip removes the tag, and then the bridge sends it
out untagged on eth1.

I think there are two valid models for VLAN + bridging:

a) bridging works on "physical" interfaces, all tags are transmitted

b) every VLAN is a different logical interface, packets from unknown
   VLANs are dropped on RX (and thus don't show up anywhere, except
   counters), bridging uses logical interfaces. VLAN 100 on eth0 may
   become VLAN 200 on eth1 and may be untagged on eth2.

"a" requires "soft" VLANs and/or adding the tags back (with
accelerated VLANs). This is how unmanaged switches labeled
"802.1Q - transparent" work. Not very flexible but usually good

"b" is how switches supporting VLANs (and 802.1Q) usually work.

I know ability to see exactly all packets as they are received
(including tags) is a really nice thing. But maybe we should change
the model? Making the ethX only carry untagged frames (even without
hw VLAN acceleration)?
Krzysztof Halasa
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists