RDK-60375 : ZeroConfig (IPv4LL) support for EntOS - AirPlay Devices #270

gururaajar · 2026-01-23T18:10:53Z

Reason for Change: As Gnome networkmanager is clearing of the link local IP address periodically after cheking for dhcp. We made the DHCP timeout of IPv4 to infinity. So that Gnome networkmanager won't delete the link local IP
Test Procedure: Check link local IP assigned persist after assigned
Priority:P1
Risks: Medium

…evices Reason for Change: As Gnome networkmanager is clearing of the link local IP address periodically after cheking for dhcp. We made the DHCP timeout of IPv4 to infinity. So that Gnome networkmanager won't delete the link local IP Test Procedure: Check link local IP assigned persist after assigned Priority:P1 Risks: Medium Signed-off-by: Gururaaja ESR<Gururaja_ErodeSriranganRamlingham@comcast.com>

Copilot

Pull request overview

This PR implements ZeroConfig (IPv4LL) support for CentOS AirPlay devices by setting the DHCP timeout to infinity for IPv4 configurations. This prevents Gnome NetworkManager from periodically clearing link-local IP addresses when checking for DHCP.

Changes:

Sets NM_SETTING_IP_CONFIG_DHCP_TIMEOUT to 2147483647 (infinite) for IPv4 configuration in WiFi connections

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-01-23T18:13:11Z

plugin/gnome/NetworkManagerGnomeWIFI.cpp

            g_object_set(G_OBJECT(sIpv6Conf), NM_SETTING_IP_CONFIG_METHOD, NM_SETTING_IP6_CONFIG_METHOD_AUTO, NULL); // autoconf = true
            g_object_set(G_OBJECT(sIpv6Conf), NM_SETTING_IP_CONFIG_DHCP_HOSTNAME, hostname.c_str(), NULL);
            g_object_set(G_OBJECT(sIpv6Conf), NM_SETTING_IP_CONFIG_DHCP_SEND_HOSTNAME, TRUE, NULL); // hostname send enabled
+            g_object_set(G_OBJECT(sIpv4Conf), NM_SETTING_IP_CONFIG_DHCP_TIMEOUT, 2147483647, NULL); // 2147483647 = infinite timeout


Consider using INT32_MAX constant instead of the hardcoded value 2147483647. This would improve code clarity and maintainability. If INT32_MAX is not available, add a comment explaining that this is the maximum value for a 32-bit signed integer, which NetworkManager treats as infinite timeout.

Copilot · 2026-01-23T18:13:12Z

plugin/gnome/NetworkManagerGnomeWIFI.cpp

            g_object_set(G_OBJECT(sIpv6Conf), NM_SETTING_IP_CONFIG_METHOD, NM_SETTING_IP6_CONFIG_METHOD_AUTO, NULL); // autoconf = true
            g_object_set(G_OBJECT(sIpv6Conf), NM_SETTING_IP_CONFIG_DHCP_HOSTNAME, hostname.c_str(), NULL);
            g_object_set(G_OBJECT(sIpv6Conf), NM_SETTING_IP_CONFIG_DHCP_SEND_HOSTNAME, TRUE, NULL); // hostname send enabled
+            g_object_set(G_OBJECT(sIpv4Conf), NM_SETTING_IP_CONFIG_DHCP_TIMEOUT, 2147483647, NULL); // 2147483647 = infinite timeout


The DHCP timeout is being set on sIpv4Conf after it has already been added to the connection (line 735). This means the timeout setting may not take effect. The timeout should be set before calling nm_connection_add_setting for sIpv4Conf. Move this line to be between lines 734 and 735, before the nm_connection_add_setting call.

…evices Reason for Change: As Gnome networkmanager is clearing of the link local IP address periodically after cheking for dhcp. We made the DHCP timeout of IPv4 to infinity. So that Gnome networkmanager won't delete the link local IP Test Procedure: Check link local IP assigned persist after assigned Priority:P1 Risks: Medium Signed-off-by: Gururaaja ESR<Gururaja_ErodeSriranganRamlingham@comcast.com>

…r into topic/RDK-60375

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-01-23T19:17:29Z

plugin/gnome/NetworkManagerGnomeProxy.cpp

