Bridged network fails

[andyp73]

Here's the output from ifconfig

Is the output you posted from running "ifconfig" or from running "ifconfig -a"?

I also have a problem with that "eno1" thing.

It is perfectly possible in Ubuntu to disable the inherited firmware generated names (needs extra kernel command line parameters defining in Grub) and to assign any old name you want through a udev rule. It is something that was quite common for a long time as some license management tools would only work with ethx style network names and not with the default enp0s3 type names.

-Andy.

[socratis]

It is perfectly possible in Ubuntu to disable the inherited firmware generated names (needs extra kernel command line parameters defining in Grub)

So, what we're talking about then is a really custom installation, right? I'm not quite sure how to go about addressing that, but I guess we'll have to wait for the OP to see what they have to say.

[TikiMojo]

"eno1" is the only option for ethernet adaptor in virtualbox UI. See screenshots above.

[TikiMojo]

The output above was from just "ifconfig". To compare I just ran "ifconfig -a" and it produced the same output.

You're probably familiar with the commercial product called "Parallels". I have that at my home office, but not here as I suspect I won't be able to convince the boss into investing into software purchase... Ubuntu 16.04 guest OS on Parallels has no problem with the bridged network. Why it doesn't work here... The mystery continues...

[TikiMojo]

any further hints on how to get the bridging network to work here?

[Martin]

Is this on a wired connection or on wireless?
Did you make sure that no firewall blocks the bridged connection on the host?

[TikiMojo]

All the machines I'm testing this on are plugged into our good friend, the wired ethernet.

I'm not aware of any firewalls of any kind between the guest OS and the outside internet. This is a very small office, with all the up-sides and down-sides that come with that.

At the end of the day my personal work can be done with the regular NAT network, but if I can get the bridged network functioning then I can send a URL in an email for my co-workers to review, and also fiddle with the site themselves... all for the greater glory and happy-making for everything, eh?

Is this on a wired connection or on wireless?
Did you make sure that no firewall blocks the bridged connection on the host?

[AfromtheB]

Hi,

Any updates on this issue?
Asking because I'm having a similar issue.

Mine is slightly different in that I have an OS X host (running High Sierra) and a Windows 10 guest. When using NAT all works well, but when I switch to bridged, using en0 (WiFi) as adapter, no DHCP is available inside the guest.

What I did try was using a fixed IP address inside the guest, with seems to work. But then again: I switch locations often, so a fixed IP address is not a proper solution for me.

Regards,
Arno

[socratis]

Asking because I'm having a similar issue.

Mine is slightly different

Then you shouldn't be posting here, it's easy enough to create a new thread. This is going to be a single answer deviation from the original thread/issue. If there's any continuation/follow up, I'm going to split your issue.

Is this on a wired connection or on wireless?

There is a really good reason that Martin asked that really pointed question. And that's because Bridged-over-WiFi doesn't always play nice. Bridged networking is outside the WLAN specification. It may or may not work. Some combinations of Routers/Access Points, WLAN cards and drivers work, some don't. See: Bridging & Wifi - Supported hardware and add your experience. For example, it works fine in my home, but not in my office. Same laptop, same VM.

And yes, the source of the problem (as you figured by accident) is the DHCP broadcast requests. Here's the technical explanation, pay special attention to the last paragraph:

Many wifi routers now try to use unicast link-level destination for broadcast/multicast IP destination. The reasons are explained in http://tools.ietf.org/html/draft-vyncke ... ficient-01 - that is in context of IPv6, but the same logic applies to IPv4 (IPv6 is hit harder since it relies more on multicast). Behavior varies between wifi routers, so you may get bridged setup working with some and not working with others.

If the wifi router that is not working for you just uses unicast delivery for multicast, then 4.3.16 should help (a typical packet capture can be seen in #12207). In this case the host was receiving DHCP replies intended for the guest (broadcast IP, but unicast to host MAC), but was not rewriting MAC address correctly, so the guest was not receiving the packet. If you plug another computer into the wired port of the router to capture DHCP exchange as seen on the wired side, you would see the same DHCP replies sent to ethernet broadcast on the wired connection. So this is just an optimization for wifi that some routers do.

Unfortunately - and this is orthogonal to multicast/unicast issue above - some routers will send DHCP replies to broadcast IP, but to the unicast client MAC address (i.e. guest MAC in this case) fetched from the DHCP request. These packets will never be even seen by the host. I'm afraid the packet captures in comment:14 is an example of that. In the ethernet capture you can see DHCP replies unicast to guest and in the wireless capture you don't see any replies at all. I have one router like this (though it at least uses ethernet broadcast for its DHCP NAKs, so you can see something in the wireless capture .

This latter kind of routers has problems with DHCP, but usually you can work around it by not using DHCP and using static IP instead. E.g. I cannot connect to that router of mine with DHCP, but if I use static IP in the guest then I get normal connectivity. Yes, this is suboptimal , but better than no connectivity if you must use bridged for some reason.