Hi,
I discovered that the dhcpcd has a regression since SLES10 with regards to DHCP renewals.
When dhcpcd got the initial lease successfully it shall perform a DHCP RENEW after T1.
In contrast to the initial DHCP REQUEST the RENEWAL is not a broadcast but a unicast message to the DHCP Server.
Current (Factory) dhcpcd-3.2.3 as used since OpenSUSE 11.0 has a regression which was not present in dhcpcd-1.3.22pl4 (SLES-10).
Correct DHCP renewal semantics as implemented in dhcpcd-1.3.22pl4:
- After renewal is due a special DHCP REQUEST is send as a unicast
message to the DHCP Server - This unicast message is sent to the IP of the DHCP server
- If the DHCP server is within the same LAN this unicast message is sent to the MAC address of the DHCP server on the ethernet layer.
- If the DHCP server is in another network the unicast message is sent to the responsible gateway MAC address
Incorrect DHCP renewal semantics as implemented in dhcpcd-3.2.3 (Factory)
- After renewal is due a special DHCP REQUEST is send as a unicast
message to the DHCP Server - This unicast message is sent to the IP of the DHCP server
- If the DHCP server is within the same LAN this unicast message is sent to the MAC BROADCAST address (ff:ff:ff:ff:ff:ff) on the ethernet layer.
- If the DHCP server is in another network the unicast message is sent to the MAC BROADCAST address (ff:ff:ff:ff:ff:ff) on the ethernet layer instead directly to the responsible gateway MAC address.
- At least CISCOs by default don’t forward packages received via Ethernet broadcast to the destination server.
Consequences
OpenSUSE cannot perform DHCP renewals → After the lease finally expires the network access is interrupted and a new lease has to be aquired. → errors on the
network level, outages etc.