From: "Pavel Kankovsky" X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.0 To: dhcp-bugs@isc.org From peak@argo.troja.mff.cuni.cz Mon Jun 26 12:23:13 2017 X-RT-Incoming-Encryption: Not encrypted User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) Subject: Zero delay between DHCPDECLINE a DHCPDISCOVER X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mx.pao1.isc.org Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx.pao1.isc.org", Issuer "COMODO RSA Organization Validation Secure Server CA" (not verified)) by bugs.isc.org (Postfix) with ESMTPS id C8E05D78ACE for ; Mon, 26 Jun 2017 12:23:13 +0000 (UTC) Received: from kerberos2.troja.mff.cuni.cz (kerberos2.troja.mff.cuni.cz [195.113.28.3]) by mx.pao1.isc.org (Postfix) with SMTP id DA1703493ED for ; Mon, 26 Jun 2017 12:23:08 +0000 (UTC) Received: (qmail 14975 invoked from network); 26 Jun 2017 12:23:07 -0000 Received: from argo.troja.mff.cuni.cz (195.113.28.11) by k2.troja.mff.cuni.cz (195.113.28.3) with SMTP (for mx.pao1.isc.org (149.20.64.53)); 26 Jun 2017 12:23:07 -0000 Received: (qmail 19415 invoked by uid 501); 26 Jun 2017 12:23:06 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost (127.0.0.1) with SMTP; 26 Jun 2017 12:23:06 -0000 Return-Path: X-Original-To: dhcp-confidential@bugs.isc.org Date: Mon, 26 Jun 2017 14:23:06 +0200 (CEST) Delivered-To: dhcp-confidential@bugs.isc.org MIME-Version: 1.0 Message-ID: X-RT-Interface: Email Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: Content-Type: TEXT/PLAIN; charset="utf-8"; format="flowed" Content-Length: 985 The client in ISC DHCP 4.3.5 (and probably in older versions) does not wait between sending DHCPDECLINE (bind_lease() in client/dhclient.c) and sending DHCPDISCOVER (state_init() in client/dhclient.c). If the call of script_go() in bind_lease() keeps failing (e.g. when somethings breaks in dhclient-script), the client will spin in a DHCPDISCOVER-DHCPDISCOVER-DHCPDECLINE loop as quickly (and as long) as the server can respond. RFC 2131 says clients should wait at least 10 seconds between DHCPDECLINE and DHCPDISCOVER. See page 16: [...] If the client detects that the address is already in use (e.g., through the use of ARP), the client MUST send a DHCPDECLINE message to the server and restarts the configuration process. The client SHOULD wait a minimum of ten seconds before restarting the configuration process to avoid excessive network traffic in case of looping. -- Pavel Kankovsky aka Peak "Que sçay-je?"