Foscam Adventures
09/02/13 16:42 Filed in: Devices
I recently acquired a couple of Foscam IP Cameras for keeping an eye on my horses while in their stables or their yards. The earlier model went in without a hitch replacing a venerable Swann IP camera which had finally died. The newer model (an FI8910W) kept rebooting every 60 or so seconds …
A couple of clues to the problem emerged early as I was able to log in to the camera’s web page and see it complaining about a communication error while it attempted to set up its Dynamic DNS (DDNS) session with Foscam’s DDNS server.
Also we found that relocating the camera to a more conventionally firewalled site the Foscam FI8910W actually successfully connected with its DDNS server and knew that it had succeeded.
The steps to a solution became obvious:
As a first cut I selected to look at only the UPD traffic and a strange port turned up - 2051 - in the successful connection. A classic keep-state UDP firewall rule would easily capture a working semantic i.e. allow a protected device to receive a response to a query for a short period after the query packet is sent. This explained why the more conventionally firewalled (permissive) site allowed the camera to work. At the site where the Foscam failed UPD port 2051 is blocked. Allowing the camera to receive traffic back on port 2051 allowed the DDNS to register fully and fixed the reboot problem.
Adding suitable rules to the firewall allows the camera to work, however, if the network is isolated and the camera reboots (a very real possibility in that location) then the camera will continue to reboot until it is able to connect to the DDNS server - a rather suboptimal outcome. The older camera and firmware which did not care if the DDNS worked is actually superior for this location.
Also we found that relocating the camera to a more conventionally firewalled site the Foscam FI8910W actually successfully connected with its DDNS server and knew that it had succeeded.
The steps to a solution became obvious:
- Set up a mirror port on the switch at the site the camera worked
- Use Wireshark to capture a successful connection
- Examine the capture for a handshake with the DDNS
As a first cut I selected to look at only the UPD traffic and a strange port turned up - 2051 - in the successful connection. A classic keep-state UDP firewall rule would easily capture a working semantic i.e. allow a protected device to receive a response to a query for a short period after the query packet is sent. This explained why the more conventionally firewalled (permissive) site allowed the camera to work. At the site where the Foscam failed UPD port 2051 is blocked. Allowing the camera to receive traffic back on port 2051 allowed the DDNS to register fully and fixed the reboot problem.
Adding suitable rules to the firewall allows the camera to work, however, if the network is isolated and the camera reboots (a very real possibility in that location) then the camera will continue to reboot until it is able to connect to the DDNS server - a rather suboptimal outcome. The older camera and firmware which did not care if the DDNS worked is actually superior for this location.