[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#656754: linux-image-2.6.39-bpo.2-amd64: vlan malfunction


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.

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.

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
    iface bri0 inet static
            bridge_ports eth0.1234
            bridge_stp on
            bridge_maxwait 10

vlans: eth0.1234, eth0.1345 # (examples).
    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, while no untagged packet get through, which would lead to the assumption that the vlan code is inactive for some reason. Filtering (ebtables/iptables ...) was previously disabled. The tagged interfaces receive packets originating from the physical eth0's mac address, which iptraf regards to be "non-IP packages".

I can not provide additional information at this time.



Reply to: