Hi On Mon, Mar 16, 2015 at 11:09 AM, Tom Gundersen <[email protected]> wrote: > On Mon, Mar 16, 2015 at 11:01 AM, Thomas Richter <[email protected]> > wrote: >> Am 16.03.2015 um 10:53 schrieb Tom Gundersen: >>> On Mon, Mar 16, 2015 at 10:34 AM, Thomas Richter <[email protected]> >>> 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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
