[gentoo-user] [systemd] Is this a NetworkManager bug?

[gentoo-user] [systemd] Is this a NetworkManager bug?

[walt]

I just switched my home LAN from wired to all wifi and I'm having trouble
with NetworkManager at boot time.

I have systemd start NetworkManager at boot because I need the internet
for ntpdate and to start the nfs server for the LAN.  Before I switched
to all-wireless this method worked perfectly, but no longer.

After bootup I see that NetworkManager started wpa_supplicant in the
background, but apparently does *not* run dhcpcd.  (The wlan0 is up
but it has no IP address and the routing table is empty.)

As an alternative to NetworkManager I can have systemd start dhcpcd
at boot, which almost (but not quite) works well enough.  This
causes a race condition because wlan0 takes several seconds to come
up properly and by then both ntpdate and nfs-server have already
run and failed.

So, I asked myself, why not have systemd start dhcpcd at boot in
addition to NetworkManager?

The reason that fails is that they both start wpa_supplicant in
the background and the two instances interfere with each other.

Anyone see a way around this catch22?


Thanks.

Re: [gentoo-user] [systemd] Is this a NetworkManager bug?

[Canek Peláez Valdés]

On Mon, Oct 13, 2014 at 6:39 PM, walt <w41ter@gmail.com> wrote:
> I just switched my home LAN from wired to all wifi and I'm having trouble
> with NetworkManager at boot time.
>
> I have systemd start NetworkManager at boot because I need the internet
> for ntpdate and to start the nfs server for the LAN.  Before I switched
> to all-wireless this method worked perfectly, but no longer.
>
> After bootup I see that NetworkManager started wpa_supplicant in the
> background, but apparently does *not* run dhcpcd.  (The wlan0 is up
> but it has no IP address and the routing table is empty.)

Do you have a system-wide connection for the wireless network? They
live in /etc/NetworkManager/system-connections. Also, what does "nmcli
-p general" says? In my case is:

centurion ~ # nmcli -p general
=============================================================
                    NetworkManager status
=============================================================
STATE      CONNECTIVITY  WIFI-HW  WIFI     WWAN-HW  WWAN
-------------------------------------------------------------
connected  full          enabled  enabled  enabled  enabled

> As an alternative to NetworkManager I can have systemd start dhcpcd
> at boot, which almost (but not quite) works well enough.  This
> causes a race condition because wlan0 takes several seconds to come
> up properly and by then both ntpdate and nfs-server have already
> run and failed.
>
> So, I asked myself, why not have systemd start dhcpcd at boot in
> addition to NetworkManager?

NetworkManager starts wpa_supplicant, but it does *NOT* use
wpa_supplicant.conf. If you do

systemctl status wpa_supplicant.service

you will see that wpa_supplicant runs with the "-u" flag; that enables
the DBus control interface, and it's through this that NetworkManager
controls wpa_supplicant. If you do not  have system-wide connections,
NM will ask wpa_supplicant to *not* enable any connection. NM calls
the shots in this case.

> The reason that fails is that they both start wpa_supplicant in
> the background and the two instances interfere with each other.
>
> Anyone see a way around this catch22?

If I'm not mistaken, you need a system-wide NM connection enabled. You
can use nm-connection-editor (included with nm-applet), or nmtui
(ncurses interface since 0.9.10.0).

Also, and orthogonal to almost all of this; I switched from ntp to
systemd-timesyncd, and it works *great*, specially in my laptop. With
my laptop, changing networks all the time, ntpd never quite worked.

Regards.
-- 
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-user] [systemd] Is this a NetworkManager bug?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 697 bytes --]

On Mon, 13 Oct 2014 16:39:18 -0700, walt wrote:

> I just switched my home LAN from wired to all wifi and I'm having
> trouble with NetworkManager at boot time.
> 
> I have systemd start NetworkManager at boot because I need the internet
> for ntpdate and to start the nfs server for the LAN.  Before I switched
> to all-wireless this method worked perfectly, but no longer.

If you only connect to a limited number of networks, you can do without NM
and let systemd-networkd handle it all for you.

https://bbs.archlinux.org/viewtopic.php?id=178625

For roaming, a network manager of some type is still preferable.


-- 
Neil Bothwick

Tact is the intelligence of the heart.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[gentoo-user] Re: [systemd] Is this a NetworkManager bug?

[walt]

