Very long wpa_supplicant startup time - Win2K Pro

[Bryan Kadzban]

Jouni Malinen wrote:
> I'm not familiar with the order in which Windows starts up various
> services.

In theory, it starts them in dependent order.  Beyond that, I believe
it's alphabetical (registry-key order under
HKLM\System\CurrentControlSet\Services), though I don't know that for
sure.  It depends on the startup type, too, obviously.

(And then there are drivers.  I'm pretty sure it goes something like
this: drivers with a type of "boot" start first, then drivers with a
type of "system", then drivers and services with a type of "automatic",
and anything that's set to "manual" (for services) or "demand" (for
drivers) gets started only as needed.)

> I would do following tests to get a bit more exact understanding on
> where this delay is coming from:
> 1) use your wrapper service to start a simple program that is just
>    writing the current timestamp in main()
> 2) build the simple program with wpcap and packet libraries linked in
> 3) try linking in ws2_32 library
> 4) add call to WSAStartup() and print timestamp after that
> 5) link in remaining libraries wpa_supplicant is using (ssl, crypto,
>    gdi32, crypt32)

OK, I've done something slightly faster (as in, it'll get me all this
information in one run) -- wrote a simple program that did a LoadLibrary
on a bunch of the DLLs involved, printing the timestamp before and after
each load.

The culprit was wanpacket.dll (a dependency of packet.dll), which took
about 25 seconds to load.  It's part of WinPcap, and the source for it
shows that in its DllMain function (the function called when the DLL is
loaded into any process), it loads up npp/ndisnpp.dll (and nothing else).

ndisnpp.dll is not part of WinPcap, but some searching showed that it's
distributed with Windows -- it's apparently the host for some of the COM
components for Microsoft's Network Monitor program.  Somewhere in
Microsoft's documentation on that DLL, it said that it uses the "network
monitor system driver (nmnt.sys)" to do the captures.

So I did some registry digging, and found that nmnt.sys corresponded to
a driver named "Network Monitor Driver".  Opening up device manager and
selecting "show hidden devices" made it show up under the "non-PnP"
group.  The startup mode of this driver was set to Demand.  (I.e., load
only when required.)

I set it to "system" (load before all services), and the delay was gone.
 I'm guessing that ndisnpp.dll tried to start that driver, but since the
service control manager was busy starting all kinds of other services,
it couldn't get around to it for a long time.  Starting the driver as
part of the system fixes the problem, presumably because the ndisnpp.dll
DllMain doesn't have to start it.

After all this, I reverted to the original wpa_supplicant binaries,
which start up in a MUCH shorter time now.

Thank you very much!

(Now all I have to do is convince the PHBs to use wpa_supplicant instead
of either the $40/machine Odyssey supplicant from Funk Software, or the
$30/machine AEGIS supplicant from Meetinghouse.  Since it's a free
download, at least I definitely have cost on my side.  ;-) )

I wonder how many other people are doing something similar, that it
might make sense to put this info in the documentation somewhere?
Something like:

---

If you start wpa_supplicant from a Windows service, you will have to set
the startup type of the "Network Monitor Driver" driver to System
instead of the default Demand, otherwise wpa_supplicant will take a very
long time to start up.  To do this, open up Device Manager, select Show
Hidden Devices, expand the "Non Plug-and-Play devices" branch, double
click "Network Monitor Driver", go to the Driver tab, and change the
Demand setting to System instead.

---

perhaps?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20050818/242af44d/attachment.pgp