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" <[email protected]> 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 > >> [email protected] > >> https://lists.isc.org/mailman/listinfo/kea-users > >> _______________________________________________ Kea-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/kea-users
