Author
Topic: DHCP leases Foscam IP camera problem (Read 34657 times)

...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.

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

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.

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

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

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:

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

net.ipv4.conf.eth0.arp_announce = 2net.ipv4.conf.eth0.arp_ignore = 1if 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!