suspend makes network-manager say eth1 is a wired device

I can confirm this, this does not happen reliably, but usually after 2 to 3 resumes

The log says that n-m knows, that the device is managed by ipw2200 but constantly talks about a 802.3 wired device

Attached is the relevant part of the log

I have a Samsung X20 with ipw2200 wireless and a b44 wired connection

I'm seeing the same thing on a Fujitsu-Siemens P7010.

Adding MODULES_WHITELIST="ipw2200" to /etc/default/acpi-support is the only workaround I've found.

I can confirm this on IBM x40 also with the Atheros ABG wireless card:

lspci gives this:
02:02.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)

My ath0 interface is identified as a wired network.

I found that logging out of Gnome and from a tty login restart dbus helps:

sudo /etc/init.d/dbus restart
After logging into Gnome the card is identified as a wireless card again. Perhaps less will do, but I haven't found out yet... I'll post here if I find a better solution.

I also tried the following which ISN'T enough:
sudo /etc/dbus-1/event.d/26NetworkManagerDispatcher stop
sudo /etc/dbus-1/event.d/25NetworkManager stop
sudo /etc/dbus-1/event.d/25NetworkManager start
sudo /etc/dbus-1/event.d/26NetworkManagerDispatcher start
killall nm-applet
nm-applet --sm-disable

Let me know if you need any info from log files and so.

I remember looking at this a while back. It's a HAL issue. My guess is
it's a race condition where HAL does its wifi-detection magic before the
driver has initalized properly and hence assumes it's wired. I'm
working on fixing it.

Just let me know if you need anything tested :)

On Mon, Sep 25, 2006 at 02:41:04PM -0000, Jacob Emcken wrote:
> Just let me know if you need anything tested :)

Actually, it'd be nice if people could test a patch for me:

For i386:
http://www.linux2go.dk/ubuntu/pool/main/h/hal/hal_0.5.7.1-0ubuntu13linux2go1_i386.deb

For amd64:
http://www.linux2go.dk/ubuntu/pool/main/h/hal/hal_0.5.7.1-0ubuntu13linux2go1_amd64.deb

Alternatively, add this to your sources.list:
deb http://www.linux2go.dk/ubuntu edgy main

I'll attach a debdiff between ubuntu13 and this package in a moment so
that it's ready if it works as good for you as it does for me.

Just FYI: It indeed WAS a race condition. On suspend, most network drivers are unloaded, and are then reloaded on resume. When loading the module, hal is notified of the presence of a new device and quickly add it to it's database. If it's a network interface, it checks /proc/net/wireless to see if the interface in question is mentioned there, and if so, it's marked as being a wifi interface. Apparantly, hal manages to check the file before the device is added to it, and hence it's detected as a non-wifi interface. This new detection code checks for the presence of /sys/class/net/<ifname>/wireless directory, which seems to be a more robust mechanism for detecting this.

Enjoy

Soren, not surprisingly (as I came up with the same patch as you :-) ), your patch and packages work perfectly for me, after about 5 suspends, NM has come back up thinking it is a wireless card every time.

patch works for me too.

Should this patch totally remove the problem, or can it theoretically still happen?

I observed the same behavior today but I just updated a lot of packages without rebooting/relogging, so it might be something else that made it happen. Anyways I have only seen it once, so it have improved a lot. I suspended at least 20 times today and I only hit it once, before it was like every 2-3 times or something.

Ill get back if it happens again

On Wed, Sep 27, 2006 at 06:21:18PM -0000, Jacob Emcken wrote:
> Should this patch totally remove the problem, or can it theoretically
> still happen?
>
> I observed the same behavior today but I just updated a lot of packages
> without rebooting/relogging,

You have to restart hal before the new package does its thing.. Did you
do that?

Soren Hansen wrote:
> You have to restart hal before the new package does its thing..
> Did you do that?

Yup... just didn't do it after the other updates I downloaded today before I suspended. But no hal packages between them and still got you package installed anyway.

Jacob: So... You still have the problem?

Patch works for me, for half a dozen resumes wireless card was identified correctly every time.

I haven't seen the bug since. I would say this is fixed :)

Just to be sure, is this "patch" already in the repository packages, or just in this bug report? Because it still seems to happen with me; on the other hand, seems like suspend is just totally broken today on my computer, maybe the dbus upgrade broke it.

On Fri, Sep 29, 2006 at 08:25:40PM -0000, Jeff Fortin wrote:
> Just to be sure, is this "patch" already in the repository packages, or
> just in this bug report?

Just in this bug report so far. So please be patient.

Cheers.

Patch also works for me

can we mark the "update-manager" as rejected, I can't see a comment related to it...

Please leave it in there, most people will want to file the bug under network-manager and will see that it has been reported already.

Has this patch been pushed upstream through a bug we can track?

On Wed, Oct 04, 2006 at 12:22:51PM -0000, Scott Robinson wrote:
> Has this patch been pushed upstream through a bug we can track?

Not as such. It's been lying around in the hal code commented out for
ages, but has recently been "commented back in". Besides, pitti said
he'd apply the patch tomorrow, so there's not immediate need to do
anything further on this bug.

I've applied Soren Hansen's patch, and the problem has disappeared from here (ipw2200, Acer Travelmate)

 hal (0.5.7.1-0ubuntu14) edgy; urgency=low
 .
   * Add debian/patches/19_fix_wifi_detection.patch:
     - Switch to sysfs based wifi detection instead of reading
       /proc/net/wireless. The latter is horribly unreliable especially after
       waking up from suspend.
     - Patch taken from upstream git, thanks to Soren Hansen for digging it
       out.
     - Closes: LP#59981

