| Message ID | 1459419510-24449-3-git-send-email-dedeckeh@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
On 03/31/2016 12:18 PM, Hans Dedecker wrote: > Let DHCP client send a release when it exists so the DHCP server is > informed the IP address is released and allowing to clean up IP/mac > state info in intermediate devices. > > Signed-off-by: Hans Dedecker <dedeckeh@gmail.com> I think in the normal case we should not send a release, so we can get the IP address back later. https://www.ietf.org/rfc/rfc2131.txt says in section 3.2 part 4.: Note that in this case, where the client retains its network address locally, the client will not normally relinquish its lease during a graceful shutdown. Only in the case where the client explicitly needs to relinquish its lease, e.g., the client is about to be moved to a different subnet, will the client send a DHCPRELEASE message. What about making this configurable? Hauke
On Sun, Apr 17, 2016 at 2:07 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote: > On 03/31/2016 12:18 PM, Hans Dedecker wrote: > > Let DHCP client send a release when it exists so the DHCP server is > > informed the IP address is released and allowing to clean up IP/mac > > state info in intermediate devices. > > > > Signed-off-by: Hans Dedecker <dedeckeh@gmail.com> > > I think in the normal case we should not send a release, so we can get > the IP address back later. > > https://www.ietf.org/rfc/rfc2131.txt says in section 3.2 part 4.: > Note that in this case, where the client retains its network > address locally, the client will not normally relinquish its > lease during a graceful shutdown. Only in the case where the > client explicitly needs to relinquish its lease, e.g., the client > is about to be moved to a different subnet, will the client send > a DHCPRELEASE message. > It's a bit ambiguous to interprete (like so many statements in rfc2131 :) ) as we don't keep the IP address locally when the udhcpc client is shutdown. > > What about making this configurable? Fine to make it configurable; will send a follow-up patch in one of the next days Hans > > Hauke >
Hans Dedecker <dedeckeh@gmail.com> writes: > On Sun, Apr 17, 2016 at 2:07 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote: > >> https://www.ietf.org/rfc/rfc2131.txt says in section 3.2 part 4.: >> Note that in this case, where the client retains its network >> address locally, the client will not normally relinquish its >> lease during a graceful shutdown. Only in the case where the >> client explicitly needs to relinquish its lease, e.g., the client >> is about to be moved to a different subnet, will the client send >> a DHCPRELEASE message. >> > It's a bit ambiguous to interprete (like so many statements in rfc2131 :) ) > as we don't keep the IP address locally when the udhcpc client is shutdown. I don't read it as ambigious at all. RFC2131 clearly states that the client need not send DHCPRELEASE on shutdown. The exact wording is (twice - both in section 3.1 and 3.2): The client may choose to relinquish its lease on a network address by sending a DHCPRELEASE message to the server. The "may choose" is hard to interprete in any other way than being entirely optional. There is nothing ambigious about that. So the question boils down to whether automatically sending DHCPRELEASE is an advantage or not. I guess this might depend on your use case, but IMHO it is definitely not. Why would anyone want their address to change every time they reboot the system? They don't. I understand that there might be situations where you do want to send DHCPRELEASE. But that is more suitable for an explicit command. It is not something you want to do automatically without having precise instructions to do so from the user. Please do not add this bug to the DHCP client. Thanks. Bjørn
On Mon, Apr 18, 2016 at 1:22 PM, Bjørn Mork <bjorn@mork.no> wrote: > Hans Dedecker <dedeckeh@gmail.com> writes: > > On Sun, Apr 17, 2016 at 2:07 PM, Hauke Mehrtens <hauke@hauke-m.de> > wrote: > > > >> https://www.ietf.org/rfc/rfc2131.txt says in section 3.2 part 4.: > >> Note that in this case, where the client retains its network > >> address locally, the client will not normally relinquish its > >> lease during a graceful shutdown. Only in the case where the > >> client explicitly needs to relinquish its lease, e.g., the client > >> is about to be moved to a different subnet, will the client send > >> a DHCPRELEASE message. > >> > > It's a bit ambiguous to interprete (like so many statements in rfc2131 > :) ) > > as we don't keep the IP address locally when the udhcpc client is > shutdown. > > I don't read it as ambigious at all. > > RFC2131 clearly states that the client need not send DHCPRELEASE on > shutdown. The exact wording is (twice - both in section 3.1 and 3.2): > > The client may choose to relinquish its lease on a network address > by sending a DHCPRELEASE message to the server. > > The "may choose" is hard to interprete in any other way than being > entirely optional. There is nothing ambigious about that. > > So the question boils down to whether automatically sending DHCPRELEASE > is an advantage or not. I guess this might depend on your use case, but > IMHO it is definitely not. Why would anyone want their address to > change every time they reboot the system? They don't. > As you mention this depends on the use case and has to be seen in a more broader network scope; devices in networks which snoop DHCP messages can hold mac/IP address state info. If the IP address is not being used anymore by a gateway on a wan interface they want to be informed about this by a release message so the mac/IP address state can be removed. > > I understand that there might be situations where you do want to send > DHCPRELEASE. But that is more suitable for an explicit command. It is > not something you want to do automatically without having precise > instructions to do so from the user. > > Please do not add this bug to the DHCP client. Thanks. > Making it configurable via UCI and keeping the default behavior will not introduce a bug Hans > > > > Bjørn >
diff --git a/package/network/config/netifd/files/lib/netifd/proto/dhcp.sh b/package/network/config/netifd/files/lib/netifd/proto/dhcp.sh index 0e88af9..546e1d6 100755 --- a/package/network/config/netifd/files/lib/netifd/proto/dhcp.sh +++ b/package/network/config/netifd/files/lib/netifd/proto/dhcp.sh @@ -52,7 +52,7 @@ proto_dhcp_setup() { proto_run_command "$config" udhcpc \ -p /var/run/udhcpc-$iface.pid \ -s /lib/netifd/dhcp.script \ - -f -t 0 -i "$iface" \ + -f -R -t 0 -i "$iface" \ ${ipaddr:+-r $ipaddr} \ ${hostname:+-H $hostname} \ ${vendorid:+-V $vendorid} \
Let DHCP client send a release when it exists so the DHCP server is informed the IP address is released and allowing to clean up IP/mac state info in intermediate devices. Signed-off-by: Hans Dedecker <dedeckeh@gmail.com> --- package/network/config/netifd/files/lib/netifd/proto/dhcp.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)