Network cards not detected when resuming from suspend / hibernate

I have the same problem here with all my networking.

I have created the following files:

/etc/acpi/suspend.d/05-network-manager.sh

#!/bin/sh

dbus-send --system \
  --dest=org.freedesktop.NetworkManager \
  /org/freedesktop/NetworkManager \
  org.freedesktop.NetworkManager.sleep

and

/etc/acpi/resume.d/91-network-manager.sh

#!/bin/sh

dbus-send --system \
  --dest=org.freedesktop.NetworkManager \
  /org/freedesktop/NetworkManager \
  org.freedesktop.NetworkManager.wake

This seems to have solved the problem.

I found that by unselecting then reselecting "Enable Networking" in the NM-Applet menu is enough to fix it.

Same here. Disable/Enable after resume works, but this shouldn't be necessary. It used to work before (some weeks ago). Please fix before dapper.

The workaround by John Cooper does not work for me, so I always have to take manual action :-(.

I failed to mention my hardware: prism54 chipset in an SMC pcmcia (cardbus) card.

Dapper up to date as of 28 april.

Same thing here.

Please do the following to debug this:
$ sudo -s
# /etc/dbus-1/event.d/25NetworkManager stop
# NetworkManager --no-daemon > nm.log

Wait for it to connect again, then suspend your computer and resume it. After it's connected again, attach the nm.log file to this bug.

You can restore "normal" operation afterwards by stopping NM with ^C then running /etc/dbus-1/event.d/25NetworkManager start

The log was captured from:
1. "NetworkManager --no-daemon &> nm.log"
2. Sleeping laptop
3. Waking laptop
(network not enabled when laptop woke up)
4. Disabled networking
5. Enabled networking
6. CTRL-C

Could you split the log up so that each stage is obvious

Right now it looks like a log file showing entirely normal NM operation

As requested.
Note, this is a Thinkpad t42. Built in 802.11b and ethernet:

0000:02:01.0 Ethernet controller: Intel Corporation 82540EP Gigabit Ethernet Controller (Mobile) (rev 03)
        Subsystem: IBM PRO/1000 MT Mobile Connection
        Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 11
        Memory at c0220000 (32-bit, non-prefetchable) [size=128K]
        Memory at c0200000 (32-bit, non-prefetchable) [size=64K]
        I/O ports at 8000 [size=64]
        Expansion ROM at ec000000 [disabled] [size=64K]
        Capabilities: <available only to root>

0000:02:02.0 Network controller: Intel Corporation PRO/Wireless 2200BG (rev 05)
        Subsystem: Intel Corporation: Unknown device 2711
        Flags: bus master, medium devsel, latency 64, IRQ 11
        Memory at c0210000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: <available only to root>

Thanks, have sent the log file upstream

I have a similar log.

I too have a similar log and must re-enable networking by right clicking the network manager icon, deselecting/reselecting "enable networking" . same issues as these other folks. My hardware is a HP Compaq NC6120 Laptop.

This is no longer an issue for my centrino laptop (Samsung X05) using the ipw2100 module

This does seem to be fixed with the latest update. It restored both wireless and wired connections after suspend.

Nope. still broken here on my HP Compaq NC6120 lappy.
Still must disable/enable network from the NM icon to get networking restored after sleep.

restarting networking from /etc/init.d/networking is no help.
modprobe -r ipw2200 && modprobe ipw2200 also is no help.

Accidentally started a new nm-applet and noticed it also did not pick up.

it seems that network-manager needs to be restarted after resume from sleep. I will try different things as it happens.

Still a problem here - I can confirm this on HP nc4200 with ipw2200. On awaken the same problem. I cannot fix using the uncheck-enable check-enable trick and must manually find the pid for NetworkManager then kill it with a -9 to get it to start again.

The ocured ONLY after update to dap 2.6.15-23-386 on 19 May. Note that the interfaces function fine on awaken just the NM crashes.

Hmm. It did work when the suspend time was short(<15 sec, short enough for PowerManager to think the suspend failed...). A longer suspend causes the problem. This error is reported after a longer suspend:

NetworkManager: <information> Waking up from sleep.
NetworkManager: <information> Deactivating device eth1.
NetworkManager: <WARNING> nm_device_802_11_wireless_get_mode (): error getting card mode on eth1: No such device
NetworkManager: <information> Deactivating device eth0.

In this case, it should have brought eth0 back up.(Wireless was disabled)

Sure sounds similar to me on my HP Compaq nc6220.

I have found that I can work around this problem by right clicking on the nm and unchecking the Enable Networking PRIOR TO sleep. When I do that, networkmanger works perfectly every time on re-awaken. I suspect the problem therefore is with the sequence of sleep mode disabling networkmanager prior to sleep.

Also I can confirm this problem on another machine, the Compaq 4020US, also running the IPW2200 wireless card

I see this issue on a Dell E1505 laptop (with a ipw3945 wireless chipset). Killing and starting NetworkManager makes it work again. (running Dapper)

I can confirm this "misbehaviour" on a Sony vaio laptop VGN-FS790 (Intel centrino). Very annoying.

fixed for me after a clean install of dapper final (been using dapper since last year, upgraded daily). Maybe some old config was still hanging around?

Hm, I'm not using a clean install. Would be great if this was fixable without doing a clean install...

Joe,

Don't rush for a clean install. I have a fresh dapper install and that was the first bug I observed after installing NetworkManager. A clean install doesn't fix it. Plus, its a very intermittent bug so it might misbehave when you least expected it

Fails for me every time I resume.

Very boring...

I also experience this from time to time on a Fujitsu Lifebook C1211D with an Atheros chipset.

As a workaround, I disable networking (right click nm-applet, uncheck enable networking) and then enable it again.

This happens to me at startup too: I have to disable and re-enable networking, in order to see the list of wireless network (and I would expect it to automatically connect to the one I configured instead).

I also have this bug when I resume from a suspend with my Asus WL-107G wireless card which has the rt2500 chipset.

https://wiki.ubuntu.com/WifiDocs/Driver/RalinkRT2500?highlight=%28rt2500%29

Running network-admin then disabling then enabling my wireless card then hitting OK makes my card work agian.

Update: seems like even if Network Manager (more specifically nm-applet) says that no network devices could be found, I can still connect to the network and do my thing.

I think this is because eth0 in network-admin is set to "Enable this connection" and DHCP. Of course, disabling this connection also disables it in nm-applet.

Can someone confirm this?

Yes, I can confirm this. Resuming on a dell inspiron 2200, nm-applet claims that there are no network devices present but networking works perfectly fine.

After a bit of googling I discovered that I need to comment out all the entries in /etc/network/interfaces except the loopback interface for n-m to work correctly. Have done so and n-m now finds interfaces on resume from suspend. Would be good if the n-m install took care of this step or at least posted a debconf warning.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Simon Hepburn wrote:
> After a bit of googling I discovered that I need to comment out all the
> entries in /etc/network/interfaces except the loopback interface for
> n-m to work correctly. Have done so and n-m now finds interfaces on
> resume from suspend. Would be good if the n-m install took care of this
> step or at least posted a debconf warning.
>

Tried it, and it fixed the problem for me.

Can we mark this bug as rejected?

- --
Ealden Esto E. Escañan <email address hidden>
GPG: 0x992B69C6 || http://ealden.net

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEmSaMi2WIGpkracYRAlHXAKCIKN5oJXEop/4gPyKpuQ7QWhO2SwCgoEWc
+qAzO1s2Un2GL3rrB2+o9QY=
=Yjdo
-----END PGP SIGNATURE-----

Ealden,
You didn't have the problem of this bug in the first place, just like Simon Hepburn. You both just had a misconfigured system. The rest of us have correctly configured systems, but we are having trouble with getting the network back online after resume. We need to take manual action, where NetworkManager should just take care of this without any action required.

This bug is still valid and not fixed.

Correct. #46883 actually describes the problem Ealden and I were having. Have posted the solution there.

John Cooper's solution works for me, he forgot to mention that both the files in /etc/acpi/suspend.d and /etc/acpi/resume.d must be made executable by giving chmod +x FILENAME.

I see there is people that said John's solution wasn't working for them. Did you chmod the scripts?

Vincenzo, that did it. John Cooper, thank you very much for posting this fix, which works for me on the nc4200. Much obliged.

Nick

Sigh, despite earlier success I faced the same problem this morning resuming laptop that had been suspended overnight. This bug seems to depend on how long the laptop is suspended, n-m can cope with being supended for short periods of time but not several hours - bizarre. Will now install the scripts John Cooper posted and see how it copes tonight.

Was delighted to resume my laptop this morning to find n-m behaving correctly. Then I suspended the thing for 30 mins while I walked my son to school. Came back and resumed to find ..."no network inerfaces found" Aaargh!! This thing has a mind of it's own. Will leave John's scripts in place as they don't seem to be doing any harm, but n-m is still not working correctly with inspiron 2200.

Seriously really frustrated now: the John Cooper fix which worked FINE for a week was B0RKED beyond repair today when I updated the latest acpi update. Can we at least know whether there is someone On the dev team working on this issue? All I see on this thread are posts from people like me complaining it's borked?

I've found a solution that seems to be quite similar to the one submitted by John Cooper but which relies on other commands to stop network-manager at suspend (hibernate) time and to start it at resume time in order to have the connection reactivated.

Anyway, it works well for me under Kubuntu Dapper, freshly dist-upgraded.

Here it is if you want to try it in case the other one doesn't work:

Just create these 2 files and be sure to make theme executable (chmod +x):

/etc/acpi/suspend.d/07-network-manager.sh
#!/bin/sh
/etc/dbus-1/event.d/25NetworkManager stop

and

/etc/acpi/resume.d/99-network-manager.sh
#!/bin/sh
/etc/dbus-1/event.d/25NetworkManager start

Good luck!

This worked for me.

BTW, there is one unusual thing about the nc6220 I'm using: it seems that whether the built in ethernet and built in wireless is eth1 or eth2 is random and unpredictable (which might be confusing NM).

And why eth0 doesn't seem to exist, I have no clue.
                           - Jim

Sadly this did NOT work for me on the nc4200.

The above didn't work for me, but setting the network manager restart script at level 63 made it work.

i.e. instead of /etc/acpi/resume.d/99-network-manager.sh
 use /etc/acpi/resume.d/63-network-manager.sh

Thanks,
Rob

Thanks Rob, but that didn't work for me on my nc4200 either :(

For me (HP nc6120), the fix of comment #43 worked fine, except that after suspend, network-manager thinks my wireless card is actually wired (see screenshot). This might be a separate bug though.

Oh, I forgot to mention, I'm on edgy, using 0.6.3-2ubuntu2.

baszoetekouw, that is a different bug. Please don't post about it here - make another bug, or wait for me to do so - I'm having the same problem.

Hi, same problem here on a Samsung P35, ipw2200 and 8139too. I tried several priorities for scripts in /etc/acpi/{suspend.d,resume.d}. It isn't necessary to stop Networkmanager, but use

/usr/bin/dbus-send --system \
      --dest=org.freedesktop.NetworkManager \
      --type=method_call \
      /org/freedesktop/NetworkManager \
      org.freedesktop.NetworkManager.sleep

and .wake instead of .sleep. As far I can see it's see, it's a timing problem. I tried to wake up nm before and after ifup, but it didn't work for me - only after logging in.
I noticed, after resume both devices are still down and not shown by ifconfig.
resume from s2ram works for me - resume from s2disk not!
Hope that helps ...

Sorry for my last comment as it's mostly redundant with the very first one, but did not work out-of-the-box for me (dapper on Samsung P35).
My fix:
    /etc/acpi/suspend.d/07-networkmanager.sh # very early, after acpi-lock
    /etc/acpi/resume.d/63-networkmanager.sh # after ifup
AND
   /etc/default/acpi-support : MODULES_WHITELIST="ipw2200"

after this changes my networking is reliably back after resume.
Could other verify this?

Ok, I've made these changes (basically moved the resume script from 85 to 63 and added the whitelist). I'll report back in a few days after I've tested it a bit.

Using Dapper on a fujitsu p7010, eth0=8139too, eth1=ipw2200.
When I type
# /usr/bin/dbus-send --system \
       --dest=org.freedesktop.NetworkManager \
       /org/freedesktop/NetworkManager \
       org.freedesktop.NetworkManager.sleep
as root on the command line, I get:
------------------------
8236: arguments to dbus_message_new_method_call() were incorrect, assertion "interface != NULL || _dbus_check_if_valid_interface (interface)" failed in file dbus-message.c line 799
This is normally a bug in some application using the D-BUS library.
8280: arguments to dbus_message_set_auto_start() were incorrect, assertion "interface != NULL" failed in file dbus-message.c line 2361
This is normally a bug in some application using the D-BUS library.
Could not allocate D-BUS message.
--------------------------

I believe that the problem is deeper,
and I think I have solved it.

My problem always was that network manager
would not detect the trusted networks.

So I tried understanding how scanning is implemented
on the ipw2200. I loaded the ipw2200 module
with associate=0 to make sure I had full control.
The 'iwlist eth1 scan' command is bizarre because
it only starts a scan when you run it as root.
Otherwise it simply returns the result of the last scan.
I used one terminal as root to start the scans,
and another as myself to see how and when
the detected networks appear.

It seems that ipw2200 implements scanning as
a lightweight operation that can take place simultaneously
with other activity. It apparently maintains a list
of detected networks. Running iwlist eth1 scan
as non root returns this list (which includes the
associated network when applicable.)
When you start scanning, results
are added to that list over the next few seconds.
They stay in the list about 12 seconds and
disappear.

It seems that the network manager code
assumes that scanning is very fast (and very intensive).
It starts scanning, waits 0.25 seconds,
and reads the list of detected networks.
Scanning happens every 15 or 20 seconds
depending on something I do not understand.
That means that a first scan returns next to nothing.
The actual results of the scan get added to the list
over the next few seconds, and removed about 12
seconds later. The next scan, 15 seconds later,
does not see the results of the previous scan
and starts from zero with the same result...

So I changed the scan interval to 10 seconds
in order to make sure that the next scan
will still see the results of the previous scan.
Here is the patch

--- network-manager-0.6.3.orig/src/nm-device-802-11-wireless.c
+++ network-manager-0.6.3/src/nm-device-802-11-wireless.c
@@ -276,16 +276,16 @@
        switch (interval)
        {
                case NM_WIRELESS_SCAN_INTERVAL_INIT:
- seconds = 15;
+ seconds = 10;
                        break;

                case NM_WIRELESS_SCAN_INTERVAL_INACTIVE:
- seconds = 120;
+ seconds = 60;
                        break;

                case NM_WIRELESS_SCAN_INTERVAL_ACTIVE:
                default:
- seconds = 20;
+ seconds = 10;
                        break;
        }

With this patch, network-manager
recognizes my trusted network in about 10 seconds.
The first scan still returns next to nothing,
but its results are still available when nm
performs the second scan.

This also works after suspend/resume cycles.

- L.

I've the same problem here, and I can say that it had'nt been solved in Edgy (I have a PB Easynote E4, which uses the same pilot for my wireless card, the ipw2200).

Nice work, but the problem also arises with wired network, so there has to be another bug.

On Sunday 10 September 2006 09:18, Nikolaus Rath wrote:
> Nice work, but the problem also arises with wired network,
> so there has to be another bug.

Mhh. I missed that.
My problem were ipw2200 reconnection problems with n-m (works well with ifup).
I looked for bug reports matching my problems, and 40125 was closest.
Intermittent bugs like this are difficult to describe reliably.

The wireless fix works well here.
But it also suggests that the scanning code of network-manager is inadequate.
I don't know about other wireless chips.
Thanks.

- L.

Hi, I'm on an Acer Travelmate 2428WXMi, built in wireless using ipw2200 module. To try to help narrow things down, Jon Cooper's solution worked for me, but mlaverdierre's didn't.

Hope this is a useful data point.

I can confirm that the solution by Nikolaus Filus (at 2006-09-08) works perfectly for me (HP Compaq nc6120). After I made the changes he suggested, I've had no more problems with the network after suspend/resume. Thanks!

Just to add another confirmation, the solution posted by Nikolaus Filus also seems to solve the problem for me.

This smacks of a hardware race condition from modules reloading. Is anyone still having this problem after trying the solution from:

https://launchpad.net/distros/ubuntu/+source/network-manager/+bug/40125/comments/53

However, modifying the WHITELIST line for the driver they are using?

This has nothing to do with gnome-power-manager.

I can confirm that the solution proposed by Nikolaus Filus at 2006-08-29 22:28:49 UTC works perfectly for me and I can finally transition from home to work flawlessly. Thanks

If my laptop is connected with a wired network connection (8139too module), setting it to standby and resume afterwards, network-manager seems not recognize the connected network cable plugged in. I need to release the plug and to connect it again that network manager recognizes it. Because I use standby mode frequently it is an annoying bug...

This was a problem in dapper for me, in edgy it is working fine.

Sometimes I need to rmmod/modprobe again the ipw3945 driver, in that case the old trick to disable/enable networking from the nm-applet does not work. I have now set that driver to the MODULES list in /etc/default/acpi-support, and that seems to work so far.

Upstream reply:

------ 8< ---------
DBus has a pending call limit of 32 by default in 1.0; you need to add this
line to /etc/dbus-1/system.d/NetworkManager.conf:

<limit name="max_replies_per_connection">512</limit>

It's in SVN for trunk and 0.6.x branches already.
------ 8< ------

Can you please try out this solution and report if it helps? I will attach an updated NetworkManager.conf which you need to put into /etc/dbus-1/system.d/. I. e. please download it and then do

   sudo cp NetworkManager.conf /etc/dbus-1/system.d/

Then please restart your computer. Thank you!

It seems to work well now, however I must say I didn't notice this bug a lot recently - I don't really know if I got used to manually activate the network or if it was working after some feisty update.

Martin, that attachment seems to be incomplete. Where exactly should I add the line to NetworkManager.conf?

(I'm experiencing this same problem, running Feisty.)

Filus' suggestion (https://bugs.launchpad.net/network-manager/+bug/40125/comments/53) fixed it for me.

I did as directed in https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/40125/comments/68 (sudo cp NetworkManager.conf /etc/dbus-1/system.d/) with http://librarian.launchpad.net/7403629/NetworkManager.conf.

After one week, I can't reproduce the misbehaviour I had (unable to use wire after wifi/suspend).

We need more people to test the workaround provided here:

https://bugs.launchpad.net/ubuntu/feisty/+source/network-manager/+bug/40125/comments/68

Please be explicit about what you tried, how you tested and what the result was, so that we can confirm the validity of the test and hopefully fix this issue for everyone.

Having had trouble for many moons, and tried several previous proposed
fixes, I tried this one on 5/05, and have had *no* trouble at all since.

This involves my use at work, in one of the busiest network environments
on the planet, and going home in the evening.

+1 on this fix.
                                  - Jim

On Fri, 2007-05-18 at 17:06 +0000, Matt Zimmerman wrote:
> We need more people to test the workaround provided here:
>
> https://bugs.launchpad.net/ubuntu/feisty/+source/network-
> manager/+bug/40125/comments/68
>
> Please be explicit about what you tried, how you tested and what the
> result was, so that we can confirm the validity of the test and
> hopefully fix this issue for everyone.
>
> ** Changed in: gnome-power-manager (Ubuntu Feisty)
> Status: Unconfirmed => Rejected
>
> ** Changed in: network-manager (Ubuntu Feisty)
> Status: Unconfirmed => Confirmed
>
--
Jim Gettys
One Laptop Per Child

This might be an IQ test that I am failing, but I can't find the file he
threatens he's going to attach.

On 5/18/07, Matt Zimmerman <email address hidden> wrote:
>
> We need more people to test the workaround provided here:
>
> https://bugs.launchpad.net/ubuntu/feisty/+source/network-
> manager/+bug/40125/comments/68
>
> Please be explicit about what you tried, how you tested and what the
> result was, so that we can confirm the validity of the test and
> hopefully fix this issue for everyone.
>
> ** Changed in: gnome-power-manager (Ubuntu Feisty)
> Status: Unconfirmed => Rejected
>
> ** Changed in: network-manager (Ubuntu Feisty)
> Status: Unconfirmed => Confirmed
>
> --
> Doesn't bring the network back online when resuming from suspend /
> hibernate
> https://bugs.launchpad.net/bugs/40125
> You received this bug notification because you are a direct subscriber
> of the bug.
>

It's the link where it says "updated NetworkManager.conf". Yes, it's an IQ test for us firefox users :) Since it is an XML file firefox renders it. Try to save it (right click and save destination) and you'll have your file. I had troubles identifying the attachment too, in the beginning so you're not alone.

To remind everyone, I'm on an HP nc4200 with an IPW2200 card.

Okay, here's what I have done. First, I had copied that line

        <limit name="max_replies_per_connection">512</limit>
into my /etc/dbus-1/system.d/NetworkManager.conf file, and frankly there has
been no improvement. When the network manager crashes after a hibernation, I
now find with Feisty that I can no longer easily restart it. This command:

sudo /usr/sbin/NetworkManagerDispatcher restart

has no effect whatever. In fact, now, when NetworkManager stops detecting
network cards after a hibernation, I am forced to restart the computer.

I did try grepping out every single NetworkManager related job and killing
those, then rmmoding the ipw2200, then restarting everything. No soap; the
interface comes back up, but NM is unable to connect properly and indicates
connection where there is not any: "You are now connected to the wireless
network Eurospot" it avers, but it's untrue, at least, I cannot do any
network related work without a full restart.

Any advice?

On 5/18/07, Vincenzo Ciancia <email address hidden> wrote:
>
> It's the link where it says "updated NetworkManager.conf". Yes, it's an
> IQ test for us firefox users :) Since it is an XML file firefox renders
> it. Try to save it (right click and save destination) and you'll have
> your file. I had troubles identifying the attachment too, in the
> beginning so you're not alone.
>
> --
> Doesn't bring the network back online when resuming from suspend /
> hibernate
> https://bugs.launchpad.net/bugs/40125
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Oh, I forgot to mention: I have now copied over that file as saved on the
wiki site and restarted so I will see if it has any effect; having said
that, the only diff I see between mine and that one was that it put the line

        <limit name="max_replies_per_connection">512</limit>
