NTP Intercept causes Eufy Doorbell camera not to work

[odiovidio]

I have a Eufy doorbell on Guest Network 1 (GT-AX6000 388.1_0_rog). If I have NTP intercept ON, the doorbell keeps trying different NTP servers every few seconds, which means it's probably not getting the response it's waiting for.

Come to think of it, this issue started around the time I updated the firmware to 388.1.
As soon as I shut off NTP intercept, the camera starts working again and stops pinging different NTP servers.

Is this a bug in 388.1?

 

[Huib]

I don't have 388.1 but do you also have the router set to be an NTP server? Maybe that got lost/changed in the upgrade?

 

[odiovidio]

Yes, "Enable Local NTP Server" is set to "Yes". I have tried setting it to "No", then Apply, then back to "Yes" then apply. But still the same problem.

 

[RMerlin]

Is the device connected to a Guest Network or one of the regular Wifi networks?

If you have access to a Linux machine, you can test ntp this way, using your router's IP address as the server:

sudo ntpdate 192.168.50.1

Then, try again using a remote server like time.nrc.ca to ensure that the redirection is also working.

Otherwise, maybe it's using some form of authentication to prevent hijacking/redirections, although I thought that required using a different port than the default 123 port.

 

[odiovidio]

Yes, the doorbell is on the 2.4 guest network

Here is the ntpdate output from my NAS: (not the doorbell)

 

[odiovidio]

checked the firewall rules...does this look correct?

 

[RMerlin]

Yes, the doorbell is on the 2.4 guest network

Guest Network 1 or 2?

Is the option to Access Intranet enabled or disabled?

 

[odiovidio]

Guest Network 1. Access Intranet disabled.

 

[RMerlin]

Guest Network 1. Access Intranet disabled.

That might be why. I fixed an issue in 388.1 related to NTP redirection on Guest Network 1, but I don't know if it would still work if Intranet access was disabled.

You could try switching to Guest Network 2 instead, which is generally less problematic since it's not customized to interface with AiMesh networks.

 

[odiovidio]

Switching to Guest Network 2 seems to have fixed it.

However, new question: I see that Guest Network 2 uses the same subnet as the normal network 192.168.50.0/24. How does it now block the guest network devices from accessing Intranet?

 

[RMerlin]

Switching to Guest Network 2 seems to have fixed it.

However, new question: I see that Guest Network 2 uses the same subnet as the normal network 192.168.50.0/24. How does it now block the guest network devices from accessing Intranet?

I believe It uses ebtable rules to block at the L2 level (which is actually more reliable than just relying on a different subnet, as this can be bypassed). My memory can be wrong tho, I haven`t looked at that part of the code in years.

I'll still have a look to see if I can make it work even with Intranet isolation on GN1, but I have my doubts.

 

[odiovidio]

ebtables doesn't show any rules set...

 

[ColinTaylor]

ebtables doesn't show any rules set...

View attachment 46161

You need to look at the BROUTING:

ebtables -t broute -L

 

[octopus]

ebtables doesn't show any rules set...

View attachment 46161

ebtables -t broute -L

 

[odiovidio]

ah yes, there they are:

Thanks guys!

 

[sfx2000]

This is kind of a hack I do on my private OpenWRT builds...

# Redirect NTP requests to go through router
iptables -t nat -A PREROUTING -i br-lan -p udp --dport 123 -j DNAT --to 192.168.1.1
iptables -t nat -A PREROUTING -i br-guest -p udp --dport 123 -j DNAT --to 192.168.1.1

 

[RMerlin]

This is kind of a hack I do on my private OpenWRT builds...

# Redirect NTP requests to go through router
iptables -t nat -A PREROUTING -i br-lan -p udp --dport 123 -j DNAT --to 192.168.1.1
iptables -t nat -A PREROUTING -i br-guest -p udp --dport 123 -j DNAT --to 192.168.1.1

That`s pretty much what Asuswrt-Merlin does, and which works for regular clients, but there might be an issue with Guest Network 1 as it does not use the same bridge as the rest of the LAN.

 2300  175K REDIRECT   udp  --  br0    *       0.0.0.0/0            0.0.0.0/0            udp dpt:123 redir ports 123

 

[RMerlin]

I see the problem. Wireless Guest Network 1 uses a different network interface, and the firewall rules (which allows DNS and DHCP) for that interface are created in the closed source portion of AiMesh. I will need to figure out how they generate these rules, and insert my own rules to handle NTP traffic.

 

[RMerlin]

Properly implementing this for Guest Network 1 would require starting a separate ntpd for each of the bands... Not worth it, so I'll just remove the ntp redirection that's implemented for Guest Network 1 to ensure that clients will at least still be able to connect to their intended ntp server.

 

[unsynaps]

Why is it connected to the guest network? Just connect it to the main and be done with it.