Report information
The Basics
Id:
36283
Status:
resolved
Priority:
Low/Low
Queue:
dhcp-public
People
BugTracker
Version Fixed:
4.4.2
Version Found:
(no value)
Versions Affected:
(no value)
Versions Planned:
4.4.2
Priority:
P2 Normal
Severity:
S2 Normal
CVSS Score:
(no value)
CVE ID:
(no value)
Component:
(no value)
Area:
(no value)
Dates
Created:Thu, 12 Jun 2014 10:49:58 -0400
Updated:Thu, 15 Nov 2018 07:08:54 -0500
Closed:Wed, 26 Sep 2018 11:12:31 -0400

This bug tracker is no longer active.

Please go to our Gitlab to submit issues (both feature requests and bug reports) for active projects maintained by Internet Systems Consortium (ISC).

Due to security and confidentiality requirements, full access is limited to the primary maintainers.

History
  Thu, 12 Jun 2014 10:49:58 -0400 rafal <rafal@ztk-rp.eu> - Ticket created
CC: marketing@isc.org
Subject: DHCP Server 4.2.2 - Abandoning IP address ....pinged before offer
Date: Thu, 12 Jun 2014 14:51:49 +0000
To: dhcp-bugs@isc.org
From: rafal <rafal@ztk-rp.eu>

Bug Report from www.isc.org:

  • Name: rafal
  • Email: rafal@ztk-rp.eu
  • Software Version: DHCP Server 4.2.2
  • OS: debian wheezy
  • Subject:Abandoning IP address ….pinged before offer

Bug Detail

I've experienced IP address change on by notebook. Server system log shows the above. It looks like the "abandoning" happens irrespective of the fact, that MAC address of the requestor is the same as that of responding pined machine.

---

This email was received through isc.org Bug Submission Form

All information within this email is considered confidential and for internal use only.

  Fri, 20 Jun 2014 18:24:32 -0400 Shawn Routhier <sar@isc.org> - Correspondence added

 Were there any other log messages about the lease?

If your client is using a valid lease it should remember
that and do a renew or rebind which doesn't trigger a
ping check.  If your client isn't using a valid lease it
shouldn't respond to the ping request.


Fri, 20 Jun 2014 18:24:33 -0400 The RT System itself - Status changed from 'new' to 'open'
  Sat, 21 Jun 2014 10:17:08 -0400 rafal <rafal@ztk-rp.eu> - Correspondence added