at the top not the bottom but both within the <busconfig>, so I don't hold
out much hope for any substantive difference, but then again what the hell
do I know, right?

Thanks,
Nick

On 5/18/07, Vincenzo Ciancia <email address hidden> wrote:
>
> It's the link where it says "updated NetworkManager.conf". Yes, it's an
> IQ test for us firefox users :) Since it is an XML file firefox renders
> it. Try to save it (right click and save destination) and you'll have
> your file. I had troubles identifying the attachment too, in the
> beginning so you're not alone.
>
> --
> Doesn't bring the network back online when resuming from suspend /
> hibernate
> https://bugs.launchpad.net/bugs/40125
> You received this bug notification because you are a direct subscriber
> of the bug.
>

IFRFlyer,
there are at least 2 problems with your last comments:
1. The bug report is about "no connection/no network cards after resume" - you said, your NM crashes
2. You can't restart /usr/sbin/NetworkManagerDispatcher restart.
    You propably mean 25NetworkManager and 26NetworkManagerDispatcher in /etc/dbus-1/event.d/, where you want to restart the first one.

For 1) Please file a new bug report. Please consult and post the log as suggested in comment #7 and the output of running processes (with ps ax) and
ifconfig. Are your interfaces configured after resume? Are NetworkManager, nm-applet, dbus, dhclient running after resume?

