Not cool: openSuse Tumbleweed switched DHCP clientID algorithm on Raspberry Pi 3, so now all devices get a non-static DHCP address
Posted by jpluimers on 2018/09/15
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-idon Ethernet is constructed from the hardware type (01for Ethernet) and followed by the hardware address (the MAC address), for example:01:52:54:00:02:c2:67
The RFC 4361
client-idstarts 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-idwhich 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-idwould 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
Leen said
Perhaps here is an explanation (first question):
https://github.com/openSUSE/wicked/wiki/FAQ
jpluimers said
You are right: it is the RFC4361 stuff.
I will update the article.
Thanks!
Joseph Mitzen said
Silly question, but did you check YaST? Hardware/ Network Settings/ Global Options tab? There’s a DNS Client Identifier field. The documentation says “If left empty, it defaults to the hardware address of the network interface.”.
jpluimers said
I did not change any setting in System / Network Settings / Global Options, as I just zypper dist-upgrade an existing Tumbleweed system (which had no updates for at least a few months as it was on the workbench for a while).
The Client Identifier field is empty, and the hardware address did not change (the MAC is still
B8:27:EB:1A:B1:EC, so it is odd that somehow this changed:1:b8:27:eb:1a:b1:ecff:eb:78:a9:4:0:1:0:1:22:6:67:49:b8:27:eb:78:a9:4Joseph Mitzen said
While I’m not sure what caused the problem yet, if you just put the old value in that field would it at least be a workaround?
jpluimers said
I could change the value in the DHCP server: that worked fine.
Will need to wait for a reaction from the opensuse people.