Re: [Kea-users] dhcp4 server stops responding to a device
adcast, ethertype IPv4 (0x0800), length 366: (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 352) 10.99.99.119.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 324, xid 0xf12fb475, Flags [Broadcast] Your-IP 10.99.99.3 Client-Ethernet-Address fc:fe:c2:05:3e:b7 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: Offer Subnet-Mask (1), length 4: 255.255.255.0 Default-Gateway (3), length 4: 10.99.99.1 Domain-Name-Server (6), length 8: 10.99.99.119,10.99.99.111 Hostname (12), length 15: "wiserheat053eb7" Domain-Name (15), length 15: "ad.domain.net" Lease-Time (51), length 4: 43200 Server-ID (54), length 4: 10.99.99.119 RN (58), length 4: 900 RB (59), length 4: 1800 It’s very sporadic. Sometimes it refuses to get an address (having rebooted the router, restarted, dhcp, restarted the wireless access point), sometimes it’ll request and renew it’s address for hours and work fine. I have splunk tracking the RSSI of the client, it’s not getting amazing signal but it should be sufficient. (-68 to -72 over last 2 hours) Considering replacing the AP but there’s nothing wrong with the AP except distance to the Wiser device From: Kea-users On Behalf Of Rick Frey Sent: 21 January 2024 16:42 To: Kea user's list Subject: Re: [Kea-users] dhcp4 server stops responding to a device The listed Kea logs for DHCP_LEASE_ADVERT would indicate that Kea is sending an OFFER to the DISCOVER request. It would seem unlikely that Kea logs the ADVERT without attempting to send the offer packet on the network (such a bug would likely affect more than your client). You also mention that you had similar issue with the legacy ISC dhcpd server. You also mention recent issue began after distro upgrade. Assuming there were not changes to Kea with the upgrade. Not enough info in thread to determine, but seems more probable that the OFFER is being dropped/blocked by your OS/network layer. Generally, if offer packet is blocked by something such as NFTables/IPTables, Kea would also log something along the lines of "failed to send DHCPv4 packet: pkt4 send failed: sendmsg() returned with an error: Operation not permitted”. Apparmor/SELinux or similar security controls could also be in play. You may want to try packet capture without filters (or just limit to port 67/68) in case there are some breadcrumbs there. If you have not already, recommend checking OS logs as well in case response packet dropped by your host. You can also turn up Kea loglevel (severity DEBUG and increased debuglevel) but since Kea is logging ADVERT, not sure you’ll learn more there. See https://kea.readthedocs.io/en/kea-2.4.1/arm/logging.html#logging-levels On Jan 19, 2024, at 07:37, Gavin Davenport mailto:gav...@gavdav.net>> wrote: Does anyone have any idea why dhcp would not actually emit the dhcp response following logging 2024-01-19 13:35:02.390 INFO [kea-dhcp4.leases/855.139674733151936] DHCP4_LEASE_ADVERT [hwtype=1 fc:fe:c2:05:3e:b7], cid=[no info], tid=0xf3db5a1f: lease 10.99.99.3 will be advertised 2024-01-19 13:35:17.539 INFO [kea-dhcp4.leases/855.139674758330048] DHCP4_LEASE_ADVERT [hwtype=1 fc:fe:c2:05:3e:b7], cid=[no info], tid=0xf3db5a1f: lease 10.99.99.3 will be advertised 2024-01-19 13:35:32.689 INFO [kea-dhcp4.leases/855.139674749937344] DHCP4_LEASE_ADVERT [hwtype=1 fc:fe:c2:05:3e:b7], cid=[no info], tid=0xf3db5a1f: lease 10.99.99.3 will be advertised It's received the discover (visible in tcpdump) but why would it get jammed and refuse to respond to this ? is there anything I have misconfigured in the scope ? Are there any improved debugging options I might use ? -Original Message- From: Kea-users mailto:kea-users-boun...@lists.isc.org>> On Behalf Of Gavin Davenport Sent: 16 January 2024 20:46 To: Kea user's list mailto:kea-users@lists.isc.org>> Subject: Re: [Kea-users] dhcp4 server stops responding to a device I was using isc-dhcp and had this behaviour too: https://gitlab.isc.org/isc-projects/dhcp/-/issues/177 I switched to kea-dhcp4 and it fixed it. I've since done a distro upgrade and it's gone flaky again. I've no idea how to diagnose signal quality from the data I can get from the wiser (there's a rest endpoint) but this isn't available when it gets unaddressed. -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit 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
Re: [Kea-users] dhcp4 server stops responding to a device
The listed Kea logs for DHCP_LEASE_ADVERT would indicate that Kea is sending an OFFER to the DISCOVER request. It would seem unlikely that Kea logs the ADVERT without attempting to send the offer packet on the network (such a bug would likely affect more than your client). You also mention that you had similar issue with the legacy ISC dhcpd server. You also mention recent issue began after distro upgrade. Assuming there were not changes to Kea with the upgrade. Not enough info in thread to determine, but seems more probable that the OFFER is being dropped/blocked by your OS/network layer. Generally, if offer packet is blocked by something such as NFTables/IPTables, Kea would also log something along the lines of "failed to send DHCPv4 packet: pkt4 send failed: sendmsg() returned with an error: Operation not permitted”. Apparmor/SELinux or similar security controls could also be in play. You may want to try packet capture without filters (or just limit to port 67/68) in case there are some breadcrumbs there. If you have not already, recommend checking OS logs as well in case response packet dropped by your host. You can also turn up Kea loglevel (severity DEBUG and increased debuglevel) but since Kea is logging ADVERT, not sure you’ll learn more there. See https://kea.readthedocs.io/en/kea-2.4.1/arm/logging.html#logging-levels > On Jan 19, 2024, at 07:37, Gavin Davenport wrote: > > Does anyone have any idea why dhcp would not actually emit the dhcp response > following logging > 2024-01-19 13:35:02.390 INFO [kea-dhcp4.leases/855.139674733151936] > DHCP4_LEASE_ADVERT [hwtype=1 fc:fe:c2:05:3e:b7], cid=[no info], > tid=0xf3db5a1f: lease 10.99.99.3 will be advertised > 2024-01-19 13:35:17.539 INFO [kea-dhcp4.leases/855.139674758330048] > DHCP4_LEASE_ADVERT [hwtype=1 fc:fe:c2:05:3e:b7], cid=[no info], > tid=0xf3db5a1f: lease 10.99.99.3 will be advertised > 2024-01-19 13:35:32.689 INFO [kea-dhcp4.leases/855.139674749937344] > DHCP4_LEASE_ADVERT [hwtype=1 fc:fe:c2:05:3e:b7], cid=[no info], > tid=0xf3db5a1f: lease 10.99.99.3 will be advertised > > It's received the discover (visible in tcpdump) but why would it get jammed > and refuse to respond to this ? > > is there anything I have misconfigured in the scope ? Are there any improved > debugging options I might use ? > > -Original Message- > From: Kea-users On Behalf Of Gavin Davenport > Sent: 16 January 2024 20:46 > To: Kea user's list > Subject: Re: [Kea-users] dhcp4 server stops responding to a device > > I was using isc-dhcp and had this behaviour too: > https://gitlab.isc.org/isc-projects/dhcp/-/issues/177 > > I switched to kea-dhcp4 and it fixed it. > > I've since done a distro upgrade and it's gone flaky again. > > I've no idea how to diagnose signal quality from the data I can get from the > wiser (there's a rest endpoint) but this isn't available when it gets > unaddressed. -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit 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
Re: [Kea-users] dhcp4 server stops responding to a device
Does anyone have any idea why dhcp would not actually emit the dhcp response
following logging
2024-01-19 13:35:02.390 INFO [kea-dhcp4.leases/855.139674733151936]
DHCP4_LEASE_ADVERT [hwtype=1 fc:fe:c2:05:3e:b7], cid=[no info], tid=0xf3db5a1f:
lease 10.99.99.3 will be advertised
2024-01-19 13:35:17.539 INFO [kea-dhcp4.leases/855.139674758330048]
DHCP4_LEASE_ADVERT [hwtype=1 fc:fe:c2:05:3e:b7], cid=[no info], tid=0xf3db5a1f:
lease 10.99.99.3 will be advertised
2024-01-19 13:35:32.689 INFO [kea-dhcp4.leases/855.139674749937344]
DHCP4_LEASE_ADVERT [hwtype=1 fc:fe:c2:05:3e:b7], cid=[no info], tid=0xf3db5a1f:
lease 10.99.99.3 will be advertised
It's received the discover (visible in tcpdump) but why would it get jammed and
refuse to respond to this ?
is there anything I have misconfigured in the scope ? Are there any improved
debugging options I might use ?
-Original Message-
From: Kea-users On Behalf Of Gavin Davenport
Sent: 16 January 2024 20:46
To: Kea user's list
Subject: Re: [Kea-users] dhcp4 server stops responding to a device
I was using isc-dhcp and had this behaviour too:
https://gitlab.isc.org/isc-projects/dhcp/-/issues/177
I switched to kea-dhcp4 and it fixed it.
I've since done a distro upgrade and it's gone flaky again.
I've no idea how to diagnose signal quality from the data I can get from the
wiser (there's a rest endpoint) but this isn't available when it gets
unaddressed.
-Original Message-
From: Kea-users On Behalf Of Andrew Rowson
via Kea-users
Sent: 16 January 2024 18:25
To: kea-users@lists.isc.org
Cc: Andrew Rowson
Subject: Re: [Kea-users] dhcp4 server stops responding to a device
For what it's worth, I also have a wiser thermostat and hand out a static IP
with kea. No issues here.
No bootp as far as I know, and any historical unreliability has been
signal-related.
Happy to replicate any tests (dhcpdump etc.) on my sort-of-working environment.
Andrew
On Tue, 16 Jan 2024, at 5:38 PM, Gavin Davenport wrote:
> I wonder, if this was the case, would it work at all ?
>
> This started misbehaving (having worked reliably) on 01/01/2024 – and
> has been steadily getting more unreliable.
>
>
> *From:* Kea-users *On Behalf Of *Dan
> Oachs
> *Sent:* 16 January 2024 14:59
> *To:* Kea user's list
> *Subject:* Re: [Kea-users] dhcp4 server stops responding to a device
>
> Is that device using BOOTP instead of DHCP by any chance? If so, you
> might need the Bootp kea hook library. But that's just a guess.
>
> --Dan
>
>
> On Tue, Jan 16, 2024 at 6:08 AM Gavin Davenport wrote:
>> I have a “Wiser smart hub”
>> https://wiser.draytoncontrols.co.uk/smart-heating-kits
>>
>> This is basically a central heating timer with a wifi adapter.
>>
>> I can’t set a static IP on it so it is dependent on working DHCP (and wifi)
>> to stay connected to the network.
>>
>> I’m seeing the kea-dhcp server not respond to its dhcprequests and
>> restarting the wifi and restarting the dhcp server do not seem to help.
>>
>> Config file has a reservation for it’s address: (fc:fe:c2:05:3e:b7)
>>
>> {
>> "Dhcp4": {
>> "interfaces-config": {
>> "interfaces": [
>> "enp2s0"
>> ]
>> },
>>
>> "control-socket": {
>> "socket-type": "unix",
>> "socket-name": "/tmp/kea4-ctrl-socket"
>> },
>>
>> "lease-database": {
>> "type": "memfile",
>> "lfc-interval": 3600
>> },
>>
>>
>> "expired-leases-processing": {
>> "reclaim-timer-wait-time": 10,
>> "flush-reclaimed-timer-wait-time": 25,
>> "hold-reclaimed-time": 3600,
>> "max-reclaim-leases": 100,
>> "max-reclaim-time": 250,
>> "unwarned-reclaim-cycles": 5
>> },
>>
>> "renew-timer": 900,
>> "rebind-timer": 1800,
>> "valid-lifetime": 43200,
>>
>> "option-data": [
>> {
>> "name": "domain-name-servers",
>> "data": "10.99.99.119, 10.99.99.111"
>> },
>> {
>> "name": "domain-name",
>> "data": "ad.domain.net"
>> },
>> {
>> "name": "domain-search",
>> "data": "ad.domain.net, domain.net"
>>
Re: [Kea-users] dhcp4 server stops responding to a device
Hi Gavin,
>
> How do I debug this ? why do I not see the “discover->offer->request->ack”
> sequence logged by the DHCP server or any of the servers responses in my
> tcpdump ?
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [
{
"output": "/var/log/kea-dhcp4.log"
}
],
"severity": "DEBUG",
"debuglevel": 99
}
]
I would start by setting debug level to 99 temporarily as shown above.
This will produce vastly more output that can be used to diagnose this
device. Also, you will get a complete log of packets received and
sent in the dhcp4.packets logger. If possible, isolate the logs of
this device by collecting logs while only it is attempting DHCP. This
should help as you should be able to see all of the details of the
entire process. Please feel free to post the resulting logs of the
device here, as well.
Thank you,
Darren Ankney
--
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit 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
Re: [Kea-users] dhcp4 server stops responding to a device
I was using isc-dhcp and had this behaviour too:
https://gitlab.isc.org/isc-projects/dhcp/-/issues/177
I switched to kea-dhcp4 and it fixed it.
I've since done a distro upgrade and it's gone flaky again.
I've no idea how to diagnose signal quality from the data I can get from the
wiser (there's a rest endpoint) but this isn't available when it gets
unaddressed.
-Original Message-
From: Kea-users On Behalf Of Andrew Rowson
via Kea-users
Sent: 16 January 2024 18:25
To: kea-users@lists.isc.org
Cc: Andrew Rowson
Subject: Re: [Kea-users] dhcp4 server stops responding to a device
For what it's worth, I also have a wiser thermostat and hand out a static IP
with kea. No issues here.
No bootp as far as I know, and any historical unreliability has been
signal-related.
Happy to replicate any tests (dhcpdump etc.) on my sort-of-working environment.
Andrew
On Tue, 16 Jan 2024, at 5:38 PM, Gavin Davenport wrote:
> I wonder, if this was the case, would it work at all ?
>
> This started misbehaving (having worked reliably) on 01/01/2024 – and
> has been steadily getting more unreliable.
>
>
> *From:* Kea-users *On Behalf Of *Dan
> Oachs
> *Sent:* 16 January 2024 14:59
> *To:* Kea user's list
> *Subject:* Re: [Kea-users] dhcp4 server stops responding to a device
>
> Is that device using BOOTP instead of DHCP by any chance? If so, you
> might need the Bootp kea hook library. But that's just a guess.
>
> --Dan
>
>
> On Tue, Jan 16, 2024 at 6:08 AM Gavin Davenport wrote:
>> I have a “Wiser smart hub”
>> https://wiser.draytoncontrols.co.uk/smart-heating-kits
>>
>> This is basically a central heating timer with a wifi adapter.
>>
>> I can’t set a static IP on it so it is dependent on working DHCP (and wifi)
>> to stay connected to the network.
>>
>> I’m seeing the kea-dhcp server not respond to its dhcprequests and
>> restarting the wifi and restarting the dhcp server do not seem to help.
>>
>> Config file has a reservation for it’s address: (fc:fe:c2:05:3e:b7)
>>
>> {
>> "Dhcp4": {
>> "interfaces-config": {
>> "interfaces": [
>> "enp2s0"
>> ]
>> },
>>
>> "control-socket": {
>> "socket-type": "unix",
>> "socket-name": "/tmp/kea4-ctrl-socket"
>> },
>>
>> "lease-database": {
>> "type": "memfile",
>> "lfc-interval": 3600
>> },
>>
>>
>> "expired-leases-processing": {
>> "reclaim-timer-wait-time": 10,
>> "flush-reclaimed-timer-wait-time": 25,
>> "hold-reclaimed-time": 3600,
>> "max-reclaim-leases": 100,
>> "max-reclaim-time": 250,
>> "unwarned-reclaim-cycles": 5
>> },
>>
>> "renew-timer": 900,
>> "rebind-timer": 1800,
>> "valid-lifetime": 43200,
>>
>> "option-data": [
>> {
>> "name": "domain-name-servers",
>> "data": "10.99.99.119, 10.99.99.111"
>> },
>> {
>> "name": "domain-name",
>> "data": "ad.domain.net"
>> },
>> {
>> "name": "domain-search",
>> "data": "ad.domain.net, domain.net"
>> },
>> {
>> "name": "default-ip-ttl",
>> "data": "0xf0"
>> }
>> ],
>>
>>
>> "subnet4": [
>> {
>> "subnet": "10.99.99.0/24",
>> "pools": [ { "pool": "10.99.99.2 - 10.99.99.63" } ],
>> "reservations": [
>> {
>> "hw-address": "fc:fe:c2:05:3e:b7",
>> "ip-address": "10.99.99.3"
>> }
>> ],
>> "option-data": [
>> {
>> "name": "routers",
>> "data": "10.99.99.1"
>> }
>> ]
>> }
>> ],
>>
>>
>> "loggers": [
>>
Re: [Kea-users] dhcp4 server stops responding to a device
For what it's worth, I also have a wiser thermostat and hand out a static IP
with kea. No issues here.
No bootp as far as I know, and any historical unreliability has been
signal-related.
Happy to replicate any tests (dhcpdump etc.) on my sort-of-working environment.
Andrew
On Tue, 16 Jan 2024, at 5:38 PM, Gavin Davenport wrote:
> I wonder, if this was the case, would it work at all ?
>
> This started misbehaving (having worked reliably) on 01/01/2024 – and
> has been steadily getting more unreliable.
>
>
> *From:* Kea-users *On Behalf Of *Dan Oachs
> *Sent:* 16 January 2024 14:59
> *To:* Kea user's list
> *Subject:* Re: [Kea-users] dhcp4 server stops responding to a device
>
> Is that device using BOOTP instead of DHCP by any chance? If so, you
> might need the Bootp kea hook library. But that's just a guess.
>
> --Dan
>
>
> On Tue, Jan 16, 2024 at 6:08 AM Gavin Davenport wrote:
>> I have a “Wiser smart hub”
>> https://wiser.draytoncontrols.co.uk/smart-heating-kits
>>
>> This is basically a central heating timer with a wifi adapter.
>>
>> I can’t set a static IP on it so it is dependent on working DHCP (and wifi)
>> to stay connected to the network.
>>
>> I’m seeing the kea-dhcp server not respond to its dhcprequests and
>> restarting the wifi and restarting the dhcp server do not seem to help.
>>
>> Config file has a reservation for it’s address: (fc:fe:c2:05:3e:b7)
>>
>> {
>> "Dhcp4": {
>> "interfaces-config": {
>> "interfaces": [
>> "enp2s0"
>> ]
>> },
>>
>> "control-socket": {
>> "socket-type": "unix",
>> "socket-name": "/tmp/kea4-ctrl-socket"
>> },
>>
>> "lease-database": {
>> "type": "memfile",
>> "lfc-interval": 3600
>> },
>>
>>
>> "expired-leases-processing": {
>> "reclaim-timer-wait-time": 10,
>> "flush-reclaimed-timer-wait-time": 25,
>> "hold-reclaimed-time": 3600,
>> "max-reclaim-leases": 100,
>> "max-reclaim-time": 250,
>> "unwarned-reclaim-cycles": 5
>> },
>>
>> "renew-timer": 900,
>> "rebind-timer": 1800,
>> "valid-lifetime": 43200,
>>
>> "option-data": [
>> {
>> "name": "domain-name-servers",
>> "data": "10.99.99.119, 10.99.99.111"
>> },
>> {
>> "name": "domain-name",
>> "data": "ad.domain.net"
>> },
>> {
>> "name": "domain-search",
>> "data": "ad.domain.net, domain.net"
>> },
>> {
>> "name": "default-ip-ttl",
>> "data": "0xf0"
>> }
>> ],
>>
>>
>> "subnet4": [
>> {
>> "subnet": "10.99.99.0/24",
>> "pools": [ { "pool": "10.99.99.2 - 10.99.99.63" } ],
>> "reservations": [
>> {
>> "hw-address": "fc:fe:c2:05:3e:b7",
>> "ip-address": "10.99.99.3"
>> }
>> ],
>> "option-data": [
>> {
>> "name": "routers",
>> "data": "10.99.99.1"
>> }
>> ]
>> }
>> ],
>>
>>
>> "loggers": [
>> {
>> "name": "kea-dhcp4",
>> "output_options": [
>> {
>> "output": "/var/log/kea-dhcp4.log"
>> }
>> ],
>> "severity": "DEBUG",
>> "debuglevel": 7
>> }
>> ]
>> }
>> }
>>
>> So I reserve 10.99.99.3 for the wiser device.
>>
>> For quite long periods of time I get this logged
>> 2024-01-16 11:51:22.170 INFO [kea-dhcp4.leases/111225
Re: [Kea-users] dhcp4 server stops responding to a device
I wonder, if this was the case, would it work at all ?
This started misbehaving (having worked reliably) on 01/01/2024 – and has been
steadily getting more unreliable.
From: Kea-users On Behalf Of Dan Oachs
Sent: 16 January 2024 14:59
To: Kea user's list
Subject: Re: [Kea-users] dhcp4 server stops responding to a device
Is that device using BOOTP instead of DHCP by any chance? If so, you might
need the Bootp kea hook library. But that's just a guess.
--Dan
On Tue, Jan 16, 2024 at 6:08 AM Gavin Davenport
mailto:gav...@gavdav.net>> wrote:
I have a “Wiser smart hub”
https://wiser.draytoncontrols.co.uk/smart-heating-kits
This is basically a central heating timer with a wifi adapter.
I can’t set a static IP on it so it is dependent on working DHCP (and wifi) to
stay connected to the network.
I’m seeing the kea-dhcp server not respond to its dhcprequests and restarting
the wifi and restarting the dhcp server do not seem to help.
Config file has a reservation for it’s address: (fc:fe:c2:05:3e:b7)
{
"Dhcp4": {
"interfaces-config": {
"interfaces": [
"enp2s0"
]
},
"control-socket": {
"socket-type": "unix",
"socket-name": "/tmp/kea4-ctrl-socket"
},
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
"expired-leases-processing": {
"reclaim-timer-wait-time": 10,
"flush-reclaimed-timer-wait-time": 25,
"hold-reclaimed-time": 3600,
"max-reclaim-leases": 100,
"max-reclaim-time": 250,
"unwarned-reclaim-cycles": 5
},
"renew-timer": 900,
"rebind-timer": 1800,
"valid-lifetime": 43200,
"option-data": [
{
"name": "domain-name-servers",
"data": "10.99.99.119, 10.99.99.111"
},
{
"name": "domain-name",
"data": "ad.domain.net<http://ad.domain.net>"
},
{
"name": "domain-search",
"data": "ad.domain.net<http://ad.domain.net>,
domain.net<http://domain.net>"
},
{
"name": "default-ip-ttl",
"data": "0xf0"
}
],
"subnet4": [
{
"subnet": "10.99.99.0/24<http://10.99.99.0/24>",
"pools": [ { "pool": "10.99.99.2 - 10.99.99.63" } ],
"reservations": [
{
"hw-address": "fc:fe:c2:05:3e:b7",
"ip-address": "10.99.99.3"
}
],
"option-data": [
{
"name": "routers",
"data": "10.99.99.1"
}
]
}
],
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [
{
"output": "/var/log/kea-dhcp4.log"
}
],
"severity": "DEBUG",
"debuglevel": 7
}
]
}
}
So I reserve 10.99.99.3 for the wiser device.
For quite long periods of time I get this logged
2024-01-16 11:51:22.170 INFO [kea-dhcp4.leases/1112259.140235902645952]
DHCP4_LEASE_ADVERT [hwtype=1 fc:fe:c2:05:3e:b7], cid=[no info], tid=0x25eeba9a:
lease 10.99.99.3 will be advertised
2024-01-16 11:51:37.918 INFO [kea-dhcp4.leases/1112259.140235894253248]
DHCP4_LEASE_ADVERT [hwtype=1 fc:fe:c2:05:3e:b7], cid=[no info], tid=0x25eeba9a:
lease 10.99.99.3 will be advertised
2024-01-16 11:51:53.681 INFO [kea-dhcp4.leases/1112259.140235885860544]
DHCP4_LEASE_ADVERT [hwtype=1 fc:fe:c2:05:3e:b7], cid=[no info], tid=0x25eeba9a:
lease 10.99.99.3 will be advertised
2024-01-16 11:52:04.033 INFO [kea-dhcp4.leases/1112259.140235911038656]
DHCP4_LEASE_ADVERT [hwtype=1 fc:fe:c2:05:3e:b7], cid=[no info], tid=0xcf035c28:
lease 10.99.99.3 will be advertised
And when I tcpdump I see this (tcpdump -v -n -A -i enp2s0 ether host
fc:fe:c2:05:3e:b7)
11:50:49.034748 IP (tos 0x0, ttl 64, id 17, offset 0, flags [none], proto UDP
(17), length 328)
0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from
fc:fe:c2:05:3e:b7, length 300, xid 0x25eeba9a, secs 224, Flags [Broadcast]
Client-Ethernet-Address fc:fe:c2:05:3e:b7
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Discover
Hostname (1
Re: [Kea-users] dhcp4 server stops responding to a device
Is that device using BOOTP instead of DHCP by any chance? If so, you might
need the Bootp kea hook library. But that's just a guess.
--Dan
On Tue, Jan 16, 2024 at 6:08 AM Gavin Davenport wrote:
> I have a “Wiser smart hub”
> https://wiser.draytoncontrols.co.uk/smart-heating-kits
>
>
>
> This is basically a central heating timer with a wifi adapter.
>
>
>
> I can’t set a static IP on it so it is dependent on working DHCP (and
> wifi) to stay connected to the network.
>
>
>
> I’m seeing the kea-dhcp server not respond to its dhcprequests and
> restarting the wifi and restarting the dhcp server do not seem to help.
>
>
>
> Config file has a reservation for it’s address: (fc:fe:c2:05:3e:b7)
>
> {
>
> "Dhcp4": {
>
> "interfaces-config": {
>
> "interfaces": [
>
> "enp2s0"
>
> ]
>
> },
>
>
>
> "control-socket": {
>
> "socket-type": "unix",
>
> "socket-name": "/tmp/kea4-ctrl-socket"
>
> },
>
>
>
> "lease-database": {
>
> "type": "memfile",
>
> "lfc-interval": 3600
>
> },
>
>
>
>
>
> "expired-leases-processing": {
>
> "reclaim-timer-wait-time": 10,
>
> "flush-reclaimed-timer-wait-time": 25,
>
> "hold-reclaimed-time": 3600,
>
> "max-reclaim-leases": 100,
>
> "max-reclaim-time": 250,
>
> "unwarned-reclaim-cycles": 5
>
> },
>
>
>
> "renew-timer": 900,
>
> "rebind-timer": 1800,
>
> "valid-lifetime": 43200,
>
>
>
> "option-data": [
>
> {
>
> "name": "domain-name-servers",
>
> "data": "10.99.99.119, 10.99.99.111"
>
> },
>
> {
>
> "name": "domain-name",
>
> "data": "ad.domain.net"
>
> },
>
> {
>
> "name": "domain-search",
>
> "data": "ad.domain.net, domain.net"
>
> },
>
> {
>
> "name": "default-ip-ttl",
>
> "data": "0xf0"
>
> }
>
> ],
>
>
>
>
>
> "subnet4": [
>
> {
>
> "subnet": "10.99.99.0/24",
>
> "pools": [ { "pool": "10.99.99.2 - 10.99.99.63" } ],
>
> "reservations": [
>
> {
>
> "hw-address": "fc:fe:c2:05:3e:b7",
>
> "ip-address": "10.99.99.3"
>
> }
>
> ],
>
> "option-data": [
>
> {
>
> "name": "routers",
>
> "data": "10.99.99.1"
>
> }
>
> ]
>
> }
>
> ],
>
>
>
>
>
> "loggers": [
>
> {
>
> "name": "kea-dhcp4",
>
> "output_options": [
>
> {
>
> "output": "/var/log/kea-dhcp4.log"
>
> }
>
> ],
>
> "severity": "DEBUG",
>
> "debuglevel": 7
>
> }
>
> ]
>
> }
>
> }
>
>
>
> So I reserve 10.99.99.3 for the wiser device.
>
>
>
> For quite long periods of time I get this logged
> 2024-01-16 11:51:22.170 INFO [kea-dhcp4.leases/1112259.140235902645952]
> DHCP4_LEASE_ADVERT [hwtype=1 fc:fe:c2:05:3e:b7], cid=[no info],
> tid=0x25eeba9a: lease 10.99.99.3 will be advertised
>
> 2024-01-16 11:51:37.918 INFO [kea-dhcp4.leases/1112259.140235894253248]
> DHCP4_LEASE_ADVERT [hwtype=1 fc:fe:c2:05:3e:b7], cid=[no info],
> tid=0x25eeba9a: lease 10.99.99.3 will be advertised
>
> 2024-01-16 11:51:53.681 INFO [kea-dhcp4.leases/1112259.140235885860544]
> DHCP4_LEASE_ADVERT [hwtype=1 fc:fe:c2:05:3e:b7], cid=[no info],
> tid=0x25eeba9a: lease 10.99.99.3 will be advertised
>
> 2024-01-16 11:52:04.033 INFO [kea-dhcp4.leases/1112259.140235911038656]
> DHCP4_LEASE_ADVERT [hwtype=1 fc:fe:c2:05:3e:b7], cid=[no info],
> tid=0xcf035c28: lease 10.99.99.3 will be advertised
>
>
>
> And when I tcpdump I see this (tcpdump -v -n -A -i enp2s0 ether host
> fc:fe:c2:05:3e:b7)
>
>
>
> 11:50:49.034748 IP (tos 0x0, ttl 64, id 17, offset 0, flags [none], proto
> UDP (17), length 328)
>
> 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from
> fc:fe:c2:05:3e:b7, length 300, xid 0x25eeba9a, secs 224, Flags [Broadcast]
>
> Client-Ethernet-Address fc:fe:c2:05:3e:b7
>
> Vendor-rfc1048 Extensions
>
> Magic Cookie 0x63825363
>
> DHCP-Message (53), length 1: Discover
>
> Hostname (12), length 15: "WiserHeat053EB7"
>
> E..H@
> .y..D.C.4}.%...>...c.Sc5WiserHeat053EB7
>
> 11:51:05.598448 IP (tos 0x0, ttl 64, id 18, offset 0, flags [none], proto
> UDP (17), length 328)
>
> 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from
> fc:fe:c2:05:3e:b7, length 300, xid 0x25eeba9a, secs 240, Flags [Broadcast]
>
> Client-Ethernet-Address fc:fe:c2:05:3e:b7
>
>
[Kea-users] dhcp4 server stops responding to a device
I have a "Wiser smart hub"
https://wiser.draytoncontrols.co.uk/smart-heating-kits
This is basically a central heating timer with a wifi adapter.
I can't set a static IP on it so it is dependent on working DHCP (and wifi) to
stay connected to the network.
I'm seeing the kea-dhcp server not respond to its dhcprequests and restarting
the wifi and restarting the dhcp server do not seem to help.
Config file has a reservation for it's address: (fc:fe:c2:05:3e:b7)
{
"Dhcp4": {
"interfaces-config": {
"interfaces": [
"enp2s0"
]
},
"control-socket": {
"socket-type": "unix",
"socket-name": "/tmp/kea4-ctrl-socket"
},
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
"expired-leases-processing": {
"reclaim-timer-wait-time": 10,
"flush-reclaimed-timer-wait-time": 25,
"hold-reclaimed-time": 3600,
"max-reclaim-leases": 100,
"max-reclaim-time": 250,
"unwarned-reclaim-cycles": 5
},
"renew-timer": 900,
"rebind-timer": 1800,
"valid-lifetime": 43200,
"option-data": [
{
"name": "domain-name-servers",
"data": "10.99.99.119, 10.99.99.111"
},
{
"name": "domain-name",
"data": "ad.domain.net"
},
{
"name": "domain-search",
"data": "ad.domain.net, domain.net"
},
{
"name": "default-ip-ttl",
"data": "0xf0"
}
],
"subnet4": [
{
"subnet": "10.99.99.0/24",
"pools": [ { "pool": "10.99.99.2 - 10.99.99.63" } ],
"reservations": [
{
"hw-address": "fc:fe:c2:05:3e:b7",
"ip-address": "10.99.99.3"
}
],
"option-data": [
{
"name": "routers",
"data": "10.99.99.1"
}
]
}
],
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [
{
"output": "/var/log/kea-dhcp4.log"
}
],
"severity": "DEBUG",
"debuglevel": 7
}
]
}
}
So I reserve 10.99.99.3 for the wiser device.
For quite long periods of time I get this logged
2024-01-16 11:51:22.170 INFO [kea-dhcp4.leases/1112259.140235902645952]
DHCP4_LEASE_ADVERT [hwtype=1 fc:fe:c2:05:3e:b7], cid=[no info], tid=0x25eeba9a:
lease 10.99.99.3 will be advertised
2024-01-16 11:51:37.918 INFO [kea-dhcp4.leases/1112259.140235894253248]
DHCP4_LEASE_ADVERT [hwtype=1 fc:fe:c2:05:3e:b7], cid=[no info], tid=0x25eeba9a:
lease 10.99.99.3 will be advertised
2024-01-16 11:51:53.681 INFO [kea-dhcp4.leases/1112259.140235885860544]
DHCP4_LEASE_ADVERT [hwtype=1 fc:fe:c2:05:3e:b7], cid=[no info], tid=0x25eeba9a:
lease 10.99.99.3 will be advertised
2024-01-16 11:52:04.033 INFO [kea-dhcp4.leases/1112259.140235911038656]
DHCP4_LEASE_ADVERT [hwtype=1 fc:fe:c2:05:3e:b7], cid=[no info], tid=0xcf035c28:
lease 10.99.99.3 will be advertised
And when I tcpdump I see this (tcpdump -v -n -A -i enp2s0 ether host
fc:fe:c2:05:3e:b7)
11:50:49.034748 IP (tos 0x0, ttl 64, id 17, offset 0, flags [none], proto UDP
(17), length 328)
0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from
fc:fe:c2:05:3e:b7, length 300, xid 0x25eeba9a, secs 224, Flags [Broadcast]
Client-Ethernet-Address fc:fe:c2:05:3e:b7
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Discover
Hostname (12), length 15: "WiserHeat053EB7"
E..H@.y..D.C.4}.%...>...c.Sc5WiserHeat053EB7
11:51:05.598448 IP (tos 0x0, ttl 64, id 18, offset 0, flags [none], proto UDP
(17), length 328)
0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from
fc:fe:c2:05:3e:b7, length 300, xid 0x25eeba9a, secs 240, Flags [Broadcast]
Client-Ethernet-Address fc:fe:c2:05:3e:b7
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Discover
Hostname (12), length 15: "WiserHeat053EB7"
E..H@.y..D.C.4}.%...>...c.Sc5WiserHeat053EB7
11:51:22.169853 IP (tos 0x0, ttl 64, id 19, offset 0, flags [none], proto UDP
(17), length 328)
0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from
