Re: Reconnecting to wireless network after waking up from suspend-to-ram takes too long
It might me be a driver issue, although I had the same problem with the old
ipw3945 driver from Intel. Back then, i worked around this problem by
restarting the regulatory daemon after waking up. This, of course, is not
possible anymore, simply due to the lack of any regulatory daemon i could
restart. I don't know, how equal both drivers are, but as they show the same
behavior, maybe it's more like a hardware thing such that the Intel 3945ABG
card needs a few seconds before it is fully working again?
Anyway, i was able to figure out a way to have NM reconnect much faster: I
set my power management software (kpowersave) to run a script after waking
up that goes like this: wait two seconds, scan for networks ('iwlist eth1
scan'), wait 1 second, scan again, wait 1 second, scan again, stop. This
always results in NM reconnecting already after 10 or so seconds, as in the
case of the ipw2200.
So, as you said, maybe NM should try to scan for networks more frequently,
until gets some results, and not only once...
On Mon, Jul 21, 2008 at 18:47, Dan Williams <[EMAIL PROTECTED]> wrote:
> On Fri, 2008-07-18 at 21:51 +0200, Peter Roediger wrote:
> > I'm using Debian/sid with a custom-built kernel (version 2.6.25.4) and
> > networkmanager 0.6.6 from the Debian repositories. My wireless network
> > card is an Intel 3945ABG. I'm using the iwl3945 driver that is
> > included with the kernel.
> >
> > Setting up the internet connection using nm-applet to my wireless
> > network with WPA encryption works seamlessly. Instead of shutting down
> > my laptop I am normally just sending it to sleep in order to quickly
> > have it back up when I need it. The only problem comes up right after
> > waking up: Reconnecting to my wireless network takes usually more than
> > one minute - a really annoying issue. Checking /var/log/syslog the
> > output of NM shows the following:
>
> Maybe scanning more frequently when disconnected right after wakeup, but
> as you said, the ipw2200 works great here so there's obviously driver
> issues at work too. NM will scan at least once right after it finds the
> card again, but if the card doesn't have anything to report the scan
> interval will back off to 40 seconds. We probably want to do that more
> frequently. In reality that will just mask the problem deeper down in
> the driver, or in the supplicant <-> driver communication.
>
> dan
>
> > Jul 18 19:32:29 Kati-PC NetworkManager: Waking up from sleep.
> > Jul 18 19:32:29 Kati-PC NetworkManager: Deactivating device
> > eth1.
> > Jul 18 19:32:29 Kati-PC NetworkManager: Deactivating device
> > eth0.
> > Jul 18 19:32:29 Kati-PC kernel: ADDRCONF(NETDEV_UP): eth1: link is not
> > ready
> > Jul 18 19:32:29 Kati-PC NetworkManager: eth1: Device is
> > fully-supported using driver 'iwl3945'.
> > Jul 18 19:32:29 Kati-PC NetworkManager: eth1: driver supports
> > SSID scans (scan_capa 0x01).
> > Jul 18 19:32:29 Kati-PC NetworkManager: nm_device_init():
> > waiting for device's worker thread to start
> > Jul 18 19:32:29 Kati-PC NetworkManager: nm_device_init():
> > device's worker thread started, continuing.
> > Jul 18 19:32:29 Kati-PC NetworkManager: Now managing wireless
> > (802.11) device 'eth1'.
> > Jul 18 19:32:29 Kati-PC NetworkManager: Deactivating device
> > eth1.
> > Jul 18 19:32:29 Kati-PC kernel: ADDRCONF(NETDEV_UP): eth0: link is not
> > ready
> > Jul 18 19:32:29 Kati-PC NetworkManager: eth0: Device is
> > fully-supported using driver 'e100'.
> > Jul 18 19:32:29 Kati-PC NetworkManager: nm_device_init():
> > waiting for device's worker thread to start
> > Jul 18 19:32:29 Kati-PC NetworkManager: nm_device_init():
> > device's worker thread started, continuing.
> > Jul 18 19:32:29 Kati-PC NetworkManager: Now managing wired
> > Ethernet (802.3) device 'eth0'.
> > Jul 18 19:32:29 Kati-PC NetworkManager: Deactivating device
> > eth0.
> > Jul 18 19:33:39 Kati-PC NetworkManager: SWITCH: no current
> > connection, found better connection 'eth1'.
> > Jul 18 19:33:39 Kati-PC NetworkManager: Will activate
> > connection 'eth1/WLAN-Caste'.
> > Jul 18 19:33:39 Kati-PC NetworkManager: Device eth1 activation
> > scheduled...
> > Jul 18 19:33:39 Kati-PC NetworkManager: Activation (eth1)
> > started...
> > Jul 18 19:33:39 Kati-PC NetworkManager: Activation (eth1)
> > Stage 1 of 5 (Device Prepare) scheduled...
> > Jul 18 19:33:39 Kati-PC NetworkManager: Activation (eth1)
> > Stage 1 of 5 (Device Prepare) started...
> > Jul 18 19:33:39 Kati-PC NetworkManager: Activation (eth1)
> > Stage 2 of 5 (Device Configure) scheduled...
> > Jul 18 19:33:39 Kati-PC NetworkManager: Activation (eth1)
> > Stage 1 of 5 (Device Prepare) complete.
> > Jul 18 19:33:39 Kati-PC NetworkManager: Activation (eth1)
> > Stage 2 of 5 (Device Configure) starting...
> > Jul 18 19:33:39 Kati-PC NetworkManager: Activation
> > (eth1/wireless): access point 'WLAN-Caste' is encrypted, and a key
> > exists. No new key needed.
> >
> > ..and so on.
Re: Reconnecting to wireless network after waking up from suspend-to-ram takes too long
On Fri, 2008-07-18 at 21:51 +0200, Peter Roediger wrote: > I'm using Debian/sid with a custom-built kernel (version 2.6.25.4) and > networkmanager 0.6.6 from the Debian repositories. My wireless network > card is an Intel 3945ABG. I'm using the iwl3945 driver that is > included with the kernel. > > Setting up the internet connection using nm-applet to my wireless > network with WPA encryption works seamlessly. Instead of shutting down > my laptop I am normally just sending it to sleep in order to quickly > have it back up when I need it. The only problem comes up right after > waking up: Reconnecting to my wireless network takes usually more than > one minute - a really annoying issue. Checking /var/log/syslog the > output of NM shows the following: Maybe scanning more frequently when disconnected right after wakeup, but as you said, the ipw2200 works great here so there's obviously driver issues at work too. NM will scan at least once right after it finds the card again, but if the card doesn't have anything to report the scan interval will back off to 40 seconds. We probably want to do that more frequently. In reality that will just mask the problem deeper down in the driver, or in the supplicant <-> driver communication. dan > Jul 18 19:32:29 Kati-PC NetworkManager: Waking up from sleep. > Jul 18 19:32:29 Kati-PC NetworkManager: Deactivating device > eth1. > Jul 18 19:32:29 Kati-PC NetworkManager: Deactivating device > eth0. > Jul 18 19:32:29 Kati-PC kernel: ADDRCONF(NETDEV_UP): eth1: link is not > ready > Jul 18 19:32:29 Kati-PC NetworkManager: eth1: Device is > fully-supported using driver 'iwl3945'. > Jul 18 19:32:29 Kati-PC NetworkManager: eth1: driver supports > SSID scans (scan_capa 0x01). > Jul 18 19:32:29 Kati-PC NetworkManager: nm_device_init(): > waiting for device's worker thread to start > Jul 18 19:32:29 Kati-PC NetworkManager: nm_device_init(): > device's worker thread started, continuing. > Jul 18 19:32:29 Kati-PC NetworkManager: Now managing wireless > (802.11) device 'eth1'. > Jul 18 19:32:29 Kati-PC NetworkManager: Deactivating device > eth1. > Jul 18 19:32:29 Kati-PC kernel: ADDRCONF(NETDEV_UP): eth0: link is not > ready > Jul 18 19:32:29 Kati-PC NetworkManager: eth0: Device is > fully-supported using driver 'e100'. > Jul 18 19:32:29 Kati-PC NetworkManager: nm_device_init(): > waiting for device's worker thread to start > Jul 18 19:32:29 Kati-PC NetworkManager: nm_device_init(): > device's worker thread started, continuing. > Jul 18 19:32:29 Kati-PC NetworkManager: Now managing wired > Ethernet (802.3) device 'eth0'. > Jul 18 19:32:29 Kati-PC NetworkManager: Deactivating device > eth0. > Jul 18 19:33:39 Kati-PC NetworkManager: SWITCH: no current > connection, found better connection 'eth1'. > Jul 18 19:33:39 Kati-PC NetworkManager: Will activate > connection 'eth1/WLAN-Caste'. > Jul 18 19:33:39 Kati-PC NetworkManager: Device eth1 activation > scheduled... > Jul 18 19:33:39 Kati-PC NetworkManager: Activation (eth1) > started... > Jul 18 19:33:39 Kati-PC NetworkManager: Activation (eth1) > Stage 1 of 5 (Device Prepare) scheduled... > Jul 18 19:33:39 Kati-PC NetworkManager: Activation (eth1) > Stage 1 of 5 (Device Prepare) started... > Jul 18 19:33:39 Kati-PC NetworkManager: Activation (eth1) > Stage 2 of 5 (Device Configure) scheduled... > Jul 18 19:33:39 Kati-PC NetworkManager: Activation (eth1) > Stage 1 of 5 (Device Prepare) complete. > Jul 18 19:33:39 Kati-PC NetworkManager: Activation (eth1) > Stage 2 of 5 (Device Configure) starting... > Jul 18 19:33:39 Kati-PC NetworkManager: Activation > (eth1/wireless): access point 'WLAN-Caste' is encrypted, and a key > exists. No new key needed. > > ..and so on. After this, a connection is successfully established. > Note that between "Jul 18 19:32:29 Kati-PC NetworkManager: > Deactivating device eth0." and the next message "Jul 18 19:33:39 > Kati-PC NetworkManager: SWITCH: no current connection, found > better connection 'eth1'." 1 minute and 10 seconds have passed (though > this time period varies). Btw., when trying to scan for wireless > networks within this time period using "iwlist eth1 scan", it shows me > all available networks correctly. Trying to manually reconnect using > the nm-applet is not possible as it does not show any wireless > networks until it reconnects. > > I have another laptop, though with an Intel 2200 wireless card, but > the same kernel version and OS, and there this time period is usually > down to only 10 seconds or so, making it reconnect much faster. > > Is there any way, any setting to speed up reconnecting? This is really > the only issue I encounter, otherwise NM works just great. > > ___ > NetworkManager-list mailing list > NetworkManager-list@gnome.org > http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list Network
Re: Reconnecting to wireless network after waking up from suspend-to-ram takes too long
On Fri, 2008-07-18 at 21:51 +0200, Peter Roediger wrote: I'm using Debian/sid with a custom-built kernel (version 2.6.25.4) and networkmanager 0.6.6 from the Debian repositories. My wireless network card is an Intel 3945ABG. I'm using the iwl3945 driver that is included with the kernel. Setting up the internet connection using nm-applet to my wireless network with WPA encryption works seamlessly. Instead of shutting down my laptop I am normally just sending it to sleep in order to quickly have it back up when I need it. The only problem comes up right after waking up: Reconnecting to my wireless network takes usually more than one minute - a really annoying issue. Checking /var/log/syslog the output of NM shows the following: [...log messages deleted...] ..and so on. After this, a connection is successfully established. Note that between "Jul 18 19:32:29 Kati-PC NetworkManager: Deactivating device eth0." and the next message "Jul 18 19:33:39 Kati-PC NetworkManager: SWITCH: no current connection, found better connection 'eth1'." 1 minute and 10 seconds have passed (though this time period varies). Btw., when trying to scan for wireless networks within this time period using "iwlist eth1 scan", it shows me all available networks correctly. Trying to manually reconnect using the nm-applet is not possible as it does not show any wireless networks until it reconnects. I have another laptop, though with an Intel 2200 wireless card, but the same kernel version and OS, and there this time period is usually down to only 10 seconds or so, making it reconnect much faster. Is there any way, any setting to speed up reconnecting? This is really the only issue I encounter, otherwise NM works just great. I often see the same behavior in Fedora 8 (currently NetworkManager-0.7.0-0.6.9.svn3675.fc8.x86_64 and also the iwl3945 driver). (Didn't look at the log messages, but the rest of the description is accurate for me as well.) -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Reconnecting to wireless network after waking up from suspend-to-ram takes too long
I'm using Debian/sid with a custom-built kernel (version 2.6.25.4) and networkmanager 0.6.6 from the Debian repositories. My wireless network card is an Intel 3945ABG. I'm using the iwl3945 driver that is included with the kernel. Setting up the internet connection using nm-applet to my wireless network with WPA encryption works seamlessly. Instead of shutting down my laptop I am normally just sending it to sleep in order to quickly have it back up when I need it. The only problem comes up right after waking up: Reconnecting to my wireless network takes usually more than one minute - a really annoying issue. Checking /var/log/syslog the output of NM shows the following: Jul 18 19:32:29 Kati-PC NetworkManager: Waking up from sleep. Jul 18 19:32:29 Kati-PC NetworkManager: Deactivating device eth1. Jul 18 19:32:29 Kati-PC NetworkManager: Deactivating device eth0. Jul 18 19:32:29 Kati-PC kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready Jul 18 19:32:29 Kati-PC NetworkManager: eth1: Device is fully-supported using driver 'iwl3945'. Jul 18 19:32:29 Kati-PC NetworkManager: eth1: driver supports SSID scans (scan_capa 0x01). Jul 18 19:32:29 Kati-PC NetworkManager: nm_device_init(): waiting for device's worker thread to start Jul 18 19:32:29 Kati-PC NetworkManager: nm_device_init(): device's worker thread started, continuing. Jul 18 19:32:29 Kati-PC NetworkManager: Now managing wireless (802.11) device 'eth1'. Jul 18 19:32:29 Kati-PC NetworkManager: Deactivating device eth1. Jul 18 19:32:29 Kati-PC kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready Jul 18 19:32:29 Kati-PC NetworkManager: eth0: Device is fully-supported using driver 'e100'. Jul 18 19:32:29 Kati-PC NetworkManager: nm_device_init(): waiting for device's worker thread to start Jul 18 19:32:29 Kati-PC NetworkManager: nm_device_init(): device's worker thread started, continuing. Jul 18 19:32:29 Kati-PC NetworkManager: Now managing wired Ethernet (802.3) device 'eth0'. Jul 18 19:32:29 Kati-PC NetworkManager: Deactivating device eth0. Jul 18 19:33:39 Kati-PC NetworkManager: SWITCH: no current connection, found better connection 'eth1'. Jul 18 19:33:39 Kati-PC NetworkManager: Will activate connection 'eth1/WLAN-Caste'. Jul 18 19:33:39 Kati-PC NetworkManager: Device eth1 activation scheduled... Jul 18 19:33:39 Kati-PC NetworkManager: Activation (eth1) started... Jul 18 19:33:39 Kati-PC NetworkManager: Activation (eth1) Stage 1 of 5 (Device Prepare) scheduled... Jul 18 19:33:39 Kati-PC NetworkManager: Activation (eth1) Stage 1 of 5 (Device Prepare) started... Jul 18 19:33:39 Kati-PC NetworkManager: Activation (eth1) Stage 2 of 5 (Device Configure) scheduled... Jul 18 19:33:39 Kati-PC NetworkManager: Activation (eth1) Stage 1 of 5 (Device Prepare) complete. Jul 18 19:33:39 Kati-PC NetworkManager: Activation (eth1) Stage 2 of 5 (Device Configure) starting... Jul 18 19:33:39 Kati-PC NetworkManager: Activation (eth1/wireless): access point 'WLAN-Caste' is encrypted, and a key exists. No new key needed. ..and so on. After this, a connection is successfully established. Note that between "Jul 18 19:32:29 Kati-PC NetworkManager: Deactivating device eth0." and the next message "Jul 18 19:33:39 Kati-PC NetworkManager: SWITCH: no current connection, found better connection 'eth1'." 1 minute and 10 seconds have passed (though this time period varies). Btw., when trying to scan for wireless networks within this time period using "iwlist eth1 scan", it shows me all available networks correctly. Trying to manually reconnect using the nm-applet is not possible as it does not show any wireless networks until it reconnects. I have another laptop, though with an Intel 2200 wireless card, but the same kernel version and OS, and there this time period is usually down to only 10 seconds or so, making it reconnect much faster. Is there any way, any setting to speed up reconnecting? This is really the only issue I encounter, otherwise NM works just great. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
