VMware Communities
bgertzfield
Commander
Commander

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

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".

0 Kudos
209 Replies
Halenbeck
Contributor
Contributor

Hello jbas,

reading your problem description I dont think that you are talking about the issue of this thread. In order to reduce it to your core problem, I would suggest

1) Apply the patch to Fusion 1.1

2) create a new vm with bridged networking

3) reinstall vista from scratch.

To me it sounds like you have just totally messed up your vista network configuration before even applying the VM Ware patch.

0 Kudos
bicchu
Contributor
Contributor

Hello,

I don't forget you.... I tried to stop Fusion network services as you

explained me w/o any visible effect bur I am not sure I performed it

correctly.

Finally, I uninstalled VMware Fusion and got back the wireless connection.

So, I installed it again and the wifi network seems to work fine now.

I hope it will persist after restarting.

Regards

--

Philippe Le Bras

0 Kudos
pwagland
Contributor
Contributor

Yay!

I had not really experienced the network problems, but I had been having problems with the keyboard and trackpad sporadically being disabled after I had run VMWare, and now that problem also appears to have resolved itself after installing this fix.

Does that make any sense? I am not quite sure how the two should be related, but... so far, so good!

Thanks!

0 Kudos
gm80
Contributor
Contributor

I was experiencing the issue when running Fedora 8 in Fusion ... I didn't seem to notice it when running Windows XP (not to say it wasn't there). My Airport connection would hang in the host and guest, and then drop altogether. The Airport menu bar item would still indicate it was connected. Cycling the Airport on and off would reconnect. Repeat ad infinitum.

The patch solved it.

Host:

MacBook C2D 2.0 GHz, 2GB RAM, OS 10.5.1, Fusion 62573

Guests:

Windows XP Pro, 8GB preallocated, 512 RAM, VMware Tools installed

Fedora 8, 8GB preallocated, 512 RAM, VMware Tools NOT installed

Thanks.

0 Kudos
chrisbinnssmith
Contributor
Contributor

Hi:

After reading the symptoms, it appears to potentially solve my problem. The issue I am having is the "Settings" for the Network(On XP) randomly resets and then

disconnects the network.

Does this potential fix cover this issue.

In terms of the MAC side, Internet is fine.

Thanks,

Chris

0 Kudos
admin
Immortal
Immortal

After reading the symptoms, it appears to potentially solve my problem. The issue I am having is the "Settings" for the Network(On XP) randomly resets and then disconnects the network.

That sounds like a Windows configuration issue not related to Fusion, but you're welcome to try this patch and see if it helps. You didn't say whether you're using Fusion's bridged mode with a wireless network; may I assume you are? If yes, does switching to either NAT or a wired network work any better?

0 Kudos
legacyb4
Contributor
Contributor

OS X 10.5.1, WiFi network only

VMWare Fusion 1.1 + Networking Patch

Windows XP SP2 (fresh install)

No luck on getting the VM to even recognize that there is a network in Bridged Mode but NAT mode works okay.

Disabling Network and restarting network gives me the following console log entry:

Dec 12 16:25:28 MacBook kernel[0]: vmnet: VMNetDisconnect called for port 0xadbd500

Dec 12 16:25:28 MacBook kernel[0]: vmnet: bridge-en1: disabled promiscuous mode

Dec 12 16:25:28 MacBook kernel[0]: vmnet: VNetUserIfFree: freeing userIf at 0xadbd500.

Dec 12 16:25:35 MacBook kernel[0]: vmnet: VNetUserIf_Create: created userIf at 0xb2afc80.

Dec 12 16:25:35 MacBook kernel[0]: vmnet: VMNetConnect: returning port 0xb2afc80

Dec 12 16:25:35 MacBook kernel[0]: vmnet: bridge-en1: enabled promiscuous mode

Dec 12 16:25:35 MacBook kernel[0]: vmnet: VMNET_SO_BINDTOHUB: port: paddr 00:50:56:f7:42:94

Dec 12 16:25:35 MacBook kernel[0]: vmnet: Hub 0

Dec 12 16:25:35 MacBook kernel[0]: vmnet: Port 0

Dec 12 16:25:35 MacBook kernel[0]: vmnet: Port 1

0 Kudos
Benj
Contributor
Contributor

