Re: [systemd-devel] throw routes are getting removed when networkd is restarted

2021-12-22 Thread Anita Zhang
Are these throw routes managed by systemd-networkd (i.e. there's a
corresponding .network file for them)? I'm guessing there is not and that
StrongSwan is managing them separately. systemd-networkd by default will
remove unmanaged routes unless told otherwise. There are two settings that
can prevent this, KeepConfiguration= (from the systemd.network man page)
and ManageForeignRoutingPolicyRules=/ManageForeignRoutes= (from the
networkd.conf man page).

Hope that helps,
Anita


On Tue, Dec 21, 2021 at 2:57 AM Robert Dahlem  wrote:

> Hi,
>
> I'm running on Debian Bullseye, systemd 247.
>
> StrongSwan 5.9.1 (an IPsec implementation) establishes throw routes in
> table 220 when activating the bypass-lan plugin.
>
> Basically that means: you have a VPN tunnel giving you a prioritized
> default route through the VPN gateway but you can still reach systems in
> local networks. It looks like this:
>
> # ip a
> ...
> 2: ens18:  mtu 1500 qdisc pfifo_fast
> state UP group default qlen 1000
>  ...
>  inet 192.168.1.160/24 brd 192.168.1.255 scope global dynamic ens18
>  inet 172.29.254.11/32 scope global ens18
> 3: ens19:  mtu 1500 qdisc pfifo_fast
> state UP group default qlen 1000
>  ...
>  inet 192.168.180.2/24 brd 192.168.180.255 scope global ens19
> 4: vmbr1:  mtu 1500 qdisc noqueue state
> UP group default qlen 1000
>  inet 10.10.10.1/24 brd 10.10.10.255 scope global vmbr1
>  ...
> # ip rule
> 0:  from all lookup local
> 220:from all lookup 220
> 32766:  from all lookup main
> 32767:  from all lookup default
> # ip route sh table 220
> default via 192.168.1.1 dev ens18 proto static src 172.29.254.11
> throw 10.10.10.0/24 proto static
> throw 192.168.1.0/24 proto static
> throw 192.168.180.0/24 proto static
>
> Any outgoing traffic goes through table 220 where the default route
> points to the VPN tunnel. Without the throw routes traffic for local
> networks would be sent through the VPN tunnel too.
>
> Now the problem: when I restart networkd, the throw routes get removed:
>
> # systemctl restart systemd-networkd
> # ip route sh table 220
> default via 192.168.1.1 dev ens18 proto static src 172.29.254.11
>
> Of course now I can no longer reach the local networks.
>
> I run networkd with "Environment=SYSTEMD_LOG_LEVEL=debug", so I get this
> in the log:
>
> # grep throw /var/log/syslog  | cut -d " " -f 6- | grep -v lo: \
> | sed 's!src: n/a, gw: n/a, prefsrc: n/a, scope: global, !!'
> Remembering route: dst: 192.168.180.0/24, table: 220, proto: static,
> type: throw
> Remembering route: dst: 192.168.1.0/24, table: 220, proto: static, type:
> throw
> Remembering route: dst: 10.10.10.0/24, table: 220, proto: static, type:
> throw
> Removing route: dst: 192.168.180.0/24, table: 220, proto: static, type:
> throw
> Removing route: dst: 10.10.10.0/24, table: 220, proto: static, type: throw
> Removing route: dst: 192.168.1.0/24, table: 220, proto: static, type:
> throw
> Removing route: dst: 192.168.180.0/24, table: 220, proto: static, type:
> throw
> Removing route: dst: 10.10.10.0/24, table: 220, proto: static, type: throw
> Removing route: dst: 192.168.1.0/24, table: 220, proto: static, type:
> throw
> Removing route: dst: 192.168.180.0/24, table: 220, proto: static, type:
> throw
> Removing route: dst: 10.10.10.0/24, table: 220, proto: static, type: throw
> Removing route: dst: 192.168.1.0/24, table: 220, proto: static, type:
> throw
> Forgetting route: dst: 192.168.180.0/24, table: 220, proto: static,
> type: throw
> Forgetting route: dst: 10.10.10.0/24, table: 220, proto: static, type:
> throw
> Forgetting route: dst: 192.168.1.0/24, table: 220, proto: static, type:
> throw
>
> At first, networkd remembers the throw routes, then it removes and
> forgets them. Why is that and how can I prevent it from doing so?
>
> (Actually, the problem is a bit more complex and has to do with
> disappearing throw routes when interfaces come up "late", i.e. WIFI
> interfaces. I tried to show the behavior in a simple test case.)
>
> Regards,
> Robert
>