On 10/13/2014 04:56 PM, Canek Peláez Valdés wrote:
> On Mon, Oct 13, 2014 at 6:39 PM, walt <w41ter@gmail.com> wrote:
>> I just switched my home LAN from wired to all wifi and I'm having trouble
>> with NetworkManager at boot time.
>>
>> I have systemd start NetworkManager at boot because I need the internet
>> for ntpdate and to start the nfs server for the LAN.  Before I switched
>> to all-wireless this method worked perfectly, but no longer.
>>
>> After bootup I see that NetworkManager started wpa_supplicant in the
>> background, but apparently does *not* run dhcpcd.  (The wlan0 is up
>> but it has no IP address and the routing table is empty.)
> 
> Do you have a system-wide connection for the wireless network? They
> live in /etc/NetworkManager/system-connections. Also, what does "nmcli
> -p general" says? In my case is:
> 
> centurion ~ # nmcli -p general
> =============================================================
>                     NetworkManager status
> =============================================================
> STATE      CONNECTIVITY  WIFI-HW  WIFI     WWAN-HW  WWAN
> -------------------------------------------------------------
> connected  full          enabled  enabled  enabled  enabled
> 
>> As an alternative to NetworkManager I can have systemd start dhcpcd
>> at boot, which almost (but not quite) works well enough.  This
>> causes a race condition because wlan0 takes several seconds to come
>> up properly and by then both ntpdate and nfs-server have already
>> run and failed.
>>
>> So, I asked myself, why not have systemd start dhcpcd at boot in
>> addition to NetworkManager?
> 
> NetworkManager starts wpa_supplicant, but it does *NOT* use
> wpa_supplicant.conf. If you do
> 
> systemctl status wpa_supplicant.service
> 
> you will see that wpa_supplicant runs with the "-u" flag; that enables
> the DBus control interface, and it's through this that NetworkManager
> controls wpa_supplicant. If you do not  have system-wide connections,
> NM will ask wpa_supplicant to *not* enable any connection. NM calls
> the shots in this case.
> 
>> The reason that fails is that they both start wpa_supplicant in
>> the background and the two instances interfere with each other.
>>
>> Anyone see a way around this catch22?
> 
> If I'm not mistaken, you need a system-wide NM connection enabled. You
> can use nm-connection-editor (included with nm-applet), or nmtui
> (ncurses interface since 0.9.10.0).
> 
> Also, and orthogonal to almost all of this; I switched from ntp to
> systemd-timesyncd, and it works *great*, specially in my laptop. With
> my laptop, changing networks all the time, ntpd never quite worked.

Lots of great information, thanks.  What I learned while following up
on your hints is that the NM behavior I thought was a bug is merely
a feature ;)

After boot, but before startx, wlan0 exists but is not properly set
up.  After X is running I can use the nm-applet to click on the name
of my wireless network and *then* NM runs dhcpcd to configure wlan0
and set up the routing table.  It works, but I need to do that manually
after every boot, not really optimal for my purpose.

I tried Neil's suggestion to use systemd-networkd and it works perfectly
for this (desktop) machine.  (BTW enabling systemd-networkd also pulls
in systemd-timesyncd, which works great, just as you said.)

Great advice Canek and Neil, and very much appreciated.

Re: [gentoo-user] Re: [systemd] Is this a NetworkManager bug?

[Canek Peláez Valdés]

On Tue, Oct 14, 2014 at 5:48 PM, walt <w41ter@gmail.com> wrote:
[ snip ]
> Lots of great information, thanks.  What I learned while following up
> on your hints is that the NM behavior I thought was a bug is merely
> a feature ;)
>
> After boot, but before startx, wlan0 exists but is not properly set
> up.  After X is running I can use the nm-applet to click on the name
> of my wireless network and *then* NM runs dhcpcd to configure wlan0
> and set up the routing table.  It works, but I need to do that manually
> after every boot, not really optimal for my purpose.

I've seen this behavior before (that you need to manually "enable" the
wireless connection), but never on my machines. On my two wireless
systems (laptop and desktop), NM enables the connection by default. I
don't think I did anything special for this to happen, it just does.

> I tried Neil's suggestion to use systemd-networkd and it works perfectly
> for this (desktop) machine.  (BTW enabling systemd-networkd also pulls
> in systemd-timesyncd, which works great, just as you said.)

Good to know.

Regards.
-- 
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-user] Re: [systemd] Is this a NetworkManager bug?

[Jc García]