BTW: Please cut the cited text from your replies, as it clutters the bug report.

Hi,
>IFRFlyer,
>there are at least 2 problems with your last comments:
>1. The bug report is about "no connection/no network cards after resume" -
you said, your NM >crashes

Sorry, I meant that it loses its ability to detect network interface after
hibernation. It is running, but says, 'No network inferface detected' . I
was sloppy in my description

>2. You can't restart /usr/sbin/NetworkManagerDispatcher restart.
  > You propably mean 25NetworkManager and 26NetworkManagerDispatcher in
/etc/dbus-1/event.d/, >where you want to restart the first one.

Thanks for that, of course that works - sorry.

>For 1) Please file a new bug report. Please consult and post the log as
suggested in comment #7 and >the output of running processes (with ps ax)
and
>ifconfig. Are your interfaces configured after resume? Are NetworkManager,
nm-applet, dbus, dhclient >running after resume?

Will check and come back, thanks

>BTW: Please cut the cited text from your replies, as it clutters the bug
>report.
Done, sorry

nm.log file from IFRFlyer attached. I couldn't get this:

 NetworkManager --no-daemon > nm.log

to work but this:

 NetworkManager --no-daemon >nm.log 2>&1

did the trick

I fixed the MIME type on the "updated NetworkManager.conf" attachment to make it easier to test

