Bug#488267: lenny-beta2-netinst: wifi interface renaming causes big glitch on first reboot
Otavio Salvador wrote:
Hello Barry,
Looking at the output data I fail to see how this mess happened. I'd
like to ask you to do another test for us. Please boot d-i and after
wireless has been properly setup grab the following information:
/proc/net/dev
lspci -knn
My current bet is that wireless is using a different module, but it's
a guess and I'd like to confirm that.
Further to my recent email with lots of output included:
A bit of digging found the following, amongst others:
http://blog.janus.cx/archives/226-Renaming-interface-wlan0_rename-to-wlan0-using-a-udev-rule-under-Debian-Etch.html
http://ubuntuforums.org/showthread.php?p=4598734
https://bugs.launchpad.net/ubuntu/+source/udev/+bug/202575
I now believe this is squarely to do with the "master/slave" stuff
between wifi0 and wlan0 in SOME drivers, aka hostap I think. I came
across it before with madwifi. See eg
http://madwifi.org/wiki/UserDocs/StationInterface
although I seem to recall finding better documentation than that
previously - I'll keep looking.
The basic idea seems to be that some drivers - now, I think including
the current hermes/orinoco - create a base device (often called wifiN,
typically N=0), and this has the capability of being used as master for
a number (maybe 1) of APs (access points) and a number of "stations"
(normal 802.11 clients). So bringing up such an interface in the
"normal" way involves:
* driver creates master device eg wifi0
* someone (?who - also the driver?) creates single station device wlan0
as in above link
You can see this happening in the syslog extract I supplied.
THEN, in our context, someone like udev gets involved and for some
reason wlan0 has to be renamed wlan0_rename...
It would be great if you knew someone who (a) could explain this better,
or point at the FAQ and (b) could see how to circumvent, subvert or just
mend it for our simple context!
Hope this helps,
Barry
Reply to: