Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #225133 > unrolled thread

Slow wifi-reconnection when waking up

Back to article view | Back to linux.debian.user

Contents

  Slow wifi-reconnection when waking up Stefan Monnier <monnier@iro.umontreal.ca> - 2020-07-22 21:10 +0200
    Re: Slow wifi-reconnection when waking up Dan Ritter <dsr@randomstring.org> - 2020-07-22 21:20 +0200
    Re: Slow wifi-reconnection when waking up Brad Rogers <brad@fineby.me.uk> - 2020-07-22 21:30 +0200
      Re: Slow wifi-reconnection when waking up Stefan Monnier <monnier@iro.umontreal.ca> - 2020-07-22 22:10 +0200
        Re: Slow wifi-reconnection when waking up Kushal Kumaran <kushal@locationd.net> - 2020-07-23 02:30 +0200
          Re: Slow wifi-reconnection when waking up Stefan Monnier <monnier@iro.umontreal.ca> - 2020-07-23 05:00 +0200
        Re: Slow wifi-reconnection when waking up Brad Rogers <brad@fineby.me.uk> - 2020-07-23 09:30 +0200
    Re: Slow wifi-reconnection when waking up Stefan Monnier <monnier@iro.umontreal.ca> - 2020-07-22 21:50 +0200
    Re: Slow wifi-reconnection when waking up David Wright <deblis@lionunicorn.co.uk> - 2020-07-23 00:30 +0200
      Re: Slow wifi-reconnection when waking up Stefan Monnier <monnier@iro.umontreal.ca> - 2020-07-23 00:40 +0200
    Re: Slow wifi-reconnection when waking up Charles Curley <charlescurley@charlescurley.com> - 2020-07-23 01:30 +0200
      Re: Slow wifi-reconnection when waking up Charles Curley <charlescurley@charlescurley.com> - 2020-07-23 02:10 +0200
        Re: Slow wifi-reconnection when waking up Stefan Monnier <monnier@iro.umontreal.ca> - 2020-07-23 05:00 +0200
          Re: Slow wifi-reconnection when waking up David Wright <deblis@lionunicorn.co.uk> - 2020-07-23 05:20 +0200
            Re: Slow wifi-reconnection when waking up Stefan Monnier <monnier@iro.umontreal.ca> - 2020-07-24 02:20 +0200
          Re: Slow wifi-reconnection when waking up Tixy <tixy@yxit.co.uk> - 2020-07-23 09:00 +0200
            Re: Slow wifi-reconnection when waking up Stefan Monnier <monnier@iro.umontreal.ca> - 2020-07-24 02:30 +0200
      Re: Slow wifi-reconnection when waking up Joe <joe@jretrading.com> - 2020-07-23 17:20 +0200
        Re: Slow wifi-reconnection when waking up Stefan Monnier <monnier@iro.umontreal.ca> - 2020-07-24 02:30 +0200
          Re: Slow wifi-reconnection when waking up Yvan Masson <yvan@masson-informatique.fr> - 2020-07-24 15:30 +0200

#225133 — Slow wifi-reconnection when waking up

When I wake up from suspend, my Debian machines take a "long" time to
reconnect to the wifi.  Looking at the `nm-applet` icon in my XFCE4
panel, I see:
- for about 10s the icon is "two computers" (which IIUC represents
  just NetworkManager).
- then the icon changes to the one representing a wired ethernet
  connection and stays that way for about 10s (there's nothing
  plugged into the ethernet port of this computer).
- then the icon changes to the "two dots, with something circling
  between them" which indicates that the system is in the process of
  connecting to a wifi network.
- after about 5s this changes to the bars representation of the
  signal quality.

IOW, while it takes about 5s to connect to the wifi network, it takes
about 20 additional seconds for NM to decide that it should try to
connect.

I have the impression that a few years ago, my Debian machines
reconnected more quickly to the wifi.

I can live with this delay, especially when it's waking up in
a different place than where it got suspended, but in the case where
it's waking up at the same place where it got suspended, those extra 20s
seem hard to justify.

Any idea what might be going on and how to make it quicker?


        Stefan

[toc] | [next] | [standalone]

#225134

