Shared Networking with (Mac OS X) PPP Adapter -- not working

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