After looking at the last attached nm.log, I would ask if:
Could it be, that in IFRFlyer case, nm-applet and not NM is irritated? As far the log says, the first DHCP request after resuming fails, then a 2nd is attempted and successful!
I would say there should be network connectivity and only nm-applet is wrong saying 'No network inferface detected'. This would match the dbus problem with max_replies_per_connection, where nm-applet doesn't get a list of network interfaces after resuming.

IFRFlyer - could you please re-check your NetworkManager.conf with the one attached to this report? Please try once more
- run NetworkManager --no-daemon 2>&1 | tee nm.log
- suspend / wait a litte / resume
- look at the nm output for sucessful configuration (stage 5 completed, wpa_supplicant ASSOCIATED, ....)
- check configuration in another terminal with ifconfig
- restart nm-applet, if necessary

Nikolaus Filus,
You said, 'attached to this report' - did you mean the one previously attached or a new one you were attaching with comment 84?

I have a problem analogous to what IFRFlyer described with Ubuntu Feisty on Toshiba Satellite A100 with Marvell Yukon eth card. I implemented suggestions of Nikolaus Filus from 2006-09-08 and Martin Pitt from 2007-04-25. I just replaced MODULES_WHITELIST="ipw2200" by MODULES_WHITELIST="sky2", where sky2 is a driver for Marvell Yukon. Symptoms are the same. After resuming from suspend network interface is present, but network is unreachable. I have a fixed IP configuration, so it's not a DHCP problem. I found the following lines in /var/log/messages
May 21 20:58:33 pjk-glaptop gnome-power-manager: (user) Resuming computer
May 21 20:58:33 pjk-glaptop kernel: [33766.888000] sky2 eth0: enabling interface
May 21 20:58:33 pjk-glaptop kernel: [33766.892000] sky2 eth0: phy write timeout
--------------------------------------------the same message 6 times------------------------------------
May 21 20:58:33 pjk-glaptop kernel: [33766.900000] sky2 eth0: phy write timeout
May 21 20:58:33 pjk-glaptop kernel: [33766.908000] sky2 eth0: ram buffer 1020K

