br0: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM feature.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
bridge-utils (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: bridge-utils
I'm running "Ubuntu 8.04.1" (Italian Locale) with all updates up to 24/9/2008
I suspect the bug to be in:
bridge-utils:
Installato: 1.2-2
Candidato: 1.2-2
Tabella versione:
*** 1.2-2 0
500 http://
100 /var/lib/
... but it might be also filed in "kernel": please advise.
I defined a series of tapX and brY devices for use with VirtualBox (I installed the closed-source version, but that is beyond the point).
This is my /etc/network/
=======
auto lo
iface lo inet loopback
#------
# permanent host interfaces
#------
# LAN -------
auto eth0 tap0 br0
iface eth0 inet manual
iface tap0 inet manual
up ifconfig $IFACE 0.0.0.0 up
down ifconfig $IFACE down
tunctl_user mauro
iface br0 inet static
address 192.168.0.5
netmask 255.255.255.0
#gateway 192.168.0.254
bridge_ports eth0 tap0
bridge_maxwait 0
#------
# WAN -------
auto eth2 tap2 tap4 br2
# physical interface to Ydea net
iface eth2 inet static
address 192.168.120.5
netmask 255.255.255.0
iface tap2 inet manual
up ifconfig $IFACE 0.0.0.0 up
down ifconfig $IFACE down
tunctl_user mauro
iface tap4 inet manual
up /root/Ydea/
down /root/Ydea/
tunctl_user mauro
iface br2 inet manual
# address 192.168.120.5
# netmask 255.255.255.0
bridge_ports tap4 tap2
bridge_maxwait 0
#------
# DMZ -------
auto tap1 tap3 br1
iface tap1 inet manual
up ifconfig $IFACE 0.0.0.0 up
down ifconfig $IFACE down
tunctl_user mauro
iface tap3 inet manual
up ifconfig $IFACE 0.0.0.0 up
down ifconfig $IFACE down
tunctl_user mauro
iface br1 inet static
address 192.168.77.5
netmask 255.255.255.0
bridge_ports tap1 tap3
bridge_maxwait 0
#------
=======
While bringing up the interfaces I see the following messages:
=======
...
Sep 25 08:51:28 heimdall kernel: [ 47.261241] ip_tables: (C) 2000-2006 Netfilter Core Team
Sep 25 08:51:28 heimdall kernel: [ 47.401043] tun: Universal TUN/TAP device driver, 1.6
Sep 25 08:51:28 heimdall kernel: [ 47.401049] tun: (C) 1999-2004 Max Krasnyansky <email address hidden>
Sep 25 08:51:28 heimdall kernel: [ 47.565493] Bridge firewalling registered
Sep 25 08:51:28 heimdall kernel: [ 47.565709] br0: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM feature.
Sep 25 08:51:28 heimdall kernel: [ 47.570157] device eth0 entered promiscuous mode
Sep 25 08:51:28 heimdall kernel: [ 47.570168] audit(122232548
Sep 25 08:51:28 heimdall kernel: [ 47.573490] device tap0 entered promiscuous mode
Sep 25 08:51:28 heimdall kernel: [ 47.573499] audit(122232548
Sep 25 08:51:28 heimdall kernel: [ 47.575940] br0: port 2(tap0) entering learning state
Sep 25 08:51:28 heimdall kernel: [ 47.575945] br0: port 1(eth0) entering learning state
Sep 25 08:51:28 heimdall kernel: [ 48.855641] br2: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM feature.
Sep 25 08:51:28 heimdall kernel: [ 48.859899] device tap4 entered promiscuous mode
Sep 25 08:51:28 heimdall kernel: [ 48.859909] audit(122232548
Sep 25 08:51:28 heimdall kernel: [ 48.866610] device tap2 entered promiscuous mode
Sep 25 08:51:28 heimdall kernel: [ 48.866620] audit(122232548
Sep 25 08:51:28 heimdall kernel: [ 48.869110] br2: port 2(tap2) entering learning state
Sep 25 08:51:28 heimdall kernel: [ 48.869115] br2: port 1(tap4) entering learning state
Sep 25 08:51:28 heimdall kernel: [ 49.068262] br1: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM feature.
Sep 25 08:51:28 heimdall kernel: [ 49.072613] device tap1 entered promiscuous mode
Sep 25 08:51:28 heimdall kernel: [ 49.072623] audit(122232548
Sep 25 08:51:28 heimdall kernel: [ 49.075919] device tap3 entered promiscuous mode
Sep 25 08:51:28 heimdall kernel: [ 49.075928] audit(122232548
Sep 25 08:51:28 heimdall kernel: [ 49.078420] br1: port 2(tap3) entering learning state
Sep 25 08:51:28 heimdall kernel: [ 49.078425] br1: port 1(tap1) entering learning state
Sep 25 08:51:28 heimdall kernel: [ 51.566701] No dock devices found.
Sep 25 08:51:29 heimdall avahi-daemon[6034]: Found user 'avahi' (UID 106) and group 'avahi' (GID 114).
Sep 25 08:51:29 heimdall avahi-daemon[6034]: Successfully dropped root privileges.
Sep 25 08:51:29 heimdall avahi-daemon[6034]: avahi-daemon 0.6.22 starting up.
Sep 25 08:51:29 heimdall avahi-daemon[6034]: Successfully called chroot().
Sep 25 08:51:29 heimdall avahi-daemon[6034]: Successfully dropped remaining capabilities.
Sep 25 08:51:29 heimdall avahi-daemon[6034]: No service file found in /etc/avahi/
Sep 25 08:51:29 heimdall avahi-daemon[6034]: Joining mDNS multicast group on interface br1.IPv4 with address 192.168.77.5.
Sep 25 08:51:29 heimdall avahi-daemon[6034]: New relevant interface br1.IPv4 for mDNS.
Sep 25 08:51:29 heimdall avahi-daemon[6034]: Joining mDNS multicast group on interface br0.IPv4 with address 192.168.0.5.
Sep 25 08:51:29 heimdall avahi-daemon[6034]: New relevant interface br0.IPv4 for mDNS.
Sep 25 08:51:29 heimdall avahi-daemon[6034]: Joining mDNS multicast group on interface eth2.IPv4 with address 192.168.120.5.
Sep 25 08:51:29 heimdall avahi-daemon[6034]: New relevant interface eth2.IPv4 for mDNS.
Sep 25 08:51:29 heimdall avahi-daemon[6034]: Network interface enumeration completed.
Sep 25 08:51:29 heimdall avahi-daemon[6034]: Registering new address record for fe80::2ff:
Sep 25 08:51:29 heimdall avahi-daemon[6034]: Registering new address record for 192.168.77.5 on br1.IPv4.
Sep 25 08:51:29 heimdall avahi-daemon[6034]: Registering new address record for fe80::2ff:
Sep 25 08:51:29 heimdall avahi-daemon[6034]: Registering new address record for fe80::2ff:
Sep 25 08:51:29 heimdall avahi-daemon[6034]: Registering new address record for fe80::2ff:
Sep 25 08:51:29 heimdall avahi-daemon[6034]: Registering new address record for fe80::2ff:
Sep 25 08:51:29 heimdall avahi-daemon[6034]: Registering new address record for fe80::2ff:
Sep 25 08:51:29 heimdall avahi-daemon[6034]: Registering new address record for fe80::211:
Sep 25 08:51:29 heimdall avahi-daemon[6034]: Registering new address record for 192.168.0.5 on br0.IPv4.
Sep 25 08:51:29 heimdall avahi-daemon[6034]: Registering new address record for fe80::2ff:
Sep 25 08:51:29 heimdall avahi-daemon[6034]: Registering new address record for fe80::211:
Sep 25 08:51:29 heimdall avahi-daemon[6034]: Registering new address record for fe80::20e:
Sep 25 08:51:29 heimdall avahi-daemon[6034]: Registering new address record for 192.168.120.5 on eth2.IPv4.
Sep 25 08:51:29 heimdall avahi-daemon[6034]: Registering HINFO record with values 'I686'/'LINUX'.
Sep 25 08:51:29 heimdall kernel: [ 53.571650] ppdev: user-space parallel port driver
Sep 25 08:51:29 heimdall kernel: [ 53.888963] audit(122232548
Sep 25 08:51:30 heimdall kernel: [ 54.173143] eth0: no IPv6 routers present
Sep 25 08:51:30 heimdall avahi-daemon[6034]: Server startup complete. Host name is heimdall.local. Local service cookie is 1221156342.
Sep 25 08:51:30 heimdall kernel: [ 54.544520] eth2: no IPv6 routers present
...
=======
Everything *seems* to work, but a couple of times I got some weird behavior with lost packets over one of the bridges; one of the occurrences looked like:
=======
mauro@heimdall:~$ ping fw
PING fw (192.168.0.15) 56(84) bytes of data.
64 bytes from fw (192.168.0.15): icmp_seq=3 ttl=64 time=0.730 ms
64 bytes from fw (192.168.0.15): icmp_seq=4 ttl=64 time=0.381 ms
64 bytes from fw (192.168.0.15): icmp_seq=9 ttl=64 time=0.383 ms
64 bytes from fw (192.168.0.15): icmp_seq=10 ttl=64 time=0.292 ms
64 bytes from fw (192.168.0.15): icmp_seq=11 ttl=64 time=0.459 ms
64 bytes from fw (192.168.0.15): icmp_seq=12 ttl=64 time=0.408 ms
64 bytes from fw (192.168.0.15): icmp_seq=16 ttl=64 time=0.903 ms
64 bytes from fw (192.168.0.15): icmp_seq=17 ttl=64 time=0.394 ms
64 bytes from fw (192.168.0.15): icmp_seq=19 ttl=64 time=0.383 ms
--- fw ping statistics ---
21 packets transmitted, 9 received, 57% packet loss, time 20003ms
rtt min/avg/max/mdev = 0.292/0.
mauro@heimdall:~$ traceroute fw
traceroute to fw (192.168.0.15), 30 hops max, 40 byte packets
1 fw (192.168.0.15) 1.980 ms 1.872 ms 1.778 ms
mauro@heimdall:~$ ping fw
PING fw (192.168.0.15) 56(84) bytes of data.
64 bytes from fw (192.168.0.15): icmp_seq=3 ttl=64 time=0.313 ms
64 bytes from fw (192.168.0.15): icmp_seq=18 ttl=64 time=0.394 ms
64 bytes from fw (192.168.0.15): icmp_seq=19 ttl=64 time=0.366 ms
64 bytes from fw (192.168.0.15): icmp_seq=20 ttl=64 time=0.393 ms
64 bytes from fw (192.168.0.15): icmp_seq=21 ttl=64 time=0.309 ms
64 bytes from fw (192.168.0.15): icmp_seq=31 ttl=64 time=0.380 ms
64 bytes from fw (192.168.0.15): icmp_seq=62 ttl=64 time=0.562 ms
64 bytes from fw (192.168.0.15): icmp_seq=63 ttl=64 time=0.369 ms
--- fw ping statistics ---
64 packets transmitted, 8 received, 87% packet loss, time 63084ms
rtt min/avg/max/mdev = 0.309/0.
mauro@heimdall:~$
=======
This pings are actually between two sides of br0:
from the ubuntu host (heimdall) to the virtual machine (fw) on the other side of br0.
How can I lose packets there??
Notice that br0 was still working somehow, I know because I had an open ssh connection to fw and that was working flawlessly; in that condition I was *not* able to initiate a second (new) ssh connection; apparently existing connections were ok but new ones had problems. Does this make any sense?
Shutting down the virtual client and networking and restarting them cures the problem (but I see the warnings again).
I found the following browsing the Internet. It could be relevant.
=======
"This means that for some reason the UFO flag has been enabled
on the bridge device without also enabling TX checksum offload.
This is an illegal configuration which is why the kernel warns
about it. As to why the UFO flag is set at all more investigation
is needed on the actual machine.
However, this is harmless as UFO isn't supported by Xen anyway."
=======
It seems this problem is known, but I didn't find a solution.
Thanks
Mauro
I'm using KVM based on Ubuntu 8.04. Guests have same OS. My problem is very similar. Bridge interface on host mashine is going down when network load grows up. To bring up guests networking I need to reboot guest systems.