AD410 doorbell: MAC address changes and password no longer works

[Nikotine]

This device is driving me crazy.
When you setup the doorbell, it uses the MAC address that's shown on the Device Information page.


I use that MAC address to assign a fixed IP to the device.
But after a while, it suddenly starts using another MAC address, even though the Device Information page remains unchanged:



So instead of 9c:8e30:a2:df, it starts using 00:e0:4c:0f:ee:10.
Why does it do that? Where is that other MAC address coming from?

Now, the app continues to work, and I can update my DHCP server to assign the IP address to that new MAC address.
But a bigger problem is that it doesn't let me watch the rtsp stream anymore, because it believes my password is wrong.
I've done a hard reset and gone through the complete setup again two times now, and it keeps doing this.

Both issues must be related, because I'm 100% sure my password is correct.

[Revo2Maxx]

My guess is that something has been done to the camera or some type of system fail as happened. IT almost looks like someone tried to clean the Software programming from the Device.. The First Mac Address that it setup with is a good Amcrest Mac or in the Range didn't look it up. however it is the same as my Doorbell with the first 6 as Amcrest based and the rest is unique to the Device it is assigned to, So looking at my Router table my Doorbell still is listed with the 9c:8e:cd set of Mac

What is odd and why I think something is wrong either someone trying to Re Write software or something is because the Mac your saying shows up after the fact if Realtek and my guess is that is the type of wifi chip that was programmed with the Amcrest Mac

I think might want to reach out to the Support Dept and see if they can get you a Replacement

[Nikotine]

You mean someone is trying to hack into the device and upload different firmware??

[Revo2Maxx]

Well not really saying thats the case but sounds strange that it would revert to a Mac address from component level . Personnally never seen that in over 20 years and that was done at software level. Still there are some Mac Cloning software out there. Are you running Mesh? Maybe the router did it for some odd reason?

[Nikotine]

Definitely something wrong here. I did a reboot and now it's using the original MAC address again, but the password still isn't working. I'm going to factory reset once more.

I am not using mesh network, I just have two access points who are both broadcasting an SSID on 2.4 GHz and 5 GHz.

[abigdeel]

Okay, I have a very similar problem. And I think I've figured some if it out. Let me know what you think...

I have a mesh wifi system. Two nodes broadcasting 2.4GHz and 5GHz, same SSID names of course.
So I set up the AD410 doorbell and found that wifi connectivity is just terrible right outside the front door. All the metal/brick/etc means quite the dead spot around that part of the house exterior I guess. Anyways, I was able to get one of my mesh nodes closer to that part of the house, and I could notice in the Amcrest app that it was picking up a higher signal strength for that node. So I set a static IP for the doorbell and then I bound it to the node near the front door.

Great? Only at first.. What I noticed was that if the doorbell ever struggled to connect to that node for whatever reason, all hell would break loose.

What I think happens is that the doorbell will always try to connect to the SSID specified as quickly as possible, and then it doesn't want to do much after that. So when it can't find my good node that it's bound to with that static IP, the doorbell will just randomly change to a different MAC address and try to connect again. And for some reason it just picks the first SSID with the matching name and often tries to connect to the weaker node. But my mesh wifi tries to force it to the other node, and the doorbell never reconnects. Instead I end up with 10+ different MAC addresses all trying to connect but fail to stay connected to my wifi.

So to get it to kinda work, I have to unbind the doorbell and set the static IP in the doorbell's settings and just hope it somehow connects to the stronger node. If I set a static IP in my mesh wifi, then it sometimes leads to your issue. The doorbell struggles to reconnect for whatever reason, just fucking gives up and tries to connect with a new MAC address, and my router assigns it a new IP address.

When I look through the API they provide, the scanWlanDevices command will show my two nodes with the same name (SSID) but it also shows my nodes' MAC addresses as well (BSSID). But the API command to actually set the wifi (SetWlanConfig), the parameters you can specify only includes SSID and not BSSID.


So at this point I don't know anything about networking or the logic behind how the doorbell connects to wifi, but I feel like the issue is that the doorbell isn't configured to keep trying the same BSSID again. It just matches against the SSID and tries to connect and then anything after that can screw it up.

There is a LinkMode command in the API that seems like it's for specifying if the wifi network is a mesh network. So I am about to try to set that from Auto to Ad-hoc to see if that helps in my scenario.


