DHCP leases Foscam IP camera problem

[b4rney]

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

[jondecker76]

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

[b4rney]

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

[jondecker76]

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

[jondecker76]

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

[jondecker76]

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

[b4rney]

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

[b4rney]

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

[jondecker76]

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?

[b4rney]

Yes, all genuine foscams.

Wireless works OK. I get these problems primarily with a wired connection.
Barney

[jondecker76]

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.

[jondecker76]

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

[jondecker76]

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

Code: [Select]

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:

Code: [Select]

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

[b4rney]

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

Code: [Select]

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

[jondecker76]

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.