Hi Thomas On Tue, 2021-04-27 at 19:46 +0200, Thomas Haller wrote: > 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. Has the rework mentioned been done yet? Is the time right to look at it again? > > 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. We may have a free resource that can take on the topic. Can you give us some initial thoughts or an entry point into this topic?
regards Matthias _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