2014-10-14 16:54 GMT-06:00 Canek Peláez Valdés <caneko@gmail.com>:
> On Tue, Oct 14, 2014 at 5:48 PM, walt <w41ter@gmail.com> wrote:
> [ snip ]
>> Lots of great information, thanks.  What I learned while following up
>> on your hints is that the NM behavior I thought was a bug is merely
>> a feature ;)
>>
>> After boot, but before startx, wlan0 exists but is not properly set
>> up.  After X is running I can use the nm-applet to click on the name
>> of my wireless network and *then* NM runs dhcpcd to configure wlan0
>> and set up the routing table.  It works, but I need to do that manually
>> after every boot, not really optimal for my purpose.
>
I had this problem, but, with a Ethernet connection, I wanted NM to
connect it via dhcp at boot, but didn't happen, and the same as you,
once logged-in just 2 clicks and the connection worked, after digging
a little the configs, I found, somehow this line got into my
/etc/NetworkManager/NetworkManager.conf
no-auto-default=p2p1
I removed that and now It works as it should, maybe something like
this is your problem.

> I've seen this behavior before (that you need to manually "enable" the
> wireless connection), but never on my machines. On my two wireless
> systems (laptop and desktop), NM enables the connection by default. I
> don't think I did anything special for this to happen, it just does.
>
>> I tried Neil's suggestion to use systemd-networkd and it works perfectly
>> for this (desktop) machine.  (BTW enabling systemd-networkd also pulls
>> in systemd-timesyncd, which works great, just as you said.)
>
> Good to know.
>
> Regards.
> --
> Canek Peláez Valdés
> Profesor de asignatura, Facultad de Ciencias
> Universidad Nacional Autónoma de México
>

Re: [gentoo-user] [systemd] Is this a NetworkManager bug?

[Tom H]

On Mon, Oct 13, 2014 at 7:39 PM, walt <w41ter@gmail.com> wrote:
>
> I just switched my home LAN from wired to all wifi and I'm having trouble
> with NetworkManager at boot time.
>
> I have systemd start NetworkManager at boot because I need the internet
> for ntpdate and to start the nfs server for the LAN. Before I switched
> to all-wireless this method worked perfectly, but no longer.
>
> After bootup I see that NetworkManager started wpa_supplicant in the
> background, but apparently does *not* run dhcpcd. (The wlan0 is up
> but it has no IP address and the routing table is empty.)
>
> As an alternative to NetworkManager I can have systemd start dhcpcd
> at boot, which almost (but not quite) works well enough. This
> causes a race condition because wlan0 takes several seconds to come
> up properly and by then both ntpdate and nfs-server have already
> run and failed.
>
> So, I asked myself, why not have systemd start dhcpcd at boot in
> addition to NetworkManager?
>
> The reason that fails is that they both start wpa_supplicant in
> the background and the two instances interfere with each other.
>
> Anyone see a way around this catch22?

Do you have "All users may connect" unticked in the NM applet or
"permissions=user:walt:;" in the NM connection's config?

[gentoo-user] Re: [systemd] Is this a NetworkManager bug?

[walt]

On 10/15/2014 08:23 PM, Tom H wrote:
> On Mon, Oct 13, 2014 at 7:39 PM, walt <w41ter@gmail.com> wrote:
>>
>> I just switched my home LAN from wired to all wifi and I'm having trouble
>> with NetworkManager at boot time.
>>
>> I have systemd start NetworkManager at boot because I need the internet
>> for ntpdate and to start the nfs server for the LAN. Before I switched
>> to all-wireless this method worked perfectly, but no longer.
>>
>> After bootup I see that NetworkManager started wpa_supplicant in the
>> background, but apparently does *not* run dhcpcd. (The wlan0 is up
>> but it has no IP address and the routing table is empty.)
>>
>> As an alternative to NetworkManager I can have systemd start dhcpcd
>> at boot, which almost (but not quite) works well enough. This
>> causes a race condition because wlan0 takes several seconds to come
>> up properly and by then both ntpdate and nfs-server have already
>> run and failed.
>>
>> So, I asked myself, why not have systemd start dhcpcd at boot in
>> addition to NetworkManager?
>>
>> The reason that fails is that they both start wpa_supplicant in
>> the background and the two instances interfere with each other.
>>
>> Anyone see a way around this catch22?
> 
> Do you have "All users may connect" unticked in the NM applet or
> "permissions=user:walt:;" in the NM connection's config?

After studying the logs I'm beginning to think that NM is actually
trying to start wlan0 at boot time but failing with this message:
'no secrets', which I assume means no password, maybe?

Yes, I do have the all-users box ticked.  Question:  I've set up the
wlan0 connection (as root) several times using nmtui, including the
SSID password, yet each time I start nmtui the password field is blank
again.  Is this normal behavior?  How can I tell if the password is
actually being stored somewhere?

Thanks.

Re: [gentoo-user] Re: [systemd] Is this a NetworkManager bug?

[Canek Peláez Valdés]

