I am using hostapd to implement a WPA-protected wireless access point on my gentoo box. When hostapd starts up, it creates a device called "wlan0ap", which apparently is necessary for hostapd to run. However, after this interface is initially created, or perhaps after the hostapd process is terminated, udev does something strange to the "wlan0ap" interface, which causes hostapd to cease functioning. Here's what happens when I try to restart a fully functional hostapd process: leech ~ # /etc/init.d/hostapd restart * Stopping hostapd ... [ ok ] * Starting hostapd ... Configuration file: /etc/hostapd/hostapd.conf ioctl(SIOCGIFINDEX): No such device hostap driver initialization failed. rmdir[ctrl_interface]: No such file or directory [ !! ] leech ~ # udev then proceeds to edit /etc/udev/rules.d/70-persistent-net.rules and adds this line: SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:09:5b:0f:03:40", ATTRS{type}=="1", NAME="wlan0ap" Which then makes the wlan0ap interface strangeness persist across reboots. In order to get this working, I've had to add some code to my /etc/conf.d/local.stop to remove the above line from 70-persistent-net.rules on every shutdown. However, I'm not a udev guru, so I've had to resort to rebooting my machine every time I make a configuration change to hostapd. Obviously this is unacceptable. Right now I'm running hostapd-0.5.4, however I had the exact same problem with the stable version. Here's my emerge --info, please let me know if there's anything else you'd like to know: Portage 2.1.1-r2 (default-linux/x86/2006.0, gcc-4.1.1, glibc-2.4-r4, 2.6.19.1 i686) ================================================================= System uname: 2.6.19.1 i686 AMD Athlon(tm) Gentoo Base System version 1.12.6 Last Sync: Mon, 01 Jan 2007 10:00:01 +0000 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] app-admin/eselect-compiler: [Not Present] dev-java/java-config: [Not Present] dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -O2 -ggdb -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=athlon-xp -O2 -ggdb -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distcc distlocks metadata-transfer nostrip sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/var/tmp/lucyvartmp/gentoo-portage" PORTDIR_OVERLAY="/usr/local/portage-overlay" SYNC="rsync://jove.eng.yale.edu/gentoo-portage" USE="x86 3dnow X aiglx alsa alsa_cards_ali5451 alsa_cards_als4000 alsa_cards_atiixp alsa_cards_atiixp-modem alsa_cards_bt87x alsa_cards_ca0106 alsa_cards_cmipci alsa_cards_emu10k1x alsa_cards_ens1370 alsa_cards_ens1371 alsa_cards_es1938 alsa_cards_es1968 alsa_cards_fm801 alsa_cards_hda-intel alsa_cards_intel8x0 alsa_cards_intel8x0m alsa_cards_maestro3 alsa_cards_trident alsa_cards_usb-audio alsa_cards_via82xx alsa_cards_via82xx-modem alsa_cards_ymfpci alsa_pcm_plugins_adpcm alsa_pcm_plugins_alaw alsa_pcm_plugins_asym alsa_pcm_plugins_copy alsa_pcm_plugins_dmix alsa_pcm_plugins_dshare alsa_pcm_plugins_dsnoop alsa_pcm_plugins_empty alsa_pcm_plugins_extplug alsa_pcm_plugins_file alsa_pcm_plugins_hooks alsa_pcm_plugins_iec958 alsa_pcm_plugins_ioplug alsa_pcm_plugins_ladspa alsa_pcm_plugins_lfloat alsa_pcm_plugins_linear alsa_pcm_plugins_meter alsa_pcm_plugins_mulaw alsa_pcm_plugins_multi alsa_pcm_plugins_null alsa_pcm_plugins_plug alsa_pcm_plugins_rate alsa_pcm_plugins_route alsa_pcm_plugins_share alsa_pcm_plugins_shm alsa_pcm_plugins_softvol apm bash-completion berkdb bitmap-fonts bzip2 cli cracklib crypt debug dlloader dri eds elibc_glibc emboss encode foomaticdb fortran gdbm gif glitz gnome gpm gstreamer gtk gtk2 iconv imlib input_devices_evdev input_devices_keyboard input_devices_mouse isdnlog jpeg kde kdeenablefinal kernel_linux libg++ libwww logrotate mad memlimit mikmod mmx motif mp3 mpeg mysql ncurses nptl nptlonly offensive opengl oss pam pcmcia pcre perl php png posix pppd python qt3 quicktime readline reflection sdl session sharedmem sockets spell spl sse ssl tcpd truetype truetype-fonts type1-fonts udev userland_GNU video_cards_nv video_cards_nvidia xml xorg xv zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS
*** Bug 159647 has been marked as a duplicate of this bug. ***
What is the udev-version you used? And can you please post the list of existing network devices (see /sys/class/net/). Is there any device called *_rename ?
Perhaps you can do the following: Attach "udevmonitor --env" output for empty 70-persistent-net.rules
No response in over a month, and I do believe that with udev latest stable this issue should be fixed. Please reopen if this isn't the case.
Unfortunately this is not fixed in current stable udev-114 and hostapd-0.4.7 and I have no idea how to fix it, it might be a design problem in udev. Udev assumes that MAC addres is unique, but it's not the case here. When hostap module is loaded, it creates interface wlan0. Udev notices it and writes persistent net rule. Then when hostapd starts, it tells the module via some ioctl to create virtual interface wlan0ap. And this interface is created with the same MAC address! So udev tries to rename the interface to wlan0, which already exists and gets confused, leaving wlan0_rename and breaking hostapd. A quick hack is to disable renaming of wlan* in 70-persistent-net.rules, but a better solution would need an exception somewhere where the renaming occurs - I don't know where it is. I hope this explanation helps someone smarter to find it.
There was a bug in 75-persistent-net.rules. This is fixed in ~arch udev. See Bug 190692. Please test if udev-115 or newer fixes this.
Unfortunately it's not fixed, I tried both the ~arch version and the masked one. I think this can't be fixed by a change of udev rules (other than the quick hack mentioned above), but it would require change to the renaming itself in udev_device.c (function rename_netif). But this function already checks if the target interface exists... I will debug it further later this day.
(In reply to comment #7) > Unfortunately it's not fixed, I tried both the ~arch version and the masked > one. I think this can't be fixed by a change of udev rules (other than the Did you remove the created rules 70-persistent-net.rules before testing a new udev version?
Yes, but udev readded the persistent rule for wlan0, so it broke again.
I've finally understood the code in udev_device.c: it checks whether the target interface exists, and if it does, it adds _rename to its name and tries to set the target name every second up to 30 times. It's quite a simple solution to swap names of two interfaces, but does not help us at all. But I have found how to tell udev not to rename wlan?ap interfaces - by adding KERNEL!="*ap" to the persistent-net rules. This patch against /lib/udev/write_net_rules does this: --- write_net_rules.orig 2007-08-24 01:29:54.000000000 +0200 +++ write_net_rules 2007-09-10 23:30:42.000000000 +0200 @@ -123,6 +123,11 @@ match="$match, ATTR{type}==\"1\"" # do not match the wifi* interfaces fi +# Do not match the wlan?ap interface created by hostapd +if [ $basename = "wlan" ]; then + match="$match, KERNEL!=\"*ap\"" +fi + write_rule "$match" "$INTERFACE" "$COMMENT" unlock_rules_file
Can you please check this modification suggested by Kay: Altering 75-persistent-net-generator.rules from KERNEL!="eth*|ath*|wlan*|ra*|sta*|ctc*|lcs*|hsi*", GOTO="persistent_net_generator_end" to KERNEL!="eth*|ath*|wlan*[0-9]|ra*|sta*|ctc*|lcs*|hsi*", GOTO="persistent_net_generator_end" So that it will no longer try to act on wlan*ap interfaces.
Unfortunately this don't work. It prevents udev from adding persistent rule for wlan0ap, but it still creates rule for wlan0. And this rule also matches wlan0ap. So the exception must be in the generated rule, not in the generator.
(In reply to comment #12) > Unfortunately this don't work. It prevents udev from adding persistent rule for > wlan0ap, but it still creates rule for wlan0. And this rule also matches > wlan0ap. So the exception must be in the generated rule, not in the generator. > Can you please attach output of udevinfo -a -p /sys/class/net/wlan0 and udevinfo -a -p /sys/class/net/wlan0ap
Created attachment 131723 [details] udevinfo -a -p /sys/class/net/wlan0
Created attachment 131725 [details] udevinfo -a -p /sys/class/net/wlan0ap
(In reply to comment #12) > Unfortunately this don't work. It prevents udev from adding persistent rule for > wlan0ap, but it still creates rule for wlan0. And this rule also matches > wlan0ap. So the exception must be in the generated rule, not in the generator. > Can you please try it again. And also show me the rule it creates for wlan0. As from the udevinfo output I guess testing ATTRS{type}=="1" should be enough to ignore wlan0ap.
Yes, I see... This is the generated rule: # PCI device 0x1260:0x3873 (hostap_pci) SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:60:b3:65:6c:23", ATTR{type}=="1", NAME="wlan0" But udev still tries to rename the interface (output od udevd --verbose): [4355] wait_for_sysfs: file '/sys/devices/pci0000:00/0000:00:08.0/0000:01:0a.0/net/wlan0ap/address' appeared after 0 loops [4355] udev_rules_get_name: rule applied, 'wlan0ap' becomes 'wlan0' [4355] rename_netif: changing net interface name from 'wlan0ap' to 'wlan0' I run udevd via strace: [pid 10936] lstat64("/sys/devices/pci0000:00/0000:00:08.0/0000:01:0a.0/net/wlan0ap/type", {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0 [pid 10936] open("/sys/devices/pci0000:00/0000:00:08.0/0000:01:0a.0/net/wlan0ap/type", O_RDONLY|O_LARGEFILE) = 3 [pid 10936] read(3, "1\n", 256) = 2 It read type 1, but when I look to the file there's 801! So maybe it's some race condition? Maybe udev reads the type before it is valid?
So it may be a kernel-bug, citing from Mail from Kay Sievers: Maybe the type assignment just needs to be done before registration in: drivers/net/wireless/hostap/hostap_main.c::hostap_enable_hostapd(): local->apdev = hostap_add_interface(local, HOSTAP_INTERFACE_AP, rtnl_locked, local->ddev->name, "ap"); if (local->apdev == NULL) return -ENOMEM; local->apdev->hard_start_xmit = hostap_mgmt_start_xmit; local->apdev->type = ARPHRD_IEEE80211; Kay
Maybe, but I don't have a SMP system (old Barton 2500+). I have Voluntary Preemption enabled, I will try it with non-preemptible kernel tomorrow.
Created attachment 131838 [details, diff] hostap driver patch please see if this patch changes anything
Created attachment 131839 [details, diff] slightly nicer patch
Yes, this patch really fixed the problem, udev now reads the type correctly: [pid 3112] lstat64("/sys/devices/pci0000:00/0000:00:08.0/0000:01:0a.0/net/wlan0ap/type", {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0 [pid 3112] open("/sys/devices/pci0000:00/0000:00:08.0/0000:01:0a.0/net/wlan0ap/type", O_RDONLY|O_LARGEFILE) = 3 [pid 3112] read(3, "801\n", 256) = 4 But the change in Comment #11 is needed too, otherwise udev adds this persistent rule (the type there comes from write_net_rules script, not sysfs): # PCI device 0x1260:0x3873 (hostap_pci) SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:60:b3:65:6c:23", ATTR{type}=="1", NAME="wlan0ap" The kernel patch and this change combined solve the original bug. Many thanks for the great work!
Thanks for testing. This patch was accepted upstream for 2.6.24. It will be included in the next gentoo-sources-2.6.22 release, and all gentoo-sources-2.6.23 releases. Now someone just needs to ship the updated rules in udev.
Fixed. The new rules are contained in udev-115-r2 and newer.
