Yes, it is true. Some stuff might set/clear as well (like Wi-Fi extenders) along the path, I think having a socket bound to INADDRY_ANY with SO_BROADCAST set would be the correct way to solve this.
Changing the socket to a raw socket might help for embedded devices, where you usually have root and nobody as users, but not for all kinds of desktops.
//M
Sent from my BlackBerry — the most secure mobile device The client determines the type of response by setting or clearing the BROADCAST bit (0x80000( in the flags of the request. If the bit is clear, either the dhcp server or the relay is non-conformant. Brad Kemp
On Thu, May 23, 2019 at 9:30 AM Krzysztof Charusta <[email protected]> wrote:I upgraded busybox from version 1.29.2 to 1.30.1 and noticed that the client behaves differently after commit "udhcpc: ensure at least one
unicast renew attempt" (c05aa6a776ab2420a42c041a3b5d45db587fd9ef).
I'm testing a setup:
- dhcp server (dnsmasq-2.78) lease time 122 sec.
- dhcp client (busybox 1.30.1)
with a dhcp relay in between (also busybox but this should not matter).
Actual result:
In the test scenario the server restarts/reconfigures and when the client sends a renew DHCPREQUEST the server replies a broadcast DHCPNAK ("address not available"). However, when in RENEWING state (T1 reached) the client does not reply to broadcast messages due to change_listen_mode(LISTEN_KERNEL). The client then waits until the REBINDING state (T2) and only then listen to broadcast.
Expected result:
According to [https://www.ietf.org/rfc/rfc2131.txt, Page 22, Sec 4.1]: "In all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK messages to 0xffffffff."
Would it be reasonable to think that the client should listen to broadcast in RENEWING state as well?
Well, no. My understanding is the whole point why RENEWINGstate exists instead of all clients just go back to bcastREBINDING, is to avoid using bcast / perusing all packets,instead of only those packets sent to our IP:PORT.Compare udhcp_recv_raw_packet() and udhcp_recv_kernel_packet().Raw receive sees way more packets._______________________________________________busybox mailing list[email protected]http://lists.busybox.net/mailman/listinfo/busybox
|
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
