wpa_supplicant cannot authenticate connection on prism2 radios if interface names do not match
dcbw at redhat.com
Tue Mar 17 12:10:22 EDT 2015
On Mon, 2015-03-16 at 21:13 +0100, Thomas Richter wrote:
> Hi Dan,
> >> 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
Can you get a full 'ls -al' dump of /sys/class/net/wlan0/device/ ?
wpa_driver_wext_finish_drv_init() should probably do some sysfs parkour
to find the wifi interface instead of relying on the device name.
> > 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
> to do.
> 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