The DHCP-client in RENEWING state does not reply to broadcast messages

Krzysztof Charusta charustak at gmail.com
Fri May 24 12:09:30 UTC 2019


Hi,

I am not saying that changing to LISTEN_RAW is acceptable/optimal solution.

I think the question that needs answer is:
Should a client listen to broadcast messages while in the RENEWING state?
I didn't find in RFC2131 any suggestion that the client should *only*
listen to unicast while in the RENEWING state, it only says that a renew
DHCPREQUEST should be a unicast in that state (Sec 4.4.5). The standard
also states the server can broadcast a DHCPNAK to inform about error or so.
It feels natural to me that the client listens to this. As I understand it
is the only way for the server to inform the client about an error/change
of config (e.g. IP-pool change). Now, if the client does not listen to what
server says until REBINDING (which in case of busybox is only the last
60sec of the lease time) then potentially a lot of time is wasted.

What is the common behaviour of DHCP-servers on the market? Do they all
send unicast DHCPNAK?

If the answer to the question is "yes" then one could think about a
solution.

Best regards,
Krzysztof

On Fri, 24 May 2019 at 11:53, Denys Vlasenko <vda.linux at googlemail.com>
wrote:

> On Thu, May 23, 2019 at 4:46 PM Brad Kemp <brad at beechwoods.com> wrote:
> > 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.
>
> I don't think that's what BROADCAST flag is for.
> RFC's generally specify which packets should/should not be broadcast,
> and BROADCAST flag is intended to be used when some hardware
> would fail to receive unicasts until fully configured.
>
>
> >
> > Brad Kemp
> >
> > On May 23, 2019, at 8:36 AM, Denys Vlasenko <vda.linux at googlemail.com>
> wrote:
> >
> > On Thu, May 23, 2019 at 9:30 AM Krzysztof Charusta <charustak at gmail.com>
> 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 RENEWING
> > state exists instead of all clients just go back to bcast
> > REBINDING, 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
> > busybox at busybox.net
> > http://lists.busybox.net/mailman/listinfo/busybox
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20190524/ffef193f/attachment.html>


More information about the busybox mailing list