What's New/What's Fixed in Beta3 (comments)

I've never had any problem with WiFi. I simply set the network port to en1 in the VM configuration screen and it works on my MacBookPro over the airport connection. Windows doesn't know or care if it's using a wireless connection. When I move the VM to my iMac I switch it to en0 and it still works, while Windows doesn't notice the difference and continues to work the same. Don't try to use any of the wireless setup tools in Windows - it's not needed.

 

I have the same problem running Fedora Core 4

 

I am successfully using ethernet but DHCP is not working for me, I had to assign an IP Address.

 

okay, so i'm using a copy of windows 98 SE. i basically just wanted to play around with this. so, according to above, there is supposed to be sound in beta 3? well, i can't get it to work in 98 if there is.....

patric

 

I have very similar DHCP behavior for a Windows XP SP2 guest OS. I also occasionally see the ipconfig /release followed by ipconfig /renew not succeed. But for me, this will normally work and allow network access. I normally do not re-boot but use the suspend and resume features of Parallels Workstation. I was not expecting DHCP to fail in this situation and require manual intervention to re-establish. But it does.

Perhaps beta 4 will improve this behavior.

 

I am running Windows 2000 SP4 (iMac hw and Airport networking) and for me DHCP is sort of working:

* If I restart parallels and reboot the guest OS the guest W2K seem has until now a 100% success rate of getting an IP config via DHCP.

* Just rebooting the guest OS once or twice reduces the probability substantially (50%?)

* Further reboots (or W2K hibernation) causes DHCP to fail entirely.

* On a guest where DHCP has failed once on boot any number of "ipconfig /release; ipconfig /renew" will also fail with "could not contact DHCP server".

* Setting static IP configuration on a running guest with a failing DHCP client works without a hitch. Using static config also works 100% regardless of reboots.

It would seem that the parallels network driver or virtual hardware somehow "decays" and takes to long to initialize or something which causes the DHCP client to time out.