Also have problems with Bridged Network & DHCP

[fred-o]

I have an application that I have been running on a Dell w/Win2K-Pro that communicates with my alarm system via TCP/UDP. It is very lightweight, with small packets of data being exchanged. Now I'm testing it on a new MacBook Pro, with the same Win2K-Pro running on Fusion.

I can start a wired, Bridged connection and it works for a while then loses the connection during transmission. On the Mac side, it's using Ethernet en0 with DHCP, while en1 is assinged to Airport which is turned OFF. The Fusion Tools are installed.

It's about a 50/50 chance that packets make it thru OK. The Dell continues to work on same network without any connection interruptions.

[rcardona2k]

Do you know the UDP ports being used? You could also try NAT networking but this requires registering your UDP ports in nat.conf.

Your other options are to run a network trace on your Dell with ethereal (freeware at http://www.ethereal.com/) and run the same capture and Fusion and find the true error rate and any patterns, etc which can be debugged by VMware engineers. This is how they resolved my PPTP VPN problem.

[fred-o]

I do know what port is being used. Can it be specified in the Bridged configuration?

[rcardona2k]

>Can it be specified in the Bridged configuration?

No, it's not necessary to specify any ports, etc in bridged mode. The network adapter is essentially "raw", all ethernet protocols and layer 3 protocols are transparently communicated, that's why it's called bridged.

If you want to remain in bridged, you'll want to start capturing packet traces.

[fred-o]

OK, switched to NAT, updated nat.conf as follows, but I may have the wrong IP here...

\# UDP port forwarding example

4369 = 192.168.1.99:4369

...where the IP address is the device I'm trying to connect to ? or should it be the VM, or what?

Also, is there another way to refresh this if you don't have root privs?

./boot.sh --restart

VMware Fusion 36932: Shutting down VMware Fusion:

permission denied; you must be root to unload kexts

VMware Fusion 36932: Starting VMware Fusion:

you must be running as root to load modules into the kernel

[rcardona2k]

>OK, switched to NAT, updated nat.conf as follows, but I may have the wrong IP here...

Yes, NAT is somewhat confusing to set up. What you want to do is release your VM's previous DHCP address with "ipconfig /release", then switch to Virtual Machine > Ethernet > NAT, then renew the DHCP lease with "ipconfig /renew". Your VM will now get a completely differently looking address like 192.168.208.x. This is the address you specify in nat.conf.

If your device needs to configure or originate a connection to your VM, you need to specify your host's publically available IP address. Those ports must be unused on the host before enabling NAT, then NAT will forward just your nat.conf TCP and UDP-configured port traffic to your guest.

The address you specify for your device in the Guest OS doesn't change at all, it should still be the device address on your local LAN.

>Also, is there another way to refresh this if you don't have root privs?

>./boot.sh --restart

Yes, prefix the command with sudo, e.g. sudo ./boot.sh --restart.

[fred-o]

tried all the above using both VM's IP after renew, and external IP (from router), still similar problems. It works ok for 15 or 20 seconds then starts timming out and loses the connection.

I assume the sudo command was ok although it got errors also....

sudo ./boot.sh --restart

Password:

VMware Fusion 36932: Shutting down VMware Fusion:

No matching processes were found

kextunload: unload kext /Library/Application Support/VMware Fusion/kexts/vmmon.kext failed

kextunload: unload kext /Library/Application Support/VMware Fusion/kexts/vmioplug.kext succeeded

kextunload: unload kext /Library/Application Support/VMware Fusion/kexts/vmnet.kext failed

VMware Fusion 36932: Starting VMware Fusion:

kextload: extension /Library/Application Support/VMware Fusion/kexts/vmmon.kext is already loaded

kextload: /Library/Application Support/VMware Fusion/kexts/vmioplug.kext loaded successfully

kextload: extension /Library/Application Support/VMware Fusion/kexts/vmnet.kext is already loaded

Internet Software Consortium DHCP Server 2.0

Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium.

All rights reserved.

Are these setup difficulties going to be addressed in the final version or will we still be required to do all these steps? Maybe I'll wait a few months...?

[rcardona2k]

>Are these setup difficulties going to be addressed in the final version or will we still be required to do all these steps? Maybe I'll wait a few months...?

I'm not speaking for VMware but if other VMware products are any indicator, NAT setup is done via a GUI on Windows (vmnetcfg.exe).

Also from the read me notes, Fusion has a few networking challenges to workout (host-to-guest, wireless bridged, etc). Once the fixes for these issues are in place it will not be necessary to use the workarounds here that require extra set up steps.

Your issue appears altogether different. If you could capture just a few seconds of packet traces in the working/non-working cases, VMware may be able to determine if it's a technical block, timing problem, etc.

As a beta tester, your scenarios have the ability to influence the outcome for tens, hundreds, thousands, if not more users down the road. That's powerful.

[fred-o]

I have a trace of when it fails, what to do with it now?

[rcardona2k]

Open an online support request with VMware at: http://www.vmware.com/support/services/Beta.html

For completeness, run the vm-support script which provides information about your host so VMware has a complete picture of your environment. Provide as many details about your device and configuration as you're comfortable with.

To run the support script, open a Terminal window and type:

cd Desktop

sudo /Library/Application\ Support/VMware\ Fusion/vm-support-mac.tool[/code]

The text at the end will tell you the name of the archive file that the script created.

On the web page form following the description of the beta support request you will be offered the opportunity to add attachments. You will include the output of the support script and your network capture to VMware. They'll take it from there or contact you for further information.