Bug: Stick Up cam sends bogus ARP response every few nights
Our Stick Up cam routinely disrupts our home network every few nights by sending a bogus ARP response claiming to be our router. I suspect there's either some routine maintenance happening on the device, or possibly it's renewing its DHCP lease at the time. The symptom is that my home FreeBSD server logs these messages at the time of network disconnections: arp: 192.168.1.1 moved from 34:97:f6:xx:xx:xx to 54:e0:19:xx:xx:xx on em0 arp: 192.168.1.1 moved from 54:e0:19:xx:xx:xx to 34:97:f6:xx:xx:xx on em0 192.168.1.1 is the address of the router of course, 34:97:f6::: is the router's MAC, and 53:e0:19::: is the MAC address of the Stick Up cam. Each time this ARP poisoning lasts only a few seconds because there's so much traffic going through the router, but it's enough to cause a disruption on the network. Here are the last handful of times it has happened from the system messages: Jun 24 20:06:08 turing kernel: arp: 192.168.1.1 moved from 34:97:f6:xx:xx:xx to 54:e0:19:xx:xx:xx on em0 Jun 24 20:06:21 turing kernel: arp: 192.168.1.1 moved from 54:e0:19:xx:xx:xx to 34:97:f6:xx:xx:xx on em0 Jun 25 01:44:16 turing kernel: arp: 192.168.1.1 moved from 34:97:f6:xx:xx:xx to 54:e0:19:xx:xx:xx on em0 Jun 25 01:44:21 turing kernel: arp: 192.168.1.1 moved from 54:e0:19:xx:xx:xx to 34:97:f6:xx:xx:xx on em0 Jul 2 01:12:20 turing kernel: arp: 192.168.1.1 moved from 34:97:f6:xx:xx:xx to 54:e0:19:xx:xx:xx on em0 Jul 2 01:12:31 turing kernel: arp: 192.168.1.1 moved from 54:e0:19:xx:xx:xx to 34:97:f6:xx:xx:xx on em0 Jul 4 03:08:11 turing kernel: arp: 192.168.1.1 moved from 34:97:f6:xx:xx:xx to 54:e0:19:xx:xx:xx on em0 Jul 4 03:08:35 turing kernel: arp: 192.168.1.1 moved from 54:e0:19:xx:xx:xx to 34:97:f6:xx:xx:xx on em0 Jul 6 01:22:24 turing kernel: arp: 192.168.1.1 moved from 34:97:f6:xx:xx:xx to 54:e0:19:xx:xx:xx on em0 Jul 6 01:22:50 turing kernel: arp: 192.168.1.1 moved from 54:e0:19:xx:xx:xx to 34:97:f6:xx:xx:xx on em0 Jul 8 02:48:44 turing kernel: arp: 192.168.1.1 moved from 34:97:f6:xx:xx:xx to 54:e0:19:xx:xx:xx on em0 Jul 8 02:49:05 turing kernel: arp: 192.168.1.1 moved from 54:e0:19:xx:xx:xx to 34:97:f6:xx:xx:xx on em0 As you can see it tends to happen in the middle of the night, and usually not more than once every two days, though on one day when we needed to reboot the cam a few times, it did it quite a bit more frequently and during the daytime. This is kind of annoying, anti-social behavior on the part of the Stick Up cam... if someone had a lot of these, it could really disrupt a network. As it happens, only the Stick Up cam does this- no other device on our network, including our Ring doorbell and Spotlight Cam, does. I'm happy to send the unredacted logs over to somebody at Ring if they want to look in more detail... in the mean time I'm going to see if our router can do some ARP response filtering from this device to prevent it from poisoning ARP caches on our network.
3701 •
0 •
3 •
09-07-2020 05:06:26
Responses (14)
- C
Hi neighbors! For a concern like this, it would be best for you to reach out to our support team directly as we are a neighbor-to-neighbor forum and cannot look into your account. You can give our support team a call at one of the numbers available [here](https://support.ring.com/hc/en-us/articles/213608406). If you are outside of the US, please visit [here ](https://support.ring.com/hc/en-gb/articles/213608406)to see how to contact support.. :)
•0
22-12-2020 08:14:08
•
SYeah I'm definitely going to call the off-shore support team and explain to them what ARP caches are. This needs to be escalated to someone responsible for maintaining the network stack of the cameras. It isn't something that any combination of settings, rebooting, removing, readding, etc., is going to change.
•0
15-12-2022 04:49:50
- U
Hello, this is still an issue. I had a device on 192.168.1.1 and it would lose network. in it's log I found that my Ring doorbell was requesting 1.1 even though it's configured to use another IP from my DHCP server. So it's a bug across multiple Ring devices. My work around is to change my other device IP, but this should be addressed by Ring.
•1
21-10-2021 02:51:11
•
SThat's a good idea actually. I'm going to try to change my default gateway to be 192.168.1.254 instead of 192.168.1.1 and see if the Ring cameras persist in trying to poison ARP caches for .1 or if they just switch and start trying to steal .254 instead.
•0
17-12-2022 12:17:13
SFWIW, the workaround to set your default gateway to have the IP address 192.168.1.254 instead of 192.168.1.1 does work. It's fiddly and convoluted and you shouldn't have to do it, but it works. You have to make sure you update your router's LAN IP as well as its DHCP server and DNS server configuration to ensure that you change all instances of 192.168.1.1 to 192.168.1.254, then restart your router to make everything on your network renew their DHCP leases. Anything that's hard-wired on the LAN into a switch needs to be unplugged from the switch or the switch restarted too; otherwise these devices may not realize that the network has changed. I reconfigured my DHCP pool to start at 192.168.1.2 and end at 192.168.1.253 so that I could put my router on 192.168.1.254 and ensure that nothing on the network would be assigned 192.168.1.1 by DHCP from the router. It's silly and messy but it works and keeps your Ring cameras with their firmware bug from causing everything on your home network to disconnect.
•0
08-01-2023 06:38:48
- P
I've removed our Stick Up Cameras from the network until this is resolved.
•0
23-10-2022 05:37:08
•
- S
Bumping this once again, because it's STILL a bug and it's STILL happening, more than two years after I initially reported it. Got this message last night from one of my servers, on which I had to create a permanent ARP table entry because the Stick-Up Cams kept hijacking it otherwise: ``` Dec 14 01:18:00 turing kernel: arp: 90:48:6c:xx:xx:xx attempts to modify permanent entry for 192.168.1.1 on em0 ``` Is anyone at Ring paying attention to this horrendous networking bug?
•0
15-12-2022 04:48:43
•
Didn't find an answer ?
Log in or create your Ring account to post a question and join in the on the conversation.
Community Resources
©2024 Ring LLC or its affiliates
shoek
Same thing happens to me... Would really like to hear from Ring on this! In my case I have a Pi-hole device at 192.168.1.1 and it was getting hijacked in the middle of the night every few days.
0
22-12-2020 02:00:12
•