Stefan Monnier wrote: 
> When I wake up from suspend, my Debian machines take a "long" time to
> reconnect to the wifi.  Looking at the `nm-applet` icon in my XFCE4
> panel, I see:
> - for about 10s the icon is "two computers" (which IIUC represents
>   just NetworkManager).
> - then the icon changes to the one representing a wired ethernet
>   connection and stays that way for about 10s (there's nothing
>   plugged into the ethernet port of this computer).
> - then the icon changes to the "two dots, with something circling
>   between them" which indicates that the system is in the process of
>   connecting to a wifi network.
> - after about 5s this changes to the bars representation of the
>   signal quality.
> 
> IOW, while it takes about 5s to connect to the wifi network, it takes
> about 20 additional seconds for NM to decide that it should try to
> connect.
> 
> I have the impression that a few years ago, my Debian machines
> reconnected more quickly to the wifi.
> 
> I can live with this delay, especially when it's waking up in
> a different place than where it got suspended, but in the case where
> it's waking up at the same place where it got suspended, those extra 20s
> seem hard to justify.
> 
> Any idea what might be going on and how to make it quicker?

With no Network Manager and using wicd instead, my buster laptop
takes about 5 seconds from lid open to re-connect.

-dsr-

[toc] | [prev] | [next] | [standalone]

#225137

[Multipart message — attachments visible in raw view] — view raw

On Wed, 22 Jul 2020 15:04:44 -0400
Stefan Monnier <monnier@iro.umontreal.ca> wrote:

Hello Stefan,

>Any idea what might be going on and how to make it quicker?

You could set up networkmanager so that it ignores the ethernet port.
That should save you some time.

See;
https://developer.gnome.org/NetworkManager/stable/NetworkManager.conf.html

In particular the 'keyfile section' and 'ifupdown section', which detail
methods by which network interface devices can be ignored.

-- 
 Regards  _
         / )           "The blindingly obvious is
        / _)rad        never immediately apparent"
We can dance like Iggy Pop
Coffee Shop - Red Hot Chili Peppers

[toc] | [prev] | [next] | [standalone]

#225139

> You could set up networkmanager so that it ignores the ethernet port.
> That should save you some time.
>
> See;
> https://developer.gnome.org/NetworkManager/stable/NetworkManager.conf.html
>
> In particular the 'keyfile section' and 'ifupdown section', which detail
> methods by which network interface devices can be ignored.

Are you saying that you suffer from the same problem?
Are you all seeing this ridiculous 20s delay before NM even tries to
reconnect to your wifi?

To be clear, I consider the current behavior I see as a *bug*, so I'd
rather not try and come up with kludges to work around it, but would
prefer to "fix it for good" by finding the origin of the problem (which
I assume is some misconfiguration somewhere on my side, probably due to
the fact that these are Debian testing systems that have been upgraded
without any clean reinstall over more than 10 years).



        Stefan

[toc] | [prev] | [next] | [standalone]

#225145

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> You could set up networkmanager so that it ignores the ethernet port.
>> That should save you some time.
>>
>> See;
>> https://developer.gnome.org/NetworkManager/stable/NetworkManager.conf.html
>>
>> In particular the 'keyfile section' and 'ifupdown section', which detail
>> methods by which network interface devices can be ignored.
>
> Are you saying that you suffer from the same problem?
> Are you all seeing this ridiculous 20s delay before NM even tries to
> reconnect to your wifi?
>

I have no idea how to fix your problem.  I do use NM though, and my wifi
is already connected in the time I unlock after my laptop has been
sleeping overnight.

> To be clear, I consider the current behavior I see as a *bug*, so I'd
> rather not try and come up with kludges to work around it, but would
> prefer to "fix it for good" by finding the origin of the problem (which
> I assume is some misconfiguration somewhere on my side, probably due to
> the fact that these are Debian testing systems that have been upgraded
> without any clean reinstall over more than 10 years).
>

I use stable.

The UI I use to manage NM shows a "Priority" field for each connection.
My wired connection has a priority of -100, and the wifi has a priority
of 0.  It documents that connections with higher priority are
"preferred".  In the nmcli c show output, this is the
connection.autoconnect-priority attribute.  Perhaps you can see what
these values are set to for you and whether adjusting these improves
things.

-- 
regards,
kushal

[toc] | [prev] | [next] | [standalone]

#225147

