Discussion of VMware Fusion 1.1.1 and later wireless networking issues

[bgertzfield]

Hi folks,

This thread is to discuss any remaining wireless networking issues in VMware Fusion 1.1.1. This is a continuation of the old discussion of 1.0 and 1.1.0 wireless networking issues from .

Thanks to your help in the previous thread, we think we've tracked down the remaining issue where virtual machines set to used Bridged networking sometimes fail to get a DHCP address when your Mac is connected to certain wireless routers. Stay tuned for more updates!

[shortspecialbus]

I ended up having to delete the files and create a new vmware thing for the boot camp, which was no big deal, but I got it working fine. Also, bridged mode now works flawlessly with DHCP. Thanks!

-stefan

[postmorphia]

Magi,

I worked with you directly to try a patch to fix some dhcp issues I had with WLAN networks. It worked for me. I recently upgraded to 1.1.2 assuming the patch was integrated into that release. Well, now the old problem appears to be back. Can I apply the same patch on top of 1.1.2? Maybe if you could contact me privately we could chat about the issue.

Cheers,

Tom

[admin]

1.1.2 should definitely have the patch which you tested earlier. I'll contact you.

[berck]

Well, the minor issue is becoming more of an annoyance. Many times today I've been doing internet downloads from within my VM's. Sometimes things go smoothly and others not so. I'll get time outs on the interent connection, then after a couple of minutes, it comes back. The more I have to download, the more this problem shows up.

This could be an issue between this fix and the cisco router we have. I don't remember seeing these problems at home at all (after the fix).

[admin]

berck, can I get the complete story on how you've configured things? This is a VM with Windows XP installed, using bridged networking and a wireless network connection on the host, correct?

Next time this happens, can you try running experiments with ping and traceroute (which Windows calls tracert) from both your host and VM, and see if you have a reliable connection to (a) the router itself and (b) some host beyond the router?

[berck]

Here is my setup. I have three VM's. Windows XP Pro, Vista Business and Ubuntu 7.10. All three are running in a bridged mode with wireless networking (wired networking hasn't ever been a problem in this setup). Prior to 1.1.2, this setup wouldn't ever work at work or at home. After 1.1.2, the setup mostly works everywhere I've tried it. I had seen a small problem initially, but it appeared to only surface after I stopped using the VM OS for a bit.

All three VM OSes are experiencing this problem I mentioned. I have tried the 'ping' test, but not the traceroute. When I see the stall, I immediately test it using ping. The host OS (OS X 10.5.2) has never had a problem. The VM OS (doesn't matter which one), will usually not allow connection to the internet through the router. Local connection is fine, after a few tests, the connection with the internet usually gets restored.

I've been running exclusively in a wireless setting since 1.1.2 came out. I've never had any issues with networking problems until I needed to make some OS updates today with my VMed OSes. From work, the issue has always been getting beyond the router for me. It was that way at home too until 1.1.2. This is why I'm thinking about the router itself (Cisco PIX 503).

[admin]

When you ping, are you pinging by hostname or IP?

[berck]

Hostname for systems outside of my network. IP address for all the internal systems. What point are you trying to make?

[admin]

The point is to eliminate one more source of uncertainty. If ping by hostname fails, it's hard to tell where the failure was -- could be name resolution, could be connectivity (in lots of places). So it's a more reliable test to use an address you know ahead of time you should be able to reach. If that works, but ping by name doesn't, then signs point to a name resoution problem. If ping by address still fails (or equivalently, if ping by name is obviously translating the name to an address reliably but then failing to contact that address), it points at a connectivity problem.

[berck]

I understand, but did you all miss the point that the host OS doesn't exhibit any problems? I do the exact same tests under the host OS without any issues. Its only the VMed OSes where the problems occur.

[admin]

No, that point is not lost on us

For bridged networking, the guest OS has to do its own name resolution, so the fact that the host can do it doesn't automatically mean there's no concern about the guest's ability to do it.

Anyway, the problem you're describing, and we're chasing, definitely has something to do with the guest failing at something the host is succeeding at, or with the network getting confused when the guest does something but not getting confused when the host does the same thing. This could be DNS lookups, it could be ARP lookups, it could be a routing problem in the guest, it could be a bug in our code... none of these seem especially likely, but one of them must be true. So the details are important.

[gs_ir]

I am not very technical -- but I think I have the same problem:

I have a MacBook Air running 10.5.2 running a VM through the BootCamp partition Fusion version 1.1.2

After several hours, I lose my network connection on the VM. MacOS internet works fine.

I have done the Network Repair - no luck. I have disabled/enabled - no luck. The only thing that works is rebooting the MacOS. Closing Fusion and restarting the VM does not fix the problem.

I am in NAT mode using a wireless connection to an Air Port Extreme. I have tried disabling and re-enabling the connection. Attached is the ipconfig window from Windows and the text from ifconfig follows:

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384

inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1

inet 127.0.0.1 netmask 0xff000000

inet6 ::1 prefixlen 128

inet6 fd51:a69f:cfd:c2eb:21e:c2ff:feb6:d911 prefixlen 128

gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280

stf0: flags=0 mtu 1280

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500

inet6 fe80::21e:c2ff:feb6:d911%en0 prefixlen 64 scopeid 0x4

inet 192.168.140.198 netmask 0xffffff00 broadcast 192.168.140.255

inet6 2002:621a:7cef::21e:c2ff:feb6:d911 prefixlen 64 autoconf

ether 00:1e:c2:b6:d9:11

media: autoselect status: active

supported media: autoselect

vmnet8: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500

inet 192.168.140.1 netmask 0xffffff00 broadcast 192.168.140.255

ether 00:50:56:c0:00:08

vmnet1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500

inet 192.168.213.1 netmask 0xffffff00 broadcast 192.168.213.255

ether 00:50:56:c0:00:01

Help!

[admin]

gs_ir, I wonder if the problem you're running into is the same one described here (which we haven't been able to capture or understand, unfortunately):

