Wired Arlo Video Doorbell Randomly Disconnects (AVD1001Ar1.2) (Ubiquiti/Unifi Network)

[ArloUser1925]

Device: Arlo Video Doorbell (Wired)
Hardware: AVD1001Ar1.2
Firmware: 1.14.0.0_1117_c9951d1_b4efa46

Network: Ubiquiti EdgeRouter Lite + Ubiquiti Unifi AP-AC Lite (connected to UAP AC Lite on 2.4GHz)

Ever since I installed my wired Arlo Video Doorbell, it's been negatively affecting my network as well as resulting in the camera not functioning. I have began to notice that from time-to-time the Arlo Doorbell causes my entire network to crash. I reached out to my network equipment's forum thinking the issue was with them, but I'm pretty sure the Arlo device is at fault. After all, it's the only device that is left without an allocated IP address when the network comes back up after it essentially takes it down.

From what I have noticed, every time the network goes down, the following logs are outputted on my router:

Aug 20 12:36:14 ubnt kernel: IPv4: martian source 192.168.1.1 from 192.168.1.1, on dev eth1
Aug 20 12:36:14 ubnt kernel: ll header: 00000000: ff ff ff ff ff ff a4 11 62 3c 50 39 08 06    ........b<P9..
Aug 20 12:42:16 ubnt kernel: IPv4: martian source 192.168.1.1 from 192.168.1.1, on dev eth1
Aug 20 12:42:16 ubnt kernel: ll header: 00000000: ff ff ff ff ff ff a4 11 62 3c 50 39 08 06    ........b<P9..
Aug 20 12:43:20 ubnt kernel: IPv4: martian source 192.168.1.1 from 192.168.1.1, on dev eth1
Aug 20 12:43:20 ubnt kernel: ll header: 00000000: ff ff ff ff ff ff a4 11 62 3c 50 39 08 06    ........b<P9..

and for another example

Aug 21 06:39:32 ubnt kernel: IPv4: martian source 192.168.1.1 from 192.168.1.1, on dev eth1
Aug 21 06:39:32 ubnt kernel: ll header: 00000000: ff ff ff ff ff ff a4 11 62 3c 50 39 08 06        ........b<P9..
Aug 21 06:45:35 ubnt kernel: IPv4: martian source 192.168.1.1 from 192.168.1.1, on dev eth1
Aug 21 06:45:35 ubnt kernel: ll header: 00000000: ff ff ff ff ff ff a4 11 62 3c 50 39 08 06        ........b<P9..
Aug 21 06:46:38 ubnt kernel: IPv4: martian source 192.168.1.1 from 192.168.1.1, on dev eth1
Aug 21 06:46:38 ubnt kernel: ll header: 00000000: ff ff ff ff ff ff a4 11 62 3c 50 39 08 06        ........b<P9..
Aug 21 06:47:39 ubnt kernel: IPv4: martian source 192.168.1.1 from 192.168.1.1, on dev eth1
Aug 21 06:47:39 ubnt kernel: ll header: 00000000: ff ff ff ff ff ff a4 11 62 3c 50 39 08 06        ........b<P9..
Aug 21 06:47:42 ubnt kernel: IPv4: martian source 192.168.1.65 from 192.168.1.1, on dev eth1
Aug 21 06:47:42 ubnt kernel: ll header: 00000000: ff ff ff ff ff ff a4 11 62 3c 50 39 08 06        ........b<P9..
Aug 21 06:47:42 ubnt kernel: IPv4: martian source 192.168.1.64 from 192.168.1.1, on dev eth1
Aug 21 06:47:42 ubnt kernel: ll header: 00000000: ff ff ff ff ff ff a4 11 62 3c 50 39 08 06        ........b<P9..
Aug 21 06:47:42 ubnt kernel: IPv4: martian source 192.168.1.76 from 192.168.1.1, on dev eth1
Aug 21 06:47:42 ubnt kernel: ll header: 00000000: ff ff ff ff ff ff a4 11 62 3c 50 39 08 06        ........b<P9..
Aug 21 06:47:44 ubnt kernel: IPv4: martian source 192.168.1.91 from 192.168.1.1, on dev eth1
Aug 21 06:47:44 ubnt kernel: ll header: 00000000: ff ff ff ff ff ff a4 11 62 3c 50 39 08 06        ........b<P9..
Aug 21 06:47:49 ubnt kernel: IPv4: martian source 192.168.1.92 from 192.168.1.1, on dev eth1
Aug 21 06:47:49 ubnt kernel: ll header: 00000000: ff ff ff ff ff ff a4 11 62 3c 50 39 08 06        ........b<P9..
Aug 21 06:47:50 ubnt kernel: IPv4: martian source 192.168.1.92 from 192.168.1.1, on dev eth1
Aug 21 06:47:50 ubnt kernel: ll header: 00000000: ff ff ff ff ff ff a4 11 62 3c 50 39 08 06        ........b<P9..
Aug 21 08:25:57 ubnt kernel: IPv4: martian source 192.168.1.1 from 192.168.1.1, on dev eth1
Aug 21 08:25:57 ubnt kernel: ll header: 00000000: ff ff ff ff ff ff a4 11 62 3c 50 39 08 06        ........b<P9..

