Arlo Base Station sends ARP announcement for 192.168.1.1

[psayre23]

I have an Arlo Base Station (VMB4000r3) with the latest firmware. It is connected to my network through an ethernet cable. My network is a 192.168.1.0/24.

For the last several months, my internet has gone down for a couple minutes, and I was finally able to track down why. My router is receiving an ARP announcement for my Base Station's MAC address to be 192.168.1.1, which is my router's IP. When this happens, every device on my network tries to send internet traffic to the Base Station. Eventually, my router will emit an ARP announcement saying this it is 192.168.1.1, and everything is back to normal.

Why is the Base Station announcing that it is the router? How can I prevent this?

[StephenB]

---

@psayre23 wrote:

Why is the Base Station announcing that it is the router? How can I prevent this?

---

One possibility is that the base is somehow getting 192.168.1.1 from the router's DHCP server.

Have you tried assigning/reserving the IP address in the router?  Most routers have that facility (though the name of the feature depends on the manufacturer).

[psayre23]

That is a great idea! Let me give that a shot.

I don't have a great way to find out if the ARP announcement from the Base Station is proceeded by the Router telling it to be 192.168.1.1 (which would be really odd, but I can't rule it out). I'll try that and report back in a couple weeks if this helped.

[psayre23]

Just had it happen again. Even with my router's DHCP manually setting the IP for the Base Station, it still sends an ARP packet as 192.168.1.1.

[arlouser503]

Just wanted to let you know that I'm having the same issue on my network. Do you by any chance have the wireless door chime connected to your wifi?

Initially, I thought the issue was with the Arlo Base station randomly sending arp announcements for 192.168.1.1, which is my router's address. (Obviously .1 is not in my DHCP pool or this would potentially be happening with literally any devices on my network using DHCP to obtain IP addresses).  After matching up mac addresses though, it looks like the .1 announcements are actually coming from the wireless door chime!

I've verified it via my firewall logs and with packet captures.  It's confusing because the chime already has an IP address assigned successfully (in my case it's using 192.168.1.120) when it suddenly begins broadcasting itself as .1. I'm wondering if there's some default IP address baked into the chime that rears its head when its dhcp lease times out. Whatever the reason, this is such horrible behavior from a wireless device, I have no idea why it's doing it.

I'm going to just pick a new completely different subnet to use for my home network (which is a pain due to a lot of static assignments for port fwd'ing etc) but I've tried everything else I can think of, other than just isolating it on its own vlan entirely. 

[PaulJeff]

I'm seeing the same issue as you describe @arlouser503.

I have an Arlo Chime with the following details;

Firmware: 1.1.0.0_299_7c2d1e3

Hardware: AC2001Aer1.2

Serial Number: A91218WP007A9

It's plugged into a mains outlet and connects via WiFi to my home network.

My home network uses the 192.168.1.0/24 subnet and my router is 192.168.1.1

I was just moving the Chime from one room to another when I noticed that each time I plugged it back in (I was trying it in different rooms to check volume etc), my laptop and other devices in the house lost Internet connectivity for about 1-2 minutes every time.

My Ubiquity network reported an error, saying "Multiple devices are using the same IP address?: 192.168.1.1. Please check each device's configuration and ensure that none are communicating with a rogue DHCP server." at the time.

Which alerted me to the fact that there may be an issue with the Arlo devices choosing to be 192.168.1.1 briefly when they first plug in.  Your post above confirmed it and I just did a packet capture and can see exactly what you describe.

Shortly after plugging in the Arlo Chime (which has been configured and working elsewhere for weeks) it does indeed send out a Gratuitous ARP as if it was 192.168.1.1 ! See packet cap below.  It sends out a bunch of additional ARP requests straight after too.

Then when my Ubiquiti router sends out a gratuitous ARP itself, for 192.168.1.1 (which it does once every 90 odd seconds) then everything works again as expected.

Best I can tell the Arlo Chime only does it once when its powered up and does not do it again, but I may not have waited long enough to know that for sure (I only monitored for 1 hour).

The interesting/unfortunate thing is my WiFi Arlo cameras also seem to do it!

I have two Arlo Essential Indoor WiFi cameras and they both caused the same brief outage when I powered them up after moving them from one room to another.

I will try and open a support ticket to see if this behaviour can be fixed.

Thanks,

Paul

[StephenB]

---

@PaulJeff wrote:

Shortly after plugging in the Arlo Chime (which has been configured and working elsewhere for weeks) it does indeed send out a Gratuitous ARP as if it was 192.168.1.1 ! See packet cap below.  It sends out a bunch of additional ARP requests straight after too.

