Discussion:
Bouncing interface once chrony is synced
(too old to reply)
Ian Pilcher
2017-07-05 15:29:21 UTC
Permalink
Raw Message
I am using CentOS 7 (systemd 219) on a Banana Pi as my residential
firewall/gateway. The Banana Pi does not have a persistent clock, so
it has no idea what the time is until it is able to sync via NTP. Thus,
the initial DHCP leases that the BPi receives have incorrect expiration/
renewal times (since the system can't sync via NTP before it has an IP
address - chicken and egg).

My first attempt to address this was to add a drop-in to
chrony-wait.service that bounces the WAN interface.

/etc/systemd/system/chrony-wait.service.d/bounce-wan.conf:

# Bounce the WAN interface once time is synced, ensuring that
# DHCP leases have proper expiration/refresh times.

[Service]
ExecStartPost=/usr/sbin/ifdown eth0.256
ExecStartPost=/usr/sbin/ifup eth0.256

This does bounce the interface at boot time:

Dec 31 18:00:18 firewall.penurio.us systemd[1]: Starting Wait for
chrony to synchronize system clock...
Jul 04 13:05:07 firewall.penurio.us dhclient[1336]: DHCPDISCOVER on
eth0.256 to 255.255.255.255 port 67 interval 8 (xid=0x38c8bfa7)
Jul 04 13:05:07 firewall.penurio.us dhclient[1336]: DHCPREQUEST on
eth0.256 to 255.255.255.255 port 67 (xid=0x38c8bfa7)
Jul 04 13:05:07 firewall.penurio.us dhclient[1336]: DHCPOFFER from
70.119.128.1
Jul 04 13:05:07 firewall.penurio.us dhclient[1336]: DHCPACK from
70.119.128.1 (xid=0x38c8bfa7)
Jul 04 13:05:10 firewall.penurio.us dhclient[1336]: bound to
70.119.136.2 -- renewal in 23274 seconds.
Jul 04 13:05:11 firewall.penurio.us dhclient[1431]: PRC: Previous
lease is devoid of active addresses. Re-initializing.
Jul 04 13:05:11 firewall.penurio.us dhclient[1431]: XMT: Solicit on
eth0.256, interval 1010ms.
Jul 04 13:05:11 firewall.penurio.us dhclient[1431]: RCV: Advertise
message on eth0.256 from fe80::201:5cff:fe77:bc46.
Jul 04 13:05:11 firewall.penurio.us dhclient[1431]: XMT: Request on
eth0.256, interval 940ms.
Jul 04 13:05:11 firewall.penurio.us dhclient[1431]: RCV: Advertise
message on eth0.256 from fe80::201:5cff:fe77:bc46.
Jul 04 13:05:11 firewall.penurio.us dhclient[1431]: Packet received,
but nothing done with it.
Jul 04 13:05:11 firewall.penurio.us dhclient[1431]: RCV: Reply
message on eth0.256 from fe80::201:5cff:fe77:bc46.
Jul 04 13:05:20 firewall.penurio.us systemd[1]: Started Wait for
chrony to synchronize system clock.

Unfortunately, the expected dhclient processes are not running, so the
addresses are never renewed. I suspect that systemd may be killing
them, because chrony-wait is a oneshot service.

Can anyone suggest a way to achieve this?
--
========================================================================
Ian Pilcher ***@gmail.com
-------- "I grew up before Mark Zuckerberg invented friendship" --------
========================================================================
Reindl Harald
2017-07-05 15:36:29 UTC
Permalink
Raw Message
Post by Ian Pilcher
I am using CentOS 7 (systemd 219) on a Banana Pi as my residential
firewall/gateway. The Banana Pi does not have a persistent clock, so
it has no idea what the time is until it is able to sync via NTP. Thus,
the initial DHCP leases that the BPi receives have incorrect expiration/
renewal times (since the system can't sync via NTP before it has an IP
address - chicken and egg).
My first attempt to address this was to add a drop-in to
chrony-wait.service that bounces the WAN interface.
Unfortunately, the expected dhclient processes are not running, so the
addresses are never renewed. I suspect that systemd may be killing
them, because chrony-wait is a oneshot service.
Can anyone suggest a way to achieve this?
by just doing the dhcpd stuff on your own, do what ever you need
"oneshot" in ExecStartPre/ExecStartPost and put the dchclient into
ExecStart of a Type=forking unit

s[***@srv-rhsoft:~]$ systemctl status network-wan-bridge.service
? network-wan-bridge.service - Network Internet Bridge
Loaded: loaded (/etc/systemd/system/network-wan-bridge.service;
enabled; vendor preset: disabled)
Active: active (running) since Di 2017-07-04 08:47:33 CEST; 1 day 8h ago
Main PID: 8182 (dhclient)
Tasks: 1 (limit: 512)
CGroup: /system.slice/network-wan-bridge.service
??8182 /usr/sbin/dhclient -4 -H srv-rhsoft -q
--request-options subnet-mask,broadcast-address,routers,interface-mtu br-wan

Warning: Journal has been rotated since unit was started. Log output is
incomplete or unavailable.
[***@srv-rhsoft:~]$ cat /etc/systemd/system/network-wan-bridge.service
[Unit]
Description=Network Internet Bridge
After=network.service systemd-networkd.service network-online.target

