[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: The DHCP-client in RENEWING state does not reply to broadcast messages
From:       Denys Vlasenko <vda.linux () googlemail ! com>
Date:       2019-05-26 10:19:09
Message-ID: CAK1hOcNp8QyJ60bT11YBZE2s-xQCvMnwWbB4487JzJ0TYA7Kwg () mail ! gmail ! com
[Download RAW message or body]

On Fri, May 24, 2019 at 2:09 PM Krzysztof Charusta <charustak@gmail.com> wrote:
> 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.

Broadcast NAK is sent to 255.255.255.255, not client's address.
IIUC, receiving that packet requires having a raw socket
to listen to *all* packets.

Since RENEWING state, unlike REBINDING, can last for hours,
this would make udhcpc listen to all packets for all this time.

> 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.

Well, DHCP makes no promises that there is a way to switch to
new IPs sooner than all leases have expired.
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


[prev in list] [next in list] [prev in thread] [next in thread]