Archived: Old fix for Fusion 1.0 and 1.1.0 wireless networking problems

[bgertzfield]

NOTE: The software patch in this thread applies ONLY to VMware Fusion 1.0 (build 51348) and VMware Fusion 1.1.0 (build 62573).

If you're running VMware Fusion 1.1.1 (build c) or later, you do NOT need the software patch attached to this thread, as the fix is already included in that software. (Please don't apply the patch to VMware Fusion 1.1.1; doing so will prevent you from using the network in your virtual machine.)

For further discussion of wireless networking issues with VMware Fusion 1.1.1, please use the new thread:

-

---

Hi folks,

We know a ton of people have been running into lots of issues running VMware Fusion virtual machines when their Macs are set up to use wireless (Airport) networking.

We've finally reproduced the issues in-house, and we have a potential fix. We'd like your help in testing this fix.

NOTE: This fix has been sanity-checked in-house and works in our reproduction case, but it may not work for all cases. This is beta code, so as always, don't use it on production systems.

I've attached the fix to this post in vmnet_fix.zip. Here's the steps to run it:

0) Do NOT apply the fix if you're running VMware Fusion 1.1.1 build 72241 or later. The fix is already included in that version.

1) Suspend or shut down any running VMs.

2) Double-click on vmnet_fix.zip to unzip it.

3) Run the "VMware Fusion Networking Fix 2007-12-04" application.

4) Enter your administrator username and password.

5) Resume or start up your VMs.

If you use wireless networking on your Mac and you've run into network problems including DHCP issues, packet loss, and loss of connectivity, please give this fix a try and let us know the results.

Again, thanks to everyone for your patience and your assistance in helping us diagnose the issue.

If you run into network problems after installing this fix, please let us know the following:

1) Open Console.app, click on system.log, and copy-and-paste the line containing "vmnet: Initializing module" into a reply to this thread.

2) Let us know if you're using bridged or NAT networking.

3) Try connecting your Mac to both wireless and wired Ethernet networks.

To revert the fix to your original version, follow these steps:

1) Suspend or shut down any running VMs.

2) Open Terminal.app and run the following:

3) cd "/Library/Application Support/VMware Fusion"

4) sudo ./boot.sh --stop

5) cd kexts

6) sudo mv vmnet.kext vmnet.kext.1.1fc1

7) sudo mv vmnet.kext.disabled.* vmnet.kext

😎 cd ..

9) sudo ./boot.sh --start".

[TheAngryPenguin]

Many, many thanks for this. While I rarely experience the issue while at home, I look forward to keeping an eye on it at work tomorrow. Quick question: Since this script modifies a kernel extension, is a system reboot recommended or encouraged?

[bgertzfield]

Many, many thanks for this. While I rarely experience the issue while at home, I look forward to keeping an eye on it at work tomorrow. Quick question: Since this script modifies a kernel extension, is a system reboot recommended?

No reboot is needed. You need to suspend or shut down your VMs before running the fix, so you can swap out the kernel extension without rebooting.

Your original vmnet kernel extension isn't modified, it's just renamed, so you can get it back in the worst case.

(Note that if you don't suspend or shut down your VMs before running the fix, it'll will tell you to do so, and it won't touch your kernel extensions.)

[TheAngryPenguin]

Good deal. FWIW, I rebooted anyway, and as expected, the startup seemed to take slightly longer than normal, which is on par for Fusion upgrades. I was pleastly surprised when I discovered that the issue reported in http://communities.vmware.com/message/807268 seems to have been resolved with this revised device driver. However, my router is still displaying the same IP address assigned to two different MACs -- see the attached screenshot for more info...

...I'll report back tomorrow night with results after a day at the office

[raygump]

Unfortunately, on my Leopard machine, this fix seems to make no difference. I still loose my windows networking on the Mac (in Finder).

[admin]

However, my router is still displaying the same IP address assigned to two different MACs -- see the attached screenshot for more info...

Weird. On the wrt54g, eth2 is the wifi interface, and br0 should be bridging that and all the local ethernet ports, right? 00:17:F2:4B:A9:1D is your MacBook; it's weird that the .150 address shows up on eth2 but the .160 address shows up on br0. And then .160 shows up again (with a different MAC address) on br0; that different MAC address is 00:0C:29... which is VMware's. Do you sometimes use that VM bridged to ethernet and plug in directly to your network, and sometimes use it bridged to wifi/airport? Maybe that's confusing tomato somehow. (Educated guess: the difference between a VM switching between wired and wifi, and your MB switching between wired and wifi, is the MB knows when it switches, and acquires a new IP address via DHCP on whichever interface you activate; the wired and wifi interfaces each have their own MAC address and they can even be active at the same time. But for the VM, they can't be active at the same time and it doesn't know when it switches. So say you plug the MB into a wire, and Fusion is bridging to your host en0, and the VM acquires an IP address via DHCP, namely .160. Then you unplug the MB from the wire, and Fusion bridges to host en1, but the VM doesn't know anything is different, and keeps sending traffic from IP address .160, but now it's using your MB's en1 MAC instead of the VM's own MAC. ARP lets the router learn that .160 is now owned by 00:17:F2... instead of 00:0C:29..., but it doesn't expire the mapping it had between .160 and 00:0C:29..., so now it thinks that IP address corresponds to both MACs.)

[admin]

Unfortunately, on my Leopard machine, this fix seems to make no difference. I still loose my windows networking on the Mac (in Finder).