On Thu, Oct 16, 2014 at 3:53 PM, walt <w41ter@gmail.com> wrote:
> On 10/15/2014 08:23 PM, Tom H wrote:
>> On Mon, Oct 13, 2014 at 7:39 PM, walt <w41ter@gmail.com> wrote:
>>>
>>> I just switched my home LAN from wired to all wifi and I'm having trouble
>>> with NetworkManager at boot time.
>>>
>>> I have systemd start NetworkManager at boot because I need the internet
>>> for ntpdate and to start the nfs server for the LAN. Before I switched
>>> to all-wireless this method worked perfectly, but no longer.
>>>
>>> After bootup I see that NetworkManager started wpa_supplicant in the
>>> background, but apparently does *not* run dhcpcd. (The wlan0 is up
>>> but it has no IP address and the routing table is empty.)
>>>
>>> As an alternative to NetworkManager I can have systemd start dhcpcd
>>> at boot, which almost (but not quite) works well enough. This
>>> causes a race condition because wlan0 takes several seconds to come
>>> up properly and by then both ntpdate and nfs-server have already
>>> run and failed.
>>>
>>> So, I asked myself, why not have systemd start dhcpcd at boot in
>>> addition to NetworkManager?
>>>
>>> The reason that fails is that they both start wpa_supplicant in
>>> the background and the two instances interfere with each other.
>>>
>>> Anyone see a way around this catch22?
>>
>> Do you have "All users may connect" unticked in the NM applet or
>> "permissions=user:walt:;" in the NM connection's config?
>
> After studying the logs I'm beginning to think that NM is actually
> trying to start wlan0 at boot time but failing with this message:
> 'no secrets', which I assume means no password, maybe?
>
> Yes, I do have the all-users box ticked.  Question:  I've set up the
> wlan0 connection (as root) several times using nmtui, including the
> SSID password, yet each time I start nmtui the password field is blank
> again.  Is this normal behavior?  How can I tell if the password is
> actually being stored somewhere?

As I said some messages ago, check:

/etc/NetworkManager/system-connections

In that directory should be all the system-wide network
configurations. Also, check

/etc/NetworkManager/NetworkManager.conf

and make sure you have "plugins=keyfile" in the "[main]" section. At
some point NM had integration with the OpenRC network configuration,
and (AFAIR) sometimes it made a mess inside /etc/conf.d. I don't know
if such integration exists anymore; nowadays I don't even have
/etc/{conf,init}.d, and everything works so much better.

Regards.
-- 
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-user] Re: [systemd] Is this a NetworkManager bug?

[Tom H]

On Thu, Oct 16, 2014 at 4:53 PM, walt <w41ter@gmail.com> wrote:
> On 10/15/2014 08:23 PM, Tom H wrote:
>> On Mon, Oct 13, 2014 at 7:39 PM, walt <w41ter@gmail.com> wrote:
>>>
>>> I just switched my home LAN from wired to all wifi and I'm having trouble
>>> with NetworkManager at boot time.
>>>
>>> I have systemd start NetworkManager at boot because I need the internet
>>> for ntpdate and to start the nfs server for the LAN. Before I switched
>>> to all-wireless this method worked perfectly, but no longer.
>>>
>>> After bootup I see that NetworkManager started wpa_supplicant in the
>>> background, but apparently does *not* run dhcpcd. (The wlan0 is up
>>> but it has no IP address and the routing table is empty.)
>>>
>>> As an alternative to NetworkManager I can have systemd start dhcpcd
>>> at boot, which almost (but not quite) works well enough. This
>>> causes a race condition because wlan0 takes several seconds to come
>>> up properly and by then both ntpdate and nfs-server have already
>>> run and failed.
>>>
>>> So, I asked myself, why not have systemd start dhcpcd at boot in
>>> addition to NetworkManager?
>>>
>>> The reason that fails is that they both start wpa_supplicant in
>>> the background and the two instances interfere with each other.
>>>
>>> Anyone see a way around this catch22?
>>
>> Do you have "All users may connect" unticked in the NM applet or
>> "permissions=user:walt:;" in the NM connection's config?
>
> After studying the logs I'm beginning to think that NM is actually
> trying to start wlan0 at boot time but failing with this message:
> 'no secrets', which I assume means no password, maybe?
>
> Yes, I do have the all-users box ticked. Question: I've set up the
> wlan0 connection (as root) several times using nmtui, including the
> SSID password, yet each time I start nmtui the password field is blank
> again. Is this normal behavior? How can I tell if the password is
> actually being stored somewhere?

I've never used nmtui (I didn't even know about it).

