I'm testing out the foscam ip cameras from ebay and I've run into a problem. I have three cameras added children of motion wrapper. They have all appeared in the dhcp leases page with static addresses and work well.
I added the final outdoor camera, which works ok when tested on the external network. It appeared briefly in the dhcp leases as an active dhcp lease when plugged into the internal network. I used these details to add it under motion wrapper and it worked ..... for a while.
The camera has not appeared as a static dhcp entry and lmce loses contact with the camera after a few minutes. I have to disconnect/reconnect the network cable for it to reappear and the device isn't listed in the dhcp table at all.
Anyone experienced this?
Barney
Last night I plugged the camera into my external router/switch and it got a DHCP address. I pointed the camera device at the external ip address and it has worked flawlessly since then.
Looks like I might have a problem with DHCP in lmce. Will report back if I figure it out.
Barney
OK continuing this discussion it appears the foscams periodically cease to respond to arp requests which breaks the network communication.
http://blog.stead.id.au/2010/06/resolving-foscam-connection-dropouts.html
The suggested fix is to add a static arp record. Don't know if this will persist after a restart though. I hope to start testing this. Anyone else want to test?
I will also get onto foscam to see if they can do a firmware fix for this problem.
Barney
Based on this http://ubuntuforums.org/showthread.php?t=742424, I did a...
sudo arp -i eth0 -s 192.168.80.XXX 12:34:56:78:90:AB
...followed by checking the outputs of...
arp -a
...and...
arp
This last command shows a CM flag for the camera, which is good apparently. Only time will tell if this has stuck properly! Will report back.
Nope, didn't work, I will try resetting the core now.
>:(
So annoying. Thought we might have nailed it!
I'll try the same method to see if I can get any further. Maybe we need to do something with dhcpd conf.
Must be to do with the specific dhcp server and arp requests. My camera has worked perfectly attached to the external router/switch for weeks now and never lost dhcp.
Thanks for trying.
Barney
Well I have tried a hard reset of the core, and reissued the arp command, and the cameras still flake out after 10 minutes or so.
When you plug the cameras into the external router/switch, is the IP address assigned to them still in the 192.168.80.xxx format? Can you still see them in DHCP leases in web admin? Just trying to get my head around how all this works.
Cheers,
Matt.
No. The external network will be your cable modems dhcp range ... usually 192.168.0.x or 192.168.1.x etc.
The core can access this network without issue so it is certainly your best option.
I will keep testing ... if only to confirm the results you've found.
Cheers
Barney
purps,
Just a thought .....
My 192.168.80.x internal network is on eth1. The command you pasted references eth0. Did you change this when you ran the command?
sudo arp -i eth0 -s 192.168.80.XXX 12:34:56:78:90:AB
Barney
QuoteNo. The external network will be your cable modems dhcp range ... usually 192.168.0.x or 192.168.1.x etc.
The core can access this network without issue so it is certainly your best option.
I will keep testing ... if only to confirm the results you've found.
Cheers
Barney
Ah yes, that makes sense. I will dig my switch out later if it comes to it and see if that works.
Try this as well if you don't mind...
sudo arp -s 192.168.80.xxx 12:34:56:78:90:AB...slight variation on the one I posted earlier. I have two Foscams, and so far the camera I applied this arp thing to hasn't died! *crosses fingers, toes, eyes...*
Just thinking out loud; would setting up a static IP from within the cameras admin page make any difference? I will certainly try it if this latest arp command is unsuccessful.
Cheers,
Matt.
Quote from: b4rney on December 04, 2010, 10:38:38 PM
purps,
Just a thought .....
My 192.168.80.x internal network is on eth1. The command you pasted references eth0. Did you change this when you ran the command?
sudo arp -i eth0 -s 192.168.80.XXX 12:34:56:78:90:AB
Barney
I did yes, I forgot to change it to eth1 on the example command I posted, sorry for any confusion! You obviously spotted it though :)
Quote from: purps on December 04, 2010, 10:46:08 PM
QuoteNo. The external network will be your cable modems dhcp range ... usually 192.168.0.x or 192.168.1.x etc.
The core can access this network without issue so it is certainly your best option.
I will keep testing ... if only to confirm the results you've found.
Cheers
Barney
Ah yes, that makes sense. I will dig my switch out later if it comes to it and see if that works.
Try this as well if you don't mind...
sudo arp -s 192.168.80.xxx 12:34:56:78:90:AB
...slight variation on the one I posted earlier. I have two Foscams, and so far the camera I applied this arp thing to hasn't died! *crosses fingers, toes, eyes...*
Just thinking out loud; would setting up a static IP from within the cameras admin page make any difference? I will certainly try it if this latest arp command is unsuccessful.
Cheers,
Matt.
Nope >:( Couldn't set up a static IP through the camera page either, kept giving me nasty errors.
Hi,
my foscam camera is running for weeks without problem. I did use a static address (defined on the camera first) in the internal network.
I don't know why, but it was the only way to avoid the problems described.
The same (static address) i did for the other cameras (linksys and swann).
Quote from: pw44 on December 05, 2010, 02:56:34 PM
Hi,
my foscam camera is running for weeks without problem. I did use a static address (defined on the camera first) in the internal network.
I don't know why, but it was the only way to avoid the problems described.
The same (static address) i did for the other cameras (linksys and swann).
That is very interesting. Would you mind if we went into the static IP settings in a bit more detail? Everything I have tried results in the error message "error: illegal params."
So in the Foscam admin page, I go into "Device Management"->"Basic Network Settings". Then uncheck "Obtain IP from DHCP Server" and enter the following parameters...
IP Addr - 192.168.80.xxx (the IP address that LMCE assigned to the camera)
Subnet Mask - 255.255.255.0 (INTERNAL_NETMASK from web admin, Advanced->Network->Network settings)
Gateway - xx.xx.xxx.x (GATEWAY from web admin)
DNS Server - xxx.xxx.x.xxx (DNS1 from web admin)
Http Port - 80
Cheers,
Matt.
That looks right to me.
Where do you get the error, is it in the foscam admin?
Barney
Yes, foscam admin page, uncheck DHCP in the basic network settings and after entering values, submit.
Mine has the ip address 192.168.80.183.
Quote from: b4rney on December 06, 2010, 12:57:39 AM
That looks right to me.
Where do you get the error, is it in the foscam admin?
Barney
Yes, the "error: illegal params." error is in the foscam admin page, can't work it out! I tried removing the camera from web admin, and also removing the MAC range for that camera in the template (so that it wouldn't PnP and assign the IP), and this didn't work either.
Cheers,
Matt.
Two ways: reset camera to factory default or update firmware.
I should have said; I already tried a factory reset in conjunction with the other stuff I mentioned. I shall try updating the firmware.
Another weird behaviour I've seen more than once which might be relevant ....
When attempting to change or renew DHCP on my outdoor camera I sometimes lose network communication if it's dark outside. Weird or what. When I try in daylight it works. Might be to do with power requirements?
Might not be relevant but worth mentioning!
Barney
I can tell only that after defining static ip address and upgrading the firmware, the foscam did not show any of the described problems. It works under motion, without PTZ, and it was installed as a generic ip camera. It is working for the last 4 weeks (24x7) without interrupts or glitches. Before, defined as DHCP, i had a lot of disconnection problems. The last time i did reboot the core/hybrid was 4 weeks ago, and i will do it today, after todays lmce update.
That is encouraging.
I take it I need access to the Foscam site to download the newer firmware? Their website just times out!!
@PW44 Do I have to decrease the dhcp span and set the Foscam ipadress outside the dhcp span? or just leave it as it was?
@Ladekribs: My foscam is defined with static ip address 192.168.80.183, the swann 192.168.80.182 and the linksys 192.168.80.181. I did not change the network settings in webamin (dhcp ranges pluto / non-pluto).
It was the only way i have found to have them reliable streaming to motion.
@Purps: Maybe you shall try to set it up with the M$ Windows utilities :(. Was not my case, but reading about your problems with it, may be a way to get it setted up.
Going to be hard, there's no windows in my house <insert obvious joke here>.
Actually I do have XP running in VirtualBox, I might try it in that. I already tried the utility in wine, but it wasn't happening.
I would really like to try updating the firmware, but I need to email Foscam about this as they don't put it on their site http://foscam.us/content.php?id=firmware
@PW44 I get the same problem with static IP-address
Purps,
The firmware is usually mirrored on the gadgetvictims website/blog:
http://www.gadgetvictims.com/
Don't you have the FI8905W? You should have the latest firmware already I imagine?
Barney
Thanks, that's good to know.
Yes, I have the FI8905W, device details as follows...
Device Firmware Version 11.15.2.17
Device Embeded Web UI Version 2.4.9.14
Cheers,
Matt.
@Barney just curious, suppose you have access to a demo webcamera, could it be used in Linuxmce?
@purps .... I think that is the latest. Going to test mine today.
@ladekribs ... I imagine it would work but the frame rate should be reduced. There is a command for the url to reduce the frame rate.
/videostream.cgi?user=user&pwd=password&rate=1
OK. I can confirm that the ARP fix doesn't work. I set the arp record for this camera on the core using:
sudo arp -s 192.168.80.XXX AA:BB:CC:DD:EE:FF
This does not affect the dropouts.
Just tried pw44s suggestion of fixing the IP in the cameras web admin. Still lost connection within 10 mins.
>:(
@Purps did you try http://www.foscam.com/dow.asp?anid=6 ?
@Barney I wonder what the differnce is when you put it behind a gateway I tried a Dlink, and there it seems to work(have not tried port forwarding yet...)
@ladekribs
I can't access that url either. I think my IP range (sky broadband in the uk) must be blocked somehow. Should be possible using a proxy.
The camera works on my regular router too. Just about to post my findings.
Barney
I have all but given up on this. My suggested fix is:
1. Connect the Foscam to your external router
2. Log onto the camera web admin and give the camera a fixed IP address on your external network
3. Use this IP address in the lmce web admin
This works for me.
I am frustrated that there is no solution. I think the problem must be related to the handling of arp/dhcp by lmce (dhcpd) and the camera itself. This camera works fine on almost any other dhcp network. Conversely it seems that any other IP camera works in lmce.
Here's what I just retried:
1. Connected my FI8905W to the lmce network switch using cat6 cable (passive poe injected).
2. The camera works
3. After a few minutes the connection is lost. I can't access the camera from my PC ... or ping ... or anything.
4. Simply unplug the network cable then reconnect
5. Go to step 2
This also happened on my wired FI8904W.
My FI8908Ws use wireless and don't seem to have this problem.
Any network experts want to chip in?
Barney
Quote from: b4rney on December 08, 2010, 12:41:34 PM
OK. I can confirm that the ARP fix doesn't work. I set the arp record for this camera on the core using:
sudo arp -s 192.168.80.XXX AA:BB:CC:DD:EE:FF
This does not affect the dropouts.
Just tried pw44s suggestion of fixing the IP in the cameras web admin. Still lost connection within 10 mins.
>:(
Are you fixing the IP in Firefox on the core? That is where I get the error "error: illegal params." in the page. Did you use windoze and the supplied Foscam utility at any point?
Quote from: b4rney on December 08, 2010, 01:18:59 PM
@ladekribs
I can't access that url either. I think my IP range (sky broadband in the uk) must be blocked somehow. Should be possible using a proxy.
The camera works on my regular router too. Just about to post my findings.
Barney
Nope, can't access the URL either.
My setup:
internal network card: Intel PCI-ex 1000
Switch: Asus Gigabit switch
Wifi AP: D-Link DWL-2100AP
All 3 cameras are wireless and with static ip address.
1 IPAQ Wifi as orbiter
2 Cisco 7970 (wired)
1 SPA-3102 (wired)
Netgear printserver (wired)
1 MD (wired)
I can only say that my cameras are defined as generic ip cameras, under motion and that they work without problems.
The only problem i still have is with motion, when DCERouter is reloaded, sometimes motion is lost, so i need to restart it with /etc/init.d/motion restart, and voilà, it works again....
The decision to define the cameras with static ip was because of the frequent lost of connection.....
I really cannot say why you are having connection problems..... i would check all the network pieces, or the distance of the cameras to the ap, if used wireless.
I think my only option now is to try and set up static IPs in windoze. Will try it in VirtualBox before I beg/borrow/steal a laptop from someone.
Cheers,
Matt.
Quote from: pw44 on December 08, 2010, 06:26:16 PM
I can only say that my cameras are defined as generic ip cameras, under motion and that they work without problems.
Do you mean generic MOTION ip camera? Not being pedantic, just want to be sure we're all talking about the same thing here.
Cheers,
Matt.
Quote from: purps on December 08, 2010, 02:04:36 PM
Are you fixing the IP in Firefox on the core? That is where I get the error "error: illegal params." in the page. Did you use windoze and the supplied Foscam utility at any point?
I used the cameras web admin (using google chrome browser on ubuntu).
Went to:
Device management > Basic network settings
Unchecked 'obtain IP from DHCP server'
Set the IP address:
192.168.0.XX
subnet mask to:
255.255.255.0
gateway and DNS to:
192.168.0.1 (router)
I don't get any errors like you have. I have the same firmware version as you.
Barney
I think pw44 is using 'Generic IP camera' and not motion. I doubt this would make any difference to our problem. He's also using wireless where I'm using a wired connection.
I don't get this problem with wireless on my FI8908Ws.
Are you using wired Matt?
Barney
Barney,
That's interesting, I'm trying to think whether I have tried using my normal desktop (as opposed to the core). I'm sure I would have tried that, but I can't specifically remember, will try tonight to be certain. Maybe it only worked because your cameras are connected to your router as opposed to the core?!
Anyway, I tried doing it through my VBox XP installation last night, and whilst I am feeling dirty all over, I had some success. Both the Foscam utility and web admin (in IE) were able to set static IPs (no more nasty errors on the web page). The IP Addr and Subnet Mask were automatically filled out correctly, but both Gateway and DNS Server were filled out with the same thing, 192.168.80.1. Obviously this isn't in line with the network settings in web admin, so I will change this tonight and see how it goes.
Yes, I am using wired.
Cheers,
Matt.
I think that's your problem.
The camera is basically attached to your external network and uses the external gateway and dns (192.168.0.1 usually).
LMCE can still access the camera on the external network, you just need to change the IP address of the camera in lmce web admin and the corresponding 'path'.
Barney
Quote
Do you mean generic MOTION ip camera? Not being pedantic, just want to be sure we're all talking about the same thing here.
Yes, Generic Motion IP Camera #1916. Sorry for not defined the complete device template used, which could cause confusion.
Quote from: b4rney on December 09, 2010, 11:36:34 AM
I think that's your problem.
The camera is basically attached to your external network and uses the external gateway and dns (192.168.0.1 usually).
LMCE can still access the camera on the external network, you just need to change the IP address of the camera in lmce web admin and the corresponding 'path'.
Barney
I can't say one way or the other at this precise moment. I need to try the correct static IP settings with the cameras on the internal network, which I will do this evening. I haven't tried putting them on the external network yet, something I would like to avoid, as the router is then ANOTHER device I have to plug into my UPS, but failing this static IP set up thing, I am not going to have much choice it would seem.
Hi,
In PW44 case his camera communicates via the "Wifi AP: D-Link DWL-2100AP" ie ARP nefore it is linked to the core, that might be the reason it works for him.
guess you already figured that out :-)
by the way it worked to use an external demo camera as you said barney
br stefan
@pw44 - could you please confirm whether your Foscams are wired or wireless please? I assumed you were talking wired.
Cheers,
Matt.
My foscam is wireless connected.
OK. I am trying to do this wired.
It would seem that setting static IPs has not worked for me. When I apply the static IP, the following is generated...
IP Addr - 192.168.80.139
Subnet Mask - 255.255.255.0
Gateway - 192.168.80.1
DNS Server - 192.168.80.1
...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.
Why is 86.28.XXX.X an "illegal" gateway?
Cheers,
Matt.
@purps because you want the traffic to go to your core, not to the dns server
br Stefan
So would you say that the Gateway and DNS Server that was automatically specified by the Foscam utility...
Gateway - 192.168.80.1
DNS Server - 192.168.80.1
...is correct? If not, is there anything else I can try?
Cheers,
Matt.
EDIT: In web admin the Gateway and DNS1 are 86.28.XXX.X and 194.168.4.100 respectively.
these looks correct:
IP Addr - 192.168.80.139
Subnet Mask - 255.255.255.0 - masking: what is left on the rightmost dot is outside(mostly internet) and right of dot is inside
Gateway - 192.168.80.1 - where you want all traffic to go(you want all to go via the core)
DNS Server - 192.168.80.1 - core will act as a proxy for your inside clients requests.
one test we could do is to setup a std kubuntu server with the same dhcp server as in linuxmce installed and see if the foscam fails the same way.
I will also test port forwarding on the local net
BR Stefan
Thank you for confirming, Stefan.
I can therefore confirm that setting up static IPs (for a wired setup) does not work.
I have a funny feeling that it would probably work on a standard Kubuntu server, as Barney has it working using a normal router; an approach that I now have no choice but to take in order to get this working before Christmas.
Cheers,
Matt.
Purps,
My camera has been rock solid on my external router for two days now. Using fixed IP address (set in the foscam web admin) on my external network, with a wired connection.
Are you still getting errors when you try to set the static IP on the camera?
Barney
Hi Barney,
I am going to attempt the external router approach next; I have little choice. Hopefully it will work (not that I don't trust you ;)).
Regarding the error, see my previous post...
QuoteIt would seem that setting static IPs has not worked for me. When I apply the static IP, the following is generated...
IP Addr - 192.168.80.139
Subnet Mask - 255.255.255.0
Gateway - 192.168.80.1
DNS Server - 192.168.80.1
...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.
Why is 86.28.XXX.X an "illegal" gateway?
@Matt,
Sorry ... missed that.
Your gateway (and usually dns) needs to be on the same subnet, but I guess you figured that out already!
@stefan ... I'd be interested to see the results of a standard kubuntu dhcp server test. Another useful tool I just read about is arpwatch. Just in case it is an arp problem.
Barney
Truth be told Barney, I am not familiar with many of these terms. So what you and Stefan are saying is that the gateway and DNS basically need to be in the format 192.168.XXX.X, and not the "external looking" one.
I will try it using 192.168.80.1 for the gateway and use DNS1 from web admin for DNS on the Foscam, but I don't have much hope.
FYI I noticed on the utility that you run in windows that there is an option (when you right-click on the camera) to "flush ARP". Not sure if that's relevant, but thought I'd mention it.
Cheers,
Matt.
Hi Matt,
It is confusing. In LMCE we often refer to internal and external networks. The internal address is always 192.168.80.X. This is the internal subnet used by LMCE.
When we talk about the external network we actually mean the home adsl network. In your case I think your home network is 192.168.4.X.
Confusingly these are both private networks.
http://en.wikipedia.org/wiki/Private_network
You need to attach the camera to the external network.
This means an ip address in the 192.168.4.X network.
Subnet mask 255.255.255.0
Gateway 192.168.4.100
DNS 192.168.4.100
The 192.168.4.100 is your cable modem which acts as your gateway/dns server.
Hope this helps.
Barney
Well the camera is working, on the external network as you described. Very glad that it is working (thank you!), but frustrated at the same time that we couldn't get it working on the internal network.... and now I've got to go out an buy another wireless access point also.
I am curious as to why you suggested 192.168.4.X. for my home network? Is this based on the DNS1 address I found in web admin? What does that have to do with my home network? Not having a go at you, I am genuinely curious!
My Netgear router admin page is accessed via 192.168.1.1, so I put this in for both gateway and DNS - is that the wrong way to do it? Whilst it is working now, I don't want it to be unreliable because I messed up the settings! Subnet 225.225.225.0 as per usual and the actual IP 192.168.1.X.
Cheers,
Matt.
I picked up a few foscams to test this problem with. On mine, I can watch the mjpeg stream directly in a browser by going to <ip_address>/videostream.cgi from any computer in the network.
However, it will not work at all under motion wrapper (I do have several other mjpeg cameras running fine under motion wrapper also). For these foscams, I only get a gray screen saying that the connection has been lost.
I have been doing a lot of reading on ARP problems - there is a good read here:
http://linux-ip.net/html/ether-arp.html
ARP Flux is apparently a common problem when running multiple network cards in linux. I have tried both setting static ARP table entries as well as setting the arp_filter sysctl with no luck - but it does seem that there is a problem specifically in LinuxMCE's handling of these ARP requests. Surely there has to be a networking wizard here that could chime in and help us fix this permanently!
Quote from: purps on December 09, 2010, 10:36:54 PM
...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
@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
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
Quote from: b4rney on December 12, 2010, 12:30:24 PM
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.
Quote from: jondecker76 on December 13, 2010, 02:51:45 AM
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.
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 :)
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.
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:
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!
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
@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
>:(
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):
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:
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:
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).
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
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
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:
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:
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!
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...
Done the same as your last post (including removal of filters). Rebooted and the camera was blank. Disconnected the cable then reconnected and it appeared.
Am now watching with bated breath.
Barney
How long does your camera usually last before it dies? Mine was lasting 10 minutes tops (and even hard cycling power to the camera wouldn't bring it back).
The arp_filter got me 10 hours, and power cycling the camera would bring it back.
Now, lets see how the arp_announce/ignore works
Normally fails within 10 minutes. However, simply removing the network cable and replacing it would bring it back.
Since your fix I've had 40 minutes and still going.
I applied the fix to eth1.
Barney
ok cool
since you're trying without an arp_filter, I switched and I'm trying with arp_filter=1, arp_ignore=1 and arp_announce=2. Hopefully one or both of us will have success
unfortunately, no good news to report yet. The foscam holds on for a few hours then locks (no longer responds to arping requests at all)
Going to keep trying different settings...
I would like to hear if this is working for other foscam users.
I just did some research and found out that the foscam that I'm using is a fake foscam, so my results may not be reliable!
Here is a good article that has a great example of telling a fake from a real foscam based on the stickers on the back....
http://www.gadgetvictims.com/2009/09/yet-another-firmware-for-foscam-fi8908w.html
Bad news I'm afraid. Left my camera running after my last post but it had already failed after the initial 40 minutes.
Let me know if you want more testing.
Barney
Just checking the cameras image folders and motion is taking a snapshot every second instead of every minute from each of my cameras as well as monitoring the videostream.cgi. So I have 3600 images per hour per camera (two cameras at present).
In the motion config the setting reads:
snapshot_interval 60
Which surely means every minute.
Anyone else seeing this?
Barney
I checked mine, and mine are all once per minute
Sounds like maybe its detecting false motion (noise?) as it will also store images on a per second basis when there is motion.
Can you confirm if you have a genuine Foscam?
Yes, all genuine foscams.
Wireless works OK. I get these problems primarily with a wired connection.
Barney
I'm going to start fresh. I enabled dhcpd logging and I'm going to take a fresh look at what happens when connection is lost and go from there. I just spent a bunch of time examining out DHCP setup, as well as studying al the available configuration options.
DHCP doesn't seem to be the problem.
I removed the surveillance camera from the web admin so that Motion wouldn't be requesting any images from it, and did a reboot.
Watching the DHCP logs, everything goes as it should and the foscam is given an IP address, and everything ran for over 24 hours without the foscam dropping out. I was also running tcpdump and analyzed the packets in wireshark.
Just re-added the foscam in the web admin and did a reload of the router. Motion is now grabbing images - I'm running tcpdump so I can examine what goes wrong in wireshark, and I'm also logging the DHCP stuff as well. Hopefully I'll find something!
The camera just crashed while I was writing this, going to analyze the data now...
Been glancing over the data, and here is what I have so far....
The camera served its last image to motion at 10:05.07, and got the first disconnection grey screen at 10:05.12
Here is a small section of the tcpdump (without the actual packet data to keep it small). You can see that the foscam would send 2 packets of data to the core, then the core would send an ACK.. This repeated for over 10 minutes - 2 data packets from the foscam, and ack from the core.. repeat... repeat...
Then, look at packet 206761... The foscam sends only a single package, and its marked as a retransmission, then the core sends a duplicate ACK.. From there, things look a little messed up for a few packages, then the ARP requests start firing, and the foscam never responds..
No. Time Source Destination Protocol Info
206752 686.838205 192.168.80.1 192.168.80.202 TCP 60632 > http [ACK] Seq=124 Ack=189955810 Win=87872 Len=0 TSV=12705657 TSER=5021270
206753 686.838592 192.168.80.202 192.168.80.1 HTTP Continuation or non-HTTP traffic[Packet size limited during capture]
206754 686.838857 192.168.80.202 192.168.80.1 HTTP Continuation or non-HTTP traffic[Packet size limited during capture]
206755 686.838936 192.168.80.1 192.168.80.202 TCP 60632 > http [ACK] Seq=124 Ack=189957993 Win=87872 Len=0 TSV=12705658 TSER=5021270
206756 686.874947 192.168.80.202 192.168.80.1 HTTP Continuation or non-HTTP traffic[Packet size limited during capture]
206757 686.875301 192.168.80.202 192.168.80.1 HTTP Continuation or non-HTTP traffic[Packet size limited during capture]
206758 686.875411 192.168.80.1 192.168.80.202 TCP 60632 > http [ACK] Seq=124 Ack=189960889 Win=87872 Len=0 TSV=12705667 TSER=5021273
206759 686.875852 192.168.80.202 192.168.80.1 HTTP Continuation or non-HTTP traffic[Packet size limited during capture]
206760 686.915893 192.168.80.1 192.168.80.202 TCP 60632 > http [ACK] Seq=124 Ack=189962337 Win=87872 Len=0 TSV=12705677 TSER=5021273
206761 687.046868 192.168.80.202 192.168.80.1 HTTP [TCP Retransmission] Continuation or non-HTTP traffic[Packet size limited during capture]
206762 687.046942 192.168.80.1 192.168.80.202 TCP [TCP Dup ACK 206760#1] 60632 > http [ACK] Seq=124 Ack=189962337 Win=87872 Len=0 TSV=12705710 TSER=5021273 SLE=189950018 SRE=189951466
206763 687.178848 PcPartne_27:b8:1a DavicomS_86:78:a6 ARP Who has 192.168.80.202? Tell 192.168.80.1
206764 687.466883 192.168.80.202 192.168.80.1 HTTP [TCP Retransmission] Continuation or non-HTTP traffic[Packet size limited during capture]
206765 687.466960 192.168.80.1 192.168.80.202 TCP [TCP Dup ACK 206760#2] 60632 > http [ACK] Seq=124 Ack=189962337 Win=87872 Len=0 TSV=12705815 TSER=5021273 SLE=189950018 SRE=189951466
206766 687.832034 192.168.80.1 192.168.80.202 NBNS Name query NBSTAT *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>
206767 688.179661 PcPartne_27:b8:1a DavicomS_86:78:a6 ARP Who has 192.168.80.202? Tell 192.168.80.1
206768 688.306900 192.168.80.202 192.168.80.1 HTTP [TCP Retransmission] Continuation or non-HTTP traffic[Packet size limited during capture]
206769 688.306997 192.168.80.1 192.168.80.202 TCP [TCP Dup ACK 206760#3] 60632 > http [ACK] Seq=124 Ack=189962337 Win=87872 Len=0 TSV=12706025 TSER=5021273 SLE=189950018 SRE=189951466
206770 689.179664 PcPartne_27:b8:1a DavicomS_86:78:a6 ARP Who has 192.168.80.202? Tell 192.168.80.1
206771 689.986923 192.168.80.202 192.168.80.1 HTTP [TCP Retransmission] Continuation or non-HTTP traffic[Packet size limited during capture]
206772 689.987066 192.168.80.1 192.168.80.202 TCP [TCP Dup ACK 206760#4] 60632 > http [ACK] Seq=124 Ack=189962337 Win=87872 Len=0 TSV=12706444 TSER=5021273 SLE=189950018 SRE=189951466
206773 693.346951 192.168.80.202 192.168.80.1 HTTP [TCP Retransmission] Continuation or non-HTTP traffic[Packet size limited during capture]
206774 693.350801 PcPartne_27:b8:1a Broadcast ARP Who has 192.168.80.202? Tell 192.168.80.1
206775 694.350674 PcPartne_27:b8:1a Broadcast ARP Who has 192.168.80.202? Tell 192.168.80.1
206776 695.351191 PcPartne_27:b8:1a Broadcast ARP Who has 192.168.80.202? Tell 192.168.80.1
206777 696.879048 PcPartne_27:b8:1a Broadcast ARP Who has 192.168.80.202? Tell 192.168.80.1
206778 697.879183 PcPartne_27:b8:1a Broadcast ARP Who has 192.168.80.202? Tell 192.168.80.1
206779 698.880183 PcPartne_27:b8:1a Broadcast ARP Who has 192.168.80.202? Tell 192.168.80.1
206780 699.939171 PcPartne_27:b8:1a Broadcast ARP Who has 192.168.80.202? Tell 192.168.80.1
206781 700.067001 192.168.80.202 192.168.80.1 HTTP [TCP Retransmission] Continuation or non-HTTP traffic[Packet size limited during capture]
206782 700.939177 PcPartne_27:b8:1a Broadcast ARP Who has 192.168.80.202? Tell 192.168.80.1
206783 701.939205 PcPartne_27:b8:1a Broadcast ARP Who has 192.168.80.202? Tell 192.168.80.1
206784 703.203170 PcPartne_27:b8:1a Broadcast ARP Who has 192.168.80.202? Tell 192.168.80.1
206785 704.203180 PcPartne_27:b8:1a Broadcast ARP Who has 192.168.80.202? Tell 192.168.80.1
206786 705.203174 PcPartne_27:b8:1a Broadcast ARP Who has 192.168.80.202? Tell 192.168.80.1
206787 709.731170 PcPartne_27:b8:1a Broadcast ARP Who has 192.168.80.202? Tell 192.168.80.1
206788 710.730686 PcPartne_27:b8:1a Broadcast ARP Who has 192.168.80.202? Tell 192.168.80.1
206789 711.732741 PcPartne_27:b8:1a Broadcast ARP Who has 192.168.80.202? Tell 192.168.80.1
206790 713.507129 192.168.80.202 192.168.80.1 HTTP [TCP Retransmission] Continuation or non-HTTP traffic[Packet size limited during capture]
(if anyone wants the full dump of this data that includes the packet data, I have that available too)
Ok, now lets look at the dhcpd log data for this time frame:
Dec 17 09:47:32 dcerouter dhcpd: For info, please visit http://www.isc.org/sw/dhcp/
Dec 17 09:47:32 dcerouter dhcpd: Wrote 0 deleted host decls to leases file.
Dec 17 09:47:32 dcerouter dhcpd: Wrote 0 new dynamic host decls to leases file.
Dec 17 09:47:32 dcerouter dhcpd: Wrote 14 leases to leases file.
Dec 17 10:05:35 dcerouter dhcpd: DHCPREQUEST for 192.168.80.200 from 00:17:ab:41:72:c5 (Wii) via eth0
Dec 17 10:05:35 dcerouter dhcpd: DHCPACK on 192.168.80.200 to 00:17:ab:41:72:c5 (Wii) via eth0
Dec 17 10:12:36 dcerouter dhcpd: DHCPREQUEST for 192.168.80.200 from 00:17:ab:41:72:c5 (Wii) via eth0
Dec 17 10:12:36 dcerouter dhcpd: DHCPACK on 192.168.80.200 to 00:17:ab:41:72:c5 (Wii) via eth0
As you can see, there are no indications that the connection was dropped by the dhcp server (it would show a DHCPNAK if it did). There is a request at 10:05.35, but this should be totally unrelated and was after 10:05.12 anyways...
One more log I checked was /var/log/pluto/dhcp_pnp.log, and it showed nothing to indicate a a DHCP problem.
So it looks like the tcpdump data is all we have to go by and now we have to figure out how and why it goes haywire
So it looks like the foscam fails? Looks like it's waiting for the ACK which is sent several times but not received for reasons unknown. At this point all communication with the camera is lost.
Still ... this does not happen when I attach my camera to my router on the external network. So what is the difference?
The tech support at foscam is very responsive. You could send these results to Sarah at foscam to see if she has an explanation.
Here is my last exchange with her.
Barney
Dear Barnaby,
Thank you for the info,I think it is the settings of your router.
The camera may cause ip conflict if there is incorrect settings in your router.
It can also obtain wrong ip if there are near network section.
If it have these issue,the better way is set a fixed ip for the camera.
As the camera have two mac address,one is wired,the other is wireless.
So it will have two different ip when wired or wireless if you obtain ip from DHCP.
Best Regards
Sarah Zhang (Miss)
Technical Support&Service Team
Email: tech@foscam.com
Foscam Intelligent Technology co., Ltd.
Tel: 86-755-2674 5668
Fax: 86-755-2674 5168
Mobile: +86 15117454607
Website: www.foscam.com
2010-12-09
From： Barnaby Fry
At： 2010-12-08 18:27:37
To： tech@foscam.com
CC：
Subject： RE: DHCP/ARP firmware fix
Hello Sarah,
The problem I have is with a wired connection. I have the newer FI8905W which replaced my FI8904W. The problem occurs on both these models when using a wired connection.
This problem only happens on certain DHCP servers. When plugged into my router the camera works fine. When plugged into my other network (using dhcpd) I lose connectivity regularly.
The link I sent suggests that there is a problem with ARP requests.
http://blog.stead.id.au/2010/06/resolving-foscam-connection-dropouts.html
Also posted problem here:
http://forum.linuxmce.org/index.php?topic=10134.0
Kind regards
Barnaby Fry
Yes, it does seem that the foscam is responsible for dropping the connection from all the logging I have done - but that doesn't explain why it works on the external network... strange!
Also, I have set up static ARP table entries for test, and even with no ARP packages being sent from LMCE, the foscam still drops connection.
Yes I know it's been a while in this post...
But I face exactly same problem with mine Foscam clones (IP-Camera-002a) + my Arduino webserver. While I used AP as DHCP server I could get access to my ip camera + Arduino webserver. but using LMCE as DHCP server seems to loose my ip connection. I have added another Foscam IP camera clone to LMCE compated to my 'old' setup, just to mention it.
I understand it's something with arp tables timeout and I assume it's not really LMCe but the DHCP server in Kubuntu that seems to be sensitive with something - I wonder if there is a quick-fix so I could force an arp table manually to never timeout or what shall I do?
you can add a static entry to the arp table (arp -s). But please be aware that arp does not directly relate to DHCP. DHCP just tells the client which IP address it shall use. The client then configures the interface and does the ARP communication with eventual local peers that want to talk to it. The initiator of the connection will send out an ARP who-has request for a specific IP on the local segment. The node with the IP address configured should send an arp reply with its MAC. This all happens without DHCP.
Hey,
Any positive solutions on the topic?
I'm having exactly the same issue. In my eyes, nothing to do with linuxmce. I can't even ping the camera anymore from my switch on (between server and camera).
It's enough to restart the switchport to solve the issue. Should be the same effect with disconnecting/reconnecting the cable. But the server itself (linuxmce) doesn't have anything to do with it...
Since it's a foscam clone (or whatever), nowhere proper support... >:(
Even messed up one camera with the wrong firmware... :$
Sorry no progress so far. I will update as soon as i get anywhere. But I have also recently become a father so I don't have much time, so please be patient :-)
If you need an solution, i think i've got one. :o
When i put my switch on 10HD instead of auto (or 100FD/HD...), i've got no interruptions.
So try the speed to 10HD (switchsettings, an old hub instead of switch...).
I've tested it also with fixed settings on 100FD, but i had the same result. I think that the build in network card can't live with real 100 full duplex... ;)
Before i lost connections after a few minutes. Now it runs for about 48hours without any hickup.
I monitor the camera with cacti, i poll it each minute, so quite sure that i've got no interruptions anymore...
Quote from: brononius on July 29, 2012, 02:27:33 PM
If you need an solution, i think i've got one. :o
When i put my switch on 10HD instead of auto (or 100FD/HD...), i've got no interruptions.
So try the speed to 10HD (switchsettings, an old hub instead of switch...).
I've tested it also with fixed settings on 100FD, but i had the same result. I think that the build in network card can't live with real 100 full duplex... ;)
Before i lost connections after a few minutes. Now it runs for about 48hours without any hickup.
I monitor the camera with cacti, i poll it each minute, so quite sure that i've got no interruptions anymore...
Hi Ben,
I have tried to change my settings in my netgear wgr614v9 but I can only choose between B&G or only G.
I will try to find an old router and try your proposal.
And thank you for sharing your valuable info :-)
-Brian
Quote from: bri_jac on July 31, 2012, 09:53:52 AM
I have tried to change my settings in my netgear wgr614v9 but I can only choose between B&G or only G.
Oei, i think that you're working wireless?
I was talking about wired conection (physical cable). :(
But maybe with an older wireless router (lower speeds?) it could give the same result?
Quote from: brononius on July 29, 2012, 02:27:33 PM
If you need an solution, i think i've got one. :o
When i put my switch on 10HD instead of auto (or 100FD/HD...), i've got no interruptions.
So try the speed to 10HD (switchsettings, an old hub instead of switch...).
I've tested it also with fixed settings on 100FD, but i had the same result. I think that the build in network card can't live with real 100 full duplex... ;)
Before i lost connections after a few minutes. Now it runs for about 48hours without any hickup.
I monitor the camera with cacti, i poll it each minute, so quite sure that i've got no interruptions anymore...
Hi everyone,
I have your same problem on my foscam camera's.
With this workaround did you finally fix the problem without more interruptions??
Thanks