[Kea-users] Kea not sending NAK

Thomas Andersen than at itu.dk
Mon Feb 29 13:58:46 UTC 2016


Hi Marcin,

Thanks for the reply.

I actually already did that just now, and now i see that the dhcp server IS sending a NAK, but is never received by the client.
It is sending the response to the mac address (which it should since the requested ip is not valid).

However, on our wireless equipment there is a broadcast/multicast filter which is stopping that packet. (Client can send mc/bc to the AP, but not the other way around).

But why is the NAK sent as a mb/bc packet to ff:ff:ff:ff:ff:ff and not the client MAC (unicast) as in a dhcp OFFER? I currently use a HP procurve 5412 as dhcp relay. The mac dat mac address in the packet sent from the server is the procure mac address, which then broadcast.

Br,
Thomas




On 29/02/16 14:38, "Marcin Siodelski" <marcin at isc.org> wrote:

>Thomas,
>
>The server is expected to return a DHCPNAK to the renewing client which
>"ciaddr" contains an address which is invalid for a subnet it is
>connected to. By renewing client I understand a client which doesn't
>include "server-ip" and doesn't include "requested-ip", per RFC2131
>section 4.3.6.
>
>Since you said that your client sends "renew packet with a requested
>address" it sounds that your case is rather an INIT-REBOOT case, when
>the client remembers previously allocated address after a reboot. Such
>client includes "requested IP address" to verify that the previously
>allocated address is still valid. In the INIT-REBOOT case it is possible
>for the server to ignore the client's message if the server has no
>record of the client (RFC2131, Section 4.3.2):
>
>" If the network is correct, then the DHCP server should check if
>  the client's notion of its IP address is correct. If not, then the
>  server SHOULD send a DHCPNAK message to the client. If the DHCP
>  server has no record of this client, then it MUST remain silent,
>  and MAY output a warning to the network administrator. This
>  behavior is necessary for peaceful coexistence of non-
>  communicating DHCP servers on the same wire."
>
>I am wondering if this is the situation you hit in your testing?
>
>It would be useful if you enabled "NAKs logging" to see what the server
>says when it discards the packet.
>
>This may be useful to see how to configure the NAK logger:
>
>http://kea.isc.org/docs/kea-guide.html#idp54421264
>
>Something like this should work....
>
>"Logging": {
>    "loggers": [
>        ....
>        {
>            "name": "kea-dhcp4.bad-packets",
>            "severity": "DEBUG",
>            "debuglevel": 99
>        }
>    ]
>}
>
>Marcin Siodelski
>ISC
>
>On 29.02.2016 11:12, Thomas Andersen wrote:
>> Hi,
>> 
>> In my kea testing, i find that if a client is sending a renew packet
>> with a requested address that is not valid for the selected network, it
>> just ignores the packet instead of sending a NAK. This means the client
>> keep sending renew packets because the previous is timed out.
>> 
>> Can this be configured to send NAK, or have i misconfigured something?
>> 
>> -- 
>> Med venlig hilsen / With best regards
>> Thomas Andersen
>> 
>> Systems and Network Administrator
>> 
>> IT University of Copenhagen
>> Rued Langgaards Vej 7
>> 2300 København S
>> 
>> Phone: +45 72185249
>> 
>> ____________________________________________________________________________
>> 
>> **NEVER DISCLOSE YOUR PASSWORD OR SHOE SIZE - NOT EVEN TO YOUR DENTIST**
>> 
>> 
>> 
>> _______________________________________________
>> Kea-users mailing list
>> Kea-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/kea-users
>> 


More information about the Kea-users mailing list