Thanks in advance for help !

I had some suspend / resume problems for some time now and digged a little bit into the infrastructure of suspending. The finding was, that some time ago I installed some additional power-management stuff, which is not as good tested as the default ubuntu setup. Since I reverted back some days ago, I have absolutely reliable NM after suspend.

Hint:
Please check, if you have powersave or kpowersave (both from universe) installed. If so, replace it by powernowd and apmd as dependencies of ubuntu-desktop.

As stated by Mr. Zimmerman:

We need more people to test the workaround provided here:

https://bugs.launchpad.net/ubuntu/feisty/+source/network-manager/+bug/40125/comments/68

Please be explicit about what you tried, how you tested and what the result was, so that we can confirm the validity of the test and hopefully fix this issue for everyone.

=============================================================================================

My machine is a Dell Latitude C610 with both a built-in Dell TrueMobile 1150 Series MiniPCI wireless card using the <orinoco_cs> driver and a Linksys wireless card using the <ndiswrapper> driver. I am currently accessing wireless successfully with the TrueMobile card using the <orinoco_cs> driver. This built-in card does not have the suspend/resume problems the Linksys card has. I suspect it may have something to do with drivers but I am not sure.

I copied the NetworkManager.conf file to the specified directory under /etc/dbus-1/system.d/ and restarted the computer as stated.