Then when my Ubiquiti router sends out a gratuitous ARP itself, for 192.168.1.1 (which it does once every 90 odd seconds) then everything works again as expected.

Best I can tell the Arlo Chime only does it once when its powered up and does not do it again, but I may not have waited long enough to know that for sure (I only monitored for 1 hour).

The interesting/unfortunate thing is my WiFi Arlo cameras also seem to do it!

I have two Arlo Essential Indoor WiFi cameras and they both caused the same brief outage when I powered them up after moving them from one room to another.

I will try and open a support ticket to see if this behaviour can be fixed.

---

It sounds like Arlo might be using 192.168.1.1 as a failover address when DHCP times out.  If so, that is a very bad choice of address on their part.  Normally you'd expect a 169.254.x.x address in that situation.  

I'm tagging the mods ( @JamesC and @ShayneS ) so they can follow up.  It would be good if you open a support case, and give them the case number.

[PaulJeff]

Hi Stephen,

Thanks for your response, I tend to agree with your analysis. Not sure why DHCP would have been failing at that time (I understand networking etc) but regardless it’s certainly something that can happen.  That said, no device (other than a router) should default to an address like 192.168.1.1 that is so commonly used by routers these days.

I’m not keen to raise a support case etc, to be honest it’s something I have provided enough info on already as have others, Arlo should just fix it. Oh and they should also respond to a legit product issue like this one here in their forum. It’s not up to the community to do additional work for them. 

Thanks,

Paul

[StephenB]

---

@PaulJeff wrote:

That said, no device (other than a router) should default to an address like 192.168.1.1

---

Totally agree.  Even in the router case, I wouldn't want the WAN address to fail over to 192.168.1.1 

[psayre23]

5 months in, and the only solution I have is to not use the chimes. This can't be the solution, right?

[arlouser503]

My workaround was to essentially put this device on its own vlan, its own ssid, with a different subnet. So it can go ahead and broadcast itself however it wants and it won't impact the rest of my network.

I can at least confirm that this still works even though the doorbell is on a different subnet from the chime (my firewall is configured to allow connections from doorbell subnet --> chime subnet, but only established connections in the other direction), so that's something.

I haven't bothered to do any packet captures to see if it's advertising the gw for the new subnet it's on or if it's still advertising 192.168.1.1 randomly, because frankly I've already spent too much time on this stupid issue already 😂

[Skrapreg]

I'm experiencing the same issue with three Arlo Essential Indoor WiFi cameras. They're not only sending these bogus ARP announcements at startup but also throughout the day, causing my router to go offline and disrupting connectivity for other devices. The MACs in the router's kernel log belong to the three cameras:

Jul  8 20:13:41 ix kernel: arp: fc:9c:98:8b:d9:4a is using my IP address 192.168.1.1 on igb2!
Jul  8 21:46:44 ix kernel: arp: fc:9c:98:8b:d9:1c is using my IP address 192.168.1.1 on igb2!
Jul  8 23:19:46 ix kernel: arp: fc:9c:98:8b:d9:6a is using my IP address 192.168.1.1 on igb2!
Jul  9 04:25:00 ix kernel: arp: fc:9c:98:8b:d9:4a is using my IP address 192.168.1.1 on igb2!
Jul  9 05:50:09 ix kernel: arp: fc:9c:98:8b:d9:1c is using my IP address 192.168.1.1 on igb2!
Jul  9 06:26:57 ix kernel: arp: fc:9c:98:8b:d9:6a is using my IP address 192.168.1.1 on igb2!
Jul  9 10:29:21 ix kernel: arp: fc:9c:98:8b:d9:4a is using my IP address 192.168.1.1 on igb2!
Jul  9 11:56:20 ix kernel: arp: fc:9c:98:8b:d9:1c is using my IP address 192.168.1.1 on igb2!
Jul  9 12:31:59 ix kernel: arp: fc:9c:98:8b:d9:6a is using my IP address 192.168.1.1 on igb2!

[StephenB]

---

@Skrapreg wrote:

I'm experiencing the same issue with three Arlo Essential Indoor WiFi cameras. They're not only sending these bogus ARP announcements at startup but also throughout the day, causing my router to go offline and disrupting connectivity for other devices. The MACs in the router's kernel log belong to the three cameras:

---

That should be fixed of course.  @JamesC - can you confirm this logged as an issue?

One work-around is to change the router IP subnet to another private address range.  192.168.0.x should work (or 10.0.0.x).