IP4M-1041B constantly trying to contact AWS, bug or deliberate?

[Bad Packet]

I recently purchased an IP4M-1041B and have it set up on an isolated wifi network after first configuring it via the web UI over wired ethernet. At my firewall, I have an explicit block and log rule for outbound traffic from this isolated subnet. I have identified two abnormal behaviors from this camera that I'm curious about. One is that it retains factory default DNS servers when configured via DHCP, and the other is that this camera is constantly trying to contact AWS, despite no "cloud" configuration being obviously present.

The firmware on the camera is up to date:

Software Version: V2.800.00AC003.0.R, Build Date: 2022-08-11
WEB Version: V3.2.1.18144
ONVIF Version: 21.12(V3.1.0.1207744)

Other configuration notes:

• I have no cloud storage configured.
• I have no SD card installed.
• I have disabled P2P and did not use it to set the camera up.
• I have no DDNS set up.
• I have disabled UPnP.
• I do not have any SMTP set up.
• I do not have any remote recording setup, no storage destinations configured, no motion/tamper/audio/abnormality detect configured.
• I used only the web UI to configure the camera, and am primarily getting video from this device via RTSP to Frigate.
• I have not factory reset the camera yet.

DNS Problem
I configured the IP via DHCP, and noticed that despite my DHCP server handing out my internal nameserver addresses, the camera retained its default settings of 8.8.8.8 and 8.8.4.4 for nameservers, so I had to manually reconfigure the TCP/IP settings with my nameservers, which are handed out correctly via DHCP without issue to every other host on the network.

AWS Problem
In PFSense, I see that this camera is trying to contact AWS pretty much all the time. I have included a minute's worth of log entries, but there are hundreds of identical entries, multiple times per minute, over 12+ hours. See end of post for those logs.

I understand from the documentation that this camera will try to contact "Amcrest Cloud" for 2 hours after every reboot, but the documented attempts to contact occur well past that timeframe.

I have an Amcrest IP8M-T2599EW that exhibits NONE of the above behaviors.

I recognize that this camera is more of a convenient home use camera than it is a professional grade camera, but I would still expect some reasonable behavior from it. It is a convenient form factor for moving around the house as needed as it does not need to be affixed to a surface, which is why I have it. Are these DHCP/DNS and AWS issues expected behavior, or bugs?

For clarity, 192.168.60.205 is the Amcrest camera.

Action	Time	Interface	Source	Destination	Protocol
Block	Feb 11 05:23:01	VLAN60	192.168.60.205:36094	34.227.196.242:443	TCP:S
Block	Feb 11 05:23:10	VLAN60	192.168.60.205:55454	34.234.184.106:443	TCP:S
Block	Feb 11 05:23:11	VLAN60	192.168.60.205:55454	34.234.184.106:443	TCP:S
Block	Feb 11 05:23:14	VLAN60	192.168.60.205:55454	34.234.184.106:443	TCP:S
Block	Feb 11 05:23:18	VLAN60	192.168.60.205:55454	34.234.184.106:443	TCP:S
Block	Feb 11 05:23:30	VLAN60	192.168.60.205:55456	34.234.184.106:443	TCP:S
Block	Feb 11 05:23:31	VLAN60	192.168.60.205:55456	34.234.184.106:443	TCP:S
Block	Feb 11 05:23:33	VLAN60	192.168.60.205:55456	34.234.184.106:443	TCP:S
Block	Feb 11 05:23:37	VLAN60	192.168.60.205:55456	34.234.184.106:443	TCP:S
Block	Feb 11 05:23:46	VLAN60	192.168.60.205:36104	34.227.196.242:443	TCP:S
Block	Feb 11 05:23:47	VLAN60	192.168.60.205:36104	34.227.196.242:443	TCP:S
Block	Feb 11 05:23:49	VLAN60	192.168.60.205:36104	34.227.196.242:443	TCP:S
Block	Feb 11 05:23:53	VLAN60	192.168.60.205:36104	34.227.196.242:443	TCP:S

 

[Bad Packet]

In an effort to eliminate variables, I went ahead and factory reset the camera and can confirm that from factory default, this camera retains and uses 8.8.8.8 and 8.8.4.4 as nameservers despite what DHCP hands out, and as soon as it gets a connection, it attempts to connect to AWS, over and over, indefinitely.