After booting up again, I tried to get the Linksys card to connect; however, it did not connect to any network available. The TrueMobile card, however, was able to connect to the wireless network and to an open access point it found.

I am wondering if I need to disable the MiniPCI card (the TrueMobile) in BIOS so that it doesn't affect the Linksys card. I am not sure if there is some interference, but I will try to test this out again to make sure there is not.

Are there any files that I should attach in order to give you more information, or any other tests to run?

I tried to make the fix from here: https://bugs.launchpad.net/ubuntu/feisty/+source/network-manager/+bug/40125/comments/1

I suspended to RAM a few times and the Dell TrueMobile card using the <orinoco_cs> driver picks up wireless well. The Linksys card with the <ndiswrapper> driver is still not working successfully.

John Cooper, should I attempt to uninstall and delete the two files that I created? If I leave them there, will they cause no problems to my machine?

I tried the change to /etc/dbus-1/system.d/NetworkManager.conf and restarted my laptop to no avail. On wakeup from suspend, network manager doesn't see my wireless interface. This is on a dell inspiron 5100 running feisty with all updates applied.

Sorry, I failed to mention - this is with an orinoco gold card (orinoco_cs).

What has since worked for me is adding the scripts in https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/40125/comments/43

with the exception that /etc/acpi/reseume.d/99-network-manager.sh was renamed to /etc/acpi/resume.d/63-network-manager.sh
in order to speed up the restart of network manager (it worked before, but I would have to wait 15-20 seconds after resume before the applet would find the network interfaces again).

IRC my problem was _only_ with the _wired_ part of NM: I was unable to use my wire connection after a suspend and/or after wifi. I did as directed in https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/40125/comments/68 with http://librarian.launchpad.net/7403629/NetworkManager.conf.