+                    // Check if only link-local IPv4 is available (169.254.x.x)
+                    if(!result.ipaddress.empty() && result.ipaddress.compare(0, 8, "169.254.") == 0)
+                    {
+                        NMLOG_WARNING("Only link-local IPv4 available on %s, not returning it", interface.c_str());
+                        result.ipaddress.clear();
+                        result.prefix = 0;
+                        result.gateway.clear();
+                        result.primarydns.clear();
+                        result.secondarydns.clear();
+                        result.dhcpserver.clear();
+                    }


The cache for IP addresses (m_ethIPv4Address and m_wlanIPv4Address) is checked before the link-local filtering logic. This means that once a link-local address is cached (before it gets cleared by the filtering logic), subsequent calls will return the cached link-local address, creating inconsistent behavior. The cache should either be updated after the filtering logic, or the filtering should happen before caching at line 745-748.

Copilot · 2026-01-23T19:17:30Z

plugin/gnome/NetworkManagerGnomeProxy.cpp

+                    // Check if only link-local IPv4 is available (169.254.x.x)
+                    if(!result.ipaddress.empty() && result.ipaddress.compare(0, 8, "169.254.") == 0)
+                    {
+                        NMLOG_WARNING("Only link-local IPv4 available on %s, not returning it", interface.c_str());
+                        result.ipaddress.clear();
+                        result.prefix = 0;
+                        result.gateway.clear();
+                        result.primarydns.clear();
+                        result.secondarydns.clear();
+                        result.dhcpserver.clear();
+                    }


The new link-local IP address filtering logic lacks test coverage. Given that there are comprehensive tests for GetIPSettings in tests/l2Test/libnm/l2_test_libnmproxy.cpp, a test case should be added to verify that link-local addresses (169.254.x.x) are correctly handled according to the intended behavior. This is especially important given that this filtering logic significantly changes the API behavior.

Copilot · 2026-01-23T19:17:30Z

plugin/gnome/NetworkManagerGnomeWIFI.cpp

            g_object_set(G_OBJECT(sIpv4Conf), NM_SETTING_IP_CONFIG_METHOD, NM_SETTING_IP4_CONFIG_METHOD_AUTO, NULL); // autoconf = true
            g_object_set(G_OBJECT(sIpv4Conf), NM_SETTING_IP_CONFIG_DHCP_HOSTNAME, hostname.c_str(), NULL);
            g_object_set(G_OBJECT(sIpv4Conf), NM_SETTING_IP_CONFIG_DHCP_SEND_HOSTNAME, TRUE, NULL); // hostname send enabled
+            g_object_set(G_OBJECT(sIpv4Conf), NM_SETTING_IP_CONFIG_DHCP_TIMEOUT, 2147483647, NULL); // 2147483647 = infinite timeout


The DHCP timeout is only being set for WiFi connections, but not for Ethernet connections. According to the PR description, this change is for ZeroConfig (IPv4LL) support which should apply to all network interfaces, not just WiFi. The createMinimalEthernetConnection function (lines 528-576) also creates IPv4 DHCP configuration but lacks the NM_SETTING_IP_CONFIG_DHCP_TIMEOUT setting. For consistency and to achieve the stated goal, the same infinite timeout should be applied to Ethernet connections as well.

Suggested change

g_object_set(G_OBJECT(sIpv4Conf), NM_SETTING_IP_CONFIG_DHCP_TIMEOUT, 2147483647, NULL); // 2147483647 = infinite timeout

g_object_set(G_OBJECT(sIpv4Conf), NM_SETTING_IP_CONFIG_DHCP_TIMEOUT, 2147483647, NULL); // 2147483647 = infinite timeout

g_object_set(G_OBJECT(sIpv4Conf), NM_SETTING_IP_CONFIG_DHCP_TIMEOUT, 2147483647, NULL); // 2147483647 = infinite timeout

Copilot · 2026-01-23T19:17:30Z

plugin/gnome/NetworkManagerGnomeProxy.cpp

