Hi On Mon, Mar 16, 2015 at 1:04 PM, Thomas Richter <t...@math.tu-berlin.de> wrote: > Am 16.03.2015 um 12:53 schrieb David Herrmann: > >> 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. >> > > FYI, I also reported this on the wpa_supplicant mailing list, but > there's no reaction on this yet. Apparently, it tries to "rfkill" the > seemingly dead wifiX radio, and fails if the radio isn't where it is > expected - or so it seems.
I wrote a patch that fixes the kernel hostap driver to report the correct name-assign-type: https://gist.github.com/dvdhrm/0a04ef4ad07ecfe7443e I will wrap it up and submit it upstream. However, it would be nice if you could describe your issues in more detail. In particular, I cannot see any "wifiX" to "wlanX" issue. The hostap driver exports a "wlanX" device as a base and multiple sub-devices with a special suffix if requested by user-space. Therefore, your system should have a "wlanX" device, and a "wlanXap" / "wlanXsta" device, and maybe multiple "wlanXwdsY" devices. Can you list the devices you see (with renaming enabled, if possible) so I can figure out what exactly goes wrong? I cannot see why you'd have a "wifiX" device. Even the wpa_supplicant driver_hostap.c file uses "wlanXap", not "wifiX". Can you elaborate on that, please? Thanks David _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel