[SOLVED] WiFi loss upon resume?

_peter · 09-14-2021, 12:13 AM

back to wireless & wired network stability confirmed at my end

Quote:

/var/log/packages/NetworkManager-1.32.10-x86_64-2

thanks

pghvlaans · 09-14-2021, 12:35 AM

Thanks, marav!

ctrlaltca · 09-14-2021, 03:11 AM

Again, this is not solved, and the last patch just made me lol.
NetworkManager checks in its configuration if a dhcp plugin has been explicitly defined.
The list of possible values is here: https://github.com/NetworkManager/Ne...listener.c#L28
The plugin is named "dhcpcd". By adding "--no-configure" to the configuration value, now the value is not one of the valid plugin names, so NetworkManager is now defaulting to using its own internal implementation (that works just fine).
Everybody can just test this by checking that, after the last patch, dhcpcd is not running anymore at all.

The best solution here is to default to the upstream "dhcp=internal" value.
Also a quote from https://github.com/NetworkManager/Ne...manager.c#L95:

Quote:

* So actually, we don't want that complexity. We want to phase out all plugins in favor
* of the internal plugin.

marav · 09-14-2021, 03:43 AM

Quote:

Originally Posted by ctrlaltca

Again, this is not solved, and the last patch just made me lol.
NetworkManager checks in its configuration if a dhcp plugin has been explicitly defined.
The list of possible values is here: https://github.com/NetworkManager/Ne...listener.c#L28
The plugin is named "dhcpcd". By adding "--no-configure" to the configuration value, now the value is not one of the valid plugin names, so NetworkManager is now defaulting to using its own internal implementation (that works just fine).
Everybody can just test this by checking that, after the last patch, dhcpcd is not running anymore at all.

The best solution here is to default to the upstream "dhcp=internal" value.
Also a quote from https://github.com/NetworkManager/Ne...manager.c#L95:

Whatever the result, and you are probably not wrong (dhcp=internal has been mentioned many times in this thread)
and it probably needs further investigations
But rather than getting to the end and laughing, you can also respect those who have been here for 15 days trying to find a solution

ctrlaltca · 09-14-2021, 04:19 AM

I'm sorry you took it personal, didn't want to offend anyone.
I would never laugh at people, but I can laugh at code; in this case i found it funny that introducing a problem actually worked as a workaround for another problem.
FYI I've been here, too, since the second comment in this thread, and the correct solution was already posted on the first page.

marav · 09-14-2021, 04:23 AM

Quote:

Originally Posted by ctrlaltca

I'm sorry you took it personal, didn't want to offend anyone.
I would never laugh at people, but I can laugh at code; in this case i found it funny that introducing a problem actually worked as a workaround for another problem.
FYI I've been here, too, since the second comment in this thread, and the correct solution was already posted on the first page.

Don't worry about it. I didn't take it personally.
It's just a matter of figuring out what's best for Slackware.
We are in the same boat

EDIT:
And I am convinced that the direction taken by the development of NetworkManager tends to free itself, for the DHCP part, of all that does not concern dhcp=internal. As it was mentioned at the beginning

marav · 09-14-2021, 04:39 AM

the fallback to dhcp=internal, as you mentioned, is indeed probable:
- the dhcpcd daemon is not executed
- /var/log/syslog mentions :

Code:

NetworkManager[8840]: <warn> [1631609669.5296] dhcp-init: DHCP client 'dhcpcd --noconfigure' not available

It's indeed "funny" to see that an option recommended by NetworkManager itself is not available...

LuckyCyborg · 09-14-2021, 05:23 AM

Quote:

Originally Posted by marav

the fallback to dhcp=internal, as you mentioned, is indeed probable:
- the dhcpcd daemon is not executed
- /var/log/syslog mentions :

Code:

NetworkManager[8840]: <warn> [1631609669.5296] dhcp-init: DHCP client 'dhcpcd --noconfigure' not available

It's indeed "funny" to see that an option recommended by NetworkManager itself is not available...

Nothing funny - it requests the dhcpd to support this "--noconfigure" option, not it to be added on the plugin name.

In that config file, "dhcpd" means the used plugin name, not the command line to be executed.

pghvlaans · 09-14-2021, 07:53 AM

Quote:

Originally Posted by LuckyCyborg

Nothing funny - it requests the dhcpd to support this "--noconfigure" option, not it to be added on the plugin name.

I'm starting to think that's the tricky part. dhcpcd.conf supports a lot of the command line options (persist, etc.), but apparently not noconfigure. It isn't mentioned in the dhcpcd.conf man page, and I tried putting it into the config file in various combinations (and with nothing else) to no effect. The connection worked until resume, just like before.

The strange thing is that the option is included in a list of options in "if-options.h" with this interesting comment:

Code:

/* These options only make sense in the config file, so don't use any
   valid short options for them */
#define O_BASE			MAX('z', 'Z') + 1
...
...
#define O_NOCONFIGURE		O_BASE + 51

marav · 09-14-2021, 08:51 AM

Quote:

Originally Posted by pghvlaans

