[systemd-devel] udev breaks hostap linkage of raw/user interfaces, causing wpa_supplicant problems

[Thomas Richter]

Am 16.03.2015 um 09:04 schrieb Greg KH:
> On Mon, Mar 16, 2015 at 08:26:00AM +0100, Thomas Richter wrote:
>> Hi folks,
>>
>>> udev seems to create a problem here with the hostap (prism2) kernel
>>> driver. Unlike many wifi devices, the hostap device driver always
>>> creates paired interfaces, a raw interface (wifiX) and a network
>>> interface (wlanX) that represents the configured network.
>>>
>>> Unfortunately, udev (or hostap?) does not seem to be aware of this
>>> linkage, and hence, if you have two wifi radios in your system, may
>>> rename the second (wlanX) without the first (wifiX), and hence causing a
>>> name mismatch between the two.
>>>
>>> In general, this is not a problem, however, wpa_supplicant seems to
>>> depend on the linkage of the names. Hence, if wifiX does not match
>>> wlanX, wpa_supplicant will be unable to provide a WPA2 connection over a
>>> hostap driven wifi connection.
>>>
>>> Even worse, the complete procedure is completely untransparent to the
>>> user, i.e. neither wpa_supplicant (nor network-manager, depending on
>>> wpa_supplicant) nor network-manager provide a useful error message.
>>>
>>> Any chance of fixing this problem? Is this "only" a configuration issue?
>>> Is this an issue of hostap? Is this an issue of wpa_supplicant?
>>>
>>> Either way, it took me several hours of figuring out what was wrong....
>>
>> One day passed, no useful pointers. Folks, sorry to say, but it is
>> unacceptable if udev *breaks* the prism wifi.
> 
> A Sunday passed, and you are upset that no one fixed a problem for an
> obsolete kernel driver?  What kind of free software support are you used
> to?
> 
> Anyway, which exact kernel driver is this?  Is it prism2_usb?  Or
> something else?

It's regular PCI based prism2, thank you. I'm not expecting *you* to fix
things in prism2, for sure. This is not the hostap mailing list.

But look, if udev can take a working kernel driver (and prism2 surely
is), and breaks its interfaces, then apparently something changed in the
interface from back then when prism2 was written and working, to now,
where it no longer is.

Of course we can now move responsibility around: It's wpa_supplicant's
fault, it's prism2's fault, ... but in the end, it doesn't help. The
driver is still not working, because udev silently changed the interface.

IOW, if you change interfaces, I believe a robust software development
should probably check whether that breaks anything, and if it does, it's
probably saver to assume that *not* renaming an interface is probably
the better choice unless you know that the corresponding kernel driver
*can* handle this. I believe a safer default assumption would be not
rename anything *unless proven safely*, but that decision was not taken.

I'm completely unaware of the inner workings of udev or the kernel
driver for that matter. I'm only reporting a problem, and a problem that
an average user is completely unable to solve.

I don't know how to configure udev to "keep its hands off prism2", but
that would be a start, and it would be a suitable default configuration
for udev that should probably ship with it. A better solution would
probably to have an indicator somewhere whether a device can be safely
renamed or not, and prism2 apparently cannot, and in that case not to
attempt to rename it.

One way or another, you have a design problem here, namely that udev
moves things around without really knowing enough about the device in
question and whether this renaming does any good for a particular device.