No devices found

[kingliam]

I've looked through the forum and support articles with not luck so far, so I just wanted to see if anyone else has any tips. I'm trying to set up the Arlo Video Doorbell Wired (AVD1001) and am able to get the doorbell to read the QR code and make the chime sound, but then the app never finds the doorbell. The doorbell is about 10 feet from the router and I have other Arlo devices on my network that connect just fine.

Here's the weirdest part: the doorbell actually connects to the router as I can see its MAC and IP addresses in my router management. I am even able to ping the doorbell from my computer. I'm using the latest Android app (and even tried an older version of the app), but the app can never finish setting up the doorbell since it can't find the doorbell on the network for some reason. It feels like a software issue.

Ugh. I've factory reset it multiple times to no avail. Very appreciative of any tips or suggestions of things to try. Thanks!

[jguerdat]

Can you force the phone to use the 2.4GHz band or disable the 5GHz band on the router temporarily?

[StephenB]

Though probably obvious, also make sure the phone wifi is turned on and connected to your home network. Maybe turn off cellular data to make sure the connection has to use wifi.

---

@jguerdat wrote:

Can you force the phone to use the 2.4GHz band 

---

Do you know any way to do that (either with Android or iOS) if the router uses the same SSID for both networks?  I've never found one.

[kingliam]

@jguerdat @StephenB Thanks for the suggestions. I really appreciate it.

I tried again with the cellular data turned off and even though my router does separate the 2.4 GHz and the 5GHz signals via two unique SSIDs, I actually went into the router and disabled the 5Ghz SSID per jguerdat's suggestion. Sadly I still couldn't get the app to find the doorbell even though it successfully appears in my list of connected devices in the router admin.

Just for fun I did a speed test as well from the doorbell and got around 70 Mbps up and down.

---

@StephenB wrote:

Do you know any way to do that (either with Android or iOS) if the router uses the same SSID for both networks?  I've never found one.

---

I don't know of a way except to disable the 5 GHz signal on the router side of things.

Thanks for the suggestions

[jguerdat]

At this point I'd swap at the store - maybe it's just faulty. Otherwies, use the Contact Support link at the bottom here to see if they can help.

[kingliam]

Just as an update to anyone else who comes across this thread in the future: 

I've been working with Arlo support for a couple weeks now and they think it's a bug in their app since the video doorbell connects to the router just fine. I've been able to re-produce the bug in their app with two separate routers, both of which work fine. Per other threads in this forum it looks like this has been around for awhile, but they maybe weren't aware of it. The weirdest part is that I have another Arlo device that works just fine with the app. I'll update this message in the future if I see a fix come down the line.

[jripchik]

I am having the same problem as all of you.  I even had a replacement device sent to me.  We received it today and went back through all of the set up and troubleshooting guidance in this forum and in the numerous arlo help articles. We stil cannot connect the doorbell to either the smarthub or the router.  

[kingliam]

Just wanted update anyone who comes across this thread in the future and reply to @Jripley 

I debugged and figured out the problem and submitted it to Arlo. From what I can tell, during the authentication process for adding the doorbell and starting the "trial" service, Arlo seems to be submitting data over a port that is being blocked on the ISP side. If you have a completely "open to the internet" ISP, this authentication handshake will succeed, but if you're using an ISP that is particular about which ports it allows through, the authentication handshake will fail.

I'm in a strange situation where my house has two ISP connected to it. In the couple dozen attempts I made on the "protected" ISP, the handshake failed 100% of the time and I could never finish adding the doorbell. I even tried using a fresh router without any custom configuration. Using the exact same original hardware and network configuration on the "open" ISP, it succeeded instantly on the first try.

So what is the solution for those who run into this issue in the future? You either need to phone your ISP and ask them to open up the ports for you OR try tethering to your mobile hotspot while adding the doorbell. Arlo has said they escalated this solution to the right teams, but only time will tell if they push a fix out to solve this.

[StephenB]

---

@kingliam wrote:

Arlo seems to be submitting data over a port that is being blocked on the ISP side.

Do you know what port this is?  

Public info on ports is that Arlo uses 80, 443, and 123.  These are almost always open.

If 80 and 443 are blocked, then web browsing fails.  A web proxy could get in the way, but that wouldn't normally be deployed by the ISP.   123 is used for NTP time sync, and there is no reason for an ISP to block it.  AFAIK, Arlo isn't using it for authentication requests.

You said earlier that you have 2 ISPs.  Did you make any tests with only one ISP enabled?

[kingliam]

I do not know which port. I could go back and sniff the traffic to see if I could figure out exactly which call was being rejected and which port it was using. I should mention that I don't know with 100% confidence that this is the problem, however I spent probably over 10 hours debugging this issue and based on my findings this was the most probable problem based on my network configurations. Arlo support escalated the ticket all the way up the line and gave tons of options to try, but was completely clueless as to what was going on. 