As you can see, the Arlo Doorbell as indicated by the martian's packet header (a4 11 62) keeps sending martian sources. Now, I don't understand martian packets entirely, but from what little I gathered, it keeps attempting to connect or host its own network connection on 192.168.1.1 (more on this later). By this time, my whole internet is crashed, even my wired connections let alone my wireless AP (more on this later). The only solution I found to bring my network and therefore Arlo back up is to restart my AP and wait for the Arlo to obtain it's IP again.

Some background information on my network and how I connected my Arlo to my network:

My UAP broadcasts both a 2.4 GHz and 5 GHz connection and decides how each device connects based on it's signal and if it can broadcast/transmit data at a particular rate. Prior to resetting my Arlo, I set up my Arlo from my phone that was connected via 2.4 GHz as instructed in the directions. After dealing with the described issues above, I reset my Arlo and created a new WLAN that only was broadcasting via 2.4 GHz. I connected my phone to the respective 2.4 GHz only network and set up my Arlo. After setting it up, I switched my Wi-Fi on my phone back to the main network that broadcasts via 2.4 GHz or 5 GHz. This did not help and my network still crashed. I noticed today that my Arlo is no longer even connected to the 2.4 GHz only network, but the same one as my phone and the main network that is broadcasting via 2.4 GHz or 5 GHz.

----

What I believe is the issue:

At first I thought that maybe that the AP at times noticed the Doorbell had a good enough connection and was being switched over to the 5G channel. Additionally, the Arlo is the only device on the network that would not get an IP address despite even setting up a static IP for it via my router. However, despite if this is the case or not, I think it may be a separate issue. As I mentioned previously I had sought out help via my network equipment's forum. The latest reply mentioned the following that seems to make sense judging by the martian packets too:

I am wondering if the Arlo has a default of 192.168.1.1 and sometimes it isn't getting a renewal, and "falls back to" 192.168.1.1 which conflicts with your ER-lite

Is this what is happening? Because my ER-Lite is in fact on 192.168.1.1 and as said multiple times, the martian packet source is pointing to 192.168.1.1 but the header indicates that it is coming from the Arlo Doorbell.

---

I would really appreciate some assistance because I would want returning the doorbell to be the last case scenario. I don't have an issue with other devices on my wireless network. This is the first time it's happening to me, and it has been the case ever since I connected my Arlo to my network.

[StephenB]

---

@ArloUser1925 wrote:

Aug 20 12:36:14 ubnt kernel: IPv4: martian source 192.168.1.1 from 192.168.1.1, on dev eth1
Aug 20 12:36:14 ubnt kernel: ll header: 00000000: ff ff ff ff ff ff a4 11 62 3c 50 39 08 06

---

FWIW, A martian packet is a packet that appears to have an illegal (or inappropriate) source or destination address.

The second line is the beginning of the ethernet header of the packet.

• ff ff ff ff ff ff: means that the packet is a broadcast packet (being sent to all devices on the local network).
• a4 11 62 3c 50 39: is the mac address of the device sourcing the packet.  
• 08 06: means this particular packet is an ARP packet.  https://en.wikipedia.org/wiki/Address_Resolution_Protocol

I don't recall if the mac address of the doorbell is printed on the label somewhere or not.  If the doorbell is on your network, you should be able to see the doorbell's mac address in the router's attached device list - that would let you confirm that the packet is coming from the doorbell.

It's hard to know why the packet is being flagged as Martian without seeing the the rest of it.  You could install wireshark on a PC, and look for it. 

This ARP packet is normally sent by the client in order to let everyone else on the network know the MAC address associated with its IP address.  That is why it is using a broadcast packet.  It shouldn't be saying its IP address is 192.168.1.1, since that is your router's address.

If this is a malformed ARP packet, you'd need to pursue that with Arlo support (it would need to be escalated up to development).  @JamesC or @Mark-V might be able to help.

---

@ArloUser1925 wrote:

After all, it's the only device that is left without an allocated IP address when the network comes back up after it essentially takes it down.

---

Can you explain what you mean by this?

---

@ArloUser1925 wrote:

Additionally, the Arlo is the only device on the network that would not get an IP address despite even setting up a static IP for it via my router.

---

Again, more details on it not getting an IP address would be helpful.  The doorbell can't function without getting an IP address.

To clarify terminology: There are two ways to get a persistent IP address for a device. 

One way is to assign a static IP address in the device itself.  The router is not involved at all, the device is simply told what IP address it is to use.

