Description of problem: The udev gives one of PLAYSTATION 3's network devices (either ether or wireless) an unexpected name, after /etc/udev/rules.d/70-persistent-net.rules was generated. Version-Release number of selected component (if applicable): udev-118-5.fc9.ppc udev-118-11.fc9.ppc How reproducible: Every time. Steps to Reproduce: 1. Install F-9 beta onto PS3. 2. Boot PS3 with F-9 beta. 3. Reboot PS3 (if it's the first boot). 4. run 'ifconfig' command. Actual results: [root@localhost ~]# cat /etc/udev/rules.d/70-persistent-net.rules # This file was automatically generated by the /lib/udev/write_net_rules # program run by the persistent-net-generator.rules rules file. # # You can modify it, as long as you keep each rule on a single line. # net device (custom name provided by external tool) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:xx:xx:xx:xx:xx", ATTR{type}=="1", NAME="eth0" # net device (custom name provided by external tool) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:xx:xx:xx:xx:xx", ATTR{type}=="1", NAME="wlan0" [root@localhost ~]# ifconfig eth0 Link encap:Ethernet HWaddr XX:XX:XX:XX:XX:XX inet addr:***.***.***.*** Bcast:***.***.***.*** Mask:***.***.***.*** inet6 addr: ****::****:****:****:****/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:11 errors:0 dropped:0 overruns:0 frame:0 TX packets:28 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1365 (1.3 KiB) TX bytes:5106 (4.9 KiB) Interrupt:50 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) wlan0_rename Link encap:Ethernet HWaddr XX:XX:XX:XX:XX:XX inet6 addr: ****::****:****:****:****/64 Scope:Link UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:586 (586.0 b) Expected results: The network devices are named 'eth0' and 'wlan0'. Additional info: This problem arises because the same MAC address is used for both of the ether and wireless on PS3 and udev uses MAC address to identify network devices.
This problem has been fixed in udev-119 by modifying the write_net_rules script.
built udev-120 for rawhide how did you modify the write_net_rules script?
The write_net_rules script in udev-119 no longer has this problem. This problem is specific to the udev-118 or earlier. So if the upcoming udev for rawhide is udev-120, this problem will disappear. I'll try the latest one. Thank you!
The udev-120 still doesn't work correctly. The fix in udev-119/120 seems to be insufficient for Fedora, since the Fedora's /etc/udev/rules.d/60-net.rules defines the 'INTERFACE_NAME' environment variable. Attached is a patch to fix it. I'm not sure that this fix is the most ideal solution, but it works for PS3.
Created attachment 301462 [details] patch for write_net_rules
Created attachment 301485 [details] patch for write_net_rules (take 2)
So, if I understand that correctly the only difference between eth0 and wlan0 seems to be the KERNEL attribute? /sys/class/net/eth0 and /sys/class/net/wlan0 look both the same?
How is that functional in general? It seems like it would lead to many issues other than just udev. Are they magically bridged?
We have a similar issue with mesh vs. eth devices on OLPC, where we need to distinguish between them by other attributes in /sys/class/$DEV/ cf. http://dev.laptop.org/ticket/5746
(In reply to comment #7) > So, if I understand that correctly the only difference between eth0 and wlan0 > seems to be the KERNEL attribute? > /sys/class/net/eth0 and /sys/class/net/wlan0 look both the same? The existence of the 'wireless' node is also difference between eth0 and wlan0, so I suppose we can distinguish between them by testing the 'wireless' node.
This problem was pointed out in the openSuSE project before: https://bugzilla.novell.com/show_bug.cgi?id=365501
(In reply to comment #8) > How is that functional in general? It seems like it would lead to many issues > other than just udev. > > Are they magically bridged? PS3 assumes these two interfaces (eth and wlan) are connected to separate subnets. We can't use both in the same network at the same time.
Created attachment 301740 [details] /sys/class/net/eth0/
Created attachment 301741 [details] /sys/class/net/wlan0/
Here is difference between /sys/class/net/eth0 and /sys/class/net/wlan0: [root@localhost ~]# diff tree-eth0.txt tree-wlan0.txt 44a45,55 > ./wireless > ./wireless/beacon > ./wireless/crypt > ./wireless/fragment > ./wireless/level > ./wireless/link > ./wireless/misc > ./wireless/noise > ./wireless/nwid > ./wireless/retries > ./wireless/status
$ for i in /sys/class/net/eth0/*; do test -f $i && diff -u /sys/class/net/{eth0,wlan0}/$(basename $i);done will show the difference of the file contents.. e.g. one could check: $ cat /sys/class/net/eth0/carrier 1 which wlan0 does not have. But that is really special for this case now.
Created attachment 301786 [details] diff -Nur /sys/class/net/eth0 /sys/class/net/wlan0/ It's difference of the file contents.
Created attachment 302303 [details] patch for write_net_rules (take 3) This patch tests the existence of the 'wireless' directory in the sysfs to distinguish between PS3's two network interfaces. I think this is the only meaningful difference between eth and wlan in the sysfs. Is this fix acceptable?
Created attachment 302312 [details] Add KERNEL=="$basename*" to all rules, not just some. Perhaps it would be better to use the basename that the kernel provides (eth%d vs wlan%d) to distinguish between the interfaces. The write_net_rules script already does this, in some cases -- I don't see why it shouldn't do it all the time. That would fix the Libertas eth%d vs. msh%d case too, without special-case hacks.
Can we discuss this on the upstream mailing list please? linux-hotplug.org http://vger.kernel.org/vger-lists.html#linux-hotplug
http://news.gmane.org/gmane.linux.hotplug.devel/
Oops, sorry -- I didn't realise that a previous patch had done exactly the same thing, and I was joining an argument :)
I posted an alternative solution: http://article.gmane.org/gmane.linux.network/90941
I'm a little confused. If $INTERFACE_NAME is set when the rule is generated (which happens when /etc/sysconfig/network-scripts/ifcfg-eth0 etc. already exist), then write_net_rules will add '(custom name provided by external tool)' to the comment in 70-persistent-net.rules. But after a clean installation, I don't see that text in the rule. And neither do I see the KERNEL== criterion. Is something _else_ writing out these rules for the first time, in the installer?
Yes. See the end of anaconda's network.py. Reassigning this to anaconda, which should include the KERNEL== criterion in the rule it creates. And which should probably also admit to having written those rules, rather than blaming it on /lib/udev/write_rules.
Created attachment 302432 [details] patch This (untested) patch should make anaconda emit rules which match the ones that the write_net_rules script would write. And also makes anaconda admit liability for the rules it writes.
Note that write_net_rules is about to change again, to include an ATTR{dev_id} criterion. If we could somehow manage to _use_ the write_net_rules script rather than constantly trying to catch up with what it does, that would be useful.
Created attachment 302441 [details] anaconda patch This time without the syntax errors...
Created attachment 302478 [details] take me out back and shoot me And this time without the bit which writes the rules to stdout instead of to the rules file. Doh.
Given that the variables used likely change over time too, I'm not sure that just running the script helps things. Committed and pushed this bit
My patch from comment #19 has been applied to udev upstream. Please could we have it too? It addresses OLPC trac #5746: http://dev.laptop.org/ticket/5746
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.