The Fix work great for me on my MBP running Leopard. Yesterday was a true test. I connect to my MBP at home from my Office, and because of the previous problems with the wireless, I always made sure that I was hardwired to the network before I left home. I forgot to do that yesterday and I did not realize it until I got home last night and noticed that I was running wirelessly all day.

It worked great for me.

Thanks

0 Kudos
sirris101
Contributor
Contributor

Hi Magi- Here's what has been happening with Wifi and NAT on Fusion 1.1 running Leopard. Also, just so you know, I've Erase and Installed both Leopard and VMWare Fusion twice to see if it was a glitch in my first installation. It's happened with both installs.

My mac is connected to my home (or office's) wireless network. The mac side can browse and use the internet just fine. Unfortunatly it doesn't seem to work very well in Fusion. As I mentioned before if I do Repair Network in Windows (the same as doing a ipconfig /release & /renew) it starts to work. I think it's the DNS, because I am able to ping the IP address of Google, but am not able to visit Google.com in my web browser. Again, the Repair Network will often fix this, but within an 20 minutes to a few hours, the same thing problem arrises. This doesn't occur with wired ethernet at all.

I would be happy to do an ipconfig /all, but unfortunatly I'm at place right now that only has wired internet. I'm also happy to help troubleshoot in other ways. I know I could use Bridged, but I would much prefer to use NAT.

0 Kudos
admin
Immortal
Immortal

Hi, sirris101. What you're describing is definitely not related to the bridged fix that we're testing here. Could you please start a new thread and describe those symptoms again so we can discuss that without getting lost in the other traffic on this thread? Offhand, I don't know of any reason why NAT cares whether what's underneath is a wired or wireless connection, so while I can think of a couple theoretically possible explanations for those symptoms, none of them would explain why you see problems only with wireless and not with wired ethernet.

0 Kudos
Ul83fPoX
Contributor
Contributor

In a bid to fix this issue on my own, I upgraded my Linksys WRT54GL from running the DD-WRT v23 SP2 firmware to v24 RC4 and RC5. Since then, I have not experienced this particular problem.

I have applied the patch anyway and it doesn't seem to have any negative effects (in case you're looking for potential bugs). Also, I think the DD-WRT firmware is buggy and possibly a contributor to the underlying issue because I have noticed that when I experience wireless dropouts now, all my wireless devices (Mac Mini, iPhone, MacBook Pro) dropout and rebooting the router is often necessary to make it functional again. Just thought you might want to know.

0 Kudos
ujohnc00
Contributor
Contributor

Excellent; worked like a charm for me. Thank you! This thread was hard to find, and I was freaking out. Any easier way to get notice of such bugs?

My config:

OSX 10.5 Host

WinXP Pro VM

Wireless Airport connection to a netgear router

VMWare Fusion 1.1

0 Kudos
vampier5000
Contributor
Contributor

im having a problem it started when i upgraded my macbook yesterday from tiger to leopard every time i start the vmware fusion this is the message that appears (The virtual machine's operating system has attempted to enable promiscuous mode on adapter Ethernet0. This is not allowed for security reasons.

Please go to the Web page "http://www.vmware.com/info?id=161" for help enabling promiscuous mode in the virtual machine.) and also i have noticed that it has started to hang and by the way im using windows xp pro in vmware

0 Kudos
admin
Immortal
Immortal

