| Summary: | sys-fs/udev-108 wrongly names ath* devices | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Vladimir Pouzanov <farcaller> |
| Component: | [OLD] Core system | Assignee: | udev maintainers <udev-bugs> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | chrb |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Which udev version is this about? sys-fs/udev-108 The workaround seems to be simple: just remove ath from persistent-net-generator so it no longer manages it.
I've found code that looks strange to me (/lib/udev/write_net_rules):
if [ $basename = "ath" -o $basename = "wlan" ]; then
match="$match, ATTRS{type}==\"1\"" # do not match the wifi* interfaces
fi
What is ATTRS{type}=="1" used for?
*** Bug 180889 has been marked as a duplicate of this bug. *** Is that bug still reproducable with udev-115 and up to date driver? It's still present in udev-114 which is the latest stable. I remove ath* from the whitelist: # device name whitelist KERNEL!="eth*|ath*|wlan*|ra*|sta*|ctc*|lcs*|hsi*", GOTO="persistent_net_generator_end" and it works, otherwise the device number keeps being incremented. As 75-persistent-net.rules will be overwritten on updates (and even faster as soon as we remove /etc/udev/rules.d/ from CONFIG_PROTECTION): One possible better workaround is to add this rule to some own file (e.g. 20-local.rules): SUBSYSTEM=="net", KERNEL=="ath*", NAME="%k" As NAME is then already set, persistent-net will not catch this device. Given that there are comments on the madwifi.org bug report for fixing debian and ubuntu by patching the same file, I wonder why this isn't being fixed in udev upstream? Isn't there a reason ath IS considered for persistent-net. I guess problems arises when there are two or more wlan devices in a system. Then the order of the devices will be random (assuming the default of automatically creating an ath device). Or is that wrong? How many device drivers use name ath? If it is just one the order will then depend on bus detection order (pci/usb). The ath devices are unique in that you use a user space tool (wlanconfig) to create virtual access point ath* devices with semi-random MAC addresses. It used to be that this caused udev to keep incrementing the device number, and I thought this was still the case, but it appears I was mistaken - my case was being caused by macchanger changing the MAC address, and then udev incrementing the device number. If you aren't changing MAC addresses then this bug appears to no longer apply. The only persistent device name I'm getting is for ath0. I think possibly this rule is now being applied: # ignore the interface if a name has already been set NAME=="?*", GOTO="persistent_net_generator_end" I don't know what version of udev introduced this. I'm going to close this bug since I can no longer reproduce it and Gentoo doesn't support macchanger with madwifi anyway (see bug #180912). on my system (udev-114 and madwifi-ng-0.9.3.2) this bug is still reproducible, so please reopen this bug. I'm not using changed MACs, in fact every athX device i create shares the MAC of the wifi0-hardware-interface. additionally I'd like to point out that everything works fine as long as I create ath0 in station mode. As described in the first post this bug only triggers when creating a athX device in monitor mode. |
Udev creates new entry in 70-persistent-net.rules eachtime when I try to do something like: wlanconfig ath create wlandev wifi0 wlanmode monitor wlanconfig reports 'ath1' but the actual iface is named athXX where XX increments each time when I recreate the iface. Rules file is full of # PCI device 0x168c:0x001c (ath_pci) SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:15:**:**:**:**", ATTRS{type}=="1", NAME="ath0" # PCI device 0x168c:0x001c (ath_pci) SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:15:**:**:**:**", ATTRS{type}=="1", NAME="ath1" # PCI device 0x168c:0x001c (ath_pci) SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:15:**:**:**:**", ATTRS{type}=="1", NAME="ath2" ... Reproducible: Always Steps to Reproduce: 1. wlanconfig ath create wlandev wifi0 wlanmode monitor 2. wlanconfig athXX destroy 3. wlanconfig ath create wlandev wifi0 wlanmode monitor ... Actual Results: New athX is created Expected Results: ath1 should be used (as reported by wlanconfig)