AD110 Amcrest Doorbell Routing issue, Technical Network Info, Outbound Ports and IPs

[kyferez]

Hi all, I recently setup an Amcrest Doorbell camera. It's a decent device, with one major caveat: It does NOT work accross an internal Layer 3 IP Route. Huh? Basically, if you have multiple subnets in your network, and the Amcrest is on one subnet (i.e. 10.0.0.0/24) and your mobile device with the Amcrest Smart Home app on another subnet (10.1.1.0/24), with a router in between and "allow any any firewall rules" (for testing) the App cannot locate the Amcrest camera to connect to it at all.

Why does that occur? While monitoring the traffic I found it's because the developers chose to use a Broadcast to 255.255.255.255 to "find" the AD110's IP address in your network in order to communicate with it. This is a problem because those broadcast packets cannot be routed, so the App cannot connect. This is a DESIGN FLAW. They should have a backup method to locate the device in the internal network; even allowing you to specify it's IP in the Smart Home app would work around this.

If you however connect your mobile device to 4G or an external Internet connection, you can connect to the Doorbell, and that works well and is a nice feature.

Additional information for those security conscious people I have found who want to use their firewall to limit the Doorbell's outbound connections. It requires the following for full connection:

It connects to these FQDNs: p2pasplus.zencamcloud.com, drs.zencamcloud.com

IPs I've found it connects to (so far, there may be more and they may change): 3.209.212.187, 34.226.44.2, 52.206.214.9, 3.226.202.54, 172.58.3.116, 34.238.41.119, 34.203.108.237, 52.91.228.238, 192.0.0.4, 34.194.126.198, 54.209.127.50, 34.232.113.251, 52.203.196.133

Outbound TCP Ports Used: 9112, 9132, 10000, 12367, 15301

Outbound UDP Ports Used: 123,8800:8815,10000:65535

KyferEz

[Revo2Maxx]

Welcome to the Forum

It has been to long since I have been in the Game of IP addresses and Networking.. So for me today I just cheat and make a bunch of Ip addresses on my Computer for my networking needs..

However the Range of IP your in has something to do with the Subnet your in as well.. So if you want to extend your Range change the Subnet that your Router is able to connect with.. I have a few different Routers on my Network, some on the same Range with them working as AP an some Working as Bridges and then I have others that are on their own range to keep them out of the Internet Pool.. If my Router don't see the range then the router want let the device to the internet...

So about the doorbell and the things that you mention might be a "Design Flaw" as you called it might have been a Programed idea to keep others from hacking or some other Network disguise.. So within the Programming of the FW and other parts within the Camera or recorder the real info is used and it talks with what is needs to and so things are working.. Then when it is in need of Stop then 255.255.255.255 is used because as you said it will reject the Binary code that relates to and again I will say that might be their programming for Stop... Also that Range is in the Class E Range of IP and is Multicast so maybe it was meant to be there....

Sadly I can't say about 5G Phone, Mine is older 4G and I am going to guess that most of the Docs for most companies talk about things like CDMA, 3G and 4G Networks being compatible and most times has to do with there was nothing out at the time software (APPs) were being made.. So then you have answered the Next part does the program work yes it works on 4G can it work with 5G sadly I don't know I do know there is some things within Phones that can block programs from working and I do remember that when I first connected my Phone to the Amcrest App my phone didn't want to work. I needed to go into my phone and tell the Networking part that the Amcrest has the right to my Internet and since then with the 31 Updates that my phone has had I haven't had another issue with P2P or Smart Home P2P connections..

So in the End it might be that there is an area within your phone that is blocking your Smarthome App from working.. I will pass the info on and see if I can get anything back about 5G and or lack of support for SM devices or not.. If I find something out I will report back...

[kyferez]

Revo,

I've hashed this out extensively. Networking and packet analysis, telling other Level 3 engineers where their networking problems are, is my day job - I support BIG businesses and read packet captures daily and deal with routing issues and load balances and decrypting HTTPS traffic and Penetration testing and much more all the time. I'm often explaining to these "Level 3 Network Engineers" how routing actually works and how to fix their security issues.

However the Range of IP your in has something to do with the Subnet your in as well.. So if you want to extend your Range change the Subnet that your Router is able to connect with.. I have a few different Routers on my Network, some on the same Range with them working as AP an some Working as Bridges and then I have others that are on their own range to keep them out of the Internet Pool.. If my Router don't see the range then the router want let the device to the internet...

The range of subnet has to do with the IPs in it, if they are public addresses or RFC1918 addresses, etc. I have VLANs and subnets and multiple routers with a transit VLAN between them, static routes on the firewalls, etc. But none of that matters for what I am discussing and can demonstrate: The two devices can communicate NO PROBLEM outside of the Smart Home APP. The problem is how the APP tries to locate the Camera's INTERNAL IP; it does NOT and WILL NOT work across routed subnets unless they update the APP to enhance how it locates the Internal IP of the Doorbell.

