Team, We have a project with Russian Railroads (mobile ticketing) where one of the requirements is that the WiFi connection must be protected by a software called VipNet - VPN-like package certified by Russian state authorities. The problem is that it does not work on our devices with Fusion driver (they've tested MC75 and MC55 and both freeze after post-installation reboot) while it works fine on the rest of the world :) using WZC. The developer says that VipNet uses own intermediate NDIS driver which does data encryption and does not assume that there are other intermediate drivers in the stack. They claim that in the case of Fusion there actually 3 drivers: JEDI10_1, miniport driver NPME\JEDI10_1, WLANPOWERDRV1. They're ready to adapt their SW to our WLAN stack but for this purpose they're asking for the possibility to debug it in the kernel mode (which I believe requires special OS images, am I right?). So my questions are 1. Is the kernel debug mode the only option here? Can we provide the developer with the tools and images required? 2. Can we provide technical documentation on Fusion which is deep enough to help the developer to adapt their intermediate driver to WLAN stack? 3. If both answers on the above is No then - do we have WZC-enable images of OS for MC75/55? 4. Any other advices are welcome as well Thanks, Valery
Intermediate NDIS driver issue// Expert user has replied. |
7 Replies
Can you post the registry settings they are removing?
They've removed the following branches: HKLM\Comm\JEDI10, HKLM\Comm\JEDI10_1 HKLM\Comm\WLANPOWERDRV HKLM\Comm\WLANPOWERDRV1 This was done after switching the unit to WZC mode.
They will cause all sort of trouble by removing those keys. I am surprised that anything still works.
Did they actually disable these other drivers, or just not bind their own intermediate driver to them? If they actually removed these other drivers, they basically prevent the entire Fusion stack from operating. They should specifically make their code bind to "NPME\HORNET10_1" or "NPME\JEDI10_1" depending on which radio they are using, and ignore the others. Their intermediate driver should be able to pick which driver to bind to, not bind to every driver that is active. -Dave
they've removed the registartion entries for these drivers from registry. Does this disable the drivers? Note that they're using MC65 switched to Windows Zero Config mode per User Guide.
Fusion 3.00 should support the use of 3rd party intermediate drivers, but the software would need to bind to NPME\JEDI10_1 which is the adapter name you get with our intermediate driver plus our miniport driver. Also note, that this is not a Fusion issue --> there are features in our intermediate driver which would exist even with a WZC client. 3rd party VPNs should be written to install on any adapter name and should not be written to assume a single miniport exists on the device.
The partner has tested MC65 switched to WZC mode. There are still three drivers in the stack but they've managed to disable all but HORNET10 e.g. they've removed registration for NPME.dll (NPME protocol) and NDUMMY.dll (WLANPOWERDRV protocol). The device remains operational e.g. WLAN module can be started/stopped and is able co connect to AP. And their VIPNET sowftware works fine. after this "customization". My questions: 1. What has been disabled exactly and how it affects or may affect the functionality and/or performance? 2. What other OS/SW components of the standard image depend on the disabled drivers if any? 3. Assuming the effect is not too much bad and customer can leave with it - can we as a vendor permit such customization from the legal and technical support points of view? Thanks, Valery