Hi, On Tue, 2021-04-27 at 12:04 +0000, Michel, Matthias via networkmanager- list wrote:
Hi I'm using the dhcp=systemd setting in the networkmanager v1.30.2.
Btw, dhcp=systemd is an (intentionally) undocumented option. Eventually it will be replaced and behave the same as dhcp=internal. In practice, for you there should be no difference between using dhcp=internal and dhcp=systemd. And if there is a difference, that is probably something we'd like to fix/investigate. But sure, dhcp=systemd works too.
I have a requirement to switch to a fallback link-local when the dhcp is not available and to return from link-local to dhcp when it is back. What I was able to configure was the fallback to link-local. But switching to dhcp automatically was not possible. my connections with networkmanager: cat br-lan.nmconnection [connection] id=br-lan uuid=0d924e20-a7ca-4eec-9ad1-28b6d2ddb0c2 autoconnect-priority=100 autoconnect-retries=1 interface-name=br-lan llmnr=2 permissions= zone=lan [bridge] stp=false [match] kernel-command-line=!test; [ipv4] dhcp-timeout=3 dns-search= may-fail=false method=auto route1=224.0.0.0/4,0.0.0.0,0 [ipv6] addr-gen-mode=stable-privacy dns-search= method=auto [proxy] cat br-lan-ll.nmconnection [connection] id=br-lan-ll uuid=1d924e20-a7ca-4eec-9ad1-28b6d2ddb0c2 type=bridge autoconnect=true autoconnect-priority=50 interface-name=br-lan llmnr=2 permissions= timestamp=1617958884 zone=lan [bridge] stp=false [match] kernel-command-line=!test; [ipv4] dns-search= method=link-local route1=224.0.0.0/4,0.0.0.0,0 [ipv6] addr-gen-mode=stable-privacy dns-search= method=disabled [proxy] my connection with networkd: cat /etc/systemd/network/lan.network [Match] Name=enp44s0u2u1 [Network] Bridge=br0 cat /etc/systemd/network/br0.netdev [NetDev] Name=br0 Kind=bridge cat /etc/systemd/network/bridge.network [Match] Name=br0 [Network] DHCP=ipv4 LinkLocalAddressing=fallback [DHCPv4] MaxAttempts=1
The problem is that once the LL profile activates, it will not fail automatically, and DHCP is never tried again. So there really needs to be one profile that enables both DHCP and LL, possibly with an option that says: only do LL while not having a DHCP lease. That requires new API. The current ipv4.method is not flexible enough for that. That needs improvement.
I studied the code of networkmanager and networkd. networkd: https://github.com/systemd/systemd/blob/3a1e9d8083b83f611a23cc84ba69a8175e659629/src/network/networkd-dhcp4.c#L1128 networkmanager: https://github.com/NetworkManager/NetworkManager/blob/af360238be198257934b89d42f24431401550721/src/core/dhcp/nm-dhcp-systemd.c#L495 Is there a design reason why this behavior is implemented differently?
The reason is that it was not implemented this way (yet). currently, you cannot have LL and DHCP together. Neither always together nor LL-fallback-for-DHCP. Both of course makes sense.
Is it mainly a configuration error on my part?
No.
Would the community accept changes to get the same behavior for networkmanager as is the case in networkd?
Yes, but it might not be as straight forwards as it should be. Also, currently we are about to rework a part in NetworkManager that manages the IP configuration. That should make it simpler to do such a thing. But the work is not yet finished. In the current code, without this larger rework, I find it rather difficult to implement this feature, and also that would conflict/overlap with that work in progress. Independent of that, there is the question how the current API (that is the settings of the connection profiles) should be extended in a backward compatible and future proof way, so that such schemes are configurable. Possbily there should be new options ipv4.dhcp=disabled|required|optional ipv4.ll=disabled|enabled|fallback that basically extend "ipv4.method". Thank you for you offer to help out. We always appreciate that!! For thinking about how the connnection profiles should be, that is already a good task. About the internals (that get currently reworked), maybe hold back for a few weeks because the work would overlap. best, Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part