https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775266
Package: virtualbox
Version: 4.3.20-dfsg-1
Severity: important
When using virtualbox VMs in Bridge Network mode, there are serious
problems.
ON the host, I have a custom bridge configured.
4: lxcbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether fe:f6:f2:03:7e:33 brd ff:ff:ff:ff:ff:ff
inet 172.16.10.1/16 brd 172.16.255.255 scope global lxcbr0
valid_lft forever preferred_lft forever
inet6 fe80::a0ef:b5ff:fe4a:215c/64 scope link
valid_lft forever preferred_lft forever
# This bridge will is used to NAT LXC containers' traffic
auto lxcbr0
iface lxcbr0 inet static
bridge_fd 0
bridge_maxwait 0
address 172.16.10.1
netmask 255.255.0.0
pre-up brctl addbr lxcbr0
post-down brctl delbr lxcbr0
post-down echo 0 > /proc/sys/net/ipv4/ip_forward
post-down echo 0 > /proc/sys/net/ipv6/conf/all/forwarding
post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
post-up iptables -A FORWARD -i lxcbr0 -s 172.16.10.1/16 -j ACCEPT
post-up iptables -A POSTROUTING -t nat -s 172.16.10.1/16 -j MASQUERADE
# add checksum so that dhclient does not complain.
# udp packets staying on the same host never have a checksum filled else
post-up iptables -A POSTROUTING -t mangle -p udp --dport bootpc -s 172.16.10.1/16 -j CHECKSUM --checksum-fill
pre-down iptables -D FORWARD -i lxcbr0 -s 172.16.10.1/16 -j ACCEPT
pre-down iptables -D POSTROUTING -t nat -s 172.16.10.1/16 -j MASQUERADE
# add checksum so that dhclient does not complain.
# udp packets staying on the same host never have a checksum filled else
pre-down iptables -D POSTROUTING -t mangle -p udp --dport bootpc -s 172.16.10.1/16 -j CHECKSUM --checksum-fill
The LXC containers, attached to the bridge, work perfect.
The VBox VMs, attached to the same brdige, ping in the beginning, but
_eventually_ cannot do any network. THe netwrok start to time out. The
VMs to have their link status.
Looking into the Host's dmesg shows:
[ 756.958798] nspr-3[6988]: segfault at 8 ip 00007f0cbcbf285c sp 00007f0ca80b7670 error 4 in VBoxXPCOM.so[7f0cbcb9b000+fe000]
My intent is to have a custom bridge interface, which I hand control.
THen, to it I'd like to attach everythign: KVM, VBox, LXC etc, and let
them all talk to each other.
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages virtualbox depends on:
ii adduser 3.113+nmu3
ii dpkg 1.17.23
ii libc6 2.19-13
ii libcurl3-gnutls 7.38.0-4
ii libgcc1 1:4.9.1-19
ii libgsoap5 2.8.17-1
ii libpng12-0 1.2.50-2+b2
ii libpython2.7 2.7.8-11
ii libsdl1.2debian 1.2.15-10+b1
ii libssl1.0.0 1.0.1j-1
ii libstdc++6 4.9.1-19
ii libvncserver0 0.9.9+dfsg-6.1
ii libvpx1 1.3.0-3
ii libx11-6 2:1.6.2-3
ii libxcursor1 1:1.1.14-1+b1
ii libxext6 2:1.3.3-1
ii libxml2 2.9.1+dfsg1-4
ii libxmu6 2:1.1.2-1
ii libxt6 1:1.1.4-1+b1
ii python 2.7.8-2
ii python2.7 2.7.8-11
ii zlib1g 1:1.2.8.dfsg-2+b1
Versions of packages virtualbox recommends:
ii libgl1-mesa-glx [libgl1] 10.3.2-1
ii libqt4-opengl 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii libqtcore4 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii libqtgui4 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii virtualbox-dkms 4.3.20-dfsg-1
ii virtualbox-qt 4.3.20-dfsg-1
Versions of packages virtualbox suggests:
ii vde2 2.3.2+r586-1
ii virtualbox-guest-additions-iso 4.3.20-1
-- no debconf information
Message #10 received at 775266@bugs.debian.org (full text, mbox, reply):
From: Ritesh Raj Sarraf <rrs@researchut.com>
To: 775266@bugs.debian.org
Subject: Fwd: Re: [vbox-dev] Custom Bridge Interface
Date: Wed, 14 Jan 2015 00:36:30 +0530
[Message part 1 (text/plain, inline)]
[Re: [vbox-dev] Custom Bridge Interface.eml (message/rfc822, attachment)]
[Re: [vbox-dev] Custom Bridge Interface.eml (message/rfc822, attachment)]
[Re: [vbox-dev] Custom Bridge Interface.eml (message/rfc822, attachment)]
[Re: [vbox-dev] Custom Bridge Interface.eml (message/rfc822, attachment)]
[Re: [vbox-dev] Custom Bridge Interface.eml (message/rfc822, attachment)]
[Re: [vbox-dev] Custom Bridge Interface.eml (message/rfc822, attachment)]
[signature.asc (application/pgp-signature, attachment)]
Message #15 received at 775266@bugs.debian.org (full text, mbox, reply):
From: Ritesh Raj Sarraf <rrs@researchut.com>
Cc: 775266@bugs.debian.org
Subject: Re: Custom Bridge Interface
Date: Wed, 14 Jan 2015 23:57:35 +0530
Adding Debian Bug report in CC. On 01/13/2015 10:56 PM, Klaus Espenlaub wrote: > Ritesh, > > On 13.01.2015 12:54, Ritesh Raj Sarraf wrote: >> Does VBox support attaching to a custom bridge interface in "Bridge >> Networking Mode" ?? > > What you're calling a "custom bridge interface" is simply a Linux bridge. > > You can directly bridge in VBox to such a device. I know multiple users > who use this successfully. > Thank you Klaus, for confirming. T As I had expected, my network config stands correct. But I still need to root cause what freezes the network at times, when both the VMs and the Containers access the network simultaneously. The odd part is that the issue is very sporadic. I haven't been able to conclude a persistent pattern, to report a bug upstream. > >> [ 756.958798] nspr-3[6988]: segfault at 8 ip 00007f0cbcbf285c sp >> 00007f0ca80b7670 error 4 in VBoxXPCOM.so[7f0cbcb9b000+fe000] > > This is a crash in the xpcom middleware VBox uses for its API, and > that's far, far away from the actual network functionality. > > Which VBox build do you use? One from debian? Then install the matching > debug info package(s), make sure that core dumps are enabled (hints see > https://www.virtualbox.org/wiki/Core_dump ), and once you have a core > you can use gdb to find out where things have crashed... postponing a > detailed recipe to avoid wasting time if you know what to do. > Yes. The build is from Debian. Me and Gianfranco currently maintain VBox for Debian (and derivatives). I'll get you the required info soon. Something else came up inbetween. >> Please see Debian Bug report for more details: >> http://bugs.debian.org/775266 > > Helpful, but still not very detailed... no hint how the VM is configured. > > Klaus > The config is simple. You already must have seen the bridge's (lxcbr0) config details in the debian bug report. I use both Containers, and VBox VMs to connect to the bridge for all network related stuff. My intent is to use Containers and VMs on the same network and make them reachable to each other. For the VMs, I use the network setting "Attached to Bridge Adapter" and the bridge interface I choose is "lxcbr0". Under "Advanced Settings", I've chosen "Promiscuous Mode" to "Allow All" With the above setting, I boot a VM and it can access the network / internet. BTW, When I start the VM, on the host, I see the following in dmesg. [44838.685860] device lxcbr0 entered promiscuous mode Here's what the syslog says to the guest VM, upon providing the network (dhcp service is provided by dnsmasq on the host). Jan 14 23:43:43 learner kernel: [45356.381385] vboxdrv: Found 8 processor cores. Jan 14 23:43:43 learner kernel: [45356.381552] vboxdrv: fAsync=0 offMin=0x1b0 offMax=0xebb Jan 14 23:43:43 learner kernel: [45356.381636] vboxdrv: TSC mode is 'synchronous', kernel timer mode is 'normal'. Jan 14 23:43:43 learner kernel: [45356.381638] vboxdrv: Successfully loaded version 4.3.20_Debian (interface 0x001a0008). Jan 14 23:43:43 learner virtualbox[15064]: Starting VirtualBox kernel modules. Jan 14 23:43:43 learner kernel: [45356.391613] vboxpci: IOMMU not found (not registered) Jan 14 23:43:56 learner kernel: [45369.535587] device lxcbr0 entered promiscuous mode Jan 14 23:44:11 learner dnsmasq[14939]: reading /var/run/dnsmasq/resolv.conf Jan 14 23:44:11 learner dnsmasq[14939]: using nameserver 8.8.8.8#53 Jan 14 23:44:11 learner dnsmasq[14939]: using nameserver 8.8.4.4#53 Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 available DHCP range: 172.16.10.10 -- 172.16.10.200 Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 client provides name: debian Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 DHCPDISCOVER(lxcbr0) 172.16.10.40 08:00:27:d6:62:9a Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 tags: lxcbr0 Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 DHCPOFFER(lxcbr0) 172.16.10.40 08:00:27:d6:62:9a Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 requested options: 1:netmask, 28:broadcast, 2:time-offset, 3:router, Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 requested options: 15:domain-name, 6:dns-server, 119:domain-search, Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 requested options: 12:hostname, 44:netbios-ns, 47:netbios-scope, Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 requested options: 26:mtu, 121:classless-static-route, 42:ntp-server Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 next server: 172.16.10.1 Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 sent size: 1 option: 53 message-type 2 Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 sent size: 4 option: 54 server-identifier 172.16.10.1 Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 sent size: 4 option: 51 lease-time 1h Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 sent size: 4 option: 58 T1 30m Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 sent size: 4 option: 59 T2 52m30s Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 sent size: 4 option: 1 netmask 255.255.0.0 Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 sent size: 4 option: 28 broadcast 172.16.255.255 Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 sent size: 4 option: 3 router 172.16.10.1 Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 sent size: 4 option: 6 dns-server 172.16.10.1 Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 sent size: 9 option: 15 domain-name lxc.local Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 available DHCP range: 172.16.10.10 -- 172.16.10.200 Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 client provides name: debian Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 DHCPREQUEST(lxcbr0) 172.16.10.40 08:00:27:d6:62:9a Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 tags: lxcbr0 Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 DHCPACK(lxcbr0) 172.16.10.40 08:00:27:d6:62:9a debian Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 requested options: 1:netmask, 28:broadcast, 2:time-offset, 3:router, Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 requested options: 15:domain-name, 6:dns-server, 119:domain-search, Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 requested options: 12:hostname, 44:netbios-ns, 47:netbios-scope, Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 requested options: 26:mtu, 121:classless-static-route, 42:ntp-server Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 next server: 172.16.10.1 Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 sent size: 1 option: 53 message-type 5 Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 sent size: 4 option: 54 server-identifier 172.16.10.1 Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 sent size: 4 option: 51 lease-time 1h Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 sent size: 4 option: 58 T1 30m Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 sent size: 4 option: 59 T2 52m30s Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 sent size: 4 option: 1 netmask 255.255.0.0 Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 sent size: 4 option: 28 broadcast 172.16.255.255 Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 sent size: 4 option: 3 router 172.16.10.1 Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 sent size: 4 option: 6 dns-server 172.16.10.1 Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 sent size: 9 option: 15 domain-name lxc.local Jan 14 23:44:11 learner dnsmasq-dhcp[14939]: 3735664666 sent size: 6 option: 12 hostname debian And then I fire up an Ubuntu Container. It too acquires the IP. Following is the host logs for the same. Jan 14 23:46:32 learner kernel: [45525.019745] device vethHF250W entered promiscuous mode Jan 14 23:46:32 learner kernel: [45525.019822] IPv6: ADDRCONF(NETDEV_UP): vethHF250W: link is not ready Jan 14 23:46:32 learner avahi-daemon[2448]: Withdrawing workstation service for vethM3U37T. Jan 14 23:46:32 learner kernel: [45525.095210] IPv6: ADDRCONF(NETDEV_CHANGE): vethHF250W: link becomes ready Jan 14 23:46:32 learner kernel: [45525.095253] lxcbr0: port 1(vethHF250W) entered forwarding state Jan 14 23:46:32 learner kernel: [45525.095260] lxcbr0: port 1(vethHF250W) entered forwarding state Jan 14 23:46:33 learner avahi-daemon[2448]: Joining mDNS multicast group on interface vethHF250W.IPv6 with address fe80::fc3f:3bff:feaa:4d08. Jan 14 23:46:33 learner avahi-daemon[2448]: New relevant interface vethHF250W.IPv6 for mDNS. Jan 14 23:46:33 learner avahi-daemon[2448]: Registering new address record for fe80::fc3f:3bff:feaa:4d08 on vethHF250W.*. Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 available DHCP range: 172.16.10.10 -- 172.16.10.200 Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 client provides name: trusty-test Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 DHCPDISCOVER(lxcbr0) 172.16.10.45 00:16:3e:91:1d:83 Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 tags: lxcbr0 Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 DHCPOFFER(lxcbr0) 172.16.10.45 00:16:3e:91:1d:83 Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 requested options: 1:netmask, 28:broadcast, 2:time-offset, 3:router, Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 requested options: 15:domain-name, 6:dns-server, 119:domain-search, Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 requested options: 12:hostname, 44:netbios-ns, 47:netbios-scope, Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 requested options: 26:mtu, 121:classless-static-route, 42:ntp-server Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 next server: 172.16.10.1 Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 sent size: 1 option: 53 message-type 2 Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 sent size: 4 option: 54 server-identifier 172.16.10.1 Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 sent size: 4 option: 51 lease-time 1h Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 sent size: 4 option: 58 T1 30m Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 sent size: 4 option: 59 T2 52m30s Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 sent size: 4 option: 1 netmask 255.255.0.0 Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 sent size: 4 option: 28 broadcast 172.16.255.255 Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 sent size: 4 option: 3 router 172.16.10.1 Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 sent size: 4 option: 6 dns-server 172.16.10.1 Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 sent size: 9 option: 15 domain-name lxc.local Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 available DHCP range: 172.16.10.10 -- 172.16.10.200 Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 client provides name: trusty-test Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 DHCPREQUEST(lxcbr0) 172.16.10.45 00:16:3e:91:1d:83 Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 tags: lxcbr0 Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 DHCPACK(lxcbr0) 172.16.10.45 00:16:3e:91:1d:83 trusty-test Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 requested options: 1:netmask, 28:broadcast, 2:time-offset, 3:router, Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 requested options: 15:domain-name, 6:dns-server, 119:domain-search, Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 requested options: 12:hostname, 44:netbios-ns, 47:netbios-scope, Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 requested options: 26:mtu, 121:classless-static-route, 42:ntp-server Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 next server: 172.16.10.1 Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 sent size: 1 option: 53 message-type 5 Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 sent size: 4 option: 54 server-identifier 172.16.10.1 Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 sent size: 4 option: 51 lease-time 1h Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 sent size: 4 option: 58 T1 30m Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 sent size: 4 option: 59 T2 52m30s Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 sent size: 4 option: 1 netmask 255.255.0.0 Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 sent size: 4 option: 28 broadcast 172.16.255.255 Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 sent size: 4 option: 3 router 172.16.10.1 Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 sent size: 4 option: 6 dns-server 172.16.10.1 Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 sent size: 9 option: 15 domain-name lxc.local Jan 14 23:46:35 learner dnsmasq-dhcp[14939]: 3088368720 sent size: 11 option: 12 hostname trusty-test Jan 14 23:46:47 learner kernel: [45540.154482] lxcbr0: port 1(vethHF250W) entered forwarding state And at this point, at times, the VBox VM connection is like frozen. rrs@learner:/var/tmp/Debian-Build/temp/stevedore (debian/unstable)$ ping 172.16.10.40 PING 172.16.10.40 (172.16.10.40) 56(84) bytes of data. From 172.16.10.1 icmp_seq=1 Destination Host Unreachable From 172.16.10.1 icmp_seq=2 Destination Host Unreachable From 172.16.10.1 icmp_seq=3 Destination Host Unreachable From 172.16.10.1 icmp_seq=4 Destination Host Unreachable ^C^C --- 172.16.10.40 ping statistics --- 7 packets transmitted, 0 received, +4 errors, 100% packet loss, time 6033ms Even pinging the VMs gateway, which is the host bridge's IP, fails. At this point, even restarting the VM doesn't help. On next boot, it is unable to acquire the DHCP IP, even though the host logs show that the DHCP server is offering the IP. Jan 14 23:55:00 learner dnsmasq-dhcp[14939]: 3770987320 DHCPOFFER(lxcbr0) 172.16.10.40 08:00:27:d6:62:9a Jan 14 23:55:00 learner dnsmasq-dhcp[14939]: 3770987320 requested options: 1:netmask, 28:broadcast, 2:time-offset, 3:router, Jan 14 23:55:00 learner dnsmasq-dhcp[14939]: 3770987320 requested options: 15:domain-name, 6:dns-server, 119:domain-search, Jan 14 23:55:00 learner dnsmasq-dhcp[14939]: 3770987320 requested options: 12:hostname, 44:netbios-ns, 47:netbios-scope, Jan 14 23:55:00 learner dnsmasq-dhcp[14939]: 3770987320 requested options: 26:mtu, 121:classless-static-route, 42:ntp-server Jan 14 23:55:00 learner dnsmasq-dhcp[14939]: 3770987320 next server: 172.16.10.1 Jan 14 23:55:00 learner dnsmasq-dhcp[14939]: 3770987320 sent size: 1 option: 53 message-type 2 Jan 14 23:55:00 learner dnsmasq-dhcp[14939]: 3770987320 sent size: 4 option: 54 server-identifier 172.16.10.1 Jan 14 23:55:00 learner dnsmasq-dhcp[14939]: 3770987320 sent size: 4 option: 51 lease-time 1h Jan 14 23:55:00 learner dnsmasq-dhcp[14939]: 3770987320 sent size: 4 option: 58 T1 30m Jan 14 23:55:00 learner dnsmasq-dhcp[14939]: 3770987320 sent size: 4 option: 59 T2 52m30s Jan 14 23:55:00 learner dnsmasq-dhcp[14939]: 3770987320 sent size: 4 option: 1 netmask 255.255.0.0 Jan 14 23:55:00 learner dnsmasq-dhcp[14939]: 3770987320 sent size: 4 option: 28 broadcast 172.16.255.255 Jan 14 23:55:00 learner dnsmasq-dhcp[14939]: 3770987320 sent size: 4 option: 3 router 172.16.10.1 Jan 14 23:55:00 learner dnsmasq-dhcp[14939]: 3770987320 sent size: 4 option: 6 dns-server 172.16.10.1 Jan 14 23:55:00 learner dnsmasq-dhcp[14939]: 3770987320 sent size: 9 option: 15 domain-name lxc.local Interestingly, this isn't a persistent behavior. At times, the network functions for a couple of minutes, before going lost. But on the Container, the connectivity is perfect. Thus I concluded this to be a VBox problem and NOT a Bridging problem. Klaus: If you need more information, please do let me know. Thanks, Ritesh -- Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response
Message #20 received at 775266@bugs.debian.org (full text, mbox, reply):
From: Ritesh Raj Sarraf <rrs@researchut.com>
To: 775266@bugs.debian.org
Subject: Re: Bug#775266: virtualbox networking problems in bridge mode
Date: Wed, 04 Nov 2015 13:31:08 +0530
[Message part 1 (text/plain, inline)]
On Tue, 2015-01-13 at 17:00 +0530, Ritesh Raj Sarraf wrote: > > My intent is to have a custom bridge interface, which I hand control. > THen, to it I'd like to attach everythign: KVM, VBox, LXC etc, and > let > them all talk to each other. The issue can now be confirmed to be a problem specific to VBox. I just switched the hypervisor to KVM and everything, in the same use case, works perfect. For vbox, I get the following. In that, the interesting line is: [37967.268511] vboxnetflt: 1693 out of 1820 packets were not sent (directed to host) [36771.944022] mce: [Hardware Error]: Machine check events logged [37117.156962] vboxdrv: ffffffffa0dae020 VMMR0.r0 [37117.307043] vboxdrv: ffffffffa0ea8020 VBoxDDR0.r0 [37117.310100] vboxdrv: ffffffffa0005020 VBoxDD2R0.r0 [37117.322672] VBoxNetFlt: attached to 'lxcbr0' / 96:07:08:fd:b1:af [37118.406945] device lxcbr0 entered promiscuous mode [37122.599766] device lxcbr0 left promiscuous mode [37126.331558] vboxnetflt: 0 out of 0 packets were not sent (directed to host) [37165.472580] vboxdrv: ffffffffa0dae020 VMMR0.r0 [37165.634561] vboxdrv: ffffffffa0ea8020 VBoxDDR0.r0 [37165.637089] vboxdrv: ffffffffa0005020 VBoxDD2R0.r0 [37165.648193] VBoxNetFlt: attached to 'lxcbr0' / 96:07:08:fd:b1:af [37166.776050] device lxcbr0 entered promiscuous mode [37369.560784] ip6_tables: (C) 2000-2006 Netfilter Core Team [37679.891682] IPv6: ADDRCONF(NETDEV_UP): vb-fedoraTempl: link is not ready [37679.891809] device vb-fedoraTempl entered promiscuous mode [37679.891872] lxcbr0: port 2(vb-fedoraTempl) entered forwarding state [37679.891913] lxcbr0: port 2(vb-fedoraTempl) entered forwarding state [37679.894684] lxcbr0: port 2(vb-fedoraTempl) entered disabled state [37681.192591] IPv6: ADDRCONF(NETDEV_CHANGE): vb-fedoraTempl: link becomes ready [37681.192867] lxcbr0: port 2(vb-fedoraTempl) entered forwarding state [37681.192920] lxcbr0: port 2(vb-fedoraTempl) entered forwarding state [37696.204504] lxcbr0: port 2(vb-fedoraTempl) entered forwarding state [37964.188986] device lxcbr0 left promiscuous mode [37967.268511] vboxnetflt: 1693 out of 1820 packets were not sent (directed to host) [38054.862510] Ebtables v2.0 registered [38397.343581] tun: Universal TUN/TAP device driver, 1.6 [38397.343587] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com> [38397.395139] device vnet0 entered promiscuous mode [38397.427568] lxcbr0: port 3(vnet0) entered forwarding state [38397.427614] lxcbr0: port 3(vnet0) entered forwarding state [38398.370910] kvm: zapping shadow pages for mmio generation wraparound [38398.378587] kvm: zapping shadow pages for mmio generation wraparound [38412.488240] lxcbr0: port 3(vnet0) entered forwarding state [38951.067857] VBoxPciLinuxLinuxUnload 2015-11-04 / 13:25:52 ♒♒♒ ☺ -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention."