Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 159646 - net-wireless/hostapd is confused by udev
Summary: net-wireless/hostapd is confused by udev
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: udev maintainers
: 159647 (view as bug list)
Depends on:
Reported: 2007-01-01 14:20 UTC by Jim Faulkner
Modified: 2007-11-19 20:52 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---

udevinfo -a -p /sys/class/net/wlan0 (wlan0,2.08 KB, text/plain)
2007-09-23 18:12 UTC, Lukas Turek
udevinfo -a -p /sys/class/net/wlan0ap (wlan0ap,2.09 KB, text/plain)
2007-09-23 18:13 UTC, Lukas Turek
hostap driver patch (hostap.patch,2.97 KB, patch)
2007-09-25 10:50 UTC, Daniel Drake (RETIRED)
Details | Diff
slightly nicer patch (hostap.patch,3.01 KB, patch)
2007-09-25 10:56 UTC, Daniel Drake (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jim Faulkner 2007-01-01 14:20:30 UTC
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, i686)
System uname: 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
CFLAGS="-march=athlon-xp -O2 -ggdb -pipe"
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"
FEATURES="autoconfig distcc distlocks metadata-transfer nostrip sandbox sfperms strict"
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'"
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"
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2007-01-01 14:35:00 UTC
*** Bug 159647 has been marked as a duplicate of this bug. ***
Comment 2 Matthias Schwarzott gentoo-dev 2007-01-24 14:18:25 UTC
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 ?
Comment 3 Matthias Schwarzott gentoo-dev 2007-01-30 16:37:46 UTC
Perhaps you can do the following:

Attach "udevmonitor --env" output for empty 70-persistent-net.rules
Comment 4 Steev Klimaszewski (RETIRED) gentoo-dev 2007-02-10 04:00:24 UTC
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.
Comment 5 Lukas Turek 2007-09-10 00:02:22 UTC
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.
Comment 6 Matthias Schwarzott gentoo-dev 2007-09-10 08:28:48 UTC
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.
Comment 7 Lukas Turek 2007-09-10 10:57:27 UTC
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.
Comment 8 Matthias Schwarzott gentoo-dev 2007-09-10 11:53:17 UTC
(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?
Comment 9 Lukas Turek 2007-09-10 12:12:08 UTC
Yes, but udev readded the persistent rule for wlan0, so it broke again.
Comment 10 Lukas Turek 2007-09-10 21:41:03 UTC
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

+# Do not match the wlan?ap interface created by hostapd
+if [ $basename = "wlan" ]; then
+	match="$match, KERNEL!=\"*ap\""
 write_rule "$match" "$INTERFACE" "$COMMENT"

Comment 11 Matthias Schwarzott gentoo-dev 2007-09-21 10:17:52 UTC
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"


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.
Comment 12 Lukas Turek 2007-09-21 10:31:50 UTC
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.
Comment 13 Matthias Schwarzott gentoo-dev 2007-09-21 21:34:25 UTC
(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
udevinfo -a -p /sys/class/net/wlan0ap
Comment 14 Lukas Turek 2007-09-23 18:12:54 UTC
Created attachment 131723 [details]
udevinfo -a -p /sys/class/net/wlan0
Comment 15 Lukas Turek 2007-09-23 18:13:31 UTC
Created attachment 131725 [details]
udevinfo -a -p /sys/class/net/wlan0ap
Comment 16 Matthias Schwarzott gentoo-dev 2007-09-23 20:03:20 UTC
(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.
Comment 17 Lukas Turek 2007-09-23 20:59:22 UTC
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?
Comment 18 Matthias Schwarzott gentoo-dev 2007-09-24 15:48:33 UTC
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:

        local->apdev = hostap_add_interface(local, HOSTAP_INTERFACE_AP,
                                            rtnl_locked, local->ddev->name,
        if (local->apdev == NULL)
                return -ENOMEM;

        local->apdev->hard_start_xmit = hostap_mgmt_start_xmit;
        local->apdev->type = ARPHRD_IEEE80211;

Comment 19 Lukas Turek 2007-09-24 19:15:26 UTC
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.
Comment 20 Daniel Drake (RETIRED) gentoo-dev 2007-09-25 10:50:45 UTC
Created attachment 131838 [details, diff]
hostap driver patch

please see if this patch changes anything
Comment 21 Daniel Drake (RETIRED) gentoo-dev 2007-09-25 10:56:37 UTC
Created attachment 131839 [details, diff]
slightly nicer patch
Comment 22 Lukas Turek 2007-09-25 21:20:07 UTC
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!
Comment 23 Daniel Drake (RETIRED) gentoo-dev 2007-10-03 11:52:30 UTC
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.
Comment 24 Matthias Schwarzott gentoo-dev 2007-11-19 20:52:06 UTC
Fixed. The new rules are contained in udev-115-r2 and newer.