dhcp-server: also read sender MAC address from packet header #21368
Comments
|
Could you test with the current git HEAD? We recently fixes several issues on DHCP server's address assignment (#21175). |
yuwata
added
the
needs-reporter-feedback ❓
|
Also, please provide debugging logs of networkd both server and client sides. Debugging logs can be generate by creating the following drop-in config by |
|
|
Thanks for the hint! Maybe I misunderstand, but isn't that the MAC of the bridge, while the dhcp server has issues finding / assigning MACs of the clients? Or are you saying that in order to hand out the MAC / IP for my windows machine as above I'll also have to set the MAC of the bridge?
Yes, I'll try tomorrow once I'm back at the machine. |
Ah, sorry, I misunderstand the report. |
|
Ok, so I had trouble building and using the latest HEAD, but I managed to enable debug logs on both machines. Since I now use a Linux client the server lease config slightly changed: For reference, the client now is a VM connected via a TAP interface with an Enabling debug logs on both both ends, and requesting a DHCP on the client I receive the following logs on the server: Meanwhile, the client printed something like: After this transaction, the client has received an |
|
I noticed that the client needs to send the MAC address. If the client is systemd-networkd, then you need to specify the following: We have tested the static lease feature in our CIs. You can find the example configuration at dhcp-server-static-lease.network and dhcp-client-static-lease.network. |
|
Closing. As the issue seems a kind of mis-configuration. Feel free to request to reopen this page, if the above setting does not fix your issue. Thank you. |
I can confirm that this works. Thanks! |
|
Hm, maybe I misunderstand, but how are Windows / Android clients supposed to get a DCHP address? I previously used dnsmasq which gave all clients an address, without any special client configuration. |
|
@ralfbiedert You mean Windows or Android clients get the static leases? Could you show an example configuration for dnsmasq? I guess the static leases are configured with other client identifiers instead of MAC address? |
|
Sure. This is the (NixOS-dnsmasq) config I previously used which gave all my clients the IPs below: Before that I used |
yuwata
removed
the
needs-reporter-feedback ❓
|
Could you try to dump DHCP packets and check the Windows or Android DHCP clients actually sends client identifier with their MAC address? If not, I guess |
My networks skills are a bit rusty, but using the systemd-networkd setting above and an iPhone 7, capturing the resulting traffic via DHCP RequestDHCP ACKI hope this works. Also here is a raw pcap export for the DHCP exchange: exported2.zip. I cropped the recording to just a few packets, but let me know if you need more of the exchange or anything else. Update, weird. Although I disconnected form the network and also renewed the lease (just for good measure) I got a pool address at first. However, after coming back to the phone I can now see it actually got Update 2 ... this gets weirder by the minute. Suddenly the Windows PC I originally created the ticket with also receives its assigned IP. It's as if running |
|
Update 3 ... omg ... it all makes sense now. Apparently with installing Anyhow, bug seems to be fixed and sorry for the late confusion! |
|
I have this issue running systemd 249 (249.7-1) on Debian bookworm (testing). I have four leases set: When I don't have the static leases set, the clients will get IPs from the pool as expected, but when I add the leases they fail DHCP entirely. Looking at a tcpdump I see the following in a loop: The reply contains the correct IP for the static lease and looks like this: Then the client responds correctly with a Request with the IP in it: Then after that there is no acknowledgement from systemd-networkd. |
|
@ammarzuberi I guess the addresses specified in the static leases are not in the address pool. If so, the issue is hopefully fixed in v250 by b713a99 (#20423). Could you test v250 or the PR? Or, try to extend the address pool to make it contain the static addresses. At least, please provide [DHCPServer] section. |
|
Expanding the pool to include the reserved addresses worked. I'll upgrade to v250 when it hits debian-testing. Thanks! |
|
Hello. Expanding PoolSize to: of the DHCPServer section didn't help either. |
|
I'm also experiencing this issue: ArchLinux - systemd 251.2-1 Server: It works fine with Looking into Wireshark, it appears that when dhcpcd: systemd-networkd: This all seems to work just fine with dnsmasq. Thankfully, I do control all the machines on this network so I can make it work with the mentioned client configuration, but it seems odd to me that it doesn't work the same way as pretty much every other DHCP server out there. Every other DHCP server I've tried can assign a static lease no problem without The client MAC address is also provided outside of the Client Identifier packet as part of the DHCP Discover, maybe that one could be used instead as a fallback to make it more robust? |
|
@yuwata , similarly to @maxpoulin64 I'm in a situation where I can't change my clients networking conf. This is why I need to use DHCP in the first place, or else I would just give them static IPs. Other DHCP servers seem to work as expected even when Would it be possible to reopen this issue or open a new one to:
|
|
Thanks @yuwata! EDIT: in the same environment, meaning without |
yuwata
changed the title
|
Yeah, MAC address should be also read from header, not only from client identifier. |
|
I'm affected by this issue as well. I've looked into the (server) code for a bit and read a small part of the RFC (2131). For the RFC this states that the client identifier is an opaque key and it shouldn't be interpreted by the server. But my guess is it would be fine to use it as lookup for static leases (as it isn't really interpreted). But I do believe that the implementation is quite odd in this regard. This as the configuration option explicitly is named MACAddress and it also validates that the provided value actually is a mac address (and thus isn't opaque, nor will accept any of the examples of the RFC like a hostname, nor the identifier generated based on RFC 4361). So to me it seems like there are two things going on:
Taking into account that the current configuration only accepts actual MAC addresses, and is named MACAddress, I do believe that it would make sense to change the server implementation to (only) look at the mac address ("chaddr") as well. This as it was already impossible to configure an opaque key, and I do think that it would be very uncommon for the client identifier to look like a mac address (which would be accepted in the configuration), but differ from the actual mac address / "chaddr". So would such a PR be accepted? Because I'm feeling comfortable enough to make such a small change to only use chaddr when checking whether a static lease is configured and renaming some variables (like the lookup table). Extending the current implentation so it does accept a ClientIdentifier option as well, and doing a lookup on either of them, would be uncomfortable for me as I'm not a C programmer and this being the first time I'm reading systemd code, so unfamiliar with how the configurarion is parsed etc. And I do believe there is an argument to only change the implentation to use chaddr instead of the client id (based on the fact that's the only thing currently accepted in the configuration). |
DHCP static leases are looked up by the client identifier as send by the client, while configured based on MAC. As RFC 2131 states the client identifier is an opaque key and must not be interpreted by the server this means that DHCP clients can (/will) also use a client identifier which is not a MAC address. One of these clients actually is systemd-networkd which uses an RFC 4361 by default to generate the client identifier. For these kind of DHCP clients static leases thus don't work because of this mismatch between configuring a MAC address but the server matching based on client identifier. This adds a fallback to try to look up a configured static lease based on the "chaddr" of the DHCP message as this will always contain the MAC address of the client. Fixes systemd#21368
DHCP static leases are looked up by the client identifier as send by the client, while configured based on MAC. As RFC 2131 states the client identifier is an opaque key and must not be interpreted by the server this means that DHCP clients can (/will) also use a client identifier which is not a MAC address. One of these clients actually is systemd-networkd which uses an RFC 4361 by default to generate the client identifier. For these kind of DHCP clients static leases thus don't work because of this mismatch between configuring a MAC address but the server matching based on client identifier. This adds a fallback to try to look up a configured static lease based on the "chaddr" of the DHCP message as this will always contain the MAC address of the client. Fixes systemd#21368
DHCP static leases are looked up by the client identifier as send by the client, while configured based on MAC. As RFC 2131 states the client identifier is an opaque key and must not be interpreted by the server this means that DHCP clients can (/will) also use a client identifier which is not a MAC address. One of these clients actually is systemd-networkd which uses an RFC 4361 by default to generate the client identifier. For these kind of DHCP clients static leases thus don't work because of this mismatch between configuring a MAC address but the server matching based on client identifier. This adds a fallback to try to look up a configured static lease based on the "chaddr" of the DHCP message as this will always contain the MAC address of the client. Fixes systemd#21368
DHCP static leases are looked up by the client identifier as send by the client, while configured based on MAC. As RFC 2131 states the client identifier is an opaque key and must not be interpreted by the server this means that DHCP clients can (/will) also use a client identifier which is not a MAC address. One of these clients actually is systemd-networkd which uses an RFC 4361 by default to generate the client identifier. For these kind of DHCP clients static leases thus don't work because of this mismatch between configuring a MAC address but the server matching based on client identifier. This adds a fallback to try to look up a configured static lease based on the "chaddr" of the DHCP message as this will always contain the MAC address of the client. Fixes systemd#21368
DHCP static leases are looked up by the client identifier as send by the client, while configured based on MAC. As RFC 2131 states the client identifier is an opaque key and must not be interpreted by the server this means that DHCP clients can (/will) also use a client identifier which is not a MAC address. One of these clients actually is systemd-networkd which uses an RFC 4361 by default to generate the client identifier. For these kind of DHCP clients static leases thus don't work because of this mismatch between configuring a MAC address but the server matching based on client identifier. This adds a fallback to try to look up a configured static lease based on the "chaddr" of the DHCP message as this will always contain the MAC address of the client. Fixes #21368
systemd version the issue has been seen with
Used distribution
Linux kernel version used (
uname -a)CPU architecture issue was seen on
Expected behaviour you didn't see
Unexpected behaviour you saw
Steps to reproduce the problem
When using a network configuration like so:
I would expect a client with MAC
04:d4:c4:52:8e:ceto be assigned the IP192.168.0.101. However, the client is instead assigned a random IP from the DHCP pool:Things I've tried that didn't work:
04:d4:c4:52:8e:ceAddress=192.168.0.101/24instead (which I've seen somewhere, but gave warning in journal)PoolOffsetandPoolSizeAdditional program output to the terminal or log subsystem illustrating the issue
Journal output around a random time I applied that config.
Actual bridge configuration for
br_internal:The text was updated successfully, but these errors were encountered: