Wansview W3 WiFi cams feeds stop - "CLOSE_WAIT"

[steveboyer85]

Good day,

I have two Wansview W3 WiFi/Ethernet cameras connected via WiFi to my Zoneminder 1.29 VM by RTSP and have been having an issue with them daily. Namely, the feeds "stop" and I'm not able to view them. The root /zm/ page has the feeds red. Clicking on them, verifying settings, and re-saving the options makes them work A-OK... until it happens again. Digging some into it via

Code: Select all

sudo netstat -a

, there are two connections to each camera stuck in a "CLOSE_WAIT" status. My understanding is the cameras send a TCP packet with the "FIN" flag set, but never send anything else to actually close the port, resulting in this port to just hang out indefinitely, waiting to finish closing out the TCP session by the camera. My latest attempt at fixing was writing a script do a

Code: Select all

netstat

, grepping out for the IP and "CLOSE_WAIT," then killing the process id associated with it (obtained via

Code: Select all

lsof -i@<ip address> -t

. It still never comes back up though, unless I go into the web UI and re-save the settings, which isn't an option when I want to execute it as a cron-job every minute. Executing

Code: Select all

sudo zmu -m <monitor ID> -L

to reload the settings for that monitor isn't sufficient either. Latest firmware available from the company applied (whose response was essentially "our app works fine!" I'm sure it does indeed work fine - for about a day then I'll have the same issue...). Changing the feeds to use a captured JPG image works indefinitely, but runs at 1-2 FPS, rather than the camera-limited 15 FPS over RTSP/h264.

Any thoughts/scripting suggestions to execute an equivalent "re-save?"

A few more details:
OS: Debian Stretch VM
ZM: 1.29 via stretch-backports
WiFi AP: Ubiquiti AC-AP-Pro
Gigabit switch in-between AP and Host PC

[bbunge]

https://wiki.zoneminder.com/Foscam_Clones

[steveboyer85]

Update: I've added deb-multimedia's repo to the apt source.list and updated ZoneMinder to 1.30.4. So far (knock on wood), I've not had any issues, so somewhere in the many updates since 1.29.0, some error handling probably was introduced to prevent this "stuck" state.

https://wiki.zoneminder.com/Foscam_Clones

Thanks, but not sure you fully understood what I was saying. I already had a connection from the ZM server to the IP Cam, but was having issues where it would need human intervention to operate correctly again. For the record:

Wansview W3 720p IP Camera:
Source Type: remote
Remote Proto: RTSP
Remote Method: RTP/RTSP/HTTP
Remote Host Name: <user>:<password>@<IP address>
Remote Host Path: /live/ch0
Target Colospave: 24-bit color
Capture width: 1280
Capture Height: 720

The camera itself is limiting to 12 fps and over a decent WiFi connection, can get that easily.

[SlowScan]

Not sure if this will help or is applicable, but it might be of interest. I had two WansView W2 cameras running using WiFi until I could run Ethernet cable to them. They would lock up at random times and require power cycling to get going again. Oddly, one of them was much more likely to fail than the other. No idea why.

Since I connected them directly via Ethernet cables and disabled WiFi in their menus, I have not had a single lock up from either one.

[steveboyer85]

The error I was having was different than this. Regardless, it is indeed interesting. I had my W3's freeze up on me once in the past couple of weeks to where I couldn't actually pull the RTSP feed off of it, but the web server itself was still responding. I was able to login via a web browser directly to the cameras and do a remote reset. Kind of crazy to do it from 200+ miles away through a VPN.

Good to know about the Ethernet run being more stable -- if I start having issues where the lock-up on me, I'll try that method. I will probably do it regardless, so I'm not using so much of the bandwidth of the 2.4 GHz spectrum.

[SlowScan]

"Good to know about the Ethernet run being more stable -- if I start having issues where the lock-up on me, I'll try that method. I will probably do it regardless, so I'm not using so much of the bandwidth of the 2.4 GHz spectrum."

I'll just add that these cams were the only thing I had on 2.4 GHz. Also, mine is a rural location with virtually no RF congestion. I suspect a software issue with the cameras.