MIME-Version: 1.0
In-Reply-To: <rt-3.8.6-35155-1404407196-1013.36283-5-0@isc.org>
References: <RT-Ticket-36283@isc.org> <9232b43fab87d09a59793a268fa05c7b@www.isc.org> <rt-3.8.6-35159-1403303073-8.36283-5-0@isc.org> <53A59391.5000702@ztk-rp.eu> <rt-3.8.6-35138-1403360228-1340.36283-5-0@isc.org> <rt-3.8.6-35155-1404407196-1013.36283-5-0@isc.org>
Message-ID: <53B5B0E4.8030602@ztk-rp.eu>
Content-Type: text/plain; charset=UTF-8; format=flowed
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0
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
Content-Transfer-Encoding: 7bit
From: Rafał Pietrak <rafal@ztk-rp.eu>
RT-Message-ID: <rt-3.8.6-35146-1404416312-1867.36283-0-0@isc.org>
Content-Length: 4871

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