Can you describe this a little further? I guess you already did, in http://communities.vmware.com/message/810194. I have some questions for you though. First off, this fix happens when Fusion is running, and never when Fusion is not running? How soon after you start Fusion does it happen? If you run the same VM under Fusion but set it to NAT networking instead of bridged, do you still see this problem? And once the problem occurs, can you still use your Mac normally on the network other than SMB (for example, does web browsing work, does 'ping' work); is it only SMB that's affected?

The reason for me peppering you with these questions is it sounds like the problem you're experiencing is a different one than the one we've been investigating so far. And while it too is important and we'll want to get the bottom of it, we'll need to keep the chains of evidence separate so we don't confuse one problem with the other.

[mykmelez]

I tried this fix to see if it would solve my problem that DNS gets spotty after about a day and a half, but after unsuspending my VM, the applications in it started freezing one by one. So I killed X with ctrl-alt-delete, and my desktop went away, but the GDM login screen never showed up.

So I hard shut down my VM and restarted Mac OS X, whereupon HTTP connections to a variety of sites (but not all of them) in both Mac OS X and my VM started dying without receiving any data.

That persisted after I replaced the new vmnet.kext with the old renamed one, even after restarting, although it seems to be gone now that I've restarted again (so it could also have been a problem with the Internet connection I'm currently using at a hotel).

I'll try again, but it'll have to wait until I'm done with a presentation I'm giving on Friday, as I don't want to do anything until that that could compromise my ability to prepare and give that presentation.

[bgertzfield]

Hi mykmelez,

Hotel network connections tend to be quite spotty. If your problem persists when you're not using wireless networking, it's almost certainly unrelated to Fusion.

[kban]

I am delighted to report that this fix seems to have resolved the problems I have had with my entire wireless networking falling over on my Macbook when running Fusion in bridged networking mode. I encountered the problem after installing a new Airport Extreme access point running under WPA; I didn't have any problems on the previous Linksys wireless access point running WEP. Anyway everything is runnign smoothly after the fix and there is no sign of the dreaded "your wireless security appears to have been compromised and will be disabled for about a minute" message. I have tucked away the lengthy network cable I had dangling across the living room floor before someone falls over it and breaks their neck. Many thanks.

Update after 24 hours: I have left Fusion running and there has been no hint of any problem with my wireless networking - this is a huge improvement over my previous experience.

[maverick808]

At last. I had switched to Parallels and didn't like it at all but this fix works and I can finally go back to using Fusion. Thanks

[DerekS]

This fix completely killed Bridged mode for me on my Mac Pro. I even tried rebooting the VM and finally, the whole machine.

NAT mode still works, bridged doesn't work at all.

How can I revert?

[bgertzfield]

This fix completely killed Bridged mode for me on my Mac Pro. I even tried rebooting the VM and finally, the whole machine.

NAT mode still works, bridged doesn't work at all.

How can I revert?

Hi Derek,

Before you revert, can you let us know what you mean by "killed"? First off, does bridged networking work when your Mac is connected to a wired network?

Do you get an error message when starting your VM?

Does your VM get an IP address from your network's DHCP server?

Does your VM work if you manually configure an IP address?

Can you ping other IP addresses on your network to see if they respond?

[BP9906]

Just to make sure its known: I've never had Fusion networking issues with my VMs. I have a MacMini CD and have always used wifi. I dont think I've ever touched my network card... except to maybe transfer a huge file via 100 MB/s networking from a windows laptop. This issue must just be related to people switching between wired and wifi; and especially folks w/ MB and MBPs.

[admin]

Also, Derek, is your Mac Pro connected via Airport, wired Ethernet, or both?

FWIW, this fix works for both bridged-to-Airport and bridged-to-Ethernet on my MBP.

[DerekS]

Before you revert, can you let us know what you mean by "killed"? First off, does bridged networking work when your Mac is connected to a wired network?

The VM cannot get an IP address via DHCP. No idea on wired network...I don't have one. Airport only.

Do you get an error message when starting your VM?

Nope, no error on boot.

Does your VM get an IP address from your network's DHCP server?

No.

Does your VM work if you manually configure an IP address?

No.

Can you ping other IP addresses on your network to see if they respond?

No.

Hope this helps!

[admin]

raygump, the problem you're describing (about SMB server browsing) is not the same one that we believe we've fixed in this patch, so I've moved that to another thread (http://communities.vmware.com/thread/115998?tstart=0) so it doesn't get lost in the discussion here.

[DerekS]

By the way, bridged worked for me on 1.1.

[admin]

Derek, many thanks, we'll look into that.

To restore the 1.1 version of the vmnet component that our updater changed, you'll need to drop into the Terminal, I believe. If you could run "kextstat | grep vm" and post the output just so we can verify which components you're running, I'd appreciate it. Then, cd to "/Library/Application Support/VMware Fusion", use "sudo ./boot.sh --stop", "cd kexts", "sudo mv vmnet.kext vmnet.kext.1.1fc1", "sudo mv vmnet.kext.disabled.* vmnet.kext", "cd ..", and "sudo ./boot.sh --start".

A shorter way of doing this could be just the "sudo mv" commands, and then reboot your Mac, if you'd rather.

[DerekS]

Here's the output:

kextstat | grep vm

111 0 0x764c9000 0x64000 0x63000 com.vmware.kext.vmx86 (1.1) <12 6 5 4 2>
112 0 0x7652d000 0xa000 0x9000 com.vmware.kext.vmci (1.1) <6 5 4 2>
113 0 0x764b6000 0x6000 0x5000 com.vmware.kext.vmioplug (1.1) <38 21 6 5 4>
115 0 0x765ed000 0x8000 0x7000 com.vmware.kext.vmnet (1.1.1fc1) <12 6 5 4 2>