[systemd-devel] "Correct" way to obtain DHCP lease info?

[Bruce A. Johnson]

Is there a correct way to obtain information about the DHCP lease
received by systemd-networkd's DHCP client functionality? It was easy
enough to find SERVER_ADDRESS in /var/run/systemd/netif/leases/4, but

# This is private data. Do not parse.

I'd like to be able to make a widget that can tell me which DHCP server
issued my lease, how much more time I have, etc., mainly because I want
to be able to ping something that is known to be on the network. I'm
dealing with a lazy sysadmin who doesn't want to put a gateway on this
private network, I haven't found a solution using the CLI tools.

Thanks in advance.

[Silvio Knizek]

Post by Bruce A. Johnson
Is there a correct way to obtain information about the DHCP lease
received by systemd-networkd's DHCP client functionality? It was easy
enough to find SERVER_ADDRESS in /var/run/systemd/netif/leases/4, but

# This is private data. Do not parse.

I'd like to be able to make a widget that can tell me which DHCP server
issued my lease, how much more time I have, etc., mainly because I want
to be able to ping something that is known to be on the network. I'm
dealing with a lazy sysadmin who doesn't want to put a gateway on this
private network, I haven't found a solution using the CLI tools.
Thanks in advance.

Hi Bruce,

IMHO "having a lease" is not a good metric to determine if you can
access something.
I would suggest something along this line:

--- /etc/systemd/system/internal-network-accessable.target
[Unit]
Description=Internal System Accessable
---
--- /etc/systemd/system/check-if-internal-system-is-accessable.service
[Unit]
Description=Check if internal system can be reached

[Service]
ExecStart=/usr/local/bin/check-if-internal-system-is-accessable.sh
Restart=always

[Install]
WantedBy=multi-user.target
---
--- /usr/local/bin/check-if-internal-system-is-accessable.sh
#!/usr/bin/bash
while :; do
if wget -q --spider $INTERNAL_RESOURCE; then
systemctl start internal-network-accessable.target
else
systemctl stop internal-network-accessable.target
fi
sleep 600
done
---

Than you can check just the status of the .target. You may need to
tweak the lifeness probe, YMMV.

Also in sd-networkd you can configure a .network to never loose its
lease, see man:systemd.network → KeepConfiguration=

HTH
Silvio

[Bruce A. Johnson]

Silvio, thanks for the suggestion. I'm not concerned with keeping the
lease forever; the system actually experiences a topology change as it's
switched from one network to another, and I can catch that from the DBus
events that occur. The problem we're trying to solve is to contact some
address that we're sure exists on the network, without knowing anything
about that network. The default gateway was an obvious choice, but
someone wants to cover the case of there being a private LAN with no
gateway. The only other choice I could see is the DHCP server that
issues the lease.

As my thinking has evolved, I really want to get at more DHCP lease
information when it comes in, like a private DHCP option code that
conveys something about the environment. I came across a comment
somewhere that said the only way is to set the systemd-networkd client
to use debug log level and read from the journal, but isn't there a more
direct way, like with the Dbus signals that tell subscribers about
network interface status?

Bruce A. Johnson | Firmware Engineer
Blue Ridge Networks, Inc.
14120 Parke Long Court Suite 103 | Chantilly, VA 20151
Main: 1.800.722.1168 | Direct: 703-633-7332
http://www.blueridgenetworks.com
OpenPGP key ID: 296D1CD6F2B84CAB https://keys.openpgp.org/

Post by Silvio Knizek

Post by Bruce A. Johnson
Is there a correct way to obtain information about the DHCP lease
received by systemd-networkd's DHCP client functionality? It was easy
enough to find SERVER_ADDRESS in /var/run/systemd/netif/leases/4, but

# This is private data. Do not parse.

I'd like to be able to make a widget that can tell me which DHCP server
issued my lease, how much more time I have, etc., mainly because I want
to be able to ping something that is known to be on the network. I'm
dealing with a lazy sysadmin who doesn't want to put a gateway on this
private network, I haven't found a solution using the CLI tools.
Thanks in advance.

