BUG SUSPECTED - Bridged nw fails - Mojave host, Ubuntu guest

[dls]

See my later comments in responses to this post for why I think there's a bug here.

I see this topic recurring on these forums in various manifestations, and I also haven't had success with resolving my case:

Host is Mojave 10.14.1
Fresh install of Virtualbox 5.2.22 r126460 (Qt5.6.3)
New VM created with default NAT networking. Ubuntu 18.04.1 freshly installed
NAT networking works fine.

Attempted to switch adapter 1 to Bridged networking.
Bridged networking fails: Connection failed: Activation of network connection failed

I've tried Bridged networking with Promiscuous mode: Allow all, and Deny.
Tried rebooting multiple times.
Tried configuring the VM to a second adapter and rebooting.

[I also later tried creating a second VM and configuring it to use bridged networking before I first booted it, then testing with "Try Ubuntu without installing". Networking still failed.]

Reviewed many of the related threads here and tried their suggestions.

ifconfig on the guest VM:

Code: Select all

ifconfig
enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 08:00:27:ab:e1:8a  txqueuelen 1000  (Ethernet)
        RX packets 1556  bytes 156654 (156.6 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1771  bytes 314299 (314.2 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 156  bytes 10838 (10.8 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 156  bytes 10838 (10.8 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ON THE MAC HOST ifconfig output is:
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
	options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
	inet 127.0.0.1 netmask 0xff000000 
	inet6 ::1 prefixlen 128 
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
	nd6 options=201<PERFORMNUD,DAD>
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
EHC29: flags=0<> mtu 0
XHC20: flags=0<> mtu 0
EHC26: flags=0<> mtu 0
en3: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
	options=60<TSO4,TSO6>
	ether 32:00:18:79:0a:c0 
	media: autoselect <full-duplex>
	status: inactive
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	ether 14:10:9f:f3:cd:52 
	inet6 fe80::448:6941:4c3b:d93a%en0 prefixlen 64 secured scopeid 0x8 
	inet 192.168.1.9 netmask 0xffffff00 broadcast 192.168.1.255
	nd6 options=201<PERFORMNUD,DAD>
	media: autoselect
	status: active
p2p0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2304
	ether 06:10:9f:f3:cd:52 
	media: autoselect
	status: inactive
awdl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1484
	ether 26:50:bb:58:eb:b7 
	inet6 fe80::2450:bbff:fe58:ebb7%awdl0 prefixlen 64 scopeid 0xa 
	nd6 options=201<PERFORMNUD,DAD>
	media: autoselect
	status: active
bridge0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	options=63<RXCSUM,TXCSUM,TSO4,TSO6>
	ether 32:00:18:79:0a:c0 
	Configuration:
		id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0
		maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
		root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0
		ipfilter disabled flags 0x2
	member: en3 flags=3<LEARNING,DISCOVER>
	        ifmaxaddr 0 port 7 priority 0 path cost 0
	nd6 options=201<PERFORMNUD,DAD>
	media: <unknown type>
	status: inactive
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 2000
	inet6 fe80::b3c:3fc9:311:d49d%utun0 prefixlen 64 scopeid 0xc 
	nd6 options=201<PERFORMNUD,DAD>
vboxnet0: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	ether 0a:00:27:00:00:00

[dls]

After much frustration, I paused & saved the virtual machine with NAT configured and put this problem aside for several days. I then happened to be on another network, and restarted the VM, switched the networking to Bridged and it worked without any sign of a problem. Later I returned to the original network, rebooted the VM and it again successfully connected with Bridged networking.

I don't dare reset to NAT to test switching back again!

I don't consider this problem resolved as the only configuration difference now is one that I'd already tried many times unsuccessfully. I'm inclined to think there's still a problem that will return if I need to switch networking again.

[dls]

Back on the original network again.

I created a cloned of the VM with Bridged networking. Boot the clone - network connection failed.
I switched the clone VM networking to NAT - works fine.

Paused the VM, saved it, changed the network setting of the clone to Bridged and powered it back on => Bridged networking connection failed.

Looks to me like a bug with sporadic workable behaviour

[andyp73]

As a general rule, if you are having issues and want people to give help / guidance posting the VBox.log file from the guest is an enormous help. It lets us see what your configuration is and any issues that VirtualBox has detected along the way.

You haven't stated which of the hosts adapters you are bridging the guest to. From the host ifconfig output the only adapter that has an IP address is the en3 interface so do we assume that is what you are trying to bridge to. On my 2017 iMac en3 is the Wi-Fi adapter and bridged networking doesn't work with any guest.

As you probably read in other posts, bridged networking isn't part of the wireless networking standards (IEEE 802.11 if memory serves) and so there is no requirement for vendors to implement this functionality. Some vendors do implement support in their device drivers, some don't and the quality of the implementation varies. There are some combinations of Wi-Fi hardware, device driver, access point, etc. that don't work and there is nothing the VirtualBox devs can do about it.

If you are using a wired interface and bridged networking isn't working then that is a whole different story...

-Andy.

[dls]

Thanks for your comments, I now understand the issue. I didn't seen the posts you refer to despite reading through forums for well over an hour.
I'm new to VirtualBox & this forum, so thanks for the suggestion about Vbox.log.

Yes, I am trying to bridge to the host Wi-Fi adapter.
Even after several decades in the industry I don't expect I should have to be closely familiar with every standard/specification of the underlying systems I'm attempting to use.

Can I request the devs to enhance Virtualbox to not allow one to configure unsupported capabilities, or at least provide a warning.