[Kea-users] Kea not sending NAK

[Thomas Andersen]

Hi Marcin,

Sorry if I’m confusing you with the description. I’m getting confused myself. :)
But I have verified that the relay (HP switch) is sending the NAK to ff:ff:ff:ff:ff:ff as a mc/bc.

From wireshark on the client we are receiving:
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)

Kea is sending unicast to the relay.

Funny thing is that OFFER packets are sent correctly as unicast to the client mac address from the relay.

Br,
Thomas





On 01/03/16 10:24, "Marcin Siodelski" <marcin at isc.org> wrote:

>On 29.02.2016 14:58, Thomas Andersen wrote:
>> 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.
>>
>
>In the environment with relays the server should unicast the DHCPNAK to
>the relay's IP/MAC address and the relay then forwards the packet to the
>client's MAC address. What you're describing here is that the Kea server
>is sending a DHCPNAK to the bc address and ff:ff:ff:ff:ff:ff? Or, is
>this a relay agent that forwards the DHCPNAK to bc?
>
>Marcin
>
>> 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
>> >>
>