Hi Bruce,
IMHO "having a lease" is not a good metric to determine if you can
access something.
--- /etc/systemd/system/internal-network-accessable.target
[Unit]
Description=Internal System Accessable
---
--- /etc/systemd/system/check-if-internal-system-is-accessable.service
[Unit]
Description=Check if internal system can be reached
[Service]
ExecStart=/usr/local/bin/check-if-internal-system-is-accessable.sh
Restart=always
[Install]
WantedBy=multi-user.target
---
--- /usr/local/bin/check-if-internal-system-is-accessable.sh
#!/usr/bin/bash
while :; do
if wget -q --spider $INTERNAL_RESOURCE; then
systemctl start internal-network-accessable.target
else
systemctl stop internal-network-accessable.target
fi
sleep 600
done
---
Than you can check just the status of the .target. You may need to
tweak the lifeness probe, YMMV.
Also in sd-networkd you can configure a .network to never loose its
lease, see man:systemd.network → KeepConfiguration=
HTH
Silvio
_______________________________________________
systemd-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[Mantas Mikulėnas]

On Thu, Apr 22, 2021 at 6:17 PM Bruce A. Johnson <

Post by Bruce A. Johnson
Silvio, thanks for the suggestion. I'm not concerned with keeping the
lease forever; the system actually experiences a topology change as it's
switched from one network to another, and I can catch that from the DBus
events that occur. The problem we're trying to solve is to contact some
address that we're sure exists on the network, without knowing anything
about that network. The default gateway was an obvious choice, but someone
wants to cover the case of there being a private LAN with no gateway. The
only other choice I could see is the DHCP server that issues the lease.

Hmm, don't you also have the case of there being a private LAN with no
gateway and no DHCP? Or possibly the case of a DHCP relay. And since you
don't know anything about the network, you also don't know whether the
address will respond to your communication attempts (other than ARP) -- it
might be pingable but it might be not.

I'm curious about what brought this problem into existence in the first
place. Why *is* it necessary to contact a random address within the
network? (If it's to check that the physical interface is working, then
just the fact that you somehow acquired a lease would be enough. no?)

[Bruce A. Johnson]

I'm still trying to get an explanation of why having a valid DHCP
address is not in itself good enough. The only reason I've been able to
see is that after the lease is issued, and before the time comes to
refresh the lease, there could be a communication failure somewhere
between the switch the DHCP client is on and the home office where the
DHCP server is. One would assume that application failures would be a
reasonable clue.... Regardless, it seems to me that it's not
unreasonable for an application outside of systemd-networkd to be able
to obtain the DHCP lease information. Am I off base here?

Bruce A. Johnson | Firmware Engineer
Blue Ridge Networks, Inc.
14120 Parke Long Court Suite 103 | Chantilly, VA 20151
Main: 1.800.722.1168 | Direct: 703-633-7332
http://www.blueridgenetworks.com
OpenPGP key ID: 296D1CD6F2B84CAB https://keys.openpgp.org/

Post by Mantas Mikulėnas
On Thu, Apr 22, 2021 at 6:17 PM Bruce A. Johnson
Silvio, thanks for the suggestion. I'm not concerned with keeping
the lease forever; the system actually experiences a topology
change as it's switched from one network to another, and I can
catch that from the DBus events that occur. The problem we're
trying to solve is to contact some address that we're sure exists
on the network, without knowing anything about that network. The
default gateway was an obvious choice, but someone wants to cover
the case of there being a private LAN with no gateway. The only
other choice I could see is the DHCP server that issues the lease.
Hmm, don't you also have the case of there being a private LAN with no
gateway and no DHCP? Or possibly the case of a DHCP relay. And since
you don't know anything about the network, you also don't know whether
the address will respond to your communication attempts (other than
ARP) -- it might be pingable but it might be not.
I'm curious about what brought this problem into existence in the
first place. Why *is* it necessary to contact a random address within
the network? (If it's to check that the physical interface is working,
then just the fact that you somehow acquired a lease would be enough. no?)
--
Mantas Mikulėnas

