Bridged Network to WLAN not working

[VBX-Runner]

VB currently 3.0.8 Host: WinXP SP3 32-bit Guests: multiple 64-bit OS: Win 7 RC1, Fedora 11, Ubuntu 9.04 desktop & server Bridged network when associated with wireless host interface (Intel(R) Wireless WiFi Link 4965AGN) has intermittent network connectivity (tested by continuous pings on Win 7 and Fedora 11; on Win7 every 11-12 pings are followed by requests timed outs, overall up to 40% packet loss; on Fedora11 up to 80% packet loss. Bridged network when associated with wired host interface (Intel(R) 82566MM Gigabit Network Connection) working properly, no packet loss. NAT interface working properly for both hosts interfaces, wireless and wired. This issue started to occur before VB v3.0.4 and continues in v3.0.8. Originally, on VB 2.2.2 & 2.2.4 this behavior was not observed, no issues observed. Guests do not report or log any errors for Nics. So, I am not sure how and where additionally track this issue. I tried wireshark, but I was not able to find anything. Dmesg or linux logs--nothing either. Other VMs on the same host machine, on VMWare server, Microsoft PC 2007 or server 2005 do not have issues with bridged networking attached to the same WiFi. Host machine by itself has no issues with WiFi either.

[VBX-Runner]

VBox log from Win7 guest

[VBX-Runner]

Fedora11 log file

[9ine]

I've the same problem: VirtualBox 3.1.2 - Host (Windows 7), Guest (Ubuntu-Server)

Bridged Connection over WLAN Atheros AR5007EG. Static IP in Guest. Every x Packages I have to restart the Network in the Guest, cause of loss connection.

This is very annoying!

[misha]

Hmm, I have exactly the same wireless adapter on my laptop (4965AGN) and I see no problems with using bridged wireless on XP & Windows 7 hosts.
Could you try whether you have the same problems with guest VM having only one network adapter bridged to host WLAN? (the logs attached show your VM has two adapters bridged with wireless and wired).
Could you also specify what other custom networking-related software do you have iinstalled on your host? (E.g. VPN clients, Antivirus, Firewalls, other virtualizers like VMWare or VirtualPC)

[misha]

Could you also try to use pcnet virtual adapter instead of e1000?

[VBX-Runner]

Here is additional information I gathered after a bit more extensive investigation: bridged network does NOT work correctly (30-75% packet loss in every virtual guest) when 4965AGN is connected to 5.5Ghz radio of WRT610N running dd-wrt, one of the latest versions (I prefer this radio due to connectivity speeds). When I switch to 2.4GHz radio, bridged network does not exhibit any packet loss! Additionally, when connected to 5.5 GHz radio and enabling P-Mode (promiscuous mode) using Microsoft Network Monitor v3.3 or tcpdump, guest connectivity recovers and stops loosing packets (I was able to observe this in Fedora11, Windows7-64Bit, however, I was not able to recover network connectivity in WinXP-64Bit, by enabling promiscuous mode). I observe similar behavior regardless whether I have 1 or more network interfaces attached to virtual guests. NAT connections do not exhibit, never, this strange behavior at all, always working, unlike bridged network. Regarding host network related software: OpenVPN, but not using it, however network interface is present, as AV/FW (anti-virus/firewall), I use Comodo Internet Security Suit, the most recent version. Other virtualization installed, but never used concurrently: MS Virtual Server 2005, MS Virtual PC 2007, VMWare server v2.02, and Virtualbox, currently v3.1.2. None of virtual guests in those other systems exhibit problems with networking at all, unlike Virtualbox bridged networking, while host is connected to 5.5GHz radio. I tried to investigate this awkward packet loss using MS Network Monitor, tcpdump, wireshark, however, I was not able to determine where they vanish. Any advice how to approach this issue, would be greatly appreciated. Regarding AMD PCnet adapter, since most of work I am doing on WindowsXP or 7 64-Bit, only available NIC drivers are for Intel MT Desktop or server NICs, I was not able to find suitable drivers for Intel T or PCnet adapters for 64-bit OS. @9ine what wifi connectivity do you use? 2.4 or 5.5GHz? Let me know if you need any additional info, what could I submit to aide to resolve this issue?

[misha]

Thanks for your investigations, I indeed have a 2.4GHz radio, and do not have a 5.5 one at hand. I'll have a look if I can test with it as well.

Could you elaborate a bit on how enabling the promiscuous mode solves the problem for you? I.e. you are enabling promiscuous in the guest, right? Does the packet loss appear again after you disable promiscuous?

[VBX-Runner]

Hello Misha, First of all: thank you very much for your interest in this issue and attempts to help to resolve the problem. Regarding promiscuous mode topic, let me describe in more details what and how I do this, this is always done on virtual guests, never on host: first of all I start continuous ping to my gateway or to a next hop, which is another dd-wrt router, in order to monitor response and packet loss. This is without promiscuous mode enabled. On Win7 I do see, pretty much 11 packets transmitted and 4 lost, this is possible to repeat almost every time (sometimes, but rarely, there is a bit bigger packet loss, but never smaller). On Fedora packet loss is bigger, up to 75%, and not as regular as on Win7. Then, on Win7 guest I start MS Network Monitor (actually a very nice and handy free tool), and choose corresponding bridged interface, and enable P-Mode (=promiscuous mode). Once I start capturing traffic, when the last packet loss loop is completed, then I start observing no packet loss whatsoever: 100% received, after enabling P-Mode. When I stop traffic capture, in a short while, packet loss loops start over again. When I start traffic capture with P-Mode enabled again, packet loss stops again. When I do not enable P-Mode on bridged interface, there are constant packet loss loops: 11 received and 4 lost, most frequently. This also applies when I use tcpdump. Once I start tcpdump packet loss loops stop. I can repeat it with pretty much 100% accuracy.

[misha]

Could you try enable the ​network tracing and create a trace for the packet loss + packet restore on P-mode activation case, and attach the trace to this report?

Despite Network Monitors, tcpdump and other sniffers running on the guest, this will allow seeing all packets the guest actually sends/receives.

[VBX-Runner]

I got file.pcap capture before P-Mode, after P-mode, after stopping it, and re-starting it again. Since the file contains some network information I'd prefer not to reveal to wide www public, is there any way to submit, deliver this capture file to you, but confidentially?

[misha]

Sure, feel free to mail them to me at mikhail dot sennikovsky at sun dot com

[VBX-Runner]

file.pcap capture was submitted to Misha for further investigation.

[Valery Ushakov]

This might be fixed in 4.3.16, though I can't tell for sure without seeing the original packet capture. WiFi routers try to send multicast ethernet frames as unicast if possible and these packets were not delivered to the guest correctly. #10019 has some more details on this. In particular ARP requests from the WiFi router are affected by this problem - though the router eventually gives up and send ARP as real broadcast and gets back the reply restoring connectivity until the next expiration of ARP cache entry for the guest.