Re: [systemd-devel] systemd-timesyncd

2021-12-22 Thread Anita Zhang
This was reported and fixed here:
https://github.com/systemd/systemd/issues/20482

Best,
Anita


On Tue, Dec 7, 2021 at 2:47 PM Scott Andrews 
wrote:

>
> This is my first forage into systemd and I need some help fixing this
> problem.  I would like to use timesyncd instead of ntp.
> I searched online and didn't find anything helpful.
>
> Using systemd-249
>
> systemd-timesyncd[246]: Error receiving message, disconnecting:
> Exchange full
>
> Is there a better list/place to inquire about errors like these?
>
> Thanks
> --
> CPE1704TKS
>


Re: [systemd-devel] throw routes are getting removed when networkd is restarted

2021-12-22 Thread Robert Dahlem

Anita,

it helped to configure

[Network]
ManageForeignRoutes=no

Thank you!

Regards,
Robert


On 22.12.2021 09:05, Anita Zhang wrote:

Are these throw routes managed by systemd-networkd (i.e. there's a
corresponding .network file for them)? I'm guessing there is not and
that StrongSwan is managing them separately. systemd-networkd by default
will remove unmanaged routes unless told otherwise. There are two
settings that can prevent this, KeepConfiguration= (from the
systemd.network man page)
and ManageForeignRoutingPolicyRules=/ManageForeignRoutes= (from the
networkd.conf man page).

Hope that helps,
Anita


On Tue, Dec 21, 2021 at 2:57 AM Robert Dahlem mailto:robert.dah...@gmx.net>> wrote:

Hi,

I'm running on Debian Bullseye, systemd 247.

StrongSwan 5.9.1 (an IPsec implementation) establishes throw routes in
table 220 when activating the bypass-lan plugin.

Basically that means: you have a VPN tunnel giving you a prioritized
default route through the VPN gateway but you can still reach systems in
local networks. It looks like this:

# ip a
...
2: ens18:  mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
      ...
      inet 192.168.1.160/24  brd
192.168.1.255 scope global dynamic ens18
      inet 172.29.254.11/32  scope global ens18
3: ens19:  mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
      ...
      inet 192.168.180.2/24  brd
192.168.180.255 scope global ens19
4: vmbr1:  mtu 1500 qdisc noqueue state
UP group default qlen 1000
      inet 10.10.10.1/24  brd 10.10.10.255
scope global vmbr1
      ...
# ip rule
0:      from all lookup local
220:    from all lookup 220
32766:  from all lookup main
32767:  from all lookup default
# ip route sh table 220
default via 192.168.1.1 dev ens18 proto static src 172.29.254.11
throw 10.10.10.0/24  proto static
throw 192.168.1.0/24  proto static
throw 192.168.180.0/24  proto static

Any outgoing traffic goes through table 220 where the default route
points to the VPN tunnel. Without the throw routes traffic for local
networks would be sent through the VPN tunnel too.

Now the problem: when I restart networkd, the throw routes get removed:

# systemctl restart systemd-networkd
# ip route sh table 220
default via 192.168.1.1 dev ens18 proto static src 172.29.254.11

Of course now I can no longer reach the local networks.

I run networkd with "Environment=SYSTEMD_LOG_LEVEL=debug", so I get this
in the log:

# grep throw /var/log/syslog  | cut -d " " -f 6- | grep -v lo: \
| sed 's!src: n/a, gw: n/a, prefsrc: n/a, scope: global, !!'
Remembering route: dst: 192.168.180.0/24 ,
table: 220, proto: static,
type: throw
Remembering route: dst: 192.168.1.0/24 ,
table: 220, proto: static, type:
throw
Remembering route: dst: 10.10.10.0/24 , table:
220, proto: static, type:
throw
Removing route: dst: 192.168.180.0/24 ,
table: 220, proto: static, type:
throw
Removing route: dst: 10.10.10.0/24 , table:
220, proto: static, type: throw
Removing route: dst: 192.168.1.0/24 , table:
220, proto: static, type: throw
Removing route: dst: 192.168.180.0/24 ,
table: 220, proto: static, type:
throw
Removing route: dst: 10.10.10.0/24 , table:
220, proto: static, type: throw
Removing route: dst: 192.168.1.0/24 , table:
220, proto: static, type: throw
Removing route: dst: 192.168.180.0/24 ,
table: 220, proto: static, type:
throw
Removing route: dst: 10.10.10.0/24 , table:
220, proto: static, type: throw
Removing route: dst: 192.168.1.0/24 , table:
220, proto: static, type: throw
Forgetting route: dst: 192.168.180.0/24 ,
table: 220, proto: static,
type: throw
Forgetting route: dst: 10.10.10.0/24 , table:
220, proto: static, type: throw
Forgetting route: dst: 192.168.1.0/24 ,
table: 220, proto: static, type:
throw

