DHCP leases Foscam IP camera problem

[b4rney]

...but it doesn't solve the problem. If I try to put in the Gateway and DNS1 (86.28.XXX.X and 194.168.4.100 respectively, from web admin), then the web page/utility gives me the error - this has been the cause of that error all along.

Hi Matt,
Yes it was from the dns1 you mentioned above. I (incorrectly) assumed this was you router subnet. Sorry for the confusion.

Your current settings are correct, your router is 192.168.1.1 and acts as both a gateway and dns server.

Glad you got it working. Why do you need another AP?
Barney

[b4rney]

@jondecker76
Did you try adding the mac address ranges to the 'generic motion ip camera' template? Then add the correct 'path' in web admin.

Weird that you can't get it working at all? Did you create a custom template for your foscams?

I agree that a network guru might shed some light on this.
Barney

[jondecker76]

Yeah, I added the mac address  information, and even a static ARP entry.

It did work for a couple of minutes after I fully rebooted, but when I checked the static arp entry i did didn't persist after the reboot. I may test it later, but it may work if I reboot, and as soon as possible issue an arp -s command to add the static entry - after this last test, its obviously ARP related

[purps]

Glad you got it working. Why do you need another AP?
Barney

Because my wireless web orbiter devices no longer work - should they?

Cheers,
Matt.

[purps]

Yeah, I added the mac address  information, and even a static ARP entry.

It did work for a couple of minutes after I fully rebooted, but when I checked the static arp entry i did didn't persist after the reboot. I may test it later, but it may work if I reboot, and as soon as possible issue an arp -s command to add the static entry - after this last test, its obviously ARP related

Thanks for taking a look at this.

After I ran the arp command, I could have sworn that the camera lasted longer than usual before going dead (20 minutes instead of 10 minutes), no idea if this was coincidence.

Cheers,
Matt.

[jondecker76]

Hold your breath, I've had it working all day now on the internal network. Its a problem called ARP Flux and its common on linux installations which have 2 subnets in one domain (I.e. our internal and external networks). After tons of reading and a lot of trial and error, I believe I have it fixed!
A little more testing and I'll share the fix

[purps]

A good diagnosis by Barney then! 

Look forward to testing your solution; thanks for taking the time to take a peek at this.

Cheers,
Matt.

[jondecker76]

Ok, several hours down and I still have a foscam running on the internal network (before the change, it made it 1-2 minutes)
Only time will tell if things will continue to work (Hopefully its still up and running tomorrow)

If anyone else want to test this as well, please do and report back here so that I can make a permanent fix

ssh into the core, and enter the following into the terminal:

Code:

echo net.ipv4.conf.all.arp_filter = 1 | sudo tee -a /etc/sysctl.conf
echo net.ipv4.conf.default.arp_filter = 1 | sudo tee -a /etc/sysctl.conf

then reboot the core. While the core is rebooting, unplug the power from your foscam then plug it back in (just in case)
When the core comes back up, hopefully your foscam will continue to work

Cross your fingers!

[ladekribs]

Hi jondecker76,
what does the code do?

BR Stefan

EDIT: ok reading this http://wiki.openvz.org/Multiple_network_interfaces_and_ARP_flux and I am trying to understand
and here: http://publib.boulder.ibm.com/infocenter/clresctr/vxrx/index.jsp?topic=%2Fcom.ibm.cluster.pe_linux43.install.doc%2Fam101_tysfbpjp.html

[b4rney]

@jondecker76

I will test this asap. Already run those commands.

Will need to put my cameras back on the internal network, then I'll report back.
Barney

[b4rney]

 
Same as before I'm afraid. Using my wired foscam on the internal network and dhcp assigned by the core (set in the 'generic motion ip camera' device settings).

After the camera has failed I get this (from the ip of the camera):

Code:

root@dcerouter:~# arp 192.168.80.152
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.80.152           ether   00:60:6e:8f:88:e1   C                     eth1

This is as expected on the internal network eth1.

Testing my external eth0 arp entries I get:

Code:

root@dcerouter:~# arp -i eth0
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.0.1              ether   00:5b:2f:41:b7:36   C                     eth0

Which is my router on the external eth0.

The camera is not accessible once the connection is lost ... however when I run the 'arp 192.168.80.152' command from my internally connected laptop (which I only turned on after the camera connection was lost) I get this:

Code:

barney@barney-laptop:~$ arp 192.168.80.152
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.80.152           ether   00:60:6e:8f:88:e1   C                     eth1

Which looks right. I am confused.
Barney

NB unplugging and reconnecting the ethernet cable from the camera makes it reappear (for a while).

[ladekribs]

hi barney,

try: sysctl -a | grep net.ipv4.conf.*.arp

this should give a list with

net.ipv4.conf.all.arp_filter = 1

to see if the command was successfull

[jondecker76]

barney: http://fixunix.com/kernel/263192-arp-bug.html
This is the exact thing you are experiencing.

My camera finally dropped out just a bit ago.  the arp_filter increased the time easily 10 fold, but it still eventually fails.  I think we're on the right track though and I'll keep poking around.
There are also sysctl variables for arp_ignore and arp_announce. I'm sure with some experimentation we will find the right combination

[jondecker76]

I'm at work for 12 hours today, so I won't get to test anything until tonight - but if you want to test.. Try adding these also to the bottom of /etc/sysctl.conf:

Code:

net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.all.arp_ignore = 1

then reboot
(i'm quite positive that this along with the arp_filter should fix the problem)

information on their meaning here:
http://kb.linuxvirtualserver.org/wiki/Using_arp_announce/arp_ignore_to_disable_ARP


Also, if this doesn't work right out the gate, try changing them to:

Code:

net.ipv4.conf.eth0.arp_announce = 2
net.ipv4.conf.eth0.arp_ignore = 1

if your internal network is on eth0 (or use eth1 if your network is flip-flopped).  I'd rather use .all. over .eth0/1., because if it works that way then the code to implement a permanent fix will be much easier!

[jondecker76]

just a quick note.. I just tried
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.all.arp_ignore = 1

remotely from work, and the camera was instantly unreachable. However, I'm now trying:
net.ipv4.conf.eth0.arp_announce = 2
net.ipv4.conf.eth0.arp_ignore = 1

And the camera is reachable again. I also removed the arp_filter lines from /etc/sysctl.conf, so lets see how this does...