Dynamic Link-Local Address

Technical Support
, , , , ,
1

I’m trying to enable the Dynamic Link-Local (IPv4LL) addressing on the torizon-core OS. I’ve done few changes on the /etc/NetworkManager/system-connections/network0.nmconnection and checked the IP address by removing the DHCP server. I expected to see an IP address of range 169.254.xx.xx, but unfortunately, I can’t see any IPv4 addresses.

This is my current /etc/NetworkManager/system-connections/network0.nmconnection file:

[connection]
id=network0
uuid=958cc5e3-1bbf-3d64-beeb-020d4414e254
type=ethernet
interface-name=ethernet0
timestamp=1716362590

[ethernet]

[ipv4]
method=auto
never-default=true
may-fail=false

[ipv6]
addr-gen-mode=stable-privacy
ip6-privacy=1
method=auto

[proxy]

Here is the information of my OS:

$ uname -a
Linux abi 5.15.77-6.3.0-devel+git.ddc6ca4d76ea #1-TorizonCore SMP PREEMPT Tue Jul 11 14:47:13 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux

Hope I’m missing some more configuration. Let me know what I’m missing!!!

2

Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:

Hello,

To enable Dynamic Link-Local (IPv4LL) addressing on TorizonCore, you need to adjust the configuration in the NetworkManager to specifically request IPv4LL when DHCP is not available. Based on the configuration file you’ve shared, it appears that the method is set to auto for IPv4, which typically allows NetworkManager to choose the best method available, including DHCP and Link-Local addressing. However, if DHCP is present in the network, NetworkManager might not fall back to IPv4LL automatically if it fails to get an address.

To force IPv4LL (169.254.0.0/16 range) addressing, you should change the IPv4 method to link-local. Here’s how you can adjust your /etc/NetworkManager/system-connections/network0.nmconnection file:

[ipv4]
method=link-local
never-default=true
may-fail=false

This configuration tells NetworkManager to use IPv4LL exclusively for this connection. The never-default=true option ensures that this connection is never considered as a default route for outgoing traffic unless it’s the only available option, and may-fail=false indicates that the connection setup is considered unsuccessful if IPv4LL addressing fails.

After adjusting the configuration, you need to reload the NetworkManager for the changes to take effect. You can do this by restarting the NetworkManager service:

sudo systemctl restart NetworkManager

Then, check the IP address again to see if an IPv4LL address is assigned:

ip addr show ethernet0

Ensure there are no DHCP servers available on the network during this test, as the presence of a DHCP server might cause NetworkManager to prefer DHCP over IPv4LL.

If you continue to face issues, verify that there are no conflicting NetworkManager connection profiles for the same interface and that the NetworkManager is correctly managing the interface.

Best regards,
Toradex AI Assistant

Please, also check if these links can help you solve your problem:

Ethernet/Network (Linux) | Toradex Developer Center.

3

Force fully changing the method to link-local is providing an IP range of 169.254.xx.xx, even with the DHCP server is present. But what I need is to assign the link local address only when the DHCP server not in the network.

4

Greetings @kkabh,

I did some digging about this use-case you described:

But what I need is to assign the link local address only when the DHCP server not in the network.

Basically you want the IPv4LL to be a fallback only in the case when DHCP is not available, correct? Well turns out there’s a thread about this same use-case on the NetworkManager repository: DHCP fallback to link-local (#966) · Issues · NetworkManager / NetworkManager · GitLab

If you see the latest comment they state:

What is still missing (and requested in this issue), that ipv4ll are only used as a fallback to DHCPv4. That’s still TODO.

Given this, it would appear that this particular use-case is still not supported properly with NetworkManager. I’m unsure at the moment if other network tools/frameworks can satisfy this use-case.

Best Regards,
Jeremias