It's been one month long and I never had the problem again. So for me the correction is effective.

My laptop is a Dell Inspiron 630m and lspci returns:
02:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)
02:03.0 Network controller: Intel Corporation PRO/Wireless 2915ABG Network Connection (rev 05)

As stated in the above subject line, I have now retested the solution and it now works perfectly!

My original post is shown below:
<https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/40125/comments/88>

Basically, even when I restarted the computer twice and did a few suspend/resume cycles, it didn't work. However, after the third reboot today, I have finally been able to get my Linksys card using the <ndiswrapper> driver to work perfectly. I can suspend and resume as often as I want and it works!

My apologies for the above commentary about it not working. Others should try this solution and hope it works immediately.

Guess what? It happened again :-(

The good news is that I think I found how to reproduce it. The sequence is something like: use Wifi (e.g. office), suspend, resume with wifi active but no network (e.g. train), suspend, resume with wifi active and known network and cable plugged-in (e.g. home) -> NM is unable to connect with the wire.

I'll try to reproduce it a couple of times, to be sure.

This post is in reply to the post below:

<https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/40125/comments/93>

================================================================================================
As I stated before in my previous posts, I have both a Linksys Card using the Broadcom 4318 chipset and the <ndiswrapper> drivers, and a built-in Dell TrueMobile 1150 Series MiniPCI card using the <orinoco_cs> driver.

Up until yesterday, I thought that I had fixed the problem with the Linksys cards; I could finally get wireless access through the Linksys card and it would work perfectly. With this, I figured that I could at least have both so that I can use the TrueMobile as a backup in case the Linksys card fails.

The Linksys card no longer works as of this morning; it can find the wireless networks and all but it cannot successfully connect to them. The TrueMobile card can successfully connect to any wireless networks it can find.

This is becoming quite troublesome as I am unsure as to what causes it. I almost want to say that the problem is random but I doubt it. I think I will take Michel's advice and check to see if it involves his method of reproduction.

I ask this again (and my most sincere apologies to anyone who reads this sentence), but is there a set of commands or instructions I should run or execute to get any more information about the driver problem??? ANYTHING!?!? If I can figure out what I'm supposed to look for, I will help. Developers, I am sending this out to you to.

--Benitez

Bummer. The fix at
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/40125/comments/93

only partially works for my ToughBook CFW4 with a IPW card - it seems that the WPA supplicant does not reload on awaken from hibernate - on awake from suspend the nm starts but cannot associate with a WPA protected access point. Doing

 sudo /etc/dbus-1/event.d/25NetworkManager restart

is ineffectual as well; it won't associate with a WPA protected access point.

As in the very beginning of this post, clicking DISABLE wireless in the NM applet (right click then deselect "Enable Wireless") is effective, and the interface will come back up after suspend.

Any help or suggestions appreciated a whole lot!

Thanks,
Nick

Feisty 32-bit, 2.6.20-16-generic with ipw3945 and e100 on a Sony Vaio VGN-FE41Z.

Using just the ipw3945 wireless connection on a WPA2 network.

After resume from suspend NetworkManager reported no network devices. Restarting NetworkManager didn't seem to solve it.

The solution was to use mlaverdiere's method dated 2006-07-05 to stop NetworkManager during suspend and start it during resume:

https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/40125/comments/43

These methods all failed to solve the issue:

1. Adding max_replies_per_connection=512 to /etc/dbus-1/system.d/NetworkManager.conf
2. Adding dbus suspend/resume scripts (with varying priorities) as per John Cooper's post
3. Disabling Wireless Networking from the nm-applet prior to suspending

Doing a suspend/resume cycle whilst running NetworkManager --no-daemon reports:

NetworkManager: <information> Activation (eth1) successful, device activated.
NetworkManager: <information> Activation (eth1) Finish handler scheduled.
NetworkManager: <information> Activation (eth1) Stage 5 of 5 (IP Configure Commit) complete.
NetworkManager: <information> wpa_supplicant(6706): cess=1
NetworkManager: <information> Going to sleep.
sendmsg(CTRL_IFACE monitor): No such file or directory
NetworkManager: <debug info> [1183921757.754011] nm_hal_device_removed (): Device removed (hal udi is '/org/freedesktop/Hal/devices/net_00_13_a9_86_51_bd').
NetworkManager: <information> Deactivating device eth2.
NetworkManager: <information> Waking up from sleep.
NetworkManager: <information> Deactivating device eth1.
NetworkManager: <WARNING> nm_device_802_11_wireless_set_essid (): error setting ESSID to '' for device eth1: Resource temporarily unavailable
NetworkManager: <WARNING> nm_device_802_11_wireless_set_wep_enc_key (): error setting key for device eth1: Resource temporarily unavailable
NetworkManager: <WARNING> nm_device_802_11_wireless_get_mode (): error getting card mode on eth1: Resource temporarily unavailable
NetworkManager: <WARNING> nm_device_802_11_wireless_set_mode (): error setting card eth1 to Infrastructure mode: Resource temporarily unavailable

** net_00_13_a9_86_51_bd is the wired interface (not in use).

Stopping and restarting NetworkManager (as daemon or not) will start the network and connect successfully if NetworkManager was running as --nodaemon during suspend.

Gutsy Tribe-5 ( 23 August 2007) 2.6.22-10-generic

Suspend S3/Resume works fine.

[Expired for network-manager (Ubuntu) because there has been no activity for 60 days.]

status confirmed to prevent further auto closes.

looking at gnome bug 341303 this should be fixed in gutsy.

I'm still seeing this in Gutsy.

nm-applet disappears after suspend too (but as pointed out earlier, it seems to only fail when suspended for several hours). starting the nm-applet fails, presumably because of NetworkManager problems.

This is still happening to me, too. After suspend, nm-icon is not showing up. Running

sudo /etc/dbus-1/event.d/25NetworkManager restart

fixes the problem, so it must be a bug in the networkmanager daemon.

On Thu, Oct 04, 2007 at 09:31:12PM -0000, Vincenzo Ciancia wrote:
> This is still happening to me, too. After suspend, nm-icon is not
> showing up. Running
>
> sudo /etc/dbus-1/event.d/25NetworkManager restart
>
> fixes the problem, so it must be a bug in the networkmanager daemon.
>

Please test my network-manager from
http://ppa.launchpad.net/asac/ubuntu/pool/main/n/network-manager/

Version to test: 0.6.5-0ubuntu16~ppa1

Thanks,

 - Alexander

The network-manager from:

http://ppa.launchpad.net/asac/ubuntu/pool/main/n/network-manager/

resolved the issue for me (Dell 1505, with Intel 3945, latest Gutsy Beta, fully up to date), with a short suspend/resume test. Will report back if longer suspend/resume cycles have issues.

Prior to the patch I would have to either reconfigure the interface with iwconfig/dhclient3 or restart NetworkManager to get the wireless interface up. Disabling/re-enabling in NetworkManager did nothing.

Recent update in Gutsy rebreaks this [network-manager-dev version 0.6.5-0ubuntu16]. Network-Manager ends up confused after a suspend/resume and thinks it is connected. iwconfig/dhclient3 will restore wireless connection.

Reverting to network-manager-dev_0.6.5-0ubuntu16~ppa1_i386.deb fixes the issue.

I thought that this fix would get pushed into Gutsy?

I have the ppa now in my sources.list. Have fixes been added to gutsy?

Frequent unexplained drops from connectivity may also be related to ACPI and APM functions.

Disabling ACPI or APM seems to allow some users to remain connected. This may be an issue related to this reported bug.

See Ubuntu Forum thread:

http://ubuntuforums.org/showthread.php?p=4004891

I appear to be having this problem in Kubuntu Hardy. I don't know if I had it in gutsy, because my hibernation didn't work.

Neither my ethernet nor my wireless come back up in knetworkmanager. I can start my ethernet with "sudo dhclient" (pasted below), but knetworkmanager still doesn't recognise it.

$ sudo dhclient
Internet Systems Consortium DHCP Client V3.0.6
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

wmaster0: unknown hardware address type 801
SIOCSIFFLAGS: No such device
SIOCSIFFLAGS: No such device
SIOCSIFFLAGS: Operation not supported
SIOCSIFFLAGS: Operation not supported
wmaster0: unknown hardware address type 801
Listening on LPF/wlan0/00:0b:7d:15:75:6e
Sending on LPF/wlan0/00:0b:7d:15:75:6e
Listening on LPF/wmaster0/
Sending on LPF/wmaster0/
Listening on LPF/eth0/00:12:3f:21:23:9e
Sending on LPF/eth0/00:12:3f:21:23:9e
Sending on Socket/fallback
DHCPDISCOVER on wmaster0 to 255.255.255.255 port 67 interval 5
send_packet: Network is down
receive_packet failed on wlan0: Network is down
receive_packet failed on wmaster0: Network is down
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8
send_packet: Network is down
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
DHCPOFFER from 192.168.1.1
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 192.168.1.1
bound to 192.168.1.9 -- renewal in 388043 seconds.

$ uname -a:
Linux naught101-laptop 2.6.24-12-generic #1 SMP Wed Mar 12 23:01:54 UTC 2008 i686 GNU/Linux

$ lspci |grep Broadcom:
01:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet PCI Express (rev 01)
02:03.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03)

also, neither wlassistant, nor kwifimanager can find the wireless card, neither of which depend on network manager.

Is this fixed?

For me it is fixed 99% of the time in hardy (intel iwl3945 and NM). Yesterday after a suspend/resume spree to try and reproduce another bug, after about 10 cycles in very short time, the NetworkManager daemon failed to reconnect. I killed it and restarted, and this fixed it. But normally it works fine.

Feel free to reopen in case you have more information, I think it's wise to close it in feisty too.

This bug is back for me in Saucy :(

Julien: It'd be better to open a brand new bug report with details of the system exhibiting the problem. In the description give a reference to this issue using "bug #40125" and the bug-tracker will hyperlink it to this page.