Thomas, Please refer to the following Kea ARM section for the details regarding authoritative/non-authoritative behavior:
https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#authoritative-dhcpv4-server-behavior Setting authoritative flag to true should solve your problem. Marcin Siodelski ISC Software Engineering On 29/08/2019 14:29, Thomas Andersen wrote: > Hi again, > > > > Sorry for bumping, but I’m sure there must be smart people out there who > can guide me – you just missed my original email. :) > > > > But to make it a lot more simple: > > Shouldn’t KEA respond with NAK when client is requesting an IP out of > configured scope? > > > > Br, > > Thomas > > > > *From: *Kea-users <kea-users-boun...@lists.isc.org> on behalf of Thomas > Andersen <t...@itu.dk> > *Date: *Thursday, 22 August 2019 at 10.19 > *To: *"kea-users@lists.isc.org" <kea-users@lists.isc.org> > *Subject: *[Kea-users] KEA not send a NAK when request ip is out of scope > > > > Hi, > > > > I got some problems with DHCP requests. > > > > Expected scenario: > > Computer logs on wifi with host login and is assigned to vlan 200 > (10.28.0.0/23) > > User logs into computer an reauthenticate on wifi and is assigned to > vlan 201 (10.28.2.0/23) > > Windows 10 sends a DHCP request for the ip address on vlan 200. > > KEA sends a NAK, as the requested ip is not in scope. > > Windows sends DHCP discover and so forth. > > > > What we see is that KEA never sends the NAK, but sees the REQUEST packet > as a bad packet, and then discards it. > > How can I get KEA to send a NAK? > > I’ve tried this with 1.3 and 1.5 > > > > Log: > > 2019-08-21 13:40:24.683 DEBUG [kea-dhcp4.packets/41217] > DHCP4_PACKET_RECEIVED [hwtype=1 a0:51:0b:0c:24:93], > cid=[01:a0:51:0b:0c:24:93], tid=0xef9810de: DHCPREQUEST (type 3) > received from 10.28.2.2 to 192.168.30.10 on interface eth0 > > 2019-08-21 13:40:24.683 DEBUG [kea-dhcp4.packets/41217] DHCP4_QUERY_DATA > [hwtype=1 a0:51:0b:0c:24:93], cid=[01:a0:51:0b:0c:24:93], > tid=0xef9810de, packet details: local_address=192.168.30.10:67, > remote_address=10.28.2.2:67, msg_type=DHCPREQUEST (3), transid=0xef9810de, > > options: > > type=012, len=008: "PC622019" (string) > > type=050, len=004: 10.28.0.172 (ipv4-address) > > type=053, len=001: 3 (uint8) > > type=055, len=014: 1(uint8) 3(uint8) 6(uint8) 15(uint8) 31(uint8) > 33(uint8) 43(uint8) 44(uint8) 46(uint8) 47(uint8) 119(uint8) 121(uint8) > 249(uint8) 252(uint8) > > type=060, len=008: "MSFT 5.0" (string) > > type=061, len=007: 01:a0:51:0b:0c:24:93 > > type=81 (CLIENT_FQDN), flags: (N=0, E=0, O=0, S=0), > domain-name='pc622019.itu.local' (partial) > > 2019-08-21 13:40:24.684 DEBUG [*kea-dhcp4.bad-packets*/41217] > DHCP4_NO_LEASE_INIT_REBOOT [hwtype=1 a0:51:0b:0c:24:93], > cid=[01:a0:51:0b:0c:24:93], tid=0xef9810de: no lease for address > 10.28.0.172 requested by INIT-REBOOT client > > > > -- > > Med venlig hilsen / With best regards > > Thomas Andersen > > > > Network Architect > > > > 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@lists.isc.org > https://lists.isc.org/mailman/listinfo/kea-users > _______________________________________________ Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