Curious now, I got a new example of the same camera, deconfigured P2P, etc as above, but left it at the as-shipped firmware:

Software Version: V2.800.0000000.15.R, Build Date: 2021-07-16
WEB Version: V3.2.1.18144
ONVIF Version: 20.06(V2.9.0.970440)

It exhibits the same two behaviors, so these two things seem to be either as-designed or long standing bugs.

@mromamcrest and @Andres_Amcrest, any thoughts? Should I contact escalation@amcrest.com with this issue?

 

[Mike A.]

Lots of cameras do similar things and I've seen the same with other Dahua (OEM) cams. They'll ignore settings in some cases and use hard-coded values for DNS servers, continue to try to contact P2P networks even when that's turned off, etc. That and other behavior is why most of us block Internet access for cams as it appears you have too. Not much you can do about it beyond that. Maybe try another version of the firmware but that has its own potential issues. I don't recall how that Amcrest setup looks but with some of the Dahua cams/firmware you need to check each service below on that settings screen not just the checkbox at the top that says enable/disable which looks like it would turn all below off but doesn't. I don't think that there's any malicious intent, just poor practice probably trying to test/ensure connectivity.

 

[mrvelous01]

I have several IP4M-1041 cameras with manually set IP's and none of mine appear to be reverting to or keeping Google DNS IPs. They all took my pfsense IP for DNS and have not reverted. I have also seen the same activity on my "non cloud" cameras. The only legitimate reason I can think of that they're all phoning home to China (yeah, 13 Amcrest, 2 Nellys NSC, a Hikvision, and a doorbell) is to check for new firmware versions. But I blocked them anyways. No Internet for you! Phoning home every minute is too suspicious for me. I blocked all outgoing access for that entire range with a pfsense alias. Below is one IP4M-1041's software levels. They appear only slightly newer than yours. The only exception to total blockage for these cameras was to allow them to hit pfsense on udp/123 for time. I also use VPN (pfsense) when I'm outside my home when I want to see my cameras. They have been running in this config for a few years.

Software Version V2.810.00AC000.0.R, Build Date: 2021-09-10
WEB VersionV3.2.1.1117289
ONVIF Version20.06(V2.0.1.45228)

 

[Bad Packet]

Its interesting, @mrvelous01, that your cameras aren't doing the same thing WRT DNS. Confims, I think, firmware variances. I have noticed and tested to confirm, that firmware:

Software Version: V2.800.0000000.15.R, Build Date: 2021-07-16
WEB Version: V3.2.1.18144
ONVIF Version: 20.06(V2.9.0.970440)

Reverts nameservers to 8.8.8.8 and 8.8.4.4 after a simple reboot, even when I have double checked to confirm I've saved my hand enteredl nameserver changes (since it ignores the DHCP-served DNS settings). That particular behavior is gone with an upgrade to 2022-08-11.

At the end of the day, I recognize that this sort of broken behavior is part of the landscape. But I take a sort of "confirm, accept, mitigate, agitate" approach. That is, I verify what I see, deal with it in whatever way is necessary, and try to make the vendor aware of the issue so it might get fixed. This isn't a half bad camera, and would be better if these sorts of things get fixed.

I will, of course, continue to block this sort of traffic, but I'm sort of hoping that if the quirks are brought to light, perhaps they will get fixed. If it's not malicious, then it's a QA issue and I'd hope that it would be in a queue to get fixed, once known.

(I'm career IT, I know Amcrest probably doesn't care and won't fix any of it. I know how this actually works in the real world, but let me have my delusional optimism.)

 

[slodat]

I just added my first Armcrest cameras to my BI system today. I noticed similar activity.. when I would save other settings, DNS servers would change from 0.0.0.0 (what I entered) to the two google servers. It did this several times. I just checked and they are still at 0.0.0.0. I changed DNS to that on my last edit when I was finished with other settings.

Just rebooted the camera and it is back to 8.8.8.8 and 8.8.4.4.

 

[Mike A.]

Maybe try using the IP of the cam itself or another dummy address. I know some of the Dahua cams will do the same if they see 0.0.0.0 but are OK if you use another IP.