Re: link-local fallback

2021-09-02 Thread Thomas Haller via networkmanager-list
On Mon, 2021-08-30 at 15:50 +, 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 +, 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
> > 

Re: link-local fallback

2021-08-30 Thread Michel, Matthias via networkmanager-list
Hi Thomas

On Tue, 2021-04-27 at 19:46 +0200, Thomas Haller wrote:
> Hi,
> 
> 
> On Tue, 2021-04-27 at 12:04 +, 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 

Re: link-local fallback

2021-04-27 Thread Thomas Haller via networkmanager-list
Hi,


On Tue, 2021-04-27 at 12:04 +, 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


signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list