Conflict with Keyspan USB server and shared networking

Has there been any resolution the problem listed in the following archived thread?

http://forum.parallels.com/showthread.php?t=11296

 

Thanks for mentioning this.

I guess this explains the problem I was having. I couldn't get shared networking to work either. I was also having a problem with the USB server where turning on "Auto-Connect" on my MBP would make the server unavailable to other network users.

 

Yes, it looks like you are also having a problem with the Keyspan server. I find the Keyspan device to be great, so I hope they can find a way to fix this issue.

 

I downloaded the latest beta of VMware Fusion and, so far, bridged mode seems to be working fine alongside the Keyspan software.

 

Not only has there been no resolution, despite 2 or 3 releases of Parallels since this was first reported in detail; but I just bought and installed the new Keyspan USB 2.0 Server, and the exact same problem exists with it as well. The exact cause (conflict in loading sequence of drivers) is known to Parallels, and has at least been reported to Keyspan. It is time for a solution to this!

Bill Halberstadt

 

Just a note to say that this problem (Keyspan USB Server s/w versus Parallels networking) still exists after upgrading to the version 3 build 5120 version. Can we at least have a workaround?

Bill Halberstadt

 

Unfortunately there is no known workaround for it.
We investigated this problem and it is a Keyspan driver issue, we just can't fix it from our side.

 

Many thanks for the status report, Spectre. Sorry to see that it can't be fixed by Parallels. Earlier, a workaround was mentioned that involved changing the load order of the drivers from Parallels and Keyspan, but not enough detail was given for me to be able to do that. Can you suggest a procedure for that?

 

Here it is - http://kb.parallels.com/entry/34/271/.
Sorry for not telling about it later, I thought you've already tried it and it didn't help.

 

To explain further, a previous post by Parallels team member "Serv" said:

"We're investigating the problem. There's no clear connection between Parallels and Keyspan drivers and we're communicating Apple on this.
Changing driver load order to load Pvsvnic.kext first and KeyspanNHCI-T.kext last would solve the problem. Unfortunately there's no simple way to do this. You can try moving /System/Library/Extensions/KeyspanNHCI-t.kext to /Library/StartupItems/NHCI/ and kextload Keyspan kext from /Library/StartupItems/Parallels/Parallels after Pvsvnic.kext. But I understand this is not user friendly solution. Stay tuned..."

I need an explanation of how to "...kextload Keyspan kext from /Library/..."

Bill Halberstadt

 

Serv meant using Terminal commands (Applications - Utilities - Terminal).
"kextload" commnad should be issued with the path for the kext to load, i.e. "sudo kextload /Library/StartupItems/NHCI/KeyspanNHCI-T.kext" for example. "kextunload" unloads driver the same way.
So I think you should try unloading Keyspan driver first, then unloading/loading Parallels driver and loading Keyspan driver again.

 

Stitchlink II

I think this is similar to the Keyspan USB server. This device is a wireless USB server for a sewing machine. I can connect directly via Parallels (USB) correctly. I can see the server and sewing machine via the Stitchlink (Silex) software, but can't connect. Anyone have a suggestion?

 

That would be nice if it worked.

Then you could just add this:

to /Library/StartupItems/Parallels/Parallels

 

Stichlink Solved (virtual USB device)

I solved it by changing the Network configuration on Parallels from Shared to Bridged. Hope this solution can solve other similar problems with virtual USB devices.

 

Upton,

Does your solution work? If so, what are the exact Terminal instructions to type in?
Thanks.

 

Yes. I didn't have to do any Terminal instructions. In Parallels Desktop, I did the following:

1) Launch Parallels Desktop for Mac

2) Click the Network Adapter link in the main configuration window to open its settings.

3) Make sure that the Enabled and Connect cable at startup options are selected in the Device Status area.

4) Under the Emulation section select the Bridged Ethernet option and choose Default Adapter or any other Mac network connection interface that is connected to the network.

5) Click OK to close Configuration Editor.

 

No, it didn't work. The kextunload command failed.

Here is the error from the system log:

Can't unload com.keyspan.iokit.KeyspanNHCI due to -
com.keyspan.iokit.KeyspanNHCI: KeyspanNHCI_UserClient has 1 instance(s)

In other words, it can't be unloaded because it's busy.

I think the trick is to move it someplace where it won't load, reboot, and then load it manually. I need to get this working now, so I'll see if I can come up with something and get back to you.

 

The problem is that bridged networking doesn't work in certain network environments. If it worked everywhere, there would be no need for three different networking configurations.

 

I'm not buying this. As someone pointed out, networking works fine alongside Keyspan USB Server in VMWare's product, so apparently they've managed to fix it from their side! Or did they just manage not to run into it in the first place?

When one product accomplishes something that another similar product can't, I find it a little hard to believe that the real problem is entirely the fault of a third party. Why would Keyspan choose to persecute you guys and leave VMWare alone? Maybe Keyspan's extension is doing something it shouldn't be, but it's just not reasonable to say that there is no way you can get your networking to work when VMWare can do it!

 

I haven't installed Leopard yet, but it's my understanding that StartupItems is going bye-bye. So I'm curious: how are people able to use Parallels in Leopard if it relies on StartupItems?

I'm also curious about why you're loading the Pvsvnic.kext from /Library/StartupItems/Parallels while all your other kernel extensions load from /System/Library/Extensions. Was this a workaround for another extension conflict of some kind?

Finally, if the problem is caused by the load order, can't you just rename your kernel extensions to, say, something that starts with J? Don't kernel extensions load in alphabetical order?