Situation: MacBookPro, 10.5.2, Parallels build 5584 with WinXP SP2 and all current patches. On the road, no wired or wireless ethernet available, so making a connection to internet via Bluetooth and 3G mobile phone (from the host Mac OS). Shared networking enabled. DCHP scope for Shared Networking is 10.0.0.200 -- 210 But ... no shared networking available for Parallels. It appears that shared network doesn't recognize or know what to do with the "ppp0" adapter that's created in Mac OS while the Bluetooth/3G connection is alive. Here's the results of "ipconfig" inside WinXP: C:\Documents and Settings\martinbear>ipconfig /all Windows IP Configuration Host Name . . . . . . . . . . . . : martin-winxp Primary Dns Suffix . . . . . . . : Node Type . . . . . . . . . . . . : Hybrid IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Parallels Network Adapter Physical Address. . . . . . . . . : 00-7F-FE-F4-78-B3 Dhcp Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes Autoconfiguration IP Address. . . : 169.254.245.102 Subnet Mask . . . . . . . . . . . : 255.255.0.0 Default Gateway . . . . . . . . . : So ... the Parallels Network Adapter is using a self-assigned IP address. And here's what Mac OS thinks ~ martinbear$ ifconfig 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 gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 stf0: flags=0<> mtu 1280 en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:16:cb:94:70:10 media: autoselect status: inactive supported media: autoselect 10baseT/UTP <half-duplex> 10baseT/UTP <full-duplex> 10baseT/UTP <full-duplex,hw-loopback> 10baseT/UTP <full-duplex,flow-control> 100baseTX <half-duplex> 100baseTX <full-duplex> 100baseTX <full-duplex,hw-loopback> 100baseTX <full-duplex,flow-control> 1000baseT <full-duplex> 1000baseT <full-duplex,hw-loopback> 1000baseT <full-duplex,flow-control> none fw0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 2030 lladdr 00:17:f2:ff:fe:57:dd:c4 media: autoselect <full-duplex> status: inactive supported media: autoselect <full-duplex> en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:17:f2:48:af:ab media: autoselect (<unknown type>) status: inactive supported media: autoselect en2: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::21c:42ff:fe00:0%en2 prefixlen 64 scopeid 0x7 inet 169.254.36.132 netmask 0xffff0000 broadcast 169.254.255.255 ether 00:1c:42:00:00:00 media: autoselect status: active supported media: autoselect en3: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::21c:42ff:fe00:1%en3 prefixlen 64 scopeid 0x8 inet 169.254.36.132 netmask 0xffff0000 broadcast 169.254.255.255 ether 00:1c:42:00:00:01 media: autoselect status: active supported media: autoselect ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 inet 77.63.39.224 --> 10.6.6.6 netmask 0xff000000 Any ideas? Am I doing something wrong, or does it just not work? Thanks
Hello Martin, Thank you for the results of "ipconfig" and "ifconfig". Could you please give us more information for analysis? Open Terminal in Applications/Utilities/ and run kextstat | grep parallels. Please send me the output. Go to System Preferences on Mac OS side, choose Network, set Location as 'Automatic', 'Show: Network status'. Make a screenshot of that window (CMD+SHIFT+4). Open Parallels, go to Edit -> Virtual Machine -> Network Adapter and make a screenshot. Run tracert www.parallels.com in CMD on Windows side. Waiting for the screenshots. Best regards, Xenos
Further details OK. To be clear: 1. Location is "Automatic" 2. Ethernet cable is disconnected. 3. Airport is "off" 4. Only active internet connection is Bluetooth/3G phone, thus via "ppp0". Now, start Parallels VM and do the additional checks you asked for. $ kextstat | grep parallels 75 0 0x724000 0x4000 0x3000 com.parallels.kext.ConnectUSB (3.0.0) <41 12 7 6 5 4> 97 0 0xa41000 0x6000 0x5000 com.parallels.kext.Pvsnet (3.0) <6 5 4 2> 111 0 0xc9e000 0x14000 0x13000 com.parallels.kext.hypervisor (3.0) <12 7 6 5 4 2> 112 0 0xc83000 0x10000 0xf000 com.parallels.kext.vmmain (3.0) <12 7 6 5 4 2> 113 0 0x54108000 0x3000 0x2000 com.parallels.kext.Pvsvnic (3.0) <39 5 4> I can't edit the VM while it's active, so let's do the "tracert" first from the Windows side: C:\Documents and Settings\martinbear>tracert www.parallels.com Unable to resolve target system name www.parallels.com. Why should we be surprised at this result? Since the ipconfig shows we have a self-assigned IP address, of course we aren't going to pick up any valid DNS. Now ... stop the VM, but leave Parallels app running and do the rest. (see two attached files below). Let me emphasize, this configuration works fine with WiFi if I'm traveling, but WiFi isn't always available, thus the need to work with a PPP connection when mobile phone is the only option. My thanks in advance,
Martin, thank you for the detailed information. Please try the following: Open Mac System Preferences -> Network -> Parallels NAT; In Configure IPv4 field choose "Off" and click "Apply"; Choose in the same field "Using DHCP" again and click "Apply" once more. Best regards, Xenos
Resetting Parallels NAT, also doesn't fix problem Xenos, I tried the reset procedure (NAT off, apply, DHCP, apply) four times, as follows: 1. Mac OS only, no Bluetooth, no Parallels app running 2. Mac OS, Bluetooth active 3. Mac OS, Bluetooth, Parallels running but VM stopped 4. Mac OS, Bluetooth, Parallels running with VM running In all cases the same result: self-assigned IP address. See the attached image of Network prefs. Thanks for your help so far. What now? (BTW: this reply is sent via the active Bluetooth connection, so internet from Mac OS is working just fine.)
Hello Martin, Please reinstall Parallels this way: Go to Finder - Applications - Utilities - Terminal. Type and run the following commands: • sudo rm /System/Library/Extensions/vmmain.kext • sudo rm /System/Library/Extensions/hypervisor.kext • sudo rm /System/Library/Extensions/Pvsvnic.kext • sudo rm /System/Library/Extensions/ConnectUSB.kext • sudo rm /System/Library/Extensions/Pvsnet.kext • sudo rm -rf /Library/Parallels/ • sudo rm ~/Library/Preferences/com.parallels.* Before you run these commands, please make sure that your VM hdd and pvs files are NOT stored in ~/Library/Parallels. Reboot your Mac and reinstall Parallels. Best regards, Xenos
No change after re-install of Parallels Xenos, Sorry, no difference. The adapters still have self-assigned IP addresses. Compare the two pictures attached: shared network prefs in Parallels vs. actual IP addresses. I tried deleting the two interfaces from Mac OS Network prefs, then re-installating them; that's why they're now named en2 and en3. However the results are the same: no internet access via Bluetooth/3G/PPP. Two notes on the reinstall process: 1. sudo rm /System/Library/Extensions/vmmain.kext and similar commands were rejected by the Mac OS command line because the files appear to be directories. I was able to delete them manually via the Finder, however. 2. It would be nice to remind users who go through this procedure to locate their registration keys beforehand; it helps avoid the mini heartattack afterwards ... So ... what now?
Problem Solved (!!) after reinstall Parallels Tools and Reboot Xenos, I found this helpful post in another thread about internet connectivity problems: I tried this -- nothing to lose after all -- and it worked. The two Parallels adapters now show correct IP addresses ... and ... connectivity via a Bluetooth/3G/PPP adapter now works. I'm not quite sure what happened here, but I'm grateful to Tintin for the suggestion and I recommend it anyone else looking in this thread.
Hello Martin, Thank you for the feedback. This is a better way to restart Parallels adapters, than the steps proposed in my post #4. Good workaround, I will add it to the appropriate KB article. Thanks to Tintin. Best regards, Xenos