On Sun, 2012-01-22 at 18:08 +0100, Erich N. Pekarek wrote: > Hello! > > Am 2012-01-21 17:34, schrieb Ben Hutchings: > > On Sat, 2012-01-21 at 15:43 +0100, Erich N. Pekarek wrote: > >> Package: linux-2.6 > >> Version: 2.6.39-3~bpo60+1 > > This is long outdated; please test 3.2.1-1 from unstable. > I did a "aptitude -t squeeze-backports" then updated and installed the > latest version available there. (State: yesterday). Since the machine > had no external network access after that, the information may differ. > It was the lastest available package from the squeeze-backports repository. > > If you regard the sid kernel available to be stable enough please add it > to the squeeze-backports repository - i would appreciate some up to date > drivers on a stable kernel. The backport was being maintained by someone else. I am just about to fix that, though. Linux 2.6.39 has known bugs including security vulnerabilities which are fixed in later versions. > >> Severity: important > >> Tags: d-i ipv6 upstream > > What on earth has this to do with d-i or ipv6?! > From a user perspective, ipv6 or debian installer functionality may be > affected by this bug in the underlying kernel. I prefer bug reports to > be tagged in an extensive way. My apologies, if that was inappropriate. Those tags mean that the bug specifically relates to the installer or IPv6, not that it might affect it. > >> The network functionality is only guaranteed on the underlying network > >> interface with vlanid 0. dmesg does not report any problems concerning > >> vlan. The 8021q module is loaded. It can be loaded and unloaded > >> without problems. Network interfaces and bridge interfaces which have > >> been set up to use vlan can not be used. > > [...] > > > > It would have been nice if you'd actually provided some specific details > > of your network configuration, but I'm going to use my psychic powers to > > guess that you have something like: > > > eth0 - physical interface > > br0 - bridge including eth0 > > eth0.N - VLAN interface attached to eth0 > > br1 - bridge including eth0.NYour psychic powers are quite amazing ;-) > > physical: eth0 > bridges: bri0, bri1, bri2, ..., bri6 > #/etc/network/interfaces: > ... > iface bri0 inet static > .... > bridge_ports eth0.1234 > bridge_stp on > bridge_maxwait 10 > ... > > vlans: eth0.1234, eth0.1345 # (examples). > #/etc/network/interfaces: > ... > iface eth0.1234 inet manual > vlan_raw_device eth0 > ... > > > and you expect VLAN-tagged packets that arrive on eth0 to be forwarded > > through br1, not br0? > > > I expect VLAN-tagged packages to arrive untagged at their respective > bridge ports, which is a VLAN-interface, and to leave those VLAN-tagged > as they do while running linux-image-2.6.32-5-amd64. We are talking > about a tested and well proven setup. > Forward in terms of bridging applies, forward in terms of NAT is not > involved at this stage. > > Currently only the bridge including the maintenance interface with the > plain eth0 interface receives all tagged and untagged packages, and > VLAN-inferfaces just receive tagged packets [...] Right, that's what I thought. You're really supposed to only attach either a bridge device or VLAN devices to an underlying physical device. However, I'm aware that the Linux bridge driver is not so useful as a VLAN bridge and that there was never any restriction in the kernel that prevented you from doing this. Due to the way VLAN tag offload was implemented, the above configuration worked for a long time if the underlying physical device implemented VLAN tag offload - but not if it didn't. In Linux 2.6.37 the handling of VLAN tags was significantly changed to remove the special case for receiving packets from devices with VLAN tag offload, causing this configuration to break. Since many people used similar configurations, this was fixed in Linux 3.2 (I think). Ben. -- Ben Hutchings Knowledge is power. France is bacon.
Attachment:
signature.asc
Description: This is a digitally signed message part