wpa_supplicant does not work properly with some USB adapters on WinXP

Adrian Nistor anistor at gmail.com
Tue Aug 22 03:36:19 EDT 2006


I also (naturally) thought that the InstanceName from the event is the same
as the Name property of Win32_NetworkAdapter. It seems to be true in most
cases. Except for pluggable devices. Every time you unplug the card and
stick it back into the USB port, something very strange happens: the
InstanceName changes. A #1 is appended to the name, then #2, #3 ... and so
on every time you unplug it and plug it back again. The situation is very
similar if you have 2 identical adapters attached to the same computer (and
I have :-(). Their instance name will be different. Unfortunatelly the name
property of the Win32_NetworkAdapter is not changed by the OS, so it will
never match the IntanceName except for the first time the adapter is
installed on the computer (only one adapter). Pretty weird. I think this
might be a bug in the WMI provider (it is already known to have many bugs).

The good news is that the Name property of the Win32_PnPEntity class is
always in sync with the InstanceName as a new Win32_PnPEntity instance is
created every time you plug the adapter. And it is easy to navigate the
association from the pnp entity to the win32_networkadapter.

This is why I first select from WMI the PNPEntity and the navigate to
win32_networkadapter and then to win32_networkadapterconfiguration to get
the GUID.

Bye

On 8/21/06, Jouni Malinen <jkmaline at cc.hut.fi> wrote:
>
> On Mon, Aug 21, 2006 at 06:43:52PM +0300, Adrian Nistor wrote:
>
> > sorry for the very late reply. In the attached ZIP file I included the
> > config file and the output of the supplicant that demonstrates the
> issue.
> > It is very probable that you cannot reproduce this benaviour unless you
> use
> > the same wireless card. Mine is a Sweex usb adapter based on the Ralink
> 2500
> > chipset. The issue also appeared with another 2 USB adapters from other
> > manufacturers.
> >
> > I also included in the ZIP the two source files I modified in order to
> fix
> > the defect. The sources are based on the snapshot published in
> 8-Aug-2006.
>
> Thanks! I was trying to understand the use of PNPDeviceID in the
> queries. Why is the Win32_PnPEntity class needed here? Is Name property
> in that class guaranteed to match with InstanceName in the events? Why
> not just use Name in Win32_NetworkAdapter?
>
> The problem for me is that I have found no documentation describing
> where that InstanceName is coming from. Win32_NetworkAdapter class has
> number of properties (Caption, Description, Name, ProductName) that
> could be used as the source or it could be something completely
> different..
>
> I'm actually considering of doing this in the opposite order, i.e.,
> mapping adapter GUID to InstanceName, i.e., something like this:
>
> SELECT Index FROM Win32_NetworkAdapterConfiguration
>    WHERE SettingID='{GUID}'
>
> SELECT Name FROM Win32_NetworkAdapter WHERE Index=idx
>
> This would need to be done only once and the matching of events could
> actually be left to WMI since the "SELECT * FROM
> MSNdis_StatusMediaConnect" type queries could actually be changed to
> "SELECT * FROM MSDNdis_StatusMediaConnect WHERE InstanceName='name'"
> (and that name would need to be the correct one; which could be Name
> from Win32_NetworkAdapter).
>
> In addition to limiting number of WMI queries and reducing latency for
> each event, this should also simplify the interface from ndis_events.c
> to driver_ndis*.c since events would be delivered only for the correct
> adapter. I would just like to get confirmation on what is exact source
> of InstanceName string in WMI..
>
> --
> Jouni Malinen                                            PGP id EFC895FA
> _______________________________________________
> HostAP mailing list
> HostAP at shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20060822/eb9fc562/attachment.htm 


More information about the HostAP mailing list