0

Using VirtualBox I created a VM with the following VirtualBox Network Settings:

Attached to: Bridged Adapter
Name: wlan0
...
..
.

wlan0 is the wireless interface of my laptop, which is connected to a home router, whose model depend of the place I was working... different places different routers models.

That setup worked well, meaning the guest OS can communicate with Internet and other PCs connected to the wireless network. My problem is when I go to some places that have a specific router model, for example model: ZXHN F660.

The problem with some of the routers models like ZXHN F660 is that the guest OS doesn't receives a DHCP reply while configuring its network interface at boot time.

I assigned an IP address to the guest OS manually to test a possible workaround, but the rate of package lost was so high, that made the network useless.

I tested configuring my host OS to not use DHCP (using static IP configuration), so in case that the router just reply one DHCP request per wireless connection, the host OS don't waste that only bullet, but nothing, even the host OS do not used DHCP to get its network configuration, the guest OS don't receive a reply from the router when try to configure its network interface at boot time. Note that I test latter with dhcpclient command and is the same.

I'm discarding some IP address limitation per wireless link cos I can ping after assign an static IP address to the guest OS (but as I said, the packages lost rate is too high).

What mechanism are using those routers to inhibit DHCP replies? Exist a workaround?

I'm on Ubuntu 14.04 with the latest VirtualBox.

EDIT

Host OS networking work well with all the routers I tested, so is discarded a problem associated with the host NIC.

3
  • @DavidSchwartz While what you wrote is completely correct, it is not the whole story: there is always proxy-arp, which I believe is what VirtualBox is using to allow you to bridge the wireless host NIC with the Ethernet guest nick. You can find here, blog.bodhizazen.net/linux/bridge-wireless-cards, a fine example of this sort of bridges. I believe the explanation for gsc-frank's problems are to be sought elsewhere. Commented Dec 21, 2014 at 19:50
  • It would be helpful if you could intercept the exchange traffic of the dhcp request. You can do that easily with tcpdump, or, even easier, with dhcpdump, both downloadable from the repos. Commented Dec 21, 2014 at 19:54
  • @MariusMatutiae The problem I'm talking about is not specific to IP, and proxy ARP won't fix it. The problem is not that remote devices don't know the hardware address, it's that the bridge is prohibited by the WiFi specification from putting packets on the wire if their hardware address doesn't match one of its clients (unless WDS is configured). Commented Jun 16, 2015 at 22:54

2 Answers 2

1

You can't bridge to a WiFi client connection. It is prohibited by the 802.11 specification. If you could, there would be no need to configure WDS in the existing access point when expanding a wireless network -- we could just make a client connection to the access point and bridge to it.

Some routers violate the 802.11 specification in various ways to make things that officially shouldn't work "just work" for the convenience of their customers. But you absolutely can't rely on it.

The problem is this -- the virtual machine and the physical machine have different network hardware addresses. By bridging to the Wifi connection, you present two different hardware addresses to the access point. But the access point only has one wireless client, and that gives it only one slot for a hardware address.

If the bridge passes the packets through with their original source hardware addresses, the 802.11 specification requires the access point to forward packets destined for only one of those hardware addresses. If the bridge passes through the packets with the same hardware address, it will have no reliable way to know which packets go to the host and which go to the VM.

The correct solution according to the 802.11 specification is WDS, which permits each wireless packet to have two destination hardware addresses, one of the wireless endpoint and one for the destination Ethernet interface. But without WDS, it can only be faked by violating the specifications.

Generally speaking, Wifi and bridging don't mix well. You can use Internet connection sharing or anything based on routing rather than bridging. Wifi is just enough like Ethernet to make people expect it to be exactly like Ethernet. But it isn't, and this is one of those places where it's really different.

1
  • Thanks for your excellent explanation, I was looking for something like that! Thanks again.
    – user193540
    Commented Jun 30, 2014 at 2:51
-1

Sadly, not all WLAN components are created equal. Even in 2014, some wireless NICs will work badly with some APs.

I am quite sure, this has nothing to do with VirtualBox - try pinging from your Host to somewhere else on the network, and I bet you will see the same packet loss.

I am also sure, that DHCP is not the reason for, but a symptom of the problem: The DHCP handshake process is very vulnerable to packet loss, so it might easily fail a few consecutive times, giving the impression of a complete failure.

Things you can try:

  • disable Wireless N mode on your NIC and/or the router/AP
  • make sure, both are in the same regulatory domain (a router set to US and a NIC set to Europe will often fail to handshake a channel)
5
  • Thanks for your reply. I edited my question to clarify that host OS networking worked well on all the routers. The problem is just when I try to connect a VirtualBox VM using that host NIC that work perfectly for the host OS, and the problem happens just at guest OS, host OS networking continue working well after start the VM.
    – user193540
    Commented Jun 30, 2014 at 1:36
  • The OP has made it very clear that the problem lies with the guest, not the host. Commented Dec 21, 2014 at 19:52
  • @MariusMatutiae Yes, he did so after I wrote the answer! Commented Dec 21, 2014 at 20:26
  • In the EDIT, but it was crystal clear already Commented Dec 21, 2014 at 21:20
  • Whatever suits you! from "My problem is when I go to some places that have a specific router model, for example model: ZXHN F660." before the edit I assumed, that this indeed was a device-specific issue. Commented Dec 21, 2014 at 21:52

You must log in to answer this question.