The second way is to reserve an IP Address in the router.  The device requests a dynamic IP address from the router, but the router always returns the same address (that is, the one you reserved).  The device has no idea that the address is reserved, that is totally internal to the router.  It's best to refer to this as "address reservation", in order to distinguish it from the direct assignment used in the first method (which is normally called a "static address").

Arlo doesn't let you configure the IP address in their devices, so only address reservation is available (FWIW, it is better anyway, since it consolidates IP address management in the router). 

Possibilities here:

• Something is wrong with the doorbell.  This would be very unusual problem - if it was widespread, ten I'd expect to have seen this show up for everyone.  You could try resetting the doorbell, and see if that resolves it.
• Something is wrong with the IP address you specified in the reservation.  That also seems unlikely, since most routers won't let you enter an illegal IP address for your network.  But you could also delete the reservation, and see if that makes a difference.

[ArloUser1925]

---

@StephenB wrote:

I don't recall if the mac address of the doorbell is printed on the label somewhere or not.  If the doorbell is on your network, you should be able to see the doorbell's mac address in the router's attached device list - that would let you confirm that the packet is coming from the doorbell.

I can confirm the mac address matches my Doorbell looking at my access points dashboard.

---

@StephenB wrote:

This ARP packet is normally sent by the client in order to let everyone else on the network know the MAC address associated with its IP address.  That is why it is using a broadcast packet.  It shouldn't be saying its IP address is 192.168.1.1, since that is your router's address.

If this is a malformed ARP packet, you'd need to pursue that with Arlo support (it would need to be escalated up to development).  @JamesC or @Mark-V might be able to help.

---

---

That is what someone brought up as a possible scenario of what is happening: the Doorbell setting itself on 192.168.1.1. As to why it happens, I have no clue. I'm not very technical let alone the fact that the issue happens completely at random so sniffing the packets with Wireshark on my network seems like a bad idea. Would have to monitor traffic until the issue occurs and I have multiple devices connected and using the network throughout the day. Unless there is a way to filter out specific IPs from being monitored I would like to avoid using Wireshark.

---

@StephenB wrote:

---

@ArloUser1925 wrote:

After all, it's the only device that is left without an allocated IP address when the network comes back up after it essentially takes it down.

---

Can you explain what you mean by this?

---

@ArloUser1925 wrote:

Additionally, the Arlo is the only device on the network that would not get an IP address despite even setting up a static IP for it via my router.

---

Again, more details on it not getting an IP address would be helpful.  The doorbell can't function without getting an IP address.

To clarify terminology: There are two ways to get a persistent IP address for a device. 

One way is to assign a static IP address in the device itself.  The router is not involved at all, the device is simply told what IP address it is to use.

The second way is to reserve an IP Address in the router.  The device requests a dynamic IP address from the router, but the router always returns the same address (that is, the one you reserved).  The device has no idea that the address is reserved, that is totally internal to the router.  It's best to refer to this as "address reservation", in order to distinguish it from the direct assignment used in the first method (which is normally called a "static address").

Arlo doesn't let you configure the IP address in their devices, so only address reservation is available (FWIW, it is better anyway, since it consolidates IP address management in the router). 

---

Sure. When my network eventually comes back up without my intervention, my access point's dashboard does not/UniFi controller does not list an IP address for the Arlo Doorbell. That's what I mean by it not having an allocated IP when everything crashes. Again, this is resolved by restarting my AP from experience.

As for how my Arlo obtains an IP, initially I had it getting an IP from my network via DHCP. I did not assign it a static IP address at that point. After the issue happened a few more times, I thought mapping a static IP to the Doorbell would fix the issue of it failing to get an IP. Again, that did not help as the issue still persisted.

I have tried resetting the Arlo Doorbell as I indicated in the OP. I have reset my access point and my router itself several times. Unfortunately nothing helped and here I am. As for other people having the issue, there are a few instances of people having issues with Arlo on their Unifi network. Not widespread of course, but the few posts are there. I wish I researched the compatibility before purchasing.

[StephenB]

---

@ArloUser1925 wrote:

---

---

---

That is what someone brought up as a possible scenario of what is happening: the Doorbell setting itself on 192.168.1.1. As to why it happens, I have no clue. I'm not very technical let alone the fact that the issue happens completely at random so sniffing the packets with Wireshark on my network seems like a bad idea. Would have to monitor traffic until the issue occurs and I have multiple devices connected and using the network throughout the day. Unless there is a way to filter out specific IPs from being monitored I would like to avoid using Wireshark.

---

The puzzle is why the doorbell would advertise the wrong IP address (and also why your doorbell doesn' seem to show up in your Unifi device list). 

You can filter the traffic with Wireshark.  But if you aren't very technical, you might not feel comfortable using it (or might not get the needed packets in the capture). If the problem is intermittent/occassional, you would need to keep it running.

In that case, perhaps try support.  Though Tier-1 probably won't be able to help, you'll probably need it escalated.