So about the doorbell and the things that you mention might be a "Design Flaw" as you called it might have been a Programed idea to keep others from hacking or some other Network disguise.. So within the Programming of the FW and other parts within the Camera or recorder the real info is used and it talks with what is needs to and so things are working..

This is not due to security. If they were concerned with security the device would not require such an excessive range of outbound ports and there would be an option to host your own connection server rather than having to use their public ones.

Then when it is in need of Stop then 255.255.255.255 is used because as you said it will reject the Binary code that relates to and again I will say that might be their programming for Stop... Also that Range is in the Class E Range of IP and is Multicast so maybe it was meant to be there....

See https://networkengineering.stackexchang ... st-traffic. 255.255.255.255 is a LIMITED broadcast, it is NOT routeable.

The app's inability to find the doorbell's Internal IP has NOTHING to do with security. The phone and Doorbell can route and communicate just fine, the problem is the LIMITED BROADCAST. Again, as stated above, if the APP was able to "FIND" the doorbell, it would connect, however it cannot do that due to using a LIMITED BROADCAST packet which is NOT Routeable and has nothing to do with security or hacking.

Sadly I can't say about 5G Phone, Mine is older 4G and I am going to guess that most of the Docs for most companies talk about things like CDMA, 3G and 4G Networks being compatible and most times has to do with there was nothing out at the time software (APPs) were being made.. So then you have answered the Next part does the program work yes it works on 4G can it work with 5G sadly I don't know I do know there is some things within Phones that can block programs from working and I do remember that when I first connected my Phone to the Amcrest App my phone didn't want to work. I needed to go into my phone and tell the Networking part that the Amcrest has the right to my Internet and since then with the 31 Updates that my phone has had I haven't had another issue with P2P or Smart Home P2P connections..

4G/5G has nothing to do with this. The only reason I mentioned 4G was to clarify that it was not connected to my Intenal Network and was using it's own WAN connection when it works fine and that was a nice feature as it will work when away from home; it doesn't matter if it's 3G 4G 5G or some other internet connection, as long as there is available bandwidth and open outbound ports on that internet connection, it will work. The point I was highlighting was it is not in my Internal Network or even on the same WAN provider as my home network when it worked, and explaining that it worked when away from home.

In the end, much of your response was incorrect or irrelevant. I made the original post, not asking for help, but to inform other highly technical users who may need or want to know prior to purchasing because none of this was available.

[GaryOkie]

Hi @kyferez -

Thanks for posting this technical detail! The broadcast design flaw you identified explains the difficulty I had with SmartHome when my AD110 was on a separate routable subnet dedicated for my IoT WiFi devices.

History has shown that the Amcrest IP's change frequently, especially the AWS server pools hosting connections. There was a design flaw last year of one these IP's actually being hardcoded in the firmware. When AWS dynamically updated the IP pool for the authentication servers, every AD110 lost connectivity! Even the FQDN's have changed in the past, but fortunately they have been DNS aliased to the new. It's still not clear that the AD110 even connects using hostnames, as if it had, changing IP's on the backend should not have mattered.

I fully agree that restricting connectivity on the AD110 is indeed wise, but likely will continue to be a moving target.

[Revo2Maxx]

Sorry I was Wrong about the 255.255.255.255 that is under the Experimental Class E and Class D was Multicast sorry.. About your text I am not sure why someone would want to keep it off network? The whole thing about this and other Doorbells is so people can have a device send them an alert that some one has entered their area of the front door.. Removing from all the NICE IP's and Fully Qualified Domain Name (FQDNs) what is the point in having a Device for Security and a way to get a Notice if someone was to remove all you listed!?

Don't want it to connect to the Network then add it to a Router that has no internet connection and then there is no need to remove any or update any outside IP's

I don't know I Guess I don't get your whole Post in the first place.. App not knowing the IP It don't have to know the IP because it is using a UUID that is connecting to a SERVER that is for this app.. While this Doorbell is able to work over ONVIF and able to work on things with RSTP sadly this isn't what the Device was really designed for.. It is 100% a Smart Home Product and it works with a UUID in a P2P and Cloud Server setup at the p2pasplus.zencamcloud.com... Each Doorbell camera has a Unique UUID and a Special user id that is encoded into the device.. This is also the case for the ASH21, ASH26, the Battery Cam and if I had to guess the rest of the Smart Home devices seeing they are on the Smart home app and work over a UUID P2P connection..

Not sure about this whole Security issue with these.. If there is an issue with one of my devices I turn off access to it in my Router and nothing outside my network will have access to it.. Change the IP to a IP outside my Router IP range and the Flow of traffic stops to the device.. Don't need to know all the servers it connects too to deny it access.. Guess my old age is catching up to me as I just don't get it...

[djsteve]

@kyferez, thank you for your very well researched and informative post. It was clearly articulated and your use cases are relevant to many of us. This EE and networking-aware user appreciates the info.