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

[David Herrmann]

Hi

On Mon, Mar 16, 2015 at 11:09 AM, Tom Gundersen <teg at jklm.no> wrote:
> On Mon, Mar 16, 2015 at 11:01 AM, Thomas Richter <thor at math.tu-berlin.de> wrote:
>> Am 16.03.2015 um 10:53 schrieb Tom Gundersen:
>>> On Mon, Mar 16, 2015 at 10:34 AM, Thomas Richter <thor at math.tu-berlin.de> wrote:
>>>> The laptop in question had a ipw2200 card installed, which was
>>>> configured by udev as wlan0 (obviously). This card got replaced
>>>> (basically, due to another bug in ipw2200 which is unrelated to udev),
>>>> and "obviously" udev picked a new name for the adapter, which now became
>>>> wlan1. Unfortunately, udev *did not* change the name of the raw radio
>>>> (wifi0), which should have become wifi1 to make wpa_supplicant happy.
>>>
>>> udev would never pick the names wlan0 or wlan1 automatically, this is
>>> not how it (ever) worked. wlan0 and wlan1 are the sort of names the
>>> kernel sets, and at most udev (in very old versions) might have tried
>>> to remember these names between reboots and reapply them. This scheme
>>> is no longer in place though, so unless your distro is shipping some
>>> non-standard stuff or you have some old rule files lying around in
>>> /etc/udev/rules.d you should not be affected by that (and even if you
>>> are, I don't see how this would cause your current problem).
>>>
>>> Are you sure that udev is even renaming your devices at all? Booting
>>> with debug logging will tell you. You should see "Renamed network
>>> interface 'foo' to 'bar'" in your logs.
>>
>> Yup, I'm exactly seeing this message. "Renamed interface wlan0 to
>> wlan1". I'll go back to you tonight with the precise wording, but
>> that's pretty much the same kind of message you describe.
>>
>> Yes, of course the old "rules" file from the ipw2200 installation date
>> was still in place when I installed the prism2 card. It had (obviously)
>> the wlan0 assigned to the now (no longer available) ipw2200.
>>
>> Again, if I edit the /etc/rules.d/70-persistent-net.rules file, and
>> throw out the ipw adapter and the udev rule for hostap there, and let
>> udev recreate it, everything is fine, but how would average Joe User
>> would possibly get to this point?
>
> He wouldn't. That's why we don't do that stuff any more. Maybe debian
> does downstream, but they really should not (IMHO).
>
> So this particular issue has been fixed upstream long ago (by dropping
> the writing of rules to /etc). As mentioned earlier there may still be
> an issue left to solve with our new naming scheme, which I'll take to
> the kernel people.
>
>> In the end, the problem is really that wpa_supplicant seems to expect a
>> naming convention (so it seems) between wifi and wlan, and udev does not
>> respect this.
>>
>> Is this a wpa_supplicant bug or a udev bug? I don't know, but at least
>> it's a completely frustrating problem that costed me one sleepless night.
>
> FTR: udev should not know anything about any naming scheme that
> wpa_supplicant has. At most we'll detect that wpa_supplicant set a
> name, and just leave it alone.

I don't see how we can fix that via name_assign_type. Sure, we could
set this to NET_NAME_PREDICTABLE and udev would no longer rename it.
But the name is *NOT* predictable, so it would be a hack.

The other fix would be to tell udev to never rename hostap devices as
they will break. However, that's just due to wpa_supplicant relying on
matching names.

I'd prefer if we could tell wpa_supplicant to find the wlanX <->wifiY
relation via /sys, instead of relying on the matching names.

Thanks
David