Cam IP randomness

[rightkick]

I recently decided to upgrade my surveillance system to Amcrest PoE sold by Foscam and Blue Iris.

Network gear is a Netgear R7000 router and Cisco Catalyst 2960 PoE 24 port switch, three IP2M22E cameras

My problem is the cameras are randomly changing their own IP's according to the software that came with them (software scans for the cameras). Then of course my network just doesn't talk to them. One minute they will work then the next they won't. I statically assigned each camera an IP in the camera itself and the router. Upon the initial configuration everything is fine, then a few minutes later they will drop off my network and a few minutes later the software will show some random IP which some times is a completely different subnet. All three are doing the same thing! I can go back into the camera change the IP again and they will work for 30 seconds to a couple of minutes. It's seems like there is a save button I'm not seeing.

Amcrest tech support even had the same problem when I let them work on it yesterday. I now have to wait until Monday for a "Senior Tech" to call me back. I can understand one defective camera but all three? It seems like there is some quirk that I'm missing somewhere and it's driving me nuts.

Anyone have any ideas?

Yes I'm a Newbie here and thanks!

 

[Kawboy12R]

I have no Amcrest experience but the first thing I'd do is turn off uPnP. It's a good idea anyway and can cause problems with random ports opening to the net that you aren't aware of. Not sure if it'll play with addressing as well but you may as well start off on the right foot even if that isn't it. I'd also do a factory reset of the cams and start from scratch after turning off uPnP. That'll give you a clean slate to start from.

 

[rightkick]

I have no Amcrest experience but the first thing I'd do is turn off uPnP. It's a good idea anyway and can cause problems with random ports opening to the net that you aren't aware of. Not sure if it'll play with addressing as well but you may as well start off on the right foot even if that isn't it. I'd also do a factory reset of the cams and start from scratch after turning off uPnP. That'll give you a clean slate to start from.

Thanks for the suggestion. I just checked and uPnP is already disabled.

 

[Kawboy12R]

Good. Didn't really think that was it but it's a good place to start if ports etc are doing unexpected things. I've no real idea why they'd be getting random subnets after being assigned fixed IPs in both the cams and router. Stuff like that makes people fix computers with an engineer's hammer.

 

[rightkick]

I'm a Network Tech and assign IP addresses all day long to equipment and I've never seen anything like this.

 

[alastairstevenson]

Anything of interest in the router logs?

some times is a completely different subnet.

Just different from the LAN subnet or different subnets?

That's a layer-3 switch do you have any advanced features configured, or is it behaving dumbly?

 

[rightkick]

Anything of interest in the router logs?

Just different from the LAN subnet or different subnets?

That's a layer-3 switch do you have any advanced features configured, or is it behaving dumbly?

Dumb as can be but good question.

Switch#sh run
Building configuration...

