First of all, huge thanks to the developer team. Firmware version 2024.4.3-12 solved some of the reported bugs. If the community gets better and better firmware, I think we can overcome the sporadic communication. (And communication is hard; I get it.) Please keep up the great work!
Problem description
I kept having problems with the local API, even after the update to 2024.4.3-12. Usually, after boot, the port is not open or is only open for a short time. (Symptoms are described in the previous issue.)
Possible bug
Eventually, I narrowed the problem to a DHCP server setting on the network:
if DHCP option 42 (NTP) is set to an IP address that does not provide NTP services, the local API eventually "times out" and closes port 8443.
This is interesting because of the observations described before:
The Tahoma Switch requests a network time update during boot from ha-ntp.overkiz.com. This succeeds in my network, and it also makes me assume that any subsequent NTP updates will also come from this server.
Somewhere in the firmware, there must be an NTP request that uses what dhcpc reported as the NTP server instead of Overkiz's hard-wired domain.
Further observation
The local API stays open as expected if there is a valid IP address in DHCP option 42 (NTP Server) that is capable of resolving NTP requests.
The local API stays open as expected if DHCP Option 42 (NTP Server) is not set.
The local API stays open if the Tahoma Switch was booted in recovery mode. (PIN pushed while turning on)
The time until the local API port closes can vary from a few minutes to hours. If DHCP Option 42 is set up after the Tahoma Switch comes online, the port closes after some time, not immediately.
There might be a downstream dependency that is requesting NTP updates.
I ran Wireshark but could not catch a request to the invalid NTP server. This might be interesting to pursue further.
Request
I would appreciate it if this could be corrected in a subsequent firmware update. Based on the boot sequence (and for a mild security enhancement), hard-wiring the NTP requests to ha-ntp.overkiz.com might be an agreeable solution. Alternatively, more descriptive documentation mentioning the importance of correct DHCP settings (including optional parameters) would also be appreciated.
This is a continuation of issue #139 .
First of all, huge thanks to the developer team. Firmware version 2024.4.3-12 solved some of the reported bugs. If the community gets better and better firmware, I think we can overcome the sporadic communication. (And communication is hard; I get it.) Please keep up the great work!
Problem description
I kept having problems with the local API, even after the update to 2024.4.3-12. Usually, after boot, the port is not open or is only open for a short time. (Symptoms are described in the previous issue.)
Possible bug
Eventually, I narrowed the problem to a DHCP server setting on the network: if DHCP option 42 (NTP) is set to an IP address that does not provide NTP services, the local API eventually "times out" and closes port 8443.
This is interesting because of the observations described before: The Tahoma Switch requests a network time update during boot from
ha-ntp.overkiz.com. This succeeds in my network, and it also makes me assume that any subsequent NTP updates will also come from this server.Somewhere in the firmware, there must be an NTP request that uses what
dhcpcreported as the NTP server instead of Overkiz's hard-wired domain.Further observation
There might be a downstream dependency that is requesting NTP updates.
I ran Wireshark but could not catch a request to the invalid NTP server. This might be interesting to pursue further.
Request
I would appreciate it if this could be corrected in a subsequent firmware update. Based on the boot sequence (and for a mild security enhancement), hard-wiring the NTP requests to
ha-ntp.overkiz.commight be an agreeable solution. Alternatively, more descriptive documentation mentioning the importance of correct DHCP settings (including optional parameters) would also be appreciated.