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.
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. If you are outside of the US, please visit here to see how to contact support…
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.
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 <kern.err> 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?
Yeah 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.
Hi @spatula. As mentioned in the previous comment, you will have to contact our support team to take a deeper look into your concern. The Ring Community is a public forum where I, other members of my team, or other neighbors can assist with general troubleshooting tips and tricks.
No, I need my report forwarded to someone who actually understands what ARP is and why broadcasting ARP pretending to be the router on a network is bad. Support folks on the phone have no idea what I’m talking about. If it doesn’t involve restarting the device, resetting it, removing it from our home and re-adding it, they don’t have a clue.
You need a way for issues like this to be escalated to someone who cares and has the capacity to actually comprehend and address the problem. This has been going on for YEARS without resolution because nobody at Ring can be bothered to listen.
That’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.
First it masquerades as 192.168.1.1 trying to figure out where 192.168.1.1 is, and then it masquerades as 192.168.1.1 looking for… itself, on the address it actually has, 192.168.1.55.
This is so very broken and wrongful behavior, and it’s a shame it’s impossible to get anyone at Ring to pay attention. Support is totally useless if it doesn’t entail rebooting, removing, re-adding, or RMA-ing a device.
Someone who actually works on the network stack for the cameras needs to see this.
*Jan 5 02:42:48: %ARP-4-ARPCHANGEMAC: ARP entry 192.168.1.1 on VLAN 1 changed c471.XXXX.XXXX to 9c76.XXXX.XXXX due to ARP packet from GigabitEthernet 0/12.
*Jan 2 18:40:16: %ARP-4-ARPCHANGEMAC: ARP entry 192.168.1.1 on VLAN 1 changed c471.XXXX.XXXX to 9c76.XXXX.XXXX due to ARP packet from GigabitEthernet 0/12.
*Dec 30 10:42:01: %ARP-4-ARPCHANGEMAC: ARP entry 192.168.1.1 on VLAN 1 changed c471.XXXX.XXXX to 9c76.XXXX.XXXX due to ARP packet from GigabitEthernet 0/12.
*Dec 29 02:20:10: %ARP-4-ARPCHANGEMAC: ARP entry 192.168.1.1 on VLAN 1 changed c471.XXXX.XXXX to 9c76.XXXX.XXXX due to ARP packet from GigabitEthernet 0/12.
*Dec 23 00:45:49: %ARP-4-ARPCHANGEMAC: ARP entry 192.168.1.1 on VLAN 1 changed c471.XXXX.XXXX to 9c76.XXXX.XXXX due to ARP packet from GigabitEthernet 0/12.
*Dec 17 03:00:38: %ARP-4-ARPCHANGEMAC: ARP entry 192.168.1.1 on VLAN 1 changed c471.XXXX.XXXX to 9c76.XXXX.XXXX due to ARP packet from GigabitEthernet 0/12.
*Dec 8 22:00:41: %ARP-4-ARPCHANGEMAC: ARP entry 192.168.1.1 on VLAN 1 changed c471.XXXX.XXXX to 9c76.XXXX.XXXX due to ARP packet from GigabitEthernet 0/12.
Not sure why the ring device wants to claim being 192.168.1.1, but for now I have changed the configuration of both the AP and the network switch to make the ARP entries static for the gateway IP.
There is no reason why the camera (Ring Stick Up Cam Battery) wants to become the gateway. Unless Amazon is putting in some SIM cards so I can still get internet?
Looks like it might be something in the camera firmware?
EDIT:
I already had static ARPs set up on my main switch.
*Jan 5 02:31:15: %ARP-4-STATICARPOVR: Attempt to overwrite c471.XXXX.XXXX for static ARP entry 192.168.1.1 by 9c76.XXXX.XXXX due to ARP packet from GigabitEthernet 0/11.
*Jan 2 18:28:55: %ARP-4-STATICARPOVR: Attempt to overwrite c471.XXXX.XXXX for static ARP entry 192.168.1.1 by 9c76.YYYY.YYYY due to ARP packet from GigabitEthernet 0/11.
*Jan 2 18:28:44: %ARP-4-STATICARPOVR: Attempt to overwrite c471.XXXX.XXXX for static ARP entry 192.168.1.1 by 9c76.YYYY.YYYY due to ARP packet from GigabitEthernet 0/11.
*Dec 30 10:30:30: %ARP-4-STATICARPOVR: Attempt to overwrite c471.XXXX.XXXX for static ARP entry 192.168.1.1 by 9c76.XXXX.XXXX due to ARP packet from GigabitEthernet 0/11.
*Dec 29 02:08:40: %ARP-4-STATICARPOVR: Attempt to overwrite c471.XXXX.XXXX for static ARP entry 192.168.1.1 by 9c76.XXXX.XXXX due to ARP packet from GigabitEthernet 0/11.
*Dec 23 00:34:20: %ARP-4-STATICARPOVR: Attempt to overwrite c471.XXXX.XXXX for static ARP entry 192.168.1.1 by 9c76.XXXX.XXXX due to ARP packet from GigabitEthernet 0/11.
*Dec 17 02:49:11: %ARP-4-STATICARPOVR: Attempt to overwrite c471.XXXX.XXXX for static ARP entry 192.168.1.1 by 9c76.XXXX.XXXX due to ARP packet from GigabitEthernet 0/11.
*Dec 8 21:49:15: %ARP-4-STATICARPOVR: Attempt to overwrite c471.XXXX.XXXX for static ARP entry 192.168.1.1 by 9c76.XXXX.XXXX due to ARP packet from GigabitEthernet 0/11.
Two cameras. ( 9c76.YYYY.YYYY and c471.XXXX.XXXX ). Both showing the same behavior. That’s three cameras across two different networks and access points.
FWIW, 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.
I was having this same issue with my Ring Chime and so I changed my router’s IP address to 192.168.1.254 as suggested but now my Ring Chime refuses to join the network. I can see the DHCP requests and it looks like it’s successfully joined my network, but the Ring Chime shows as offline and gives me a blinking blue light which means it can’t connect to the network. It seems like it really needs my router to be at 192.168.1.1 to function, but then randomly sends ARP packets and disrupts my network.
Same issue here. The only way to fix this is to kick the device off the wireless network and let it re-connect. That fixes things for a time, until some other device (or multiple RING devices) adopts 192.168.1.1. Fortunately, I’m not using that subnet, so I just have endless irritating logs in my wireless controller. RING folks, please fix this issue - or at least pretend to care!
Having this issue here. WTF Ring this is pretty nasty and random. I’ve never seen any other device do this even stuff from Alibaba has the decency to not ARP for itself as a gateway and this was reported to you over 3 years ago???
Same issue here on my Ubiquiti network. It’s been happening for at least a year and I have had these Ring cameras for at least 5 years, so this is most likely a bug Ring introduced. Setting DHCP reservation on the cams does not fix. I end up having to reboot my wireless AP once a week. This issue has been very annoying.
Same issue here, again on a Ubiquiti network. I’d love to change the 192.168.1.1 device IP but I know this is going to be disruptive and I don’t have the time to deal with it.
The symptom I’m seeing is in the Ubiquiti Network application, client device list shows the stick-up cam (I have two and both exhibit the problem) as having an IP address of 192.168.1.1. If I access the camera via the Ring app it works (live view etc.) and I’ll see Ubiquiti Network application report it with its correct IP 192.168.xx.yy address.
The temporary workaround it is reconnect the stick-up cam to WiFi then it stops. But the problem comes back after a day or so.
In my case the Ring devices are fully isolated on a separate VLAN. This means that if they appear as 192.168.1.1 then they are unable to impact the real 192.168.1.1 device which is on the main network.
Do other users here have VLANs set up, and with Ring / IoT devices isolated? I don’t know whether it is a factor in this case, but I’m sure it would be useful to Ring if they are investigating.
Like others on this thread I’d be happy to assist Ring in pinning down this issue, if indeed they are interested, and investigating.
Same issue here as well, and despite 6 months of calling in, 2 escalations and hours on hold I have gotten no where with support. As told yesterday there isnt enough folks calling in about this issue so the support group considers this an “un-established”. I would highly suggest anyone else facing the problem to ensure you reference this thread when calling in so there is some consensus.