+                    // Check if only link-local IPv4 is available (169.254.x.x)
+                    if(!result.ipaddress.empty() && result.ipaddress.compare(0, 8, "169.254.") == 0)
+                    {
+                        NMLOG_WARNING("Only link-local IPv4 available on %s, not returning it", interface.c_str());
+                        result.ipaddress.clear();
+                        result.prefix = 0;
+                        result.gateway.clear();
+                        result.primarydns.clear();
+                        result.secondarydns.clear();
+                        result.dhcpserver.clear();
+                    }


This code filters out link-local IPv4 addresses (169.254.x.x) from being returned to API consumers. However, this directly contradicts the PR's stated objective which is to "support ZeroConfig (IPv4LL)" for AirPlay devices. IPv4LL (IPv4 Link-Local) addresses are precisely the 169.254.x.x range that's being filtered out here. If the goal is to support ZeroConfig/IPv4LL, these addresses should be preserved and returned, not hidden. This change appears to break the very functionality the PR claims to implement.

Suggested change

// Check if only link-local IPv4 is available (169.254.x.x)

if(!result.ipaddress.empty() && result.ipaddress.compare(0, 8, "169.254.") == 0)

{

NMLOG_WARNING("Only link-local IPv4 available on %s, not returning it", interface.c_str());

result.ipaddress.clear();

result.prefix = 0;

result.gateway.clear();

result.primarydns.clear();

result.secondarydns.clear();

result.dhcpserver.clear();

}

// IPv4 link-local (169.254.x.x) addresses are now preserved to support ZeroConfig/IPv4LL.

gururaajar requested a review from a team as a code owner January 23, 2026 18:10

Copilot AI review requested due to automatic review settings January 23, 2026 18:10

Copilot started reviewing on behalf of gururaajar January 23, 2026 18:11 View session

Copilot AI reviewed Jan 23, 2026

View reviewed changes

gururaajar changed the title ~~RDK-60375 - ZeroConfig (IPv4LL) support for EntOS - AirPlay Devices~~ RDK-60375 : ZeroConfig (IPv4LL) support for EntOS - AirPlay Devices Jan 23, 2026

gururaajar added 4 commits January 23, 2026 13:47

Merge branch 'topic/RDK-60375' of github.com:rdkcentral/networkmanage…

52614be

…r into topic/RDK-60375

Merge branch 'topic/RDK-60375' of github.com:rdkcentral/networkmanage…

32d921e

…r into topic/RDK-60375

Merge branch 'topic/RDK-60375' of github.com:rdkcentral/networkmanage…

20ce75e

…r into topic/RDK-60375

Copilot AI review requested due to automatic review settings January 23, 2026 19:13

Copilot started reviewing on behalf of gururaajar January 23, 2026 19:13 View session

Copilot AI reviewed Jan 23, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

RDK-60375 : ZeroConfig (IPv4LL) support for EntOS - AirPlay Devices #270

RDK-60375 : ZeroConfig (IPv4LL) support for EntOS - AirPlay Devices #270

Uh oh!

gururaajar commented Jan 23, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Jan 23, 2026

Uh oh!

gururaajar Jan 23, 2026

Uh oh!

Copilot AI Jan 23, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Jan 23, 2026

Uh oh!

Copilot AI Jan 23, 2026

Uh oh!

Copilot AI Jan 23, 2026

Uh oh!

Copilot AI Jan 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

	g_object_set(G_OBJECT(sIpv4Conf), NM_SETTING_IP_CONFIG_DHCP_TIMEOUT, 2147483647, NULL); // 2147483647 = infinite timeout
	g_object_set(G_OBJECT(sIpv4Conf), NM_SETTING_IP_CONFIG_DHCP_TIMEOUT, 2147483647, NULL); // 2147483647 = infinite timeout
	g_object_set(G_OBJECT(sIpv4Conf), NM_SETTING_IP_CONFIG_DHCP_TIMEOUT, 2147483647, NULL); // 2147483647 = infinite timeout

RDK-60375 : ZeroConfig (IPv4LL) support for EntOS - AirPlay Devices #270

Are you sure you want to change the base?

RDK-60375 : ZeroConfig (IPv4LL) support for EntOS - AirPlay Devices #270

Uh oh!

Conversation

gururaajar commented Jan 23, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Jan 23, 2026

Choose a reason for hiding this comment

Uh oh!

gururaajar Jan 23, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 23, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Jan 23, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 23, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 23, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 23, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants