Bug#656754: linux-image-2.6.39-bpo.2-amd64: vlan malfunction
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.
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
#/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, 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.
Ben.
Erich
Reply to: