Re: link-local fallback

[Thomas Haller <thaller redhat com>]

On Mon, 2021-08-30 at 15:50 +0000, Michel, Matthias via networkmanager-
list wrote:
> 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?

It's still in progress, but also actively worked on.

Upstream there is now a branch "next", which will be this. That branch
doesn't yet work, and it keeps getting rebased.

> > 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?

the work on "next" branch changes the internals how NMDevice configures
IP addresses. The goal there is to simplify/improve the code, to make
future additions (like combined IP methods) simpler.

The other part is how the public API of NetworkManager (the connnection
profiles) should be extended to express the new modes. That part is
mostly independent from "next" branch, so there is no conflict with
doing that (or at least, starting to work on that now).

If you do any work however, consider to do small steps, so we can merge
them incrementally. The way how "next" branch is a huge rework that
takes many months, is undesirable (but necessary, in that case).
Otherwise, it might take a while until work gets merged, all the while
you will have to keep rebasing the branch -- with potential conflicts.

About *what* to do.... kinda what I said in my earlier email. Do you
have any specific questions about that? :) Meet us on #nm on
Libera.Chat...

Thank you for your interest!! :)


best,
Thomas