Closed albertogeniola closed 2 years ago
stale[bot]
commented
3 years ago This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
stale[bot]
commented
2 years ago This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
fuomag9
commented
8 months ago I've also seen:
I seem to have had some time drifting issues and I've tried rewriting queries to the Europe server (why would I use the North America one if I'm in Europe!!!) and I hope that improves it
During the pairing phase, the Meross hardware devices do require time setup via NTP protocol. The NTP query happens just after the device connects to the Wifi network, before joining the MQTT broker. The Meross device stalls in this state until the NTP query succeeds. The problem is that, when running on a local LAN, NTP might not be available. Moreover, it seems that Meross devices are uncapable of using the ntp-server configuration via dhcp option; instead it seems they only trust a bunch of NTP servers that are hardcoded in their firmware.
I was able to confirm this by applying specific man-in-the-middle attack on a MSS425 power strip. Here's the sniffed data from the device when access to the external internet was denied:
As you can see, the device continuously tries to reach the following NTP servers (even if a local NTP server is available in the LAN network and its address was pushed via DHCP option):
I was able to "trick" the device by mapping pool.ntp.org to the local ntp server on the lan (by adding an explicit DNSMASQ rule): that was enough to let the device acquire the time and complete the pairing phase.
This is a road-blocker for LAN-ONLY usage without internet access, which might turn into a show stopper when the user is not able to run its own dnsmasq + ntp daemon (local) service.