> I have no idea how to fix your problem.  I do use NM though, and my wifi
> is already connected in the time I unlock after my laptop has been
> sleeping overnight.

Right, that's what I remember it doing a couple years ago for me as well.
Thanks for confirming!


        Stefan

[toc] | [prev] | [next] | [standalone]

#225159

[Multipart message — attachments visible in raw view] — view raw

On Wed, 22 Jul 2020 16:05:04 -0400
Stefan Monnier <monnier@iro.umontreal.ca> wrote:

Hello Stefan,

>Are you saying that you suffer from the same problem?

No.

-- 
 Regards  _
         / )           "The blindingly obvious is
        / _)rad        never immediately apparent"
The deadbeats and the dispossessed, the seekers of unlikeliness
Street Of Dreams - The Damned

[toc] | [prev] | [next] | [standalone]

#225138

>> When I wake up from suspend,
> My current laptop is nice and fast, with an nvme boot drive, so I've
> been doing some investigations into speeding up boot times as well.

Notice the apple-vs-oranges here.
I'm talking about the time to reconnect to wifi after wake-up
from suspend.
Time to boot is a completely different kettle of fish.


        Stefan

[toc] | [prev] | [next] | [standalone]

#225141

On Wed 22 Jul 2020 at 15:04:44 (-0400), Stefan Monnier wrote:
> When I wake up from suspend, my Debian machines take a "long" time to
> reconnect to the wifi.  Looking at the `nm-applet` icon in my XFCE4
> panel, I see:
> - for about 10s the icon is "two computers" (which IIUC represents
>   just NetworkManager).
> - then the icon changes to the one representing a wired ethernet
>   connection and stays that way for about 10s (there's nothing
>   plugged into the ethernet port of this computer).
> - then the icon changes to the "two dots, with something circling
>   between them" which indicates that the system is in the process of
>   connecting to a wifi network.
> - after about 5s this changes to the bars representation of the
>   signal quality.
> 
> IOW, while it takes about 5s to connect to the wifi network, it takes
> about 20 additional seconds for NM to decide that it should try to
> connect.
> 
> I have the impression that a few years ago, my Debian machines
> reconnected more quickly to the wifi.
> 
> I can live with this delay, especially when it's waking up in
> a different place than where it got suspended, but in the case where
> it's waking up at the same place where it got suspended, those extra 20s
> seem hard to justify.
> 
> Any idea what might be going on and how to make it quicker?

Presumably the logs (daemon.log, syslog) should give details of
what's going on. But I'm not clear about how it should determine
that it woke up in the same place, except by first checking for a
wired connection (if you have that configured and prioritised), and
then negotiating a wireless connection.

All my machines, wired and wireless, negotiate DHCP leases with my
routers (so some of the timings I observe may be slowed by the
cascading involved). I don't know whether you can manually configure
an alternative, more static, type of connection that would be faster
coming up.

If you normally never use a wired connection, you might consider
blacklisting the appropriate ethernet module via a kernel parameter
(module_blacklist). That would allow you to set up alternatives as
Grub menu items.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#225142

> Presumably the logs (daemon.log, syslog) should give details of
> what's going on.

Nothing I can see there seems relevant, no.  I just see the messages
about when the connection is done.

> But I'm not clear about how it should determine that it woke up in the
> same place,

It doesn't need to.  It can just presume that it's the case when
choosing what to try in which order.

> except by first checking for a wired connection (if you
> have that configured and prioritised), and then negotiating
> a wireless connection.

I'd assume it would first look for "the network used most recently".
If that fails, it can then try other networks.

> All my machines, wired and wireless, negotiate DHCP leases with my
> routers (so some of the timings I observe may be slowed by the
> cascading involved).