Subject: Re: [ISC-Bugs #36283] DHCP Server 4.2.2 - Abandoning IP address ....pinged before offer
Date: Sat, 21 Jun 2014 16:15:45 +0200
To: dhcp-bugs@isc.org
From: Rafał Pietrak <rafal@ztk-rp.eu>

W dniu 21.06.2014 00:24, Shawn Routhier via RT pisze: > Were there any other log messages about the lease? > > If your client is using a valid lease it should remember > that and do a renew or rebind which doesn't trigger a > ping check. If your client isn't using a valid lease it > shouldn't respond to the ping request. > If the logs are not yet recycled, I'll check that on monday. May be the actual sequence of msgs will tell you more. But as I remember it, the notebook did run for a while afrer rewakening from sllep with and old IP, then had it changed because setver did "abondon" the old IP. My impression is, that MAC of the notebook didn't change, so no matter what, the server should keep the same IP for the same MAC (if randomisation is not requested) e.g: "no matter what request was", and shold not ping at alll in such case... just to let live the "wrong clients", which don't know how to ask properly for renewal. The only concern is not to assign the same address twice, and this is ansured by comparing MACs. Right? -R
  Thu, 03 Jul 2014 13:06:36 -0400 Shawn Routhier <sar@isc.org> - Correspondence added

On Sat Jun 21 14:17:08 2014, rafal@ztk-rp.eu wrote:
> W dniu 21.06.2014 00:24, Shawn Routhier via RT pisze:
> > Were there any other log messages about the lease?
> >
> > If your client is using a valid lease it should remember
> > that and do a renew or rebind which doesn't trigger a
> > ping check. If your client isn't using a valid lease it
> > shouldn't respond to the ping request.
> >
> If the logs are not yet recycled, I'll check that on monday. May be the
> actual sequence of msgs will tell you more.
>
> But as I remember it, the notebook did run for a while afrer rewakening
> from sllep with and old IP, then had it changed because setver did
> "abondon" the old IP.
>
> My impression is, that MAC of the notebook didn't change, so no matter
> what, the server should keep the same IP for the same MAC (if
> randomisation is not requested) e.g: "no matter what request was", and
> shold not ping at alll in such case... just to let live the "wrong
> clients", which don't know how to ask properly for renewal. The only
> concern is not to assign the same address twice, and this is ansured by
> comparing MACs. Right?

The IP could change if the server handed it out to a different client or
if the notebook changed subnets.  

I'll have to revisit the RFCs and think about this some more but it would
probably be best if the server allowed the client to use the address in
this case.

That said this doesn't seem to be a high priority item so I'm not sure
when we will address it.

>
> -R
>


  Thu, 03 Jul 2014 15:38:32 -0400 rafal <rafal@ztk-rp.eu> - Correspondence added
Subject: Re: [ISC-Bugs #36283] DHCP Server 4.2.2 - Abandoning IP address ....pinged before offer
Date: Thu, 03 Jul 2014 21:37:08 +0200
To: dhcp-bugs@isc.org
From: Rafał Pietrak <rafal@ztk-rp.eu>

W dniu 03.07.2014 19:06, Shawn Routhier via RT pisze: > On Sat Jun 21 14:17:08 2014, rafal@ztk-rp.eu wrote: >> W dniu 21.06.2014 00:24, Shawn Routhier via RT pisze: >>> Were there any other log messages about the lease? >>> >>> If your client is using a valid lease it should remember >>> that and do a renew or rebind which doesn't trigger a >>> ping check. If your client isn't using a valid lease it >>> shouldn't respond to the ping request. >>> >> If the logs are not yet recycled, I'll check that on monday. May be the >> actual sequence of msgs will tell you more. >> >> But as I remember it, the notebook did run for a while afrer rewakening >> from sllep with and old IP, then had it changed because setver did >> "abondon" the old IP. >> >> My impression is, that MAC of the notebook didn't change, so no matter >> what, the server should keep the same IP for the same MAC (if >> randomisation is not requested) e.g: "no matter what request was", and >> shold not ping at alll in such case... just to let live the "wrong >> clients", which don't know how to ask properly for renewal. The only >> concern is not to assign the same address twice, and this is ansured by >> comparing MACs. Right? > The IP could change if the server handed it out to a different client or > if the notebook changed subnets. > > I'll have to revisit the RFCs and think about this some more but it would > probably be best if the server allowed the client to use the address in > this case. > > That said this doesn't seem to be a high priority item so I'm not sure > when we will address it. > Ups. I've quite forgot to send you the logs. Here are some excerpts: ------------------------------- Jul 3 07:57:03 zorro dhcpd: DHCPDISCOVER from 0c:8b:fd:15:60:8f via eth1 Jul 3 07:57:03 zorro dhcpd: Abandoning IP address 192.168.1.95: pinged before offer Jul 3 07:57:11 zorro dhcpd: DHCPDISCOVER from 0c:8b:fd:15:60:8f via eth1 Jul 3 07:57:12 zorro dhcpd: DHCPOFFER on 192.168.1.96 to 0c:8b:fd:15:60:8f (nowszy) via eth1 Jul 3 07:57:13 zorro dhcpd: DHCPREQUEST for 192.168.1.96 (192.168.1.19) from 0c:8b:fd:15:60:8f (nowszy) via eth1 Jul 3 07:57:13 zorro dhcpd: DHCPACK on 192.168.1.96 to 0c:8b:fd:15:60:8f (nowszy) via eth1 Jul 3 15:22:16 zorro dhcpd: DHCPDISCOVER from 0c:8b:fd:15:60:8f via eth1 Jul 3 15:22:16 zorro dhcpd: Abandoning IP address 192.168.1.96: pinged before offer Jul 3 15:22:20 zorro dhcpd: DHCPDISCOVER from 0c:8b:fd:15:60:8f via eth1 Jul 3 15:22:21 zorro dhcpd: DHCPOFFER on 192.168.1.86 to 0c:8b:fd:15:60:8f (nowszy) via eth1 Jul 3 15:22:21 zorro dhcpd: DHCPREQUEST for 192.168.1.86 (192.168.1.19) from 0c:8b:fd:15:60:8f (nowszy) via eth1 Jul 3 15:22:21 zorro dhcpd: DHCPACK on 192.168.1.86 to 0c:8b:fd:15:60:8f (nowszy) via eth1 Jul 3 20:06:27 zorro dhcpd: Abandoning IP address 192.168.1.86: pinged before offer Jul 3 20:06:30 zorro dhcpd: DHCPDISCOVER from 0c:8b:fd:15:60:8f via eth1 Jul 3 20:06:31 zorro dhcpd: DHCPOFFER on 192.168.1.87 to 0c:8b:fd:15:60:8f (nowszy) via eth1 Jul 3 20:06:38 zorro dhcpd: DHCPDISCOVER from 0c:8b:fd:15:60:8f (nowszy) via eth1 Jul 3 20:06:38 zorro dhcpd: DHCPOFFER on 192.168.1.87 to 0c:8b:fd:15:60:8f (nowszy) via eth1 Jul 3 20:06:38 zorro dhcpd: DHCPREQUEST for 192.168.1.87 (192.168.1.19) from 0c:8b:fd:15:60:8f (nowszy) via eth1 Jul 3 20:06:38 zorro dhcpd: DHCPACK on 192.168.1.87 to 0c:8b:fd:15:60:8f (nowszy) via eth1 Jul 3 20:59:13 zorro dhcpd: DHCPDISCOVER from 0c:8b:fd:15:60:8f via eth1 Jul 3 20:59:13 zorro dhcpd: Abandoning IP address 192.168.1.87: pinged before offer Jul 3 20:59:18 zorro dhcpd: DHCPDISCOVER from 0c:8b:fd:15:60:8f via eth1 Jul 3 20:59:19 zorro dhcpd: DHCPOFFER on 192.168.1.88 to 0c:8b:fd:15:60:8f (nowszy) via eth1 Jul 3 20:59:19 zorro dhcpd: DHCPREQUEST for 192.168.1.88 (192.168.1.19) from 0c:8b:fd:15:60:8f (nowszy) via eth1 Jul 3 20:59:19 zorro dhcpd: DHCPACK on 192.168.1.88 to 0c:8b:fd:15:60:8f (nowszy) via eth1 ------------------------------------------------------------ As you can see: it systematically goes through the available IP space. I didn't "hurt me" recently, since lately I havent used ssh from that machine (and ordynary mail/web-browsing does not expose the problem). I understand, that you may regard it as low priority, but I would think that it indicates some "strange logic" you have in your code, although my impression is, that the actual bug (i.e. RFC none compliance) may be in my "nowszy" machine, because: 1. In my network I have a few other hosts: mobile phones, voip gw, linux desktops and notebooks, etc; a total of about 10 nodes. 2. this scenario show up only on wakeup (from sleep) of "nowszy", which is a fairly new ACER notebook running debian jessie (kernel 3.14). Again I'm sory I failed to respond right after you've asked for system-logs. Let me know if I can be of further assistance. -R
  Thu, 03 Jul 2014 16:17:19 -0400 Shawn Routhier <sar@isc.org> - Correspondence added

There is an issue about what we should do in this case I just need
to figure out what will work and be consistent with the specs.  As
we haven't had other complaints about this before I'm assuming
that it isn't affecting a lot of people - hence the lower priority.

Thank you for the logs.  

Shawn
  Thu, 03 Jul 2014 16:54:20 -0400 rafal <rafal@ztk-rp.eu> - Correspondence added
Subject: Re: [ISC-Bugs #36283] DHCP Server 4.2.2 - Abandoning IP address ....pinged before offer
Date: Thu, 03 Jul 2014 22:54:05 +0200
To: dhcp-bugs@isc.org
From: Rafał Pietrak <rafal@ztk-rp.eu>

Looking through my logs again I think there may be a problem with debian/jessie dhcp-client. Countrary to other hosts, it does send DHCPDISCOVER even though it does have earlier assigned IP. In that same situation others send DHCPREQUEST.... e.g that client sends DHCPDISCOVER despite the fact, that its "ethX" does have "some" address.... and will respond to ICMP ping. So my conclusion for dhcpd would be not to differenciate (much) server side processing of received DHCPDISCOVER from received DHCPREQUEST. Regarding "low priority", pls notice, that these days people don't use "long-term / human attended" connection services like ssh. One does not notice the problem while using only IMAP or HTTP. -R W dniu 03.07.2014 22:17, Shawn Routhier via RT pisze: > There is an issue about what we should do in this case I just need > to figure out what will work and be consistent with the specs. As > we haven't had other complaints about this before I'm assuming > that it isn't affecting a lot of people - hence the lower priority. > > Thank you for the logs. > > Shawn >
Mon, 29 Dec 2014 10:44:00 -0500 Brian Conry <bconry@isc.org> - Severity S3 Low added
Mon, 02 Jul 2018 06:59:52 -0400 Cathy Almond <cathya@isc.org> - Reference to https://support.isc.org/Ticket/Display.html?id=13048 added
Mon, 09 Jul 2018 07:28:53 -0400 Cathy Almond <cathya@isc.org> - Severity S3 Low changed to S1 High
Mon, 09 Jul 2018 07:28:53 -0400 Cathy Almond <cathya@isc.org> - Priority P1 High added
Thu, 12 Jul 2018 08:08:53 -0400 Thomas Markwalder <tmark@isc.org> - Severity S1 High changed to S2 Normal
Thu, 12 Jul 2018 08:08:53 -0400 Thomas Markwalder <tmark@isc.org> - Priority P1 High changed to P2 Normal
Thu, 12 Jul 2018 08:08:53 -0400 Thomas Markwalder <tmark@isc.org> - Versions Planned 4.4.2 added
Thu, 12 Jul 2018 08:08:54 -0400 Thomas Markwalder <tmark@isc.org> - FinalPriority changed from 'Medium' to 'Low'
Thu, 12 Jul 2018 08:08:54 -0400 Thomas Markwalder <tmark@isc.org> - Priority changed from 'Medium' to 'Low'
Thu, 12 Jul 2018 08:08:54 -0400 Thomas Markwalder <tmark@isc.org> - Queue changed from #8 to dhcp-public
Thu, 12 Jul 2018 08:09:15 -0400 Thomas Markwalder <tmark@isc.org> - Taken
Thu, 12 Jul 2018 11:14:21 -0400 Cathy Almond <cathya@isc.org> - Reference to https://support.isc.org/Ticket/Display.html?id=13059 added
  Thu, 12 Jul 2018 11:17:13 -0400 Cathy Almond <cathya@isc.org> - Correspondence added

Adopting this older ticket to revisit ping-check behaviour in the light of more issues reported with PXE-boot clients: Need to look at three things: 1. Configurable switch to not ping-check on returning clients 2. Make ping check threshold currently hard-coded at 60 seconds configurable 3. Determine if we are inappropriately pinging leases identified as reusable (i.e. younger than cache threshold)
Mon, 23 Jul 2018 15:42:18 -0400 Thomas Markwalder <tmark@isc.org> - Status changed from 'open' to 'review'
Mon, 23 Jul 2018 15:42:19 -0400 Thomas Markwalder <tmark@isc.org> - Untaken
Fri, 31 Aug 2018 08:46:10 -0400 Thomas Markwalder <tmark@isc.org> - Taken
Wed, 12 Sep 2018 06:30:09 -0400 Thomas Markwalder <tmark@isc.org> - Untaken
Wed, 12 Sep 2018 10:49:24 -0400 Francis Dupont <Francis_Dupont@isc.org> - Given to Thomas Markwalder <tmark@isc.org>
Wed, 26 Sep 2018 11:12:27 -0400 Thomas Markwalder <tmark@isc.org> - Version Fixed 4.4.2 added
Wed, 26 Sep 2018 11:12:31 -0400 Thomas Markwalder <tmark@isc.org> - Status changed from 'review' to 'resolved'
Wed, 26 Sep 2018 11:12:32 -0400 Thomas Markwalder <tmark@isc.org> - Dependency by #47317: added