[Kea-users] Kea not sending NAK

[Marcin Siodelski]

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
> >>