Le mar. 21 avr. 2020 à 10:38, [email protected]
<[email protected]> a écrit :
>
> Hi,
>
> When entering state S_REQUESTING, the dhclient starts sending DHCP requests. 
> If the dhclient doesn't receive an ACK (meaning either NAK or no answer at 
> all), the dhclient keeps sending DHCP requests infinitely.

I've seen this as well, didn't took the time to reproduce yet, but
here is what I've witnessed, with the server logs:

Last renew went fine:
Feb 15 18:23:22 front102-b local1: 2020-02-15 18:23:22,221 INFO :
xid:e095c2fc RECEIVE DHCPREQUEST RENEWING mac:02061F475E00 giaddr:N/A
login:fti/abcdefg icc:00016026677001 ip:86.215.147.175
Feb 15 18:23:22 front102-b local1: 2020-02-15 18:23:22,234 INFO :
xid:e095c2fc SEND DHCPACK mac:02061F475E00 giaddr:80.10.237.121
icc:00016026677001 ip:86.215.147.175
Feb 15 18:23:22 front102-b local1: 2020-02-15 18:23:22,234 INFO :
xid:e095c2fc STACK(DHCPREQUEST_RENEW:DHCPACK|-1|0|0|13|13)
AAA(ACCESS_REQUEST|0|5|OK-ACCOUNTING|0|7|OK)
DBAPPL(PR_RENEW|ok|0|1840742115|79|0)

Then, because of a power outage on cpe side, the dhclient went dark
and the release was sent by the dhcp relay after ping timeout:
Feb 16 12:48:56 front102-b local1: 2020-02-16 12:48:56,532 INFO :
xid:0 RECEIVE DHCPRELEASE mac:02061F475E00 giaddr:80.10.237.121
login:N/A icc:null ip:86.215.147.175

When the CPE went back online, it requested the same IP address it
had, with a request (no discover sent). The server replied with a NAK.
Feb 16 17:53:26 front102-b local1: 2020-02-16 17:53:26,247 INFO :
xid:85b15b34 RECEIVE DHCPREQUEST INIT/REBOOT or REBIND
mac:02061F475E00 giaddr:80.10.237.121 login:fti/abcdefg
icc:00016026677001 ip:86.215.147.175
Feb 16 17:53:26 front102-b local1: 2020-02-16 17:53:26,254 INFO :
xid:85b15b34 SEND DHCPNAK mac:02061F475E00 giaddr:80.10.237.121
icc:00016026677001 ip:86.215.147.175

And then the dhclient was stuck in a loop, requesting over and over
the same IP address:
Feb 16 17:53:30 front102-b local1: 2020-02-16 17:53:30,258 INFO :
xid:85b15b34 RECEIVE DHCPREQUEST INIT/REBOOT or REBIND
mac:02061F475E00 giaddr:80.10.237.121 login:fti/abcdefg
icc:00016026677001 ip:86.215.147.175
Feb 16 17:53:30 front102-b local1: 2020-02-16 17:53:30,270 INFO :
xid:85b15b34 SEND DHCPNAK mac:02061F475E00 giaddr:80.10.237.121
icc:00016026677001 ip:86.215.147.175
<this goes over and over with 15 packets/min, CPE blacklisted from
dhcp on Feb 17>

RFC2131 states:

     If the client receives a DHCPNAK message, the client restarts the
     configuration process.

      If the client receives a DHCPNAK message, it cannot reuse its
      remembered network address.  It must instead request a new
      address by restarting the configuration process, this time
      using the (non-abbreviated) procedure described in section
      3.1.  This action also corresponds to the client moving to
      the INIT state in the DHCP state diagram.

Thus I think the behaviour seen here is not quite correct.

---
regards,
pierre

Reply via email to