[Bruce A. Johnson]

Post by Bruce A. Johnson
I'm still trying to get an explanation of why having a valid DHCP
address is not in itself good enough.

Correction: I'm still trying to get an explanation from my requirements
person.... :facepalm:

Bruce A. Johnson | Firmware Engineer
Blue Ridge Networks, Inc.
14120 Parke Long Court Suite 103 | Chantilly, VA 20151
Main: 1.800.722.1168 | Direct: 703-633-7332
http://www.blueridgenetworks.com
OpenPGP key ID: 296D1CD6F2B84CAB https://keys.openpgp.org/

[Ulrich Windl]

um
22:14 in Nachricht

Post by Bruce A. Johnson
I'm still trying to get an explanation of why having a valid DHCP
address is not in itself good enough. The only reason I've been able to
see is that after the lease is issued, and before the time comes to
refresh the lease, there could be a communication failure somewhere
between the switch the DHCP client is on and the home office where the
DHCP server is. One would assume that application failures would be a
reasonable clue.... Regardless, it seems to me that it's not
unreasonable for an application outside of systemd-networkd to be able
to obtain the DHCP lease information. Am I off base here?

Hi!

I did not follow the discussion closely, but using USB tehering with my
smartphone typically results in DHCP leases of one hour.
I had made the experience that network stopped many times after about one hour
(when the DHCP lease should have been refreshed, but wasn't).
I ran "watch ip r sh" in a terminal to monitor: Once the "usb0" interface was
gone, I knew there is a problem. Restarting the tethering fixed the problem in
practically all cases.
So long story short: I think there is a valid reason to be able to debug DHCP
and fellows...

Regars,
Ulrich

Post by Bruce A. Johnson
Bruce A. Johnson | Firmware Engineer
Blue Ridge Networks, Inc.
14120 Parke Long Court Suite 103 | Chantilly, VA 20151
Main: 1.800.722.1168 | Direct: 703-633-7332
http://www.blueridgenetworks.com
OpenPGP key ID: 296D1CD6F2B84CAB https://keys.openpgp.org/

Post by Mantas Mikulėnas
On Thu, Apr 22, 2021 at 6:17 PM Bruce A. Johnson
Silvio, thanks for the suggestion. I'm not concerned with keeping
the lease forever; the system actually experiences a topology
change as it's switched from one network to another, and I can
catch that from the DBus events that occur. The problem we're
trying to solve is to contact some address that we're sure exists
on the network, without knowing anything about that network. The
default gateway was an obvious choice, but someone wants to cover
the case of there being a private LAN with no gateway. The only
other choice I could see is the DHCP server that issues the lease.
Hmm, don't you also have the case of there being a private LAN with no
gateway and no DHCP? Or possibly the case of a DHCP relay. And since
you don't know anything about the network, you also don't know whether
the address will respond to your communication attempts (other than
ARP) -- it might be pingable but it might be not.
I'm curious about what brought this problem into existence in the
first place. Why *is* it necessary to contact a random address within
the network? (If it's to check that the physical interface is working,
then just the fact that you somehow acquired a lease would be enough. no?)
--
Mantas Mikulėnas

[Harry G. Coin]

Post by Mantas Mikulėnas
...
I'm curious about what brought this problem into existence in the
first place. Why *is* it necessary to contact a random address within
the network? (If it's to check that the physical interface is working,
then just the fact that you somehow acquired a lease would be enough. no?)

The only non-destructive way I've found to test whether a real or
virtual nic interface computes packet checksums properly is to send a
small packet to a random address temporarily added to the suspect
interface.  If a bad udp checksum is detected, invert
tx-checksum-ip-generic.