X-MS-Has-Attach: Content-Transfer-Encoding: base64 X-RT-Interface: Email Thread-Topic: [ISC-Bugs #45540] dhclient doesn't RENEW at proper moment when system time shifts back X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mx.pao1.isc.org MIME-Version: 1.0 Message-ID: <1506456972.20041.20.camel@otago.ac.nz> X-RT-Incoming-Encryption: Not encrypted X-MS-Exchange-Transport-Fromentityheader: Hosted Content-Language: en-US X-Originating-Ip: [10.64.32.117] X-MS-Tnef-Correlator: Delivered-To: dhcp-confidential@bugs.isc.org X-RT-Original-Encoding: utf-8 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 82D6AD78B0A for ; Tue, 26 Sep 2017 20:16:45 +0000 (UTC) Received: from mailhub2.otago.ac.nz (mailhub2.otago.ac.nz [139.80.64.247]) by mx.pao1.isc.org (Postfix) with ESMTP id EA51C34D1BB for ; Tue, 26 Sep 2017 20:16:16 +0000 (UTC) Received: from mailhost.staff.otago.ac.nz (its-mail-p02.registry.otago.ac.nz [10.67.0.56]) by mailhub2.otago.ac.nz (8.13.8/8.13.8) with ESMTP id v8QKGDei019866 for ; Wed, 27 Sep 2017 09:16:13 +1300 Received: from its-mail-p08.registry.otago.ac.nz (10.67.0.92) by its-mail-p02.registry.otago.ac.nz (10.67.0.56) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 27 Sep 2017 09:16:12 +1300 Received: from its-mail-p08.registry.otago.ac.nz ([fe80::9818:9ecb:45a4:591c]) by its-mail-p08.registry.otago.ac.nz ([fe80::9818:9ecb:45a4:591c%20]) with mapi id 15.00.1293.002; Wed, 27 Sep 2017 09:16:12 +1300 From nick.phillips@otago.ac.nz Tue Sep 26 20:16:45 2017 X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.0 Return-Path: From: "Nick Phillips" X-MS-Exchange-Messagesentrepresentingtype: 1 Thread-Index: AQHTNwRMulw6isdxpku0umLdMzXEAQ== To: "dhcp-bugs@isc.org" X-Original-To: dhcp-confidential@bugs.isc.org Subject: Re: [ISC-Bugs #45540] dhclient doesn't RENEW at proper moment when system time shifts back Accept-Language: en-NZ, en-US Content-ID: X-Mailer: Evolution 3.22.6-1ubuntu1 content-type: text/plain; charset="utf-8" Date: Tue, 26 Sep 2017 20:16:12 +0000 RT-Message-ID: Content-Length: 1265 Hi... Just wanted to let you know that we have been hit by this as well. We're booting linux on systems which usually run Windows. We bring up the network and then call ntpdate to correct time. If ntpdate steps the time backwards (which it occasionally does), then dhclient does not renew its lease when it should, and continued use of the IP address is prevented by the switch we're connected to. I suspect this has been happening for years, but we've only noticed now that our network is "smarter" and drops packets from machines which don't have a valid lease. It's not clear why ntpdate sometimes needs to step time backwards (timezone issues? flaky ntp server?), but the point is that we must be able to get from a state where the system clock is unknown to a running state. Since we can't run ntpdate before starting dhclient, we either need dhclient to handle backward time steps, or we need to hack our way around it (LD_PRELOAD trick, set system time to epoch on boot, or detect negative time step and kill dhclient). It would be far nicer if dhclient could handle this itself. Cheers, Nick -- Nick Phillips / nick.phillips@otago.ac.nz / 03 479 4195 # These statements are mine, not those of the University of Otago