vboxnetflt: packets were not sent

[Courrie]

Hello,

I'm having problems using bridged networking with an Arch Linux host, the guest - originally windows, but it doesn't work with the Arch Linux live ISO either - isn't able to send or receive any packets. I can see the broadcasts in Wireshark on the host, but not from a computer in the same network and the guest isn't getting an IP.

Software I've tried (everything 64bit):

• Virtualbox 5.1.18 with dkms and Linux 4.10.4 (current and up to date)
• Virtualbox 5.1.14 with dkms and Linux 4.9.9
• Virtualbox 5.1.12 with dkms and Linux 4.9.1

Kernel log while running the VM, running dhcpcd and shutting down:

Code: Select all

kern  :warn  : [Thu Mar 23 09:23:13 2017] vboxdrv: ffffffffa0ad9020 VMMR0.r0
kern  :warn  : [Thu Mar 23 09:23:13 2017] vboxdrv: ffffffffa0bdb020 VBoxDDR0.r0
kern  :warn  : [Thu Mar 23 09:23:13 2017] VBoxNetFlt: attached to 'enp8s0' / 50:e5:49:c9:59:e1
kern  :info  : [Thu Mar 23 09:23:13 2017] device enp8s0 entered promiscuous mode
kern  :info  : [Thu Mar 23 09:24:47 2017] device enp8s0 left promiscuous mode
kern  :warn  : [Thu Mar 23 09:24:47 2017] vboxnetflt: 0 out of 36 packets were not sent (directed to host)

Thanks,
Courrie

[socratis]

What is "enp8s0", wired or wireless?

[Courrie]

Wired, there's no wireless card in the computer.

[Perryg]

Post the results of the following run from the host terminal:

Code: Select all

VBoxManage list bridgedifs

[Courrie]

Code: Select all

$ VBoxManage list bridgedifs
Name:            enp8s0
GUID:            38706e65-3073-4000-8000-50e549c959e1
DHCP:            Disabled
IPAddress:       192.168.1.111
NetworkMask:     255.255.255.0
IPV6Address:     fe80:0000:0000:0000:585b:4b2c:7e61:76a5
IPV6NetworkMaskPrefixLength: 64
HardwareAddress: 50:e5:49:c9:59:e1
MediumType:      Ethernet
Status:          Up
VBoxNetworkName: HostInterfaceNetworking-enp8s0

[Perryg]

I see in the log that you are running the (OSE) version which usually indicates a distro fork, is this true? I also see that VirtualBox is having issues detection the actual keyboard which sometimes means that the VirtualBox source has been altered.

Now back to your network issue. The bridged adapter is being passed to the guest as evident in the log and the host side sees the bridgedifs as proper, so the issue more than likely is in the guest somehow or there is an issue with the source which may have been altered by the distro. Question: if you switch to NAT instead of bridged can you get an IP address in the live CD guest?

[Courrie]

I'm using the package provided by my distribution. They are applying six patches:

git . archlinux . org/svntogit/community.git/tree/trunk?h=packages/virtualbox&id=1b18587a4fd261e7da6e9474a3c01dc087ae58e3

(sorry, I can't post links yet)

Yes, NAT works without any problem in both guests. I need the bridge for the Windows guest but while trying to isolate the issue I found that the problem is independent from the guest (Windows 7 and Arch Linux live CD).

[Perryg]

I am at a loss as to what it could be at this point. It appears that the host side code is not behaving and if that is the case you really should ask the actual maintainer what the issue might be.

[Courrie]

I just uninstalled the OSE version, installed the non-OSE version without any patches, unloaded every vbox module, loaded the new vbox modules and it still doesn't work (still VirtualBox 5.1.18 with Linux 4.10.4).

I'm open to any solution which exposes the guest to the real network and enables the guest to broadcast and open ports. I've tried to manually bridge a host-only network using bridge-utils (brctl) but I don't know much about networking so it didn't work.

[Perryg]

Have you checked your router to make sure that it is not the cause? Some restriction like MAC filtering..? Or even a firewall issue on the host?

[Courrie]

I can't access the router (or any of the switches) but I know that there's no MAC filtering. And I've disabled the firewall on the host.
/edit: I changed the MAC address of the virtual device to the real MAC address (neither a permanent nor a good solution, I know) and it now works. Looks like it has something to do with the switch.

Thanks for your help.