Closing network-manager bug too, now.

I had this problem once again and since there is a duplicate from today, the bug isn't completely fixed, reopening.

I'm running hal 0.5.7.1-0ubuntu15

Closing again. Martin, please open a new bug since the cause of your problem is likely somewhere else (perhaps a kernel issue). It is impractical to recycle bug reports. Thank you!

Incidentally, having filed the dupe Martin mentioned above, I'm fairly certain I know what my problem was - every mirror I just checked only has the -ubuntu13 package of hal, which could have something to do with the odd fact that, even though packages.ubuntu.com, on a search for hal, claims that edgy has hal-0.5.7.1-0ubuntu15, if you actually look at the hal package link on the site, it offers you -ubuntu13, and it took me ~3m on Google to find somewhere with the appropriate upgrade.

I really wish I knew what was going on here.

Hi Rich,

Rich [2006-10-10 15:53 -0000]:
> Incidentally, having filed the dupe Martin mentioned above, I'm fairly
> certain I know what my problem was - every mirror I just checked only
> has the -ubuntu13 package of hal, which could have something to do with
> the odd fact that, even though packages.ubuntu.com, on a search for hal,
> claims that edgy has hal-0.5.7.1-0ubuntu15, if you actually look at the
> hal package link on the site, it offers you -ubuntu13, and it took me
> ~3m on Google to find somewhere with the appropriate upgrade.
>
> I really wish I knew what was going on here.

I don't know, but I just checked the German mirror, and it's there:

  http://de.archive.ubuntu.com/ubuntu/pool/main/h/hal/hal_0.4.7-1ubuntu15_i386.deb

so it should be on archive.ubuntu.com, too.

Martin
--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

Well, having upgraded to Feisty, my problem no longer exists, so I'm quite happy to confirm no further problem with this.

Hi,

This bug is still present on Gutsy with the ipw2200 module

Kyle

I'm also seeing this problem in Gutsy. I put "hal" into the SERVICES field of /etc/default/acpi-support (to stop-start hal on suspend-resume). That appears to work. Can others confirm? (I also have ipw2200 white-listed, but do not know if that is necessary.)

Also happens over here, using hardy beta.

hal version:
0.5.11~rc2-1ubuntu5

device:
02:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)

driver: ipw2200

manually restarting HAL after reusme from suspend helps, but it's not a real sollution

Reopening, this bug is still present on Hardy with the ipw2200 module

I can confirm that it happens to me with Fedora Rawhide, so I guess it
is an upstream issue in Hal.

Am Mittwoch, den 09.04.2008, 14:28 +0000 schrieb Adam Banko:
> Reopening, this bug is still present on Hardy with the ipw2200 module
>
> ** Changed in: hal (Ubuntu)
> Status: Fix Released => Confirmed
>

same bug exists on Ubuntu 8.04

-Travelmate 4233

Dell XPS m1330 on Ubuntu Hardy 8.04

can confirm after resume from suspend, Network Manager detects wireless as a wired network. Disabling networking via right click on nm-applet in the system tray resets the status and allows proper detection as wireless.

No modprobe necessary.

Interesting, I have a Dell XPS m1330 on Ubuntu Hardy 8.04. For suspend, I have to reboot in order to re-establish a connection. It seems able to scan but not to connect after starting back up. I believe the mod (driver) is IWL3945. I've not tried restarting HAL manually to see if that helps. I've simply rebooted and then it eventually works but even then I have to fiddle with disabling the networking and re-enabling before it finally picks back up again.

I can confirm this intermittently on Hardy with a Dell XPS M1210 with IWL3945.

If I issue

sudo ifdown eth0

then wireless comes up, but the network manager applet shows the "wired network" icon.

Just to follow up that I do have suspend working now. I think I did have to remove the mod iwl3945 and modprobe it on resume in order to get it to work but it is functioning now for me. If I turn networking off in the nm-applet then it resets as ethanray indicated. For the most part, I think most of the stuff works for suspend on the XPS m1330 so I am happy. This remains the last little annoyance. The good news is that even though it displays the eth0 (wired connection) the wireless does work after the resume it just is not being displayed.

After disabling hardware scanning, I believe this issue has gone away for me. If others can confirm whether the following fix works for them vs modprobing:

create and edit the file --
sudo gedit /etc/modprobe.d/iwl3945

add the following to the file:
alias wlan0 iwl3945
options iwl3945 disable_hw_scan=1

save and close. Substitute the name of your intel wireless driver if other than iwl3945. Make sure to get rid of any other ugly fix scripts previously installed as they might interfere. Since installing this file, I have had no problems with the driver and card :) But I would like to help confirm whether this bug is part of the same problem or a completely different problem.

as for suspend -- it is still unusable for me until the fix for bug 183033 arrives :(

An initial test of ethanay's suggestion seems to work for me but I will need to do further testing. If I experience problems during the week I will post back. Peace - Anthony

The potential fix I posted above came from this upstream bug report:
http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1579#c15

I was looking for a fix to resolve the failure to scan problem and it may have fixed this bug, also.

This happens here on a Dell Latitude X1, Ubuntu Hardy, too. Actually, the icon of nm-applet says its wired, but in the menu wired and wireless is selected at the same time (although wired is greyed out).

The fix posted by ethany seems to -- so far -- address the issue of the "wired" icon showing with no wired network attached.

But another issue still occurs: After a suspend and disconnect from wired network, the wired network remains configured. The wireless network icon indicates that wireless is configured, and ifconfig shows that also. However, I must manually take down the wired network because it still has the default route.

Closing again, since the original issue was fixed, and the issue with ipw2200 reported later is bug 162654.