You said earlier that you have 2 ISPs.  Did you make any tests with only one ISP enabled?

---

Yes. The only difference between my two ISP's is that one is completely "open" (e.g. I host a web server on it and can manage all of my own port forwarding configurations) and the other is less tech-friendly and you have to phone the ISP to have them open up specific ports. This "protected" one, as I've called it, services over 1M+ people in the state of Utah. It works perfectly fine with every other IOT device I've ever used including other Arlo devices.

Throughout my tests I tested connecting the doorbell via both ISPs, one at a time. For each ISP, the first test was via a direct ISP uplink into a fresh router with no other devices besides the doorbell connected to it and the second was via my house's current network configuration. It didn't matter if the hierarchy was directly from ISP -> new router -> Arlo doorbell or whether it was ISP -> current network configuration -> Arlo doorbell. In 100% of the tests over the "protected" ISP, the doorbell failed to connect. In 100% of tests over the "open" ISP, the doorbell connected instantly without any problems.

So my solution was to connect over the "open" ISP and then switch back to my normal "protected" ISP. The doorbell works normal on both ISP's, but fails during the initial authentication call over the latter. If I ever had to re-add the doorbell to my network, I would need to switch back to the "open" ISP, at least temporarily, to get things running smoothly again.

If you recall earlier from my messages, in every case the doorbell did actually connect to my router since I could login and see the IP & MAC address resolutions there. I confirmed this both with the new router and current network configuration.

At the end of the day, it may not be a port issue, but there is some call that is failing and that prevents the Arlo doorbell from ever finishing setup over certain ISPs. A port issue seem suspect considering how my two ISPs operate. Arlo may just say that my ISP is wonky, but if you look through the forums or reviews for the doorbell, people have reported this problem since nearly the inception of this doorbell. Overall we may be the minority of people, but there are lots of 1 star reviews hurting the reputation of this doorbell for what seems like this exact problem.

[StephenB]

FWIW, it's clear that Arlo has more work to do in reducing friction when installing cameras (including the doorbell).

I only know of one ISP that was blocking the Arlo traffic - and that was not in the US.  But there could certainly be others.

---

@kingliam wrote:

This "protected" one, as I've called it, services over 1M+ people in the state of Utah. It works perfectly fine with every other IOT device I've ever used including other Arlo devices.

---

Is this mobile broadband?

One aspect here is the depletion of ipv4 addresses.  Mobile providers deploy a lot of ipv6 to work around that problem, augmented with some form of carrier-grade NAT (CGN) for ipv4.  Some traditional ISPs are also starting to do this. CGN can't handle much port forwarding  (too many people are sharing the same public ipv4 address), so they generally don't allow it.

Some mobile providers also have parental controls (which makes sense, since so many kids have smartphones now).  If those controls are enabled for the line, then they might get in the way of the port 80/443 traffic.

I have been playing with the T-Mobile broadband service - which doesn't allow any port forwarding, or inbound connections.  With the parental controls enabled, it does work with the VMB5000 smarthub (which has an AVD1001 paired with it).  But I haven't tried connecting any cameras directly to that network. 

[kingliam]

Yes, I think you're right. The hardware is great from my perspective, but I think they should have done a bit more QA.

---

---

---

One aspect here is the depletion of ipv4 addresses. Mobile providers deploy a lot of ipv6 to work around that problem, augmented with some form of carrier-grade NAT (CGN) for ipv4. Some traditional ISPs are also starting to do this. CGN can't handle much port forwarding (too many people are sharing the same public ipv4 address), so they generally don't allow it.

Wow that's really interesting! I haven't played much with mobile providers and didn't know about CGN. I wonder if my ISP is doing that. Also, it's not mobile broadband--just a normal residential/commercial provider (named Utah Broadband).

[StephenB]

---

@kingliam wrote:

I wonder if my ISP is doing that. Also, it's not mobile broadband--just a normal residential/commercial provider (named Utah Broadband).

---

It looks like they might be - 

https://utahbroadband.com/open-internet-disclosure/ wrote:

Equipment provided by UBB for use at customer premise locations may use NAT. All network traffic is privatized through the use of Virtual Local Area Networks (VLANs) assigned to the customers upon installation . 

---

You can sometimes tell by looking at your WAN address - with CGN it is frequently either a private address, or 100.x.x.x.  If you have ipv6 enabled, you can try a tracrt on both ipv4 and ipv6 and see how the routes compare.

Geolocation services  and/or speedtest.net also offer a hint - if the location they find for your WAN ISP is far away from your actual location, then there is a good chance that some form of CGN is being used.