At first, networkd remembers the throw routes, then it removes and
forgets them. Why is that and how can I prevent it from doing so?

(Actually, the problem is a bit more complex and has to do with
disappearing throw routes when interfaces come up "late", i.e. WIFI
interfaces. I tried to show the behavior in a simple test case.)

Regards,
Robert



Re: [systemd-devel] After= and Wants= doesn't seem to have an effect

2021-12-22 Thread Christopher Wong
The code is being run on systemd 247.6. I finally got some debug logs to share 
(see below). The starting of opticsd.service is held back, waiting for 
temperature-controller.service, which is good. However, the line right after: 
Job 721, which is a stop job for temperature-controller finished with 
result=done. That seems to trigger the continuation of opticsd.service. I don't 
have the logs for when Job 107 was started and why Job 721 is created. My guess 
is that temperature-controller is waiting for coco-wiper-manager as indicated 
in Job 722 and Job 809. Could this really be a bug and I am that lucky to 
stumble into it?


Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: Got message type=method_call 
sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 
interface=org.freedesktop.systemd1.Manager member=StopUnit cookie=1 
reply_cookie=0 signature=ss error-name=n/a error-message=n/a
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: temperature-controller.service: 
Trying to enqueue job temperature-controller.service/stop/replace
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: Added job 
temperature-controller.service/stop to transaction.
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: temperature-controller.service: 
Job 107 temperature-controller.service/start finished, result=canceled
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: Sent message type=signal 
sender=org.freedesktop.systemd1 destination=n/a path=/org/freedesktop/systemd1 
interface=org.freedesktop.systemd1.Manager member=JobRemoved cookie=1 
reply_cookie=0 signature=uoss error-name=n/a error-message=n/a
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: temperature-controller.service: 
Installed new job temperature-controller.service/stop as 721
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: temperature-controller.service: 
Enqueued job temperature-controller.service/stop as 721
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: Sent message type=signal 
sender=org.freedesktop.systemd1 destination=n/a 
path=/org/freedesktop/systemd1/unit/temperature_2dcontroller_2eservice 
interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=2 
reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: Sent message type=signal 
sender=org.freedesktop.systemd1 destination=n/a 
path=/org/freedesktop/systemd1/unit/temperature_2dcontroller_2eservice 
interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=3 
reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: Sent message type=signal 
sender=org.freedesktop.systemd1 destination=n/a path=/org/freedesktop/systemd1 
interface=org.freedesktop.systemd1.Manager member=JobNew cookie=4 
reply_cookie=0 signature=uos error-name=n/a error-message=n/a
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: Sent message type=method_return 
sender=org.freedesktop.systemd1 destination=n/a path=n/a interface=n/a 
member=n/a cookie=5 reply_cookie=1 signature=o error-name=n/a error-message=n/a
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: opticsd.service: starting held 
back, waiting for: temperature-controller.service
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: temperature-controller.service: 
Job 721 temperature-controller.service/stop finished, result=done
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: Sent message type=signal 
sender=org.freedesktop.systemd1 destination=n/a path=/org/freedesktop/systemd1 
interface=org.freedesktop.systemd1.Manager member=JobRemoved cookie=6 
reply_cookie=0 signature=uoss error-name=n/a error-message=n/a
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: Failed to read pids.max attribute 
of cgroup root, ignoring: No data available
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: opticsd.service: Forked 
/usr/bin/udevadm as 561
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: Sent message type=signal 
sender=org.freedesktop.systemd1 destination=n/a 
path=/org/freedesktop/systemd1/unit/opticsd_2eservice 
interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=7 
reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: Sent message type=signal 
sender=org.freedesktop.systemd1 destination=n/a 
path=/org/freedesktop/systemd1/unit/opticsd_2eservice 
interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=8 
reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: opticsd.service: Changed dead -> 
start-pre
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: Starting Optics daemon...
...


Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: Keeping job 
coco-wiper-manager.service/start because of temperature-controller.service/start
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: temperature-controller.service: 
Installed new job temperature-controller.service/start as 722
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: temperature