im having a problem it started when i upgraded my macbook yesterday from tiger to leopard every time i start the vmware fusion this is the message that appears (The virtual machine's operating system has attempted to enable promiscuous mode on adapter Ethernet0. This is not allowed for security reasons.

That means you've got software in the VM that is trying to look at every packet in the network. Maybe a packet sniffer, maybe other security software... but it's definitely related to something you've installed in your VM, and it's not related to the wireless network problem we're talking about in this thread.

0 Kudos
admin
Immortal
Immortal

Excellent; worked like a charm for me. Thank you! This thread was hard to find, and I was freaking out. Any easier way to get notice of such bugs?

Sorry about that. We do have a sticky posting at the top of the forum, but still, it's easy to miss. Hopefully, getting rid of such bugs so you don't need to know about them will be our best bet!

0 Kudos
notapcguy
Contributor
Contributor

Holy crap, it worked!

Running Leopard and Windows XP (yuck). The XP side of things stopped connecting to the internet. Mac side, of course, was fine. I had this problem a couple of months ago, and can't remember all the hoops I jumped through to solve the issue. I came across this thread today and installed the fix. Sweet!

0 Kudos
sbess
Contributor
Contributor

hi all,

the fix was not working for me.. if i type 'ipconfig' in a cmd message window under my windows vista (launched with vmware fusion 1.1 newest build + this new net-test application) i get an 169.x.x.x ip adress and a message that there is an ip-adress conflict.

i use a macbook pro with leopard (2.6ghz) and 4gb ram and i run windows vista ultimate (newest updates installed) in a vmware fusion 1.1 window. can someone help?

Dec 19 16:34:17 localhost kernel[0]: vmnet: Initializing module (version 1.1.1fc1, build-65852).

Dec 19 16:34:17 localhost com.vmware.launchd.vmware[38]: Internet Software Consortium DHCP Server 2.0

Dec 19 16:34:17 localhost kernel[0]: vmnet: VMNet_Start allocated gOSMallocTag

Dec 19 16:34:17 localhost com.vmware.launchd.vmware[38]: Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium.

Dec 19 16:34:17 localhost com.vmware.launchd.vmware[38]: All rights reserved.

Dec 19 16:34:17 localhost com.vmware.launchd.vmware[38]: Please contribute if you find this software useful.

Dec 19 16:34:17 localhost com.vmware.launchd.vmware[38]: For info, please visit http://www.isc.org/dhcp-contrib.html

Dec 19 16:34:17 localhost com.vmware.launchd.vmware[38]: Configured subnet: 172.16.231.0

Dec 19 16:34:17 localhost com.vmware.launchd.vmware[38]: Setting vmnet-dhcp IP address: 172.16.231.254

Dec 19 16:34:17 localhost com.vmware.launchd.vmware[38]: Opened:

Dec 19 16:34:17 localhost com.vmware.launchd.vmware[38]: Recving on VNet/vmnet8/172.16.231.0

Dec 19 16:34:17 localhost com.vmware.launchd.vmware[38]: Sending on VNet/vmnet8/172.16.231.0

Dec 19 16:34:17 localhost com.vmware.launchd.vmware[38]: Internet Software Consortium DHCP Server 2.0

Dec 19 16:34:17 localhost com.vmware.launchd.vmware[38]: Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium.

Dec 19 16:34:17 localhost com.vmware.launchd.vmware[38]: All rights reserved.

Dec 19 16:34:17 localhost com.vmware.launchd.vmware[38]: Please contribute if you find this software useful.

Dec 19 16:34:17 localhost com.vmware.launchd.vmware[38]: For info, please visit http://www.isc.org/dhcp-contrib.html

Dec 19 16:34:17 localhost kernel[0]: vmnet: Module initialized.

Dec 19 16:34:17 localhost com.vmware.launchd.vmware[38]: Configured subnet: 172.16.82.0

Dec 19 16:34:17 localhost com.vmware.launchd.vmware[38]: Setting vmnet-dhcp IP address: 172.16.82.254

Dec 19 16:34:17 localhost com.vmware.launchd.vmware[38]: Opened:

Dec 19 16:34:17 localhost com.vmware.launchd.vmware[38]: Recving on VNet/vmnet1/172.16.82.0

Dec 19 16:34:17 localhost com.vmware.launchd.vmware[38]: Sending on VNet/vmnet1/172.16.82.0

Dec 19 16:34:17 localhost kernel[0]: vmnet: VNetUserIf_Create: created userIf at 0x76b7d00.

Dec 19 16:34:17 localhost kernel[0]: vmnet: VMNetConnect: returning port 0x76b7d00

Dec 19 16:34:17 localhost kernel[0]: vmnet: Hub 8 does not exist, allocating memory.

Dec 19 16:34:17 localhost kernel[0]: vmnet: Allocated hub 0x76b9800 for hubNum 8.

Dec 19 16:34:17 localhost kernel[0]: vmnet: VMNET_SO_BINDTOHUB: port: paddr 00:50:56:fc:fb:c6

Dec 19 16:34:17 localhost kernel[0]: vmnet: Hub 8

Dec 19 16:34:17 localhost kernel[0]: vmnet: Port 0

Dec 19 16:34:17 localhost kernel[0]: vmnet: VNetUserIf_Create: created userIf at 0x765a080.

Dec 19 16:34:17 localhost kernel[0]: vmnet: VMNetConnect: returning port 0x765a080

Dec 19 16:34:17 localhost kernel[0]: vmnet: VMNET_SO_BINDTOHUB: port: paddr 00:50:56:ea:74:de

Dec 19 16:34:17 localhost kernel[0]: vmnet: Hub 8

Dec 19 16:34:17 localhost kernel[0]: vmnet: Port 0

Dec 19 16:34:17 localhost kernel[0]: vmnet: Port 1

Dec 19 16:34:17 localhost kernel[0]: vmnet: VNetUserIf_Create: created userIf at 0x765a000.

Dec 19 16:34:17 localhost kernel[0]: vmnet: VMNetConnect: returning port 0x765a000

Dec 19 16:34:17 localhost kernel[0]: vmnet: VMNET_SO_BINDTOHUB: port: paddr 00:50:56:e3:cc:b7

Dec 19 16:34:17 localhost kernel[0]: vmnet: Hub 8

Dec 19 16:34:17 localhost kernel[0]: vmnet: Port 0

Dec 19 16:34:17 localhost kernel[0]: vmnet: Port 1

Dec 19 16:34:17 localhost kernel[0]: vmnet: Port 2

Dec 19 16:34:17 localhost kernel[0]: vmnet: VNetUserIfFree: freeing userIf at 0x765a000.

Dec 19 16:34:17 localhost mDNSResponder[22]: SetDomainSecrets: mDNSKeychainGetSecrets failed error 0 CFArrayRef 00000000

Dec 19 16:34:17 localhost kernel[0]: vmnet: netif-vmnet8: Adding protocol 2.

Dec 19 16:34:17 localhost kernel[0]: vmnet: VNetUserIf_Create: created userIf at 0x765ac80.

Dec 19 16:34:17 localhost kernel[0]: vmnet: VMNetConnect: returning port 0x765ac80

Dec 19 16:34:17 localhost kernel[0]: vmnet: Hub 1 does not exist, allocating memory.

Dec 19 16:34:17 localhost kernel[0]: vmnet: Allocated hub 0x771d800 for hubNum 1.

Dec 19 16:34:17 localhost kernel[0]: vmnet: VMNET_SO_BINDTOHUB: port: paddr 00:50:56:e6:01:85

Dec 19 16:34:17 localhost kernel[0]: vmnet: Hub 1

Dec 19 16:34:17 localhost kernel[0]: vmnet: Port 0

Dec 19 16:34:17 localhost kernel[0]: vmnet: VNetUserIfFree: freeing userIf at 0x765ac80.

Dec 19 16:34:17 localhost kernel[0]: vmnet: netif-vmnet1: Adding protocol 2.

Dec 19 16:34:17 localhost kernel[0]: vmnet: VNetUserIf_Create: created userIf at 0x765af80.

Dec 19 16:34:17 localhost kernel[0]: vmnet: VMNetConnect: returning port 0x765af80

Dec 19 16:34:17 localhost kernel[0]: vmnet: VMNET_SO_BINDTOHUB: port: paddr 00:50:56:f9:1f:40

Dec 19 16:34:17 localhost kernel[0]: vmnet: Hub 1

Dec 19 16:34:17 localhost kernel[0]: vmnet: Port 0

Dec 19 16:34:17 localhost kernel[0]: vmnet: Port 1

can someone help?

best regards,

stefan

0 Kudos
sbess
Contributor
Contributor

update: im using bridged mode.. NAT is working fine with wired and wireless networks. bridged mode is working fine with wired network only.

0 Kudos
Halenbeck
Contributor
Contributor

Yep, that does not look like it has anything to do with the issue of this thread. If Vista is saying there is an IP conflict I guess, it is right and you need to reconfigure Vista or what ever else is in your Subnet using the desired address.

If your problem is not related to "My TCP/IP setup is correctly (DHCP or not) but my wireless (!!) network connection on a MAC breaks with VM Ware in bridged mode while it works with VM Ware in NAT mode". I would suggest to start a new discussion thread about your issue. I am sure you will have a higher chance of getting a solution there.

This thread is getting slightly unclear as all kind of networking problems were thrown in here.

0 Kudos
sbess
Contributor
Contributor

hmm... maybe I missunderstand you..

but isn't that exactly my problem? everything under vmware fusion is working (wired network bridged/nat and wireless nat) except wireless bridged.. i'm not getting this to work. the tcp/ip settings are correct.

br, stefan

0 Kudos