[Service]
Type=forking
ExecStartPre=-/usr/sbin/brctl addbr br-wan
ExecStartPre=-/usr/sbin/brctl stp br-wan off
ExecStartPre=-/usr/sbin/brctl setageing br-wan 600
ExecStartPre=-/usr/sbin/brctl setfd br-wan 5
ExecStartPre=-/usr/sbin/brctl addif br-wan wan
ExecStartPre=-/usr/sbin/brctl addif br-wan vmnet1
ExecStartPre=-/usr/sbin/ifconfig br-wan hw ether 00:50:8D:B5:CC:DE up
ExecStart=/usr/sbin/dhclient -4 -H srv-rhsoft -q --request-options
subnet-mask,broadcast-address,routers,interface-mtu br-wan
ExecStartPost=-/usr/sbin/ifconfig br-wan -multicast -allmulti
ExecStartPost=-/usr/sbin/ifconfig vmnet1 0.0.0.0 -multicast -allmulti up
ExecStopPost=-/usr/sbin/ifconfig br-wan down
ExecStopPost=-/usr/sbin/brctl delbr br-wan

Restart=always
RestartSec=1

PrivateTmp=yes
NoNewPrivileges=yes
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
CAP_NET_BROADCAST CAP_NET_RAW
SystemCallFilter=~acct modify_ldt add_key adjtimex clock_adjtime
delete_module fanotify_init finit_module get_mempolicy init_module
io_destroy io_getevents iopl ioperm io_setup io_submit io_cancel kcmp
kexec_load keyctl lookup_dcookie mbind migrate_pages mount move_pages
open_by_handle_at perf_event_open pivot_root process_vm_readv
process_vm_writev ptrace remap_file_pages request_key set_mempolicy
swapoff swapon umount2 uselib vmsplice




ReadOnlyDirectories=/etc
ReadOnlyDirectories=/usr

InaccessibleDirectories=-/mnt
InaccessibleDirectories=-/mnt/data
Lennart Poettering
2017-07-10 08:43:37 UTC
Permalink
Raw Message
Post by Ian Pilcher
I am using CentOS 7 (systemd 219) on a Banana Pi as my residential
firewall/gateway. The Banana Pi does not have a persistent clock, so
it has no idea what the time is until it is able to sync via NTP. Thus,
the initial DHCP leases that the BPi receives have incorrect expiration/
renewal times (since the system can't sync via NTP before it has an IP
address - chicken and egg).
DHCP only sends times as relative times, precisely to not require
synchronized clocks.

See RFC2131, section 3.3:

"As clients and servers may not have synchronized clocks, times
are represented in DHCP messages as relative times, to be
interpreted with respect to the client's local clock.
Representing relative times in units of seconds in an unsigned 32
bit word gives a range of relative times from 0 to approximately
100 years, which is sufficient for the relative times to be
measured using DHCP."

If your DHCP client implementation gets confused by the wallclock not
being steady then this appears to be a bug in the
implementation. Given that there are so many DHCP clients to choose
from, maybe use a different one?

Lennart
--
Lennart Poettering, Red Hat
Ian Pilcher
2017-07-10 15:54:39 UTC
Permalink
Raw Message
Post by Lennart Poettering
If your DHCP client implementation gets confused by the wallclock not
being steady then this appears to be a bug in the
implementation. Given that there are so many DHCP clients to choose
from, maybe use a different one?
Oh, it's definitely a bug in ISC dhclient:

https://bugzilla.redhat.com/show_bug.cgi?id=1093803

Switching DHCP clients doesn't exactly sound like a trivial exercise,
however, since it would need to be integrated into the CentOS network
startup scripts; bouncing the interface (inelegant as it is) seems like
the easier option.

This unit file seems to be doing the job for IPv6 (since *something*
seems to be already doing this for IPv4):

[Unit]
Description=IPv6 DHCP client for %I
Requires=chrony-wait.service
After=chrony-wait.service

[Service]
Type=simple
ExecStartPre=/usr/sbin/dhclient -6 -d -q -x -lf
/var/lib/dhclient/dhclient6--%I.lease -pf /var/run/dhclient6-%I.pid %I
ExecStart=/usr/sbin/dhclient -6 -d -q -1 -lf
/var/lib/dhclient/dhclient6--%I.lease -pf /var/run/dhclient6-%I.pid %I

[Install]
WantedBy=multi-user.target

Maybe systemd-networkd ...
--
========================================================================
Ian Pilcher ***@gmail.com
-------- "I grew up before Mark Zuckerberg invented friendship" --------
========================================================================
Julian Andres Klode
2017-07-10 16:03:10 UTC
Permalink
Raw Message
Post by Ian Pilcher
I am using CentOS 7 (systemd 219) on a Banana Pi as my residential
firewall/gateway. The Banana Pi does not have a persistent clock, so
it has no idea what the time is until it is able to sync via NTP. Thus,
the initial DHCP leases that the BPi receives have incorrect expiration/
renewal times (since the system can't sync via NTP before it has an IP
address - chicken and egg).
Can't you just store the time on shutdown and restore it at boot (e.g.,
take the time of the journal file) - that is usually close enough, at
least it works well enough for use cases in openwrt and lede.
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.
Mantas Mikulėnas
2017-07-10 19:50:30 UTC
Permalink
Raw Message
Post by Julian Andres Klode
Post by Ian Pilcher
I am using CentOS 7 (systemd 219) on a Banana Pi as my residential
firewall/gateway. The Banana Pi does not have a persistent clock, so
it has no idea what the time is until it is able to sync via NTP. Thus,
the initial DHCP leases that the BPi receives have incorrect expiration/
renewal times (since the system can't sync via NTP before it has an IP
address - chicken and egg).
Can't you just store the time on shutdown and restore it at boot (e.g.,
take the time of the journal file) - that is usually close enough, at
least it works well enough for use cases in openwrt and lede.
systemd-timesyncd already does this. I doubt it would help though, since
the clock would be late anyway, and dhclient seems to break if *any* clock
jumps happen at all (unlike e.g. TLS which only needs to know the
approximate time).
--
Mantas Mikulėnas <***@gmail.com>
Loading...