wpa_supplicant cannot authenticate connection on prism2 radios if interface names do not match

[Dan Williams]

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,
> 
> /sys/class/net/wlan0/device/
> 
> contains two directories, namely the two network interfaces the device 
> manages.

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.

Dan

> > 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.
> 
> Greetings,
> 	Thomas
>