Re: link-local fallback



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]