Summary: | net-wireless/hostapd is confused by udev | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jim Faulkner <dogshu> |
Component: | [OLD] Core system | Assignee: | udev maintainers <udev-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | 8an, dsd, jmjoseph, mobile+disabled |
Priority: | High | ||
Version: | 2006.1 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
udevinfo -a -p /sys/class/net/wlan0
udevinfo -a -p /sys/class/net/wlan0ap hostap driver patch slightly nicer patch |
Description
Jim Faulkner
2007-01-01 14:20:30 UTC
*** 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. |