Bugzilla Bug 159646

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 an attachment (id=131723) [details]
udevinfo -a -p /sys/class/net/wlan0

Created an attachment (id=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 an attachment (id=131838) [details]
hostap driver patch

please see if this patch changes anything

Created an attachment (id=131839) [details]
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.