This the config that I use when i visit my parents (I use a static
address at home so this corresponds to your use-case). It has to be in
0600 mode for NM to use it.

# cat /etc/NetworkManager/system-connections/mumdad
[connection]
id=mumdad
uuid=da59ada3-1349-49fe-b63b-bc68f67b6f89
type=802-11-wireless

[802-11-wireless]
ssid=number96
mode=infrastructure
security=802-11-wireless-security

[802-11-wireless-security]
key-mgmt=wpa-psk
psk=xxxxxxxxx

[ipv4]
method=auto
dns=8.8.8.8;8.8.4.4;

[ipv6]
method=link-local

You have to have "plugins=keyfile" in the "[main]" section of
"/etc/NetworkManager/NetworkManager.conf" for the above to work.

[gentoo-user] Re: [systemd] Is this a NetworkManager bug?

[walt]

On 10/16/2014 04:34 PM, Canek Peláez Valdés wrote:
> At
> some point NM had integration with the OpenRC network configuration,
> and (AFAIR) sometimes it made a mess inside /etc/conf.d. I don't know
> if such integration exists anymore; nowadays I don't even have
> /etc/{conf,init}.d, and everything works so much better.

Bingo.  I renamed conf.d and init.d and now NM works perfectly during
bootup.  Now that you mention it, journalctl did print messages about
/etc/init.d  and I thought it was a bit strange.

Thanks Canek and Tom for the excellent help.

Re: [gentoo-user] Re: [systemd] Is this a NetworkManager bug?

[Canek Peláez Valdés]

Be aware that /etc/init.d/functions.sh is still required by a lot of
things (gcc-config, python-updater, perl-cleaner, stuff like
that).They are trying to move that file to a more reasonable location;
I expect it to be done in five or six years.

Regards.

On Fri, Oct 17, 2014 at 10:00 AM, walt <w41ter@gmail.com> wrote:
> On 10/16/2014 04:34 PM, Canek Peláez Valdés wrote:
>> At
>> some point NM had integration with the OpenRC network configuration,
>> and (AFAIR) sometimes it made a mess inside /etc/conf.d. I don't know
>> if such integration exists anymore; nowadays I don't even have
>> /etc/{conf,init}.d, and everything works so much better.
>
> Bingo.  I renamed conf.d and init.d and now NM works perfectly during
> bootup.  Now that you mention it, journalctl did print messages about
> /etc/init.d  and I thought it was a bit strange.
>
> Thanks Canek and Tom for the excellent help.
>
>
>



-- 
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-user] Re: [systemd] Is this a NetworkManager bug?

[Rich Freeman]

On Fri, Oct 17, 2014 at 11:18 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> Be aware that /etc/init.d/functions.sh is still required by a lot of
> things (gcc-config, python-updater, perl-cleaner, stuff like
> that).They are trying to move that file to a more reasonable location;
> I expect it to be done in five or six years.

FYI - patches are welcome on that.  I suspect that at some time we'll
start pushing them through if maintainers drag their feet.  This
should be a pretty easy/safe change, but obviously we want to be
careful since it seems to be fairly important packages that abuse this
file.

Once this is done users should be able to remove openrc safely if they
aren't using it.  At that point we might take up whether it makes
sense to just make the init system like the
bootloader/syslog/cron/kernel/etc in the handbook and have the user
choose which one they want.

--
Rich

Re: [gentoo-user] Re: [systemd] Is this a NetworkManager bug?

[Canek Peláez Valdés]

On Fri, Oct 17, 2014 at 12:14 PM, Rich Freeman <rich0@gentoo.org> wrote:
> On Fri, Oct 17, 2014 at 11:18 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>> Be aware that /etc/init.d/functions.sh is still required by a lot of
>> things (gcc-config, python-updater, perl-cleaner, stuff like
>> that).They are trying to move that file to a more reasonable location;
>> I expect it to be done in five or six years.
>
> FYI - patches are welcome on that.  I suspect that at some time we'll
> start pushing them through if maintainers drag their feet.  This
> should be a pretty easy/safe change, but obviously we want to be
> careful since it seems to be fairly important packages that abuse this
> file.

There is a tracker bug for the packages still sourcing
/etc/init.d/functions.sh, instead of /lib/gentoo/functions.sh:

https://bugs.gentoo.org/show_bug.cgi?id=504116

My comment was tongue-in-cheek, although the change has taken years already.

> Once this is done users should be able to remove openrc safely if they
> aren't using it.  At that point we might take up whether it makes
> sense to just make the init system like the
> bootloader/syslog/cron/kernel/etc in the handbook and have the user
> choose which one they want.

Looking forward to that.

Regards.
-- 
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México