I'm starting to think that's the tricky part. dhcpcd.conf supports a lot of the command line options (persist, etc.), but apparently not noconfigure. It isn't mentioned in the dhcpcd.conf man page, and I tried putting it into the config file in various combinations (and with nothing else) to no effect. The connection worked until resume, just like before.

The strange thing is that the option is included in a list of options in "if-options.h" with this interesting comment:

Code:

/* These options only make sense in the config file, so don't use any
   valid short options for them */
#define O_BASE			MAX('z', 'Z') + 1
...
...
#define O_NOCONFIGURE		O_BASE + 51

you also have it in the man page of dhcpcd

Code:

--noconfigure
dhcpcd will not configure the system at all. This is only of use if the --script that dhcpcd calls at each network event configures the system instead.  
This is different from -T, --test mode in that it's not one shot and the only change to the environment is the addition of if_configured=false.

My feeling is:
we have one option that doesn't really work : dhcpcd
(I don't know why, but to be honest I'm a bit tired of looking for it)
and we have another one that does work : internal

we just have to use the one that works

pghvlaans · 09-14-2021, 09:10 AM

Quote:

Originally Posted by marav

we just have to use the one that works

I'd agree with that. The only things I got to (sort of) work vis-a-vis dhcpcd were:

Removing the dhcpcd user (defeats the purpose of privilege separation; leaves zombie processes)
Building dhcpcd with --disable-privsep (ditto)

dhcpcd=internal is a much better solution than either of those.

marav · 09-14-2021, 09:19 AM

Quote:

Originally Posted by LuckyCyborg

Nothing funny - it requests the dhcpd to support this "--noconfigure" option, not it to be added on the plugin name.

In that config file, "dhcpd" means the used plugin name, not the command line to be executed.

indeed
the fallback on internal misled me
but where on earth should we pass this option???

LuckyCyborg · 09-14-2021, 09:29 AM

Quote:

Originally Posted by marav

indeed
the fallback on internal misled me
but where on earth should we pass this option???

It's hardcoded in the NM code and already added.

I would say that we use a dhcpd version or build which is not compatible with the current NetworkManager.

OR, happens that we just use a code path considerably less tested than the one for systemd-dhcpd (believe or not, this thing exists)

I for one, I vote for the "internal" plugin - I use this setup since this issue risen and the results are acceptable, at least for me.

marav · 09-14-2021, 02:37 PM

Can anyone confirm that :

Code:

--- dhcpcd.conf.orig    2021-09-14 21:33:25.897647961 +0200
+++ dhcpcd.conf 2021-09-14 21:31:25.071166956 +0200
@@ -2,7 +2,7 @@
 # See dhcpcd.conf(5) for details.
 
 # Allow users of this group to interact with dhcpcd via the control socket.
-#controlgroup wheel
+controlgroup wheel
 
 # Inform the DHCP server of our hostname for DDNS.
 hostname_short

with :
dhcp=dhcpcd

works after suspend/resume ?

it works for me ...
dhcpcd is running

Code:

dhcpcd   28476  0.0  0.0   3084  1376 ?        S    18:02   0:00 dhcpcd: [master] [ip4] [ip6]
root     28477  0.0  0.0   3224  1400 ?        S    18:02   0:00  \_ dhcpcd: [privileged actioneer]
dhcpcd    4192  0.0  0.0   3224   128 ?        S    21:35   0:00  |   \_ dhcpcd: [BPF ARP] wlan0 192.168.111.15
dhcpcd   28478  0.0  0.0   3004   204 ?        S    18:02   0:00  \_ dhcpcd: [network proxy]
dhcpcd   28479  0.0  0.0   3000    60 ?        S    18:02   0:00  \_ dhcpcd: [control proxy]

LuckyCyborg · 09-14-2021, 02:50 PM

Quote:

Originally Posted by marav

Can anyone confirm that :

Code:

--- dhcpcd.conf.orig    2021-09-14 21:33:25.897647961 +0200
+++ dhcpcd.conf 2021-09-14 21:31:25.071166956 +0200
@@ -2,7 +2,7 @@
 # See dhcpcd.conf(5) for details.
 
 # Allow users of this group to interact with dhcpcd via the control socket.
-#controlgroup wheel
+controlgroup wheel
 
 # Inform the DHCP server of our hostname for DDNS.
 hostname_short

with :
dhcp=dhcpcd

works after suspend/resume ?

it works for me ...
dhcpcd is running

Code:

dhcpcd   28476  0.0  0.0   3084  1376 ?        S    18:02   0:00 dhcpcd: [master] [ip4] [ip6]
root     28477  0.0  0.0   3224  1400 ?        S    18:02   0:00  \_ dhcpcd: [privileged actioneer]
dhcpcd    4192  0.0  0.0   3224   128 ?        S    21:35   0:00  |   \_ dhcpcd: [BPF ARP] wlan0 192.168.111.15
dhcpcd   28478  0.0  0.0   3004   204 ?        S    18:02   0:00  \_ dhcpcd: [network proxy]
dhcpcd   28479  0.0  0.0   3000    60 ?        S    18:02   0:00  \_ dhcpcd: [control proxy]

Your unprivileged user is part of "wheel" group? That's not that usual on Slackware.