Intermediate NDIS driver issue

// Expert user has replied.
E Efkan YILMAZ 3 years 6 months ago
8 7 0

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

Please Register or Login to post a reply

7 Replies

D David Meyer

Can you post the registry settings they are removing?

E Efkan YILMAZ

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.

D David Meyer

They will cause all sort of trouble by removing those keys.  I am surprised that anything still works.

D David Meyer

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

E Efkan YILMAZ

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.

D David Meyer

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.

E Efkan YILMAZ

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

CONTACT
Can’t find what you’re looking for?