WZC: Keeping it on with version 0.5.4

[Bryan Kadzban]

On Fri, Aug 04, 2006 at 07:24:43AM -0700, George S. Lockwood wrote:
> Hello Jouni,
> 
> Actually, I was able to run the 4.9 binary in parallel with the WZC.  There
> might have sometimes been a slowness to connect but not sure.  I did not,
> however, see the WZC causing a disconnect???

We are not...  If WZC is running on a 2K Pro machine when 0.4.9 starts
up, wpa_supplicant will successfully authenticate, but then WZC resets
the connection and tries to authenticate on its own.  It has no
credentials configured, so this fails, and the user is off the network.

When installing our (self-written) wpa_supplicant wrapper service, we
have to go in and disable the WZC service.

> The primary reason for wanting WZC to run concurrently is for its UI the
> "Wireless Network Connections" window for its ability to display the
> detected APs.

That's a really crappy UI if you have more than one AP with the same
SSID(s) configured.  It only shows you one entry for each ESSID that it
sees, and absolutely *no* information on BSSID, security level (beyond
"this network is encrypted" (WEP) or "this network requires more
information" (WPA-PSK or WPA-EAP) -- no info on what level of WPA is
supported, or what encryption types), or any of that stuff.

(Plus, it allows even non-administrator users to screw up the network
configuration.  This is Really Bad when the machine is on the shop
floor, where people will do absolutely anything they are allowed to do,
but the machine needs to stay on the network, and the XP supplicant is
used.  In your case, it might screw stuff up or it might not, but I
don't think it's a good idea to have two programs controlling the
wireless in either case.)

Which is why we run another program we wrote, which uses WinPcap's
PacketRequest API to send NDIS requests to the wireless card, asking for
information on APs in the area.  (It also looks at a few other things,
most of which aren't really that important.  "wpa_cli status" is one of
them that's often helpful, though -- the program uses a UDP socket to
talk directly to the supplicant to get this info.  It also listens for
WMI NIC add/remove events to stop it from blue-screening when running
under WinPcap 3.1 or before -- in those versions, if you try to make a
PacketRequest on a handle whose device has been removed, you'll BSOD.)

It probably wouldn't be too difficult to come up with something similar.
That way, you would be able to see each individual BSSID (each AP), its
signal strength, and various other pieces of information that Windows
just plain won't give you.  (Or stuff that it will give you, but only in
a completely qualitative way.  I'm thinking specifically about signal
strength here -- it says the connection is "excellent", not "99%" or
"-36dBm".  What's the range of dBm values that correspond to "excellent"
or "good" or "poor"?  We don't need to know that...)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20060804/4a9180e5/attachment.pgp