I think because you don't have a mesh wifi set up, all you might need to do is set a static IP from the doorbell settings, and not your router. There is a way to do it from the mobile app settings, there's a greyed out static IP showing 0.0.0.0 that you can adjust. That way the doorbell might change MAC addresses on you if it starts to struggle to connect to either of your APs, but it'll still always keep a static IP.

Sorry for the long post, I might have figured out a few things while writing it lol.

Edit: I've never had it not accept my password btw. Not sure why that's happening.. Also in my router it'll show up as Amcrest Technologies when I set the wifi from the app, but once it starts to struggle the doorbell changes MAC addresses and defaults to the REALTEK adapter name.

[abigdeel]

Okay, so I tried messing around with LinkMode and set it to Ad-hoc from Auto. I also tried changing LinkEnable from false to true.

Code: Select all

table.WLan.eth2.LinkEnable=true
table.WLan.eth2.LinkMode=Ad-hoc

Don't think any of that helped. If anything, made the connection more unstable. The documentation is pretty vague on what this does, but it really seemed like it was for mesh networks. Another thing I noticed is that when you do call getConfig Wlan, it does have a row for BSSID, but it's blank.

Code: Select all

http://192.168.50.12/cgi-bin/configManager.cgi?action=getConfig&name=WLan
table.WLan.eth2.BSSID=

So I set that to the BSSID of my stronger node and rebooted the doorbell. The BSSID setting stuck but it still connected to the weaker node initially, so I don't think manually setting that does much. Not sure what to do next tbh, might have to ditch this doorbell if no one has a solution to this mesh / AP wifi and static IP nonsense.

[Revo2Maxx]

Well I thought it might be Related to Mesh, Looking at my Config backup files for my AD110 and my AD410 I have to admit there is something in there that kind of bothers me.. In both there is a Mac address in the file that shouldn't be there, Also looking in the AD410 file there is one of the same in there however there is also another that I don't find Related to Dahua or Amcrest and it is packed in with a eth0 port that is not active seeing the file shows eth2 is the active Wifi port. Odd in the Ad110 there is also talk of a eth0 setup as not active however what is different is the file don't have a mac address connected to it like it does in the AD410 backup.. Also Subset set in eth0 is 255.255.0.0 where the 2 is setup with the normal 255.255.255.0 so I wonder if maybe the Mesh network somehow setups a second active connection and gives out the REALTEK Mac or if the REALTEK Mac is connected to the Router and not the Cameras?

@abigdeel can you run this from chrome put in your cameras IP address in the place of mine and let me know if you do a search for eth0 if it comes up and says it is active?

http://10.0.0.235/cgi-bin/Config.backup?action=All

you will need to log into the camera when you press enter, IT will make a Text doc, When you go to look at it just say that you want to view it with notepad then under edit do a search for eth0 that is a Zero Also finding the 00:12:34 can be found faster with doing a search for PhysicalAddress and it will show the real one under Amcrest and one on eth0 that comes up under some odd persons name lol

[abigdeel]

Oooh, didn't know you could pull the entire config file at once.

I do have an eth0 as well, I wasn't sure what it's for. And yeah, it's got an IP address that couldn't have come from my router (different subset or whatever). Also, I know these are re-branded Dahua cams, but why is the Domain listed as [bold]dauha[/bold] haha.

Code: Select all

      "DefaultInterface" : "eth2",
      "Domain" : "dauha",
      "Hostname" : "DB",
      "eth0" : {
         "DefaultGateway" : "192.168.1.1",
         "DhcpEnable" : false,
         "DnsServers" : [ "8.8.8.8", "8.8.8.8" ],
         "EnableDhcpReservedIP" : false,
         "IPAddress" : "192.168.1.108",
...

I was really hoping this was going to be as simple as populating the BSSID for my preferred node in the AD410 Wlan config, but that would've been too easy I guess..

Also whether eth0 is active or not is a bit hard to tell. In most places where eth0 is mentioned Enable is set to false. It's only true under IPv6, which I'm not using anyways. So eth0 doesn't really look like it's active unless you know specifically where to look.

[Revo2Maxx]

Yes the odd thing is after playing around with this, There is on the Ad410 3 different listed Mac addresses in the File, 1 is good one at the eth2 that is Wifi if you look in the file you will see it is Default and active, However with people using Mesh I am wondering if the system is trying to pull out different ethX data because while they are not listed in working order there is a good long list for different ports that it could work under..

I have been working for days now trying to get my system to come up with something crazy outside of the normal Amcrest Mac and so far it hasn't for me however I don't use a Mesh Network...