Bug#656754: linux-image-2.6.39-bpo.2-amd64: vlan malfunction
Package: linux-2.6 Version: 2.6.39-3~bpo60+1 Severity: important Tags: d-i ipv6 upstream 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. /proc/net/vlan/config reports interface-vlan-relations as usual. Manually setting up an interface using vconfig does not change the situation. Monitoring an interface with iptraf shows traffic in eth0 (unidirectional), while traffic on vlan interface will always show non-ip traffic only. Changing the raw interface does not show up a difference in this behaviour. Installing ifupdown-scripts-zg2 and ifupdown-scripts-extras does not change anything. Tested with amd64 on Asus M2A-VM board with RTL8111/8168B network chip a 3c905C-TX/TX-M [Tornado] network card. The error is reproducible. The same configuration works well on the 2.6.32 "stock" kernel. -- Package-specific info: ** Kernel log: boot messages should be attached currently unable to attach. -- System Information: Debian Release: 6.0.3 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'proposed-updates') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-vserver-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6.39-bpo.2-amd64 depends on: ii cdebconf [debconf-2.0]0.153+squeeze2 Debian Configuration Management Sy ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy ii initramfs-tools [linux-in 0.99~bpo60+1 tools for generating an initramfs ii linux-base3.3~bpo60+1Linux image base package ii module-init-tools 3.12-1 tools for managing Linux kernel mo Versions of packages linux-image-2.6.39-bpo.2-amd64 recommends: ii firmware-linux-free2.6.32-39squeeze1 Binary firmware for various driver Versions of packages linux-image-2.6.39-bpo.2-amd64 suggests: ii grub-pc1.98+20100804-14+squeeze1 GRand Unified Bootloader, version pn linux-doc-2.6. (no description available) Versions of packages linux-image-2.6.39-bpo.2-amd64 is related to: ii firmware-bnx2 0.32~bpo60+1 Binary firmware for Broadcom NetXt ii firmware-bnx2x 0.32~bpo60+1 Binary firmware for Broadcom NetXt ii firmware-ipw2x000.32~bpo60+1 Binary firmware for Intel Pro Wire ii firmware-ivtv 0.32~bpo60+1 Binary firmware for iTVC15-family ii firmware-iwlwifi0.32~bpo60+1 Binary firmware for Intel Wireless ii firmware-linux 0.32~bpo60+1 Binary firmware for various driver ii firmware-linux-nonfree 0.32~bpo60+1 Binary firmware for various driver ii firmware-qlogic 0.32~bpo60+1 Binary firmware for QLogic IBA7220 ii firmware-ralink 0.32~bpo60+1 Binary firmware for Ralink wireles pn xen-hypervisor (no description available) -- debconf information: linux-image-2.6.39-bpo.2-amd64/prerm/removing-running-kernel-2.6.39-bpo.2-amd64: true * linux-image-2.6.39-bpo.2-amd64/postinst/missing-firmware-2.6.39-bpo.2-amd64: linux-image-2.6.39-bpo.2-amd64/postinst/ignoring-ramdisk: linux-image-2.6.39-bpo.2-amd64/postinst/depmod-error-initrd-2.6.39-bpo.2-amd64: false -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120121144341.9515.59540.report...@truelove.intern.pekarek.at
Bug#656754: linux-image-2.6.39-bpo.2-amd64: vlan malfunction
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. > Severity: important > Tags: d-i ipv6 upstream What on earth has this to do with d-i or ipv6?! > 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.N and you expect VLAN-tagged packets that arrive on eth0 to be forwarded through br1, not br0? Ben. -- Ben Hutchings When in doubt, use brute force. - Ken Thompson signature.asc Description: This is a digitally signed message part
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 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f1c4281.6010...@pekarek.at
Bug#656754: linux-image-2.6.39-bpo.2-amd64: vlan malfunction
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. signature.asc Description: This is a digitally signed message part
Bug#656754: linux-image-2.6.39-bpo.2-amd64: vlan malfunction
Ben Hutchings (ben) writes: > > > > 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). That is, unfortunately, not the case. Ganeti, and other virtualization solutions built on top of Xen and KVM, makes use of bridges to attach VMs to the underlying interface. The underlying interface could be anything: vlan, raw ethernet, bond'ed link, etc... This works fine on 2.6.32, as was pointed out, but fails afterwards. I've tried with 3.2 and 3.5, and the bug persists. My setup is as described earlier by Erich: br0: eth0 (for management) br1: eth0.3 br2: eth0.4 brX: eth0.X ... with the IP for management on br0. This, by the way, works with bonded interfaces as well on 2.6.32: br0: bond0: eth0 + eth1 br1: bond0.3 br2: bond0.4 ... On 3.2, this stopped working. At first I thought it was the bond interface, so I attempted to run directly on eth0.* - but that didn't help. Then I suspected an issue with mixing tagged and untagged + bridging. And since mixing tagged and untagged on the same link is usually not a good idea, I reconfigured everything to run in trunked/.1q, not using eth0 for any IP traffic directly: br0: eth0.100 (now using a tagged vlan for the management IP) br1: eth0.3 etc... ... but this doesn't work in 3.2+ It might not be Debian specific, but nevertheless it's a showstopper... If this configuration is not supported, what is the suggested alternative ? KVM and other hypervisors need a bridge to attach VMs to: how is one supposed to host different VMs on different subnets on a single machine ? (Something easily done on 2.6.32, or even on FreeBSD or VMWware) ? I could try OpenvSwitch... Thanks, Phil pgpFwKdL3X3jS.pgp Description: PGP signature
Bug#656754: linux-image-2.6.39-bpo.2-amd64: vlan malfunction
Please open a new bug report; you seem to be describing a different problem. Ben. -- Ben Hutchings Man invented language to satisfy his deep need to complain. - Lily Tomlin signature.asc Description: This is a digitally signed message part