Current configuration : 2956 bytes
!
version 12.2
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Switch
!
boot-start-marker
boot-end-marker
!
enable password XXXXX
!
username admin password 0 XXXXX
!
!
no aaa new-model
system mtu routing 1500
!
!
!
!
crypto pki trustpoint TP-self-signed-632689152
enrollment selfsigned
subject-name cn=IOS-Self-Signed-Certificate-632689152
revocation-check none
rsakeypair TP-self-signed-632689152
!
!
crypto pki certificate chain TP-self-signed-632689152
certificate self-signed 01
3082023D 308201A6 A0030201 02020101 300D0609 2A864886 F70D0101 04050030
30312E30 2C060355 04031325 494F532D 53656C66 2D536967 6E65642D 43657274
69666963 6174652D 36333236 38393135 32301E17 0D393330 33303130 30303230
395A170D 32303031 30313030 30303030 5A303031 2E302C06 03550403 1325494F
532D5365 6C662D53 69676E65 642D4365 72746966 69636174 652D3633 32363839
31353230 819F300D 06092A86 4886F70D 01010105 0003818D 00308189 02818100
E9CF6A7E 6F198A99 9F4625C8 46F230A1 38F07343 0DF3F837 2C187F9B 6A9AA124
9A1F3342 E2C6DBD8 A0A16318 90230D9C A24EBD9C 8BCBD726 C365AAE5 5965D147
EA897654 7003379F BBABEE73 4814341C EA530DF1 A06D02C5 A4112E61 EBC46E66
D296E627 989E54D4 2EF6545C 1A0731C4 CE061BBB F6BC7710 F9C3E2BC 7F512E5B
02030100 01A36730 65300F06 03551D13 0101FF04 05300301 01FF3012 0603551D
11040B30 09820753 77697463 682E301F 0603551D 23041830 168014D1 20488DD0
5ABE62A7 E82B62F2 1727A3A8 274CD530 1D060355 1D0E0416 0414D120 488DD05A
BE62A7E8 2B62F217 27A3A827 4CD5300D 06092A86 4886F70D 01010405 00038181
00AF0ED6 52BB3650 388B7D17 0357C6E4 938F3E89 B2FE345B A9E0CB4A D283499D
4199E213 9CF0CC23 4DA05A8F 3B2F0E5A AE71DFE7 E0E151A0 98A942F2 3F30E8E8
81D86B29 54BB9F51 49A6A921 BB21D0C1 DBAA1AD5 5B8F8803 7DA2ECF9 8C56EC3B
D62F6AA5 3F98ACF2 CF48481F 902A1CF5 1C2E3719 FACB35A2 421DA87A 4FD07126 AD
quit
!
!
!
spanning-tree mode pvst
spanning-tree extend system-id
!
vlan internal allocation policy ascending
!
!
!
interface FastEthernet0/1
!
interface FastEthernet0/2
!
interface FastEthernet0/3
!
interface FastEthernet0/4
!
interface FastEthernet0/5
!
interface FastEthernet0/6
!
interface FastEthernet0/7
!
interface FastEthernet0/8
!
interface FastEthernet0/9
!
interface FastEthernet0/10
!
interface FastEthernet0/11
!
interface FastEthernet0/12
!
interface FastEthernet0/13
!
interface FastEthernet0/14
!
interface FastEthernet0/15
!
interface FastEthernet0/16
!
interface FastEthernet0/17
!
interface FastEthernet0/18
!
interface FastEthernet0/19
!
interface FastEthernet0/20
!
interface FastEthernet0/21
!
interface FastEthernet0/22
!
interface FastEthernet0/23
!
interface FastEthernet0/24
!
interface GigabitEthernet0/1
!
interface GigabitEthernet0/2
!
interface Vlan1
ip address 192.168.1.160 255.255.255.0
!
ip http server
ip http secure-server
!
line con 0
line vty 0 4
login local
line vty 5 15
login
!
end

Switch#

 

[alastairstevenson]

Well, nothing fancy in that switch config.
But a strange problem with the cameras, most odd.

 

[rightkick]

I've managed to have two of them stable for an hour now. I did move switch ports for sh!ts and giggles. And for a test I disconnect one from the switch, plugged it back in and the IP was address had changed again. I set it back and the camera came back up. Like I said it's like there's a save button I'm not seeing but I changed the date and time as well and it keeps.

 

[nayr]

you tried doing dhcp with static mapping?

is IPv6 enabled?

Are you using IE?

 

[rightkick]

you tried doing dhcp with static mapping?

is IPv6 enabled?
Are you using IE?

1. Have not. Why would I need to?

2. Not sure - don't think so

3.No - Firefox

 

[nayr]

1. Because network auto configuration is superior in every way.. especially on headless devices you have to do a bunch of crap to reconfigure the network for.
2. Just checking, IPv6 network configuration happens automatically without the aid of DHCP, ive seen lots of poor implementations.
3. Many Cameras require IE for configuration due to ActiveX bullshit.. other browsers may look like its working but its silently failing.

 

[rightkick]

1. Because network auto configuration is superior in every way.. especially on headless devices you have to do a bunch of crap to reconfigure the network for.
2. Just checking, IPv6 network configuration happens automatically without the aid of DHCP, ive seen lots of poor implementations.
3. Many Cameras require IE for configuration due to ActiveX bullshit.. other browsers may look like its working but its silently failing.

Oh ok, I thought you were suggesting I could set some static routes. Yeah, the last thing I want is some special configuration to make this work. I haven't dug to deep into IPv6 yet. Waiting till I have to.

Using IE makes sense as that is what it seems to be doing (not really saving my config). So, I did log into the camera via IE and reconfigured/saved and did a reboot of the camera an it lost it's IP again. A "senior" tech from Amcrest is supposed to be calling me Monday but I can't see what they can do. This is the easiest part of adding gear to to a network - setting IP's.

 

[nayr]