Same here (and I assume it's the same pretty much everywhere nowadays).

> I don't know whether you can manually configure an alternative, more
> static, type of connection that would be faster coming up.

Yes, I know how to setup a static config but that's not what I'm after.

Debian used to do it more quickly.  Android does it more quickly.
MacOS does it more quickly.  What I see is a bug: there shouldn't be
a 20s delay before we try connecting to the wifi that was used before
the machine went to sleep.

> If you normally never use a wired connection, you might consider

I do use wired connections sometimes.


        Stefan

[toc] | [prev] | [next] | [standalone]

#225143

On Wed, 22 Jul 2020 15:04:44 -0400
Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> When I wake up from suspend, my Debian machines take a "long" time to
> reconnect to the wifi.  Looking at the `nm-applet` icon in my XFCE4
> panel, I see:
> - for about 10s the icon is "two computers" (which IIUC represents
>   just NetworkManager).

That indicates "no connection".

> - then the icon changes to the one representing a wired ethernet
>   connection and stays that way for about 10s (there's nothing
>   plugged into the ethernet port of this computer).

Which indicates that NM is trying to connect to a wired connection.

> - then the icon changes to the "two dots, with something circling
>   between them" which indicates that the system is in the process of
>   connecting to a wifi network.

NM negotiating to join a WiFi network.

> - after about 5s this changes to the bars representation of the
>   signal quality.

WiFi connection established.

> 
> IOW, while it takes about 5s to connect to the wifi network, it takes
> about 20 additional seconds for NM to decide that it should try to
> connect.

Somehow NM is convinced that it should try an Ethernet connection
first. You need a way to disabuse it of that notion.

What does your /etc/network/interfaces file look like? Is your Ethernet
device present there? If so, try commenting it out and restarting NM.

Otherwise, as Brad Rogers <brad@fineby.me.uk> mentioned,
https://developer.gnome.org/NetworkManager/stable/NetworkManager.conf.html
may have some tips.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#225144

On Wed, 22 Jul 2020 17:23:25 -0600
Charles Curley <charlescurley@charlescurley.com> wrote:

> Somehow NM is convinced that it should try an Ethernet connection
> first. You need a way to disabuse it of that notion.

Also check the priorities of your WiFi and Ethernet connections. Mine
are: Ethernet, -999; all WiFi, 0.

Right click on the `nm-applet` icon, select Edit Connections. Select
connections as needed. Click on the little gear thingie at the bottom.
Click on General.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#225148

>> Somehow NM is convinced that it should try an Ethernet connection
>> first.  You need a way to disabuse it of that notion.

Why doesn't it start with the last active connection?
I suspect that for 99% of the users this will be the most common case.

Also, why does it wait 10s before it tries to connect to anything?

>> What does your /etc/network/interfaces file look like? Is your Ethernet
>> device present there? If so, try commenting it out and restarting NM.

Indeed I have a

    iface eth0 inet dhcp

in there.  But removing it doesn't seem to make any difference in this
respect (even after `systemctl restart NetworkManager`).

> Also check the priorities of your WiFi and Ethernet connections. Mine
> are: Ethernet, -999; all WiFi, 0.

I never touched those, but yes I now see that they are exactly like yours.


        Stefan

[toc] | [prev] | [next] | [standalone]

#225149

On Wed 22 Jul 2020 at 22:51:00 (-0400), Stefan Monnier wrote:
> >> Somehow NM is convinced that it should try an Ethernet connection
> >> first.  You need a way to disabuse it of that notion.
> 
> Why doesn't it start with the last active connection?
> I suspect that for 99% of the users this will be the most common case.
> 
> Also, why does it wait 10s before it tries to connect to anything?
> 
> >> What does your /etc/network/interfaces file look like? Is your Ethernet
> >> device present there? If so, try commenting it out and restarting NM.
> 
> Indeed I have a
> 
>     iface eth0 inet dhcp
> 
> in there.  But removing it doesn't seem to make any difference in this
> respect (even after `systemctl restart NetworkManager`).
> 
> > Also check the priorities of your WiFi and Ethernet connections. Mine
> > are: Ethernet, -999; all WiFi, 0.
> 
> I never touched those, but yes I now see that they are exactly like yours.

In view of the fact that I haven't seen an "eth0" string for quite a
while, might it be worth checking your ethernet names? There might be
a pause while something is searching for eth0 rather than, say, enp3s0.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#225172

>> Indeed I have a
>> 
>>     iface eth0 inet dhcp
>> 
>> in there.  But removing it doesn't seem to make any difference in this
>> respect (even after `systemctl restart NetworkManager`).

> In view of the fact that I haven't seen an "eth0" string for quite a
> while, might it be worth checking your ethernet names? There might be
> a pause while something is searching for eth0 rather than, say, enp3s0.

Good spotting!  Indeed, this `eth0` is stale, my interface is actually
called `eth1` (left over settings from older versions of Debian have
prevented this one from being gobbled by the Great Renaming, apparently).

But in either case, this setting doesn't seem to have any effect on NM.


        Stefan

[toc] | [prev] | [next] | [standalone]

#225155

On Wed, 2020-07-22 at 22:51 -0400, Stefan Monnier wrote:
> > > Somehow NM is convinced that it should try an Ethernet connection
> > > first.  You need a way to disabuse it of that notion.
> 
> Why doesn't it start with the last active connection?
> I suspect that for 99% of the users this will be the most common
> case.
> 
> Also, why does it wait 10s before it tries to connect to anything?

Perhaps because it's got to detect that it's actually lost network
connection in the first place? When the computer comes back from
hibernate or suspend a running program probably doesn't know anything's
happened other that time has jumped forward a lot.

-- 
Tixy

[toc] | [prev] | [next] | [standalone]

#225173

>> Also, why does it wait 10s before it tries to connect to anything?
> Perhaps because it's got to detect that it's actually lost network
> connection in the first place? When the computer comes back from
> hibernate or suspend a running program probably doesn't know anything's
> happened other that time has jumped forward a lot.

I think NM listens to suspend/wakeup messages on D-Bus and is thus
dutifully alerted of the situation (rather than having to watch for time
jumps).


        Stefan

[toc] | [prev] | [next] | [standalone]

#225168

On Wed, 22 Jul 2020 17:23:25 -0600
Charles Curley <charlescurley@charlescurley.com> wrote:

> On Wed, 22 Jul 2020 15:04:44 -0400
> Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 

> > 
> > IOW, while it takes about 5s to connect to the wifi network, it
> > takes about 20 additional seconds for NM to decide that it should
> > try to connect.  
> 
> Somehow NM is convinced that it should try an Ethernet connection
> first. You need a way to disabuse it of that notion.
> 
Not necessarily. My netbook (stretch with NM) normally uses wires, and
that is the priority. I occasionally use wifi at home, and usually when
out, and use sleep quite often. When I open the lid, and tap a key to
wake the display, the wifi strength signal is already there. I do get a
'network is disconnected' box at this point, but this would seem to be a
hangover from the 'going to sleep' process.

I don't have an answer to the problem, but disabling Ethernet priority
with NM is not it.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#225174

>> Somehow NM is convinced that it should try an Ethernet connection
>> first. You need a way to disabuse it of that notion.
> Not necessarily. My netbook (stretch with NM) normally uses wires, and
> that is the priority. I occasionally use wifi at home, and usually when
> out, and use sleep quite often. When I open the lid, and tap a key to
> wake the display, the wifi strength signal is already there.
[...]
> I don't have an answer to the problem, but disabling Ethernet priority
> with NM is not it.

Indeed, now that I think about it, when I have wired-ethernet connected,
I think both the wired and the wifi connections are setup, so the
priority is presumably doing something else.


        Stefan

[toc] | [prev] | [next] | [standalone]

#225188

Hi,

I have two Debian laptops at home: a Dell E7440 running testing/sid and 
a Lenovo T400 running stable with LibreBoot, both with Gnome and 
NetworkManager.

I think I always had the same issue with the Dell (I had it in 2017 I 
think), while Wi-Fi reconnects immediately with the T400. So in my case 
I suppose it is a hardware issue, either BIOS/UEFI (because I have many 
ACPI errors when booting and resuming on the Dell, and because globally 
this BIOS seems to have not so good quality), either with the Wi-Fi card.

Regards,
Yvan

Le 24/07/2020 à 02:21, Stefan Monnier a écrit :
>>> Somehow NM is convinced that it should try an Ethernet connection
>>> first. You need a way to disabuse it of that notion.
>> Not necessarily. My netbook (stretch with NM) normally uses wires, and
>> that is the priority. I occasionally use wifi at home, and usually when
>> out, and use sleep quite often. When I open the lid, and tap a key to
>> wake the display, the wifi strength signal is already there.
> [...]
>> I don't have an answer to the problem, but disabling Ethernet priority
>> with NM is not it.
> 
> Indeed, now that I think about it, when I have wired-ethernet connected,
> I think both the wired and the wifi connections are setup, so the
> priority is presumably doing something else.
> 
> 
>          Stefan
> 

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web