Not sure in which changeset this happened, but here is one example:
- old DHCP client ID
1:b8:27:eb:1a:b1:ec
- new DHCP client ID
ff:eb:78:a9:4:0:1:0:1:22:6:67:49:b8:27:eb:78:a9:4
The first one was marked static in the DHCP server, which means the Raspberry Pi now did get a different IP address.
This messes up a few places that cannot do proper address resolution.
Anyone who knows where this has changed / is configured?
These did not help finding the cause:
- [WayBack] dhcp – isc dhcpd: how to insert option 61 (client id) into dhcpoffer – Server Fault
- [WayBack] networking – Wrong IP address from DHCP client on Ubuntu 18.04 – Super User
Edit
As commented by Leen below, this is about
Wicked changed its defaults to use this DHCPv6 compatible RFC4361 client-id in favour of the older RFC2132 client-id. However, this has caused some issues with older DHCPv4 servers and existing setups where the client-id stored by the server is used to assign a (static) address. It is recommended to fix this server-side, but still, wicked provides several ways of addressing this issue
So here are some links:
- [WayBack] RFC 4361 – Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)
- [WayBack] RFC 2132 – DHCP Options and BOOTP Vendor Extensions
- [WayBack] wicked-0.6.47-lp150.1.1.x86_64.rpm 15.0 Download (note “mt” is “Marius Tomaschewski” – Google Search)
2018-02-02 - mt@suse.de - version 0.6.44 - dhcp4: use rfc4361 client-id as new default for ethernet on sle15 (fate#323576). It can be also enabled/disabled in wicked-config(5). - client: fixed broken wicked arp utility command (bsc#1078245) - cleanup: add mising/explicit designated field initializers - pkgconfig: fix to request libnl3 instead of libnl1 - dbus: add missing DBUS_ERROR_FAILED type to a dbus_set_error call and enforce formatting input as string when an extension did not returned any error message. - Removed patch included in the source archive [- 0001-wickedd-explicitly-unbind-slaves-on-deletion.patch]
- [WayBack] Release version-0.6.44: version 0.6.44 · openSUSE/wicked · GitHub
- [WayBack] Commits · openSUSE/wicked · GitHub: version-0.6.44
- [WayBack] FAQ · openSUSE/wicked Wiki · GitHub
- [WayBack] Merge pull request #753 from rtorrero/man-config-rfc4361 · openSUSE/wicked@521d348 · GitHub
- [WayBack] Update man to match new DHCPv4 rfc4361 client-id · openSUSE/wicked@35d913a · GitHub
- [WayBack] Release Notes | SUSE Linux Enterprise Server 15 GA: Wicked: Using RFC 4361 DHCPv4 client-id on Ethernet REPORT BUG#, in which the description of the new RFC 4361 client-id does not match my above observations.
The traditionally used RFC 2132 DHCPv4
client-id
on Ethernet is constructed from the hardware type (01
for Ethernet) and followed by the hardware address (the MAC address), for example:01:52:54:00:02:c2:67
The RFC 4361
client-id
starts with0xff
(instead of the hardware type), followed by the DHCPv6 IAID (the interface-address association ID that describes the interface on the machine), followed by the DHCPv6 DUID (client-id
which identifies the machine).Using the above hardware type-based and hardware address-based DUID (LLT type used by default), the new RFC 4361 DHCPv4
client-id
would be:- Using the last bytes of the MAC address as the IAID:
ff:00:02:c2:67:00:01:xx:xx:xx:xx:52:54:00:02:c2:67
- When the IAID is a simple incremented number:
ff:00:00:00:01:00:01:xx:xx:xx:xx:52:54:00:02:c2:67
- Using the last bytes of the MAC address as the IAID:
- [WayBack] [Bug 1095111] Release notes should mention Wicked switching to RFC4361
–jeroen