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" <[email protected]> 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" <[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
