Public bug reported:
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 PROTECTED]>
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:
==================================
[EMAIL PROTECTED]:~$ 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
[EMAIL PROTECTED]:~$ 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
[EMAIL PROTECTED]:~$ 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
[EMAIL PROTECTED]:~$
==================================
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
** Affects: bridge-utils (Ubuntu)
Importance: Undecided
Status: New
--
br0: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM feature.
https://bugs.launchpad.net/bugs/274298
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
