wpa_supplicant cannot authenticate connection on prism2 radios if interface names do not match
thor at math.tu-berlin.de
Mon Mar 16 16:13:46 EDT 2015
>> sorry to ask again, probably the issue got lost over the weekend. I
>> reported yesterday the following weird problem for wpa_supplicant
>> failing on prism2 wireless cards under some conditions related to udev.
>> Typically, the prism2 driver creates paired devices, wifi0 (raw radio,
>> as I understand it) and wlan0 (the established connection). For reasons
>> unclear to me, wpa_supplicant seems to depend matched names, i.e. if
>> wlanX is there, and it is a hostap (prism2) managed device, it also
>> expects wifiX there, with the same X.
> I would consider it a bug that the supplicant has to depend on the
> matched names. However, if the driver provides no mechanism to
> determine the sibling from the other interface, then obviously the bug
> in the supplicant could not be fixed until the driver exposes that kind
> of information.
Well, the information on the pairing is actually available in the sysfs
filing system. Thus,
contains two directories, namely the two network interfaces the device
> I don't happen to have a PCMCIA-capable laptop usable at the moment so I
> can't plug in a prism2 card to check, but is there anything
> in /sys/class/net/wlanX or its sub-directories that would link the
> sibling interfaces together?
Yes, see above.
> If so, then perhaps the supplicant could
> be modified to use that information and solve the problem. If not, then
> the driver needs some modification to advertise those. MAC address
> matching could work too, but that seems pretty fragile.
Hmm. I wonder why that is more fragile than above? It's probably harder
Anyhow, whatever the fix is, please let me know if I can try anything here.
BTW, you do not necessarily need PCMCIA to test this, it "only" needs
the hostap kernel driver. In this particular case, it is even a mini-PCI
card, but I have the same chip in a PCMCIA card.
More information about the HostAP