Hi People,
I noticed something weird with the ipw2200 drivers being autoloaded at boot. I have an "alias eth1 ipw2200" line in modprobe.conf.
It used to work without a problem for a couple of days but suddenly I'm getting very weird interface names. Instead of "eth1", I'm getting "__tmp437329847239" where the number behind tmp is random.
NetworkManager gets sort of confused by this. The interface does work though when configged by hand.
Doing "rmmod ipw2200 && modprobe ipw2200" gives the expected "eth1" interface name.
I was wondering if anyone has seen this kind of thing before. Maybe it is the result of a common misconfiguration? A few searches on google didn't show anything, hence my question here.
Kind regards,
Rubin.
Rubin (rubin@xs4all.nl) said:
It used to work without a problem for a couple of days but suddenly I'm getting very weird interface names. Instead of "eth1", I'm getting "__tmp437329847239" where the number behind tmp is random.
Do you have an ifcfg file with the proper HWADDR for the device?
Bill
Bill Nottingham wrote:
Rubin (rubin@xs4all.nl) said:
It used to work without a problem for a couple of days but suddenly I'm getting very weird interface names. Instead of "eth1", I'm getting "__tmp437329847239" where the number behind tmp is random.
Do you have an ifcfg file with the proper HWADDR for the device?
I suffer from the same problem too. In some cases, it's the wireless that doesn't come up properly, and i have to restart things manually until it picks it up right. Yes, in my case i have the correct HWADDR lines in the ifcfg files.
On 11/3/06, Denis Leroy denis@poolshark.org wrote:
Bill Nottingham wrote:
Rubin (rubin@xs4all.nl) said:
It used to work without a problem for a couple of days but suddenly I'm getting very weird interface names. Instead of "eth1", I'm getting "__tmp437329847239" where the number behind tmp is random.
Do you have an ifcfg file with the proper HWADDR for the device?
I suffer from the same problem too. In some cases, it's the wireless that doesn't come up properly, and i have to restart things manually until it picks it up right. Yes, in my case i have the correct HWADDR lines in the ifcfg files.
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
The random name seems to be created (by udev?) when the firmware doesn't load. I suspect it is a timing problem (or the 'failed' timeout needs to be just a bit longer).
The issue was there for a while a about two months before FC6 release, disappeared for a bit and got worse just about FC6 release time. NetworkManager used to deal with the situation just fine, using the random name when it found it, but is often confused now.
I have a machine that uses IPW2100 and even the module load/unload and a restart of NM doesn't always fix the problem.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=210780
darrell
darrell pfeifer (darrellpf@gmail.com) said:
The random name seems to be created (by udev?) when the firmware doesn't load. I suspect it is a timing problem (or the 'failed' timeout needs to be just a bit longer).
Hm, why is the firmware not loading right? What messages do you get from the kernel?
Bill
darrell pfeifer wrote:
The random name seems to be created (by udev?) when the firmware doesn't load. I suspect it is a timing problem (or the 'failed' timeout needs to be just a bit longer).
The issue was there for a while a about two months before FC6 release, disappeared for a bit and got worse just about FC6 release time.
FWIW, this issue is not limited to FC6; I've seen it fairly consistently on FC5 as well (HP dv1000 laptop). I always thought it had something to do with initscripts, but I guess that's not the case.
Hi.
I started the thread. Someone responded that setting HWADDR in /etc/sysconfig/network-scripts/ifcfg-eth1 might make the problem disappear.
And it did! After setting HWADDR with the MAC for the wireless card, the problem has not been encountered since.
I guess it still is a problem, but it works. Not very nice for mom and pops at home trying out a user-friendly linux distro though.
Greets,
Rubin.
On Tue, 2006-11-07 at 12:34 -0700, Tyler Larson wrote:
darrell pfeifer wrote:
The random name seems to be created (by udev?) when the firmware doesn't load. I suspect it is a timing problem (or the 'failed' timeout needs to be just a bit longer).
The issue was there for a while a about two months before FC6 release, disappeared for a bit and got worse just about FC6 release time.
FWIW, this issue is not limited to FC6; I've seen it fairly consistently on FC5 as well (HP dv1000 laptop). I always thought it had something to do with initscripts, but I guess that's not the case.
On Tue, 2006-11-07 at 22:11 +0100, Rubin wrote:
Hi.
I started the thread. Someone responded that setting HWADDR in /etc/sysconfig/network-scripts/ifcfg-eth1 might make the problem disappear.
Not for me.
[cioby@DustPuppy cioby]$ cat /etc/sysconfig/network-scripts/ifcfg-eth1 # Please read /usr/share/doc/initscripts-*/sysconfig.txt # for the documentation of these parameters. ONBOOT=no USERCTL=yes IPV6INIT=no PEERDNS=yes TYPE=Wireless DEVICE=eth1 HWADDR=00:16:6f:5f:ce:99 BOOTPROTO=dhcp NETMASK= DHCP_HOSTNAME= IPADDR= DOMAIN= ESSID=xxxxxx CHANNEL=1 MODE=Managed RATE=
And it did! After setting HWADDR with the MAC for the wireless card, the problem has not been encountered since.
It happens mostly on boot for me. It's probably an timing issue. I don't boot much tho, thanks to suspend.
service network restart;service NetworkManager restart
fixes things for me.
I guess it still is a problem, but it works. Not very nice for mom and pops at home trying out a user-friendly linux distro though.
The HWADDR line should be set by the installer / system-config-network, not by hand so this is just a bug if not already.
I see this about 33% of the time. During the FC6 development process I was getting an error with udev when I would get __tmp#####... but then after a few rebuilds of packages that went away. But the issue has come back.
On 11/3/06, Rubin rubin@xs4all.nl wrote:
Hi People,
I noticed something weird with the ipw2200 drivers being autoloaded at boot. I have an "alias eth1 ipw2200" line in modprobe.conf.
It used to work without a problem for a couple of days but suddenly I'm getting very weird interface names. Instead of "eth1", I'm getting "__tmp437329847239" where the number behind tmp is random.
NetworkManager gets sort of confused by this. The interface does work though when configged by hand.
Doing "rmmod ipw2200 && modprobe ipw2200" gives the expected "eth1" interface name.
I was wondering if anyone has seen this kind of thing before. Maybe it is the result of a common misconfiguration? A few searches on google didn't show anything, hence my question here.
Kind regards,
Rubin.
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Fri, Nov 03, 2006 at 01:51:47PM +0100, Rubin wrote:
I noticed something weird with the ipw2200 drivers being autoloaded at boot. I have an "alias eth1 ipw2200" line in modprobe.conf.
It used to work without a problem for a couple of days but suddenly I'm getting very weird interface names. Instead of "eth1", I'm getting "__tmp437329847239" where the number behind tmp is random.
NetworkManager gets sort of confused by this. The interface does work though when configged by hand.
Doing "rmmod ipw2200 && modprobe ipw2200" gives the expected "eth1" interface name.
I was wondering if anyone has seen this kind of thing before. Maybe it is the result of a common misconfiguration? A few searches on google didn't show anything, hence my question here.
I am seeing the same thing on a server using bonding with two ethernet interfaces. I have two different cards (e1000, acenic) and on every boot one of the card fails. The bond0 interface still works with only one card by I also have to do an rmmod, modprobe to get both cards working. So I have the same error in a different setup.
Adrian
Adrian Reber (adrian@lisas.de) said:
I am seeing the same thing on a server using bonding with two ethernet interfaces. I have two different cards (e1000, acenic) and on every boot one of the card fails. The bond0 interface still works with only one card by I also have to do an rmmod, modprobe to get both cards working. So I have the same error in a different setup.
Not to sound like a broken record - but do you have ifcfg files with HWADDR in them?
Background:
PCI modules are loaded (essentially) in parallel. If one driver takes longer to initialize on a particular boot, the device ordering will change.
We have code run by udev (/lib/udev/rename_device) to handle this, but it requires that ifcfg files have the HWADDR in them for the appropriate devices so it knows what should remain what.
Bill
On Fri, Nov 03, 2006 at 10:54:52AM -0500, Bill Nottingham wrote:
Adrian Reber (adrian@lisas.de) said:
I am seeing the same thing on a server using bonding with two ethernet interfaces. I have two different cards (e1000, acenic) and on every boot one of the card fails. The bond0 interface still works with only one card by I also have to do an rmmod, modprobe to get both cards working. So I have the same error in a different setup.
Not to sound like a broken record - but do you have ifcfg files with HWADDR in them?
No.
Background:
PCI modules are loaded (essentially) in parallel. If one driver takes longer to initialize on a particular boot, the device ordering will change.
We have code run by udev (/lib/udev/rename_device) to handle this, but it requires that ifcfg files have the HWADDR in them for the appropriate devices so it knows what should remain what.
Okay. I will try it with HWADDR and see if it fixes our problem. Thanks for the information.
Adrian
On 11/3/06, Bill Nottingham notting@redhat.com wrote:
Adrian Reber (adrian@lisas.de) said:
I am seeing the same thing on a server using bonding with two ethernet interfaces. I have two different cards (e1000, acenic) and on every boot one of the card fails. The bond0 interface still works with only one card by I also have to do an rmmod, modprobe to get both cards working. So I have the same error in a different setup.
Not to sound like a broken record - but do you have ifcfg files with HWADDR in them?
Background:
PCI modules are loaded (essentially) in parallel. If one driver takes longer to initialize on a particular boot, the device ordering will change.
We have code run by udev (/lib/udev/rename_device) to handle this, but it requires that ifcfg files have the HWADDR in them for the appropriate devices so it knows what should remain what.
Bill
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
In my case the BCM4400 device (eth0) has HWADDR but the IPW2200 device (eth1) doesn't. I'm assuming that the
/etc/sysconfig/networking/profiles/default
path is the correct one, not either of
/etc/sysconfig/networking/devices/ /etc/sysconfig/network-scripts/
From the failure I see in /var/log/messages it looks like the Broadcom
driver picked up eth1 first (ignoring the HWADDR?), then IPW2200 was left to find a random name.
I'll try putting HWADDR in the IPW eth1 ifcfg file(s).
darrell
darrell pfeifer (darrellpf@gmail.com) said:
In my case the BCM4400 device (eth0) has HWADDR but the IPW2200 device (eth1) doesn't. I'm assuming that the
/etc/sysconfig/networking/profiles/default
path is the correct one, not either of
/etc/sysconfig/networking/devices/ /etc/sysconfig/network-scripts/
The last one is the path read (/etc/sysconfig/network-scripts.)
From the failure I see in /var/log/messages it looks like the Broadcom driver picked up eth1 first (ignoring the HWADDR?), then IPW2200 was left to find a random name.
Kernel pays no attention to user configuration - it just grabs the first ethX name. The renaming is done by a udev rule.
Bill
On 11/3/06, Bill Nottingham notting@redhat.com wrote:
darrell pfeifer (darrellpf@gmail.com) said:
In my case the BCM4400 device (eth0) has HWADDR but the IPW2200 device (eth1) doesn't. I'm assuming that the
/etc/sysconfig/networking/profiles/default
path is the correct one, not either of
/etc/sysconfig/networking/devices/ /etc/sysconfig/network-scripts/
The last one is the path read (/etc/sysconfig/network-scripts.)
From the failure I see in /var/log/messages it looks like the Broadcom driver picked up eth1 first (ignoring the HWADDR?), then IPW2200 was left to find a random name.
Kernel pays no attention to user configuration - it just grabs the first ethX name. The renaming is done by a udev rule.
Bill
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Added HWADDR for the IPW.
That will hopefully fix the naming. Now we move to Network Manager.
When I log in it fails to connect. A manual selection does work to connect afterwards. I'm using MAC filtering on this AP, not WPA
darrell
--------------------------------------------
Nov 3 08:34:11 localhost NetworkManager: <info> Updating allowed wireless network lists. Nov 3 08:34:11 localhost NetworkManager: <info> SWITCH: no current connection, found better connection 'eth1'. Nov 3 08:34:11 localhost dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth1 for sub-path eth1.dbus.get.reason Nov 3 08:34:11 localhost NetworkManager: <info> Will activate connection 'eth1/SMC'. Nov 3 08:34:11 localhost NetworkManager: <info> Device eth1 activation scheduled... Nov 3 08:34:11 localhost NetworkManager: <info> Activation (eth1) started... Nov 3 08:34:11 localhost NetworkManager: <info> Activation (eth1) Stage 1 of 5 (Device Prepare) scheduled... Nov 3 08:34:11 localhost NetworkManager: <info> Activation (eth1) Stage 1 of 5 (Device Prepare) started... Nov 3 08:34:11 localhost NetworkManager: <info> Activation (eth1) Stage 2 of 5 (Device Configure) scheduled... Nov 3 08:34:11 localhost NetworkManager: <info> Activation (eth1) Stage 1 of 5 (Device Prepare) complete. Nov 3 08:34:11 localhost NetworkManager: <info> Activation (eth1) Stage 2 of 5 (Device Configure) starting... Nov 3 08:34:11 localhost NetworkManager: <info> Activation (eth1/wireless): access point 'SMC' is unencrypted, no key needed. Nov 3 08:34:12 localhost NetworkManager: <info> SUP: sending command 'INTERFACE_ADD eth1 wext /var/run/wpa_supplicant ' Nov 3 08:34:13 localhost bonobo-activation-server (darrell-2706): Passing command-line arguments in .server files is deprecated: "/usr/bin/tomboy --panel-applet" Nov 3 08:34:13 localhost NetworkManager: <info> SUP: response was 'OK' Nov 3 08:34:13 localhost NetworkManager: <info> Error opening control interface to supplicant. Nov 3 08:34:13 localhost NetworkManager: <WARN> real_act_stage2_config(): Activation (eth1/wireless): couldn't connect to the supplicant. Nov 3 08:34:13 localhost NetworkManager: <info> Activation (eth1) failure scheduled... Nov 3 08:34:13 localhost NetworkManager: <info> Activation (eth1) Stage 2 of 5 (Device Configure) complete. Nov 3 08:34:13 localhost NetworkManager: <info> Activation (eth1) failed for access point (SMC) Nov 3 08:34:14 localhost kernel: ipw2200: Failed to send ASSOCIATE: Already sending a command. Nov 3 08:34:14 localhost NetworkManager: <info> Activation (eth1) failed. Nov 3 08:34:14 localhost NetworkManager: <info> Deactivating device eth1. Nov 3 08:34:17 localhost avahi-daemon[2345]: Withdrawing address record for fe80::213:ceff:febf:4eb6 on eth1. Nov 3 08:34:18 localhost avahi-daemon[2345]: Leaving mDNS multicast group on interface eth1.IPv6 with address fe80::213:ceff:febf:4eb6. Nov 3 08:34:18 localhost avahi-daemon[2345]: iface.c: interface_mdns_mcast_join() called but no local address available. Nov 3 08:34:18 localhost dhclient: receive_packet failed on eth1: Network is down Nov 3 08:34:18 localhost avahi-daemon[2345]: Interface eth1.IPv6 no longer relevant for mDNS. Nov 3 08:34:31 localhost ntpd[2197]: sendto(80.163.145.206) (fd=21): Invalid argument Nov 3 08:34:31 localhost ntpd[2197]: sendto(130.133.1.10) (fd=21): Invalid argument Nov 3 08:34:34 localhost ntpd[2197]: sendto(202.49.59.6) (fd=21): Invalid argument Nov 3 08:34:39 localhost avahi-daemon[2345]: New relevant interface eth1.IPv6 for mDNS. Nov 3 08:34:39 localhost avahi-daemon[2345]: Joining mDNS multicast group on interface eth1.IPv6 with address fe80::213:ceff:febf:4eb6. Nov 3 08:34:39 localhost avahi-daemon[2345]: Registering new address record for fe80::213:ceff:febf:4eb6 on eth1. Nov 3 08:34:43 localhost kernel: ipw2200: Firmware error detected. Restarting. Nov 3 08:34:52 localhost NetworkManager: <info> User Switch: /org/freedesktop/NetworkManager/Devices/eth1 / SMC Nov 3 08:34:52 localhost NetworkManager: <info> Deactivating device eth1.
...... Original Message ....... On Fri, 3 Nov 2006 10:54:52 -0500 "Bill Nottingham" notting@redhat.com wrote:
We have code run by udev (/lib/udev/rename_device) to handle this, but it requires that ifcfg files have the HWADDR in them for the appropriate devices so it knows what should remain what.
Bill,
In RHEL4/FC3, besides HWADDR, you also must use ONBOOT=YES. It that still the case? ___ Dax Kelson Sent with my Treo (please pardon any brevity)
Hi.
It used to work without a problem for a couple of days but suddenly I'm getting very weird interface names. Instead of "eth1", I'm getting "__tmp437329847239" where the number behind tmp is random.
I get this from time to time, too, on an iBook (airport driver, so no firmware involved).
NetworkManager gets sort of confused by this. The interface does work though when configged by hand.
NM seems to work, dhclient does not like those ifnames.
On 11/3/06, Rubin rubin@xs4all.nl wrote:
It used to work without a problem for a couple of days but suddenly I'm getting very weird interface names. Instead of "eth1", I'm getting "__tmp437329847239" where the number behind tmp is random.
I just installed FC6 on my laptop (ASUS M6Ne) and experienced the same problem. Of course at first boot the firmware was not loaded, so I quite expected wifi would not work OOTB.
However, installing the firmware and starting NM did not work, but was enough to get it going on FC5 so something is less "smart" than before.
I verified and the file /etc/sysconfig/networking/devices/ifcfg-eth1 does not contain the HWADDR line (can't tell if it was there on FC5 or not)
Moreover, eth1 does not seems to be recognized as a wireless device (I think there is at least one bug in bugzilla for this)