Ubuntu
bridge-utils package

br0: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM feature.

Bug #274298 reported by mc5686
28
This bug affects 3 people
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://it.archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status
... 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/interfaces:
==================================
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/tap-up.sh
    down /root/Ydea/tap-down.sh
    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(1222325483.656:2): dev=eth0 prom=256 old_prom=0 auid=4294967295
Sep 25 08:51:28 heimdall kernel: [ 47.573490] device tap0 entered promiscuous mode
Sep 25 08:51:28 heimdall kernel: [ 47.573499] audit(1222325483.660:3): dev=tap0 prom=256 old_prom=0 auid=4294967295
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(1222325484.948:4): dev=tap4 prom=256 old_prom=0 auid=4294967295
Sep 25 08:51:28 heimdall kernel: [ 48.866610] device tap2 entered promiscuous mode
Sep 25 08:51:28 heimdall kernel: [ 48.866620] audit(1222325484.956:5): dev=tap2 prom=256 old_prom=0 auid=4294967295
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(1222325485.160:6): dev=tap1 prom=256 old_prom=0 auid=4294967295
Sep 25 08:51:28 heimdall kernel: [ 49.075919] device tap3 entered promiscuous mode
Sep 25 08:51:28 heimdall kernel: [ 49.075928] audit(1222325485.164:7): dev=tap3 prom=256 old_prom=0 auid=4294967295
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/services.
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:bcff:fea5:ab41 on br1.*.
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:ceff:feda:680c on tap3.*.
Sep 25 08:51:29 heimdall avahi-daemon[6034]: Registering new address record for fe80::2ff:bcff:fea5:ab41 on tap1.*.
Sep 25 08:51:29 heimdall avahi-daemon[6034]: Registering new address record for fe80::2ff:9fff:fea8:7c20 on br2.*.
Sep 25 08:51:29 heimdall avahi-daemon[6034]: Registering new address record for fe80::2ff:dbff:fe99:ea66 on tap4.*.
Sep 25 08:51:29 heimdall avahi-daemon[6034]: Registering new address record for fe80::2ff:9fff:fea8:7c20 on tap2.*.
Sep 25 08:51:29 heimdall avahi-daemon[6034]: Registering new address record for fe80::211:11ff:fe0a:23b2 on br0.*.
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:33ff:fe03:5d62 on tap0.*.
Sep 25 08:51:29 heimdall avahi-daemon[6034]: Registering new address record for fe80::211:11ff:fe0a:23b2 on eth0.*.
Sep 25 08:51:29 heimdall avahi-daemon[6034]: Registering new address record for fe80::20e:2eff:fef6:fd13 on eth2.*.
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(1222325489.984:8): type=1503 operation="inode_permission" requested_mask="a::" denied_mask="a::" name="/dev/tty" pid=6076 profile="/usr/sbin/cupsd" namespace="default"
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.481/0.903/0.189 ms
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.385/0.562/0.077 ms
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

Revision history for this message
Андрей Калинин (prize2step) wrote :

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.

Revision history for this message
Evan Charlton (evan-evancharlton) wrote :

I'm using KVM based on Ubuntu 9.04 server and am experiencing this issue. Here's what happens for me:
1) The host will lose network connection. No ping, no ssh, nothing.
2) SSH into the guest that dropped will put me into the host (note that it first warns about the SSH key changing; I have to remove the offending line from ~/.ssh/known_hosts)
3) Eventually the network will kick back on (running `ipconfig eth0 promisc` helps, in my experience) and my SSH connection to the host will be dropped (the IP gets correctly assigned back to the guest)
4) I can now SSH into both guest and host as expected.

I have not tried rebooting guest systems.

Revision history for this message
Chuck Short (zulcss) wrote :

I use to see this on previous versions of Ubuntu but dont see it anymore on Karmic so Im marking this as fixed. Please re-open if you are still having problems.

Regards
chuck

Changed in bridge-utils (Ubuntu):
status: New → Fix Released
Revision history for this message
Jan Marquardt (jm-artfiles) wrote :

We are still having this issue with Hardy. It would be great if anybody could provide a solution for this, because it slows down the boot process to a couple of minutes.

Regards,

Jan

Revision history for this message
Jan Marquardt (jm-artfiles) wrote :

Any news?

Revision history for this message
Juan J. (jjptapia) wrote :

Hi all,

  I think here is the reason:

http://linux.derkeiler.com/Mailing-Lists/Kernel/2008-12/msg06164.html

Revision history for this message
Juan J. (jjptapia) wrote :

"The bridge device always causes a warning because when it is first created
it has the no checksum flag set along with all the segmentation/fragmentation
offload bits. The code in register_netdevice incorrectly checks for only
hardware checksum bit and ignores no checksum bit."

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.