Autoconfigured IP address never gets retried
This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
I recently had a power failure where the DHCP server didn't come back up, and my KP125 smartplugs defaulted to an autoconfigured IP. After I started the DHCP server, I expected the plugs to eventually retry and get a real IP. RFC 3927 which defines autoconfiguration (though unratified) says that should happen.
Instead, the autoconfigured IP seems to stick until the power to the smartplug is removed from power and plugged back in.
This seems like a bug to me because link-local IPs are not routed and so the smartplug then can't communicate with the Kasa cloud. And to fix it you have to go to every smartplug and unplug/plug it.
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Hey @JKea,
I believe that they will refresh when their existing lease expires. Its important to consider that since the plugs cannot have a Static IP address set, they will only receive their reserved address when handshaking with the DHCP server with the reservation/binding. Without that server running, it was able to connect with the rules that the default server used.
I would expect it to refresh when the lease expires. I am more surprised that a conflict was not created when you restarted the DHCP server. How long did you wait for an IP?
The devices may not have actively been seeking out a new IP at the time since they can technically operate without an internet connection and cab be controlled by devices on the LAN.
I would make sure that the default DHCP server is disabled, otherwise you would most likely need to cause a disruption to the devices Wi-Fi to kickstart the process.
- Copy Link
- Report Inappropriate Content
@Riley_S I don't think they remember an existing lease across power cycles. They immediately probe DHCP on startup, and when that is not reachable use an autoconfigure IP in the 169.254.x.y (link-local) subnet. The question is what happens when a DHCP server becomes available.
My contention is that they seem to act like they have an infinite lease on the link-local IP - I waited a couple of days on one of them, and it never got a DHCP address. Power cycling it immediately got a real DHCP address.
RFC 3927 says "If a host finds that an interface that was previously configured with an IPv4 Link-Local address now has an operable routable address available, the host MUST use the routable address when initiating new communications". What's a little vague is when it's supposed to "find" the DHCP server. Google "IETF RFC 3927" section 1.9.2 for details.
But for the purposes of Kasa, I think they should act like there's a fairly short lease on the autoconfigure IP, like 10 minutes. Otherwise if you're not home to power-cycle them, you can't use the app remotely.
- Copy Link
- Report Inappropriate Content
I am defintely going to have to look into it a bit further, as I might understand what the limitation is and our engineering team is unavailable right now. It does sound like, at least for IoT devices, that the problems from this are being fixed with matter/IPv6 which is hopeful since most devices are moving towards that.
You are correct though that it is extremely vague on the timing, along with who should really initiate that line of communication between devices. Ill see what I can dig up from our teams over the next few days.
It sounds like it should have expired at 12 or 24 hours. We wholly were not expecting you to say that they remained in that state for multiple days.
Do you have a completely separate server for your DHCP or did it simply not start on your router btw?
- Copy Link
- Report Inappropriate Content
>Do you have a completely separate server for your DHCP or did it simply not start on your router btw?
The DHCP server configuration was broken, so it didn't start.
I'm going to do an experiment where I block a KP125 from DHCP overnight, then unblock. I'll report the results here.
- Copy Link
- Report Inappropriate Content
>I'll report the results here.
Hmm, it appears that my theory of the situation that caused this behavior is incomplete. I definitely saw the original problem, but this experiment now shows that the KP125 tries to get a DHCP address roughly every minute and successfully acquires one when DHCP is available again.
I'm going to have to think about what exactly the sequence of events was, so it's probably not worth your looking into it until/unless I can reproduce it.
- Copy Link
- Report Inappropriate Content
Ok, I found out how to reproduce this. It's a slightly different from what I originally thought.
Here's the sequence of events:
1. turn off router, which disables both Internet communication and DHCP. N.b. this is not an AP. There are multiple AP's on the LAN 192 168 x y, and they are bridged so they don't do routing or DHCP. The AP's are Unifi devices and I can monitor what's attached to them and what IP address they claim.
2. unplug a couple of KP125's and plug them back in
3. wait until the 2 KP125s show up on the LAN via an AP with autoconfigured addresses (169 254 x y)
4. start up the router, verify that it is routing to the Internet and serving DHCP addresses
Now I see that about every 10 minutes those 2 KP125s leave the AP, then join it again, but come back with the same autoconfigure addresses in a few seconds. This persisted after a full day. (and see below - they are getting DHCP addresses but then not using them)
5. unplug one KP125 and plug back in
That KP125 immediately gets a real DHCP address, the other one has no change. It now works in Kasa app.
6. replug the second KP125
It's now fixed too.
Here's the weirdest part: I can see that the KP125's are making DHCP requests every 10 minutes and getting addresses, but then they continue using the autoconfigure address:
Oct 8 14:33:42 dnsmasq-dhcp[53048]: DHCPOFFER(enx70886b8f4bb4) 192.168.1.63 5c:62:8b:0e:fe:1f
Oct 8 14:33:42 dnsmasq-dhcp[53048]: DHCPREQUEST(enx70886b8f4bb4) 192.168.1.63 5c:62:8b:0e:fe:1f
Oct 8 14:33:42 dnsmasq-dhcp[53048]: DHCPACK(enx70886b8f4bb4) 192.168.1.63 5c:62:8b:0e:fe:1f smartpower2
Oct 8 14:45:02 dnsmasq-dhcp[53048]: DHCPDISCOVER(enx70886b8f4bb4) 5c:62:8b:0e:fe:1f
Oct 8 14:45:02 dnsmasq-dhcp[53048]: DHCPOFFER(enx70886b8f4bb4) 192.168.1.63 5c:62:8b:0e:fe:1f
Oct 8 14:45:02 dnsmasq-dhcp[53048]: DHCPREQUEST(enx70886b8f4bb4) 192.168.1.63 5c:62:8b:0e:fe:1f
Oct 8 14:45:02 dnsmasq-dhcp[53048]: DHCPACK(enx70886b8f4bb4) 192.168.1.63 5c:62:8b:0e:fe:1f smartpower2
$ ping smartpower2
PING smartpower2 example com (192.168.1.63) 56(84) bytes of data.
(192.168.0.207) icmp_seq=1 Destination Host Unreachable
(now replug smartpower2)
Oct 8 14:49:32 dnsmasq-dhcp[53048]: DHCPDISCOVER(enx70886b8f4bb4) 5c:62:8b:0e:fe:1f
Oct 8 14:49:32 dnsmasq-dhcp[53048]: DHCPOFFER(enx70886b8f4bb4) 192.168.1.63 5c:62:8b:0e:fe:1f
Oct 8 14:49:32 dnsmasq-dhcp[53048]: DHCPREQUEST(enx70886b8f4bb4) 192.168.1.63 5c:62:8b:0e:fe:1f
Oct 8 14:49:32 dnsmasq-dhcp[53048]: DHCPACK(enx70886b8f4bb4) 192.168.1.63 5c:62:8b:0e:fe:1f smartpower2
$ ping smartpower2
PING smartpower2 example com (192.168.1.63) 56(84) bytes of data.
64 bytes from 192.168.1.63 (192.168.1.63): icmp_seq=1 ttl=255 time=6.18 ms
64 bytes from 192.168.1.63 (192.168.1.63): icmp_seq=2 ttl=255 time=2.71 ms
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 657
Replies: 6
Voters 0
No one has voted for it yet.