most decent routers let you map dhcp leases to static ip's based upon mac-address.. so you can set the cameras to dhcp, without worrying about anything else using that IP or having the IP suddenly change.. yet you can still take the camera down, put it on a bench with another network for testing/troubleshooting without reconfiguring the device twice.

if you want to change Ip's all you have to do is update your router config and reboot the cameras, then they are all using new configuration.. Also handy if you upgrade a camera, just put the new camera's mac in the router.. put the old mac at a new ip for its new job and then replace them.. none of the cameras or nvr's need any updating.. just set them to dhcp and centralize your config on your router, never worry about alot of potential networking issues again.

perhaps they are detecting an IP conflict and trying to resolve it by hopping subnets.. are you sure that nothing can take the IP's your assigning to your cameras? If you run a static configuration on a dhcp subnet you have to configure the dhcp server so it never assigns the range of IP's you have statically assigned.. and at this point you might as well just use static-mapping unless your dhcp server is so simple it cant.

For decades every network Ive setup, maintained, or even worked with is static ip for router, network auto configuration for EVERYTHING else.. when you start getting more and more devices manually mapping IP's and ensuring conflicts never happen just becomes impossible to manage.

 

[rightkick]

most decent routers let you map dhcp leases to static ip's based upon mac-address.. so you can set the cameras to dhcp, without worrying about anything else using that IP or having the IP suddenly change.. yet you can still take the camera down, put it on a bench with another network for testing/troubleshooting without reconfiguring the device twice.

if you want to change Ip's all you have to do is update your router config and reboot the cameras, then they are all using new configuration.. Also handy if you upgrade a camera, just put the new camera's mac in the router.. put the old mac at a new ip for its new job and then replace them.. none of the cameras or nvr's need any updating.. just set them to dhcp and centralize your config on your router, never worry about alot of potential networking issues again.

perhaps they are detecting an IP conflict and trying to resolve it by hopping subnets.. are you sure that nothing can take the IP's your assigning to your cameras? If you run a static configuration on a dhcp subnet you have to configure the dhcp server so it never assigns the range of IP's you have statically assigned.. and at this point you might as well just use static-mapping unless your dhcp server is so simple it cant.

For decades every network Ive setup, maintained, or even worked with is static ip for router, network auto configuration for EVERYTHING else.. when you start getting more and more devices manually mapping IP's and ensuring conflicts never happen just becomes impossible to manage.

Well well, it looks like we might be getting somewhere. I set each camera to DHCP (already had IP mapped to Mac addys in my router) then went to verify my DHCP pool which I thought I had set up correctly because I have other devices attached statically for years that I've never had a problem with but the pool was a /24. I changed that and I now have two of the three cameras that will come back up with assigned IP after a reboot and physically being disconnected from the switch. Upon initial reboot I can see they have some random IP but after a minute or two they straighten out. The third I think keeps rebooting itself so it might have different problem all together.

Thanks for the info in regards to not setting the IP in the device itself. Makes things much easier as I've always had the Mac address in the router as well. I'll probably be in Denver in a couple of months and I'll buy you a beer! :very_drunk:

 

[w1zofaz]

Following out of curiousity. Plus looking to see if I could possibly benefit. I currently use DDNS (because my IP is dynamic from the ISP), but I have assigned static IP's to the cameras themselves.

 

[rightkick]

Following out of curiousity. Plus looking to see if I could possibly benefit. I currently use DDNS (because my IP is dynamic from the ISP), but I have assigned static IP's to the cameras themselves.

Are you having issues with your assigned IP's? Everything I've ever assigned, I've done it on the router and the end unit. This is the first time I've ever had an issue like this.

I ISP dishes out dynamic too but their DHCP lease time lasts longer than between my interval of changing routers. Everytime my ISP see's a new MAC a new IP is assigned.

 

[w1zofaz]

No IP issues from me. But following because I had never seen anything like that and with my luck may have an issue like this in the future. So, following just in case. I think the way I have it set up using DDNS and assigning static IP's will work. But nayr has made me second guess myself in doing it this way. Because maybe something I add in the future will try to assign itself to an IP that I have assigned.

 

[rightkick]

Nayr schooled me. I never even considered just assigning in the router and managing it that way. At work (which I happen to work for a ISP provider) I assign everything an IP but that's for MPLS networks and such on business class networks.

One thing to mention, I did try and set a camera do DHCP to see if my router would take care of business but wouldn't you know it, I had just managed to pick the camera that keeps rebooting itself while I wasn't aware of what was going on at the time.

Nice sig line BTW.