[gs_ir]

Could be. I read that thread earlier, but couldn't understand much of what was being discussed

[mykmelez]

I am not very technical -- but I think I have the same problem:

Since you're in NAT mode, while berck is in Bridged mode, I think you have a different problem. Your problem sounds a lot like the problem I have in NAT mode, which is that DNS resolution in the VM starts failing after some period of time (for me it is several hours to several days, but generally once or twice per day), which causes most connections to fail.

I too used to reboot, but now I just run the following command in a terminal window (no need to shut down your VMs first):

sudo /Library/Application\ Support/VMware\ Fusion/boot.sh --restart

[gs_ir]

I read that earlier today and tried it. Maybe I did something wrong -- today is the first time for me in Terminal -- it didn't work for me. However, just a moment ago I switched to Bridged mode and did the release / renew commands and now it's working. I'll wait to see if this breaks later.

What's the downside of being in Bridged mode?

[mykmelez]

What's the downside of being in Bridged mode?

Bridged mode exposes your VMs to the local network, which makes them more vulnerable to attack (although it's probably not a big deal, depending on the security of your local network). And since each VM gets its own IP address on the local network, you'll run out of IP addresses faster if a bunch of users all use a bunch of VMs in bridged mode (although it may not matter if you have plenty to spare).

Other than that, I can't think of downsides. I'd happily use bridged mode for my primary VM (and do use it sometimes when I'm at home for multiple days), but the wireless access points at work apparently won't hand more than one IP address to any physical machine, so my VMs can't get addresses from them in bridged mode.

[jakeo1]

I am using vmware fusion 1.1.3 with vista ultimate sp1. I cannot get an ip address via dhcp from wireless in bridge mode (which I need because I have multifunction devices on the network that require being in the same subnet). DHCP works fine if I don't use wireless (i.e. ethernet cable). The network/internet works fine if I use a static ip address with wireless. However, I cannot obtain an address via wireless DHCP, and of course if I use NAT (instead of bridge), that works fine too. I thought these problems were supposed to be solved with 1.1.2 of vmware fusion.

I am using a linksys wrt54g running dd-wrt v24sp1 for my wireless access point and a cisco 5505 as my router. The cisco is doing the DHCP and has no problem assigning multiple ip addresses (one for my macintosh and for the windows vista) to the same mac address of my ethernet adapter if I use a wired connection. So I eliminated that possibility (not assigning multiple IP addresses to the same mac address) as a problem.

What are the latest possible solutions for this??? I know this has been an ongoing problem, but I have not seen as many posts on this problem lately.

thanks

jakeo

[berck]

Well, welcome to the club that is having the same issue. What is similar between your's and mine is the cisco router. I have a network with a cisco pix 506E router and a Netgear AP (WN802T). It is not dependible working with the wireless connection. It works and then sometimes it doesn't. Sometimes I can't get an IP and sometimes I can. What I have seen is that when I get an IP, I have connection to the LAN, but the router doesn't let me talk with the Internet. That has been the biggest issue for me now.

I don't believe your wired test is valid from the MAC point of view. From what I remember them saying is that the VM creates a new MAC address for the wired setting so it appears as a different computer to the cisco router. Apparently they can't do this with the wireless MAC address.

I have fewer problems at home with a netgear router and a netgear AP. The fix in 1.1.2 seemed to have resolved my problem there, but I also thought it did at work. It was a software update to one of my VM OSes that made me realize that there was still a problem.

[admin]

berck, jake01, thanks for the information.

To the best of my knowledge, we don't have any remaining bugs in this area as of Fusion 1.1.3; we've fixed everything we know how to fix or have seen demonstrated as a problem, with the exception of routers that actively prevent more than one DHCP client per MAC address (in this situation there's nothing we can do; please correct me if I'm wrong).

I know some Cisco routers and wireless access points implement this policy, and you've both mentioned your problems involving a Cisco router or access point.

If you can't tell your router to be compatible with wireless bridging, and you think this is our bug, please help us solve it... you guys sound plenty technically savvy, if you own Cisco gear and upgrade the firmware on your routers What we'd need is a packet capture from (1) inside the VM, (2) on your Mac host's vmnet0 interface using "/Library/Application\ Support/VMware\ Fusion/vmnet-sniffer", (3) on your Mac host's en1 interface, and if possible (4) on the DHCP server, while your VM is requesting a DHCP address.

And for reference, the known remaining incompatibility is specifically (this is the most succinct description I can give) when: a VM that's bridged to wireless using DHCP requests a DHCP address from a router or over an access point that doesn't allow more than one DHCP client instance per MAC address. If you use a wired interface, or NAT instead of bridged, or the guest doesn't use DHCP, or the router doesn't have this draconian policy, we should work fine. It's the combination of all four factors that's a problem.