Am 16.03.2015 um 16:28 schrieb David Herrmann:
>
> 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?
Sure. The prism2pci (actually, hostap_pci) driver creates paired
devices. Without udev coming into play, it gets the names wlan0 and
wifi0, and "ifconfig" reports both of them. "wifi0" is, as far as I
understand the story, the raw "radio", and the hostapd user space daemon
sits on top of it for creating the access point.
For reasons unclear to me, wpa_supplicant *also* accesses both,
apparently because it has a dedicated driver model for hostap, besides
the generic wifi model (or so it seems). It then tries an rfkill on the
wifi0 driver, and if that does not exist, it falls over. Actually,
wpa_cli does not give much details about what exactly it pukes about,
only that it fails. I only found by experimenting.
If udev comes into play, it renames wlan0 to wlan1, because wlan0 was
already taken from a previously installed ipw2200 card that is no longer
in the system. Hence, I have now the network interfaces wifi0 and wlan1,
and that confuses wpa_supplicant to an amount that it can no longer
authenticate the connection. Why precisely that is the case I do not
know, but naming both interfaces the same resolves the problem.
> 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?
Actually, what's probably part of the confusion (likely) is that
"hostap" is the name of the kernel driver for the prism2/2.5/3 chipsets,
and their special feature is that they can *also* act as host-driven
access point (hence the name). To enable this feature, you also need an
additional user-space daemon, but that is not involved in the whole
problem. It may create additional network interfaces, though this is not
relevant for the matter at hand.
The same problem also appears for PCMCIA-driven prism2 chipsets, here
specifically for old "LinkSys" wifi PCMCIA cards. They are handled by
hostap_cs. Same problem, it creates two interfaces, not one, the radio
at "wifi0", and the configured network at "wlan0".
All the hostap drivers seem to be in supported state, i.e. they are not
part of the "stagging" kernel.
Greetings,
Thomas
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
