Feature Enhancement: Add MHD_OPTION_CONNECTION_TIMEOUT and a user parameter.

[dranch]

I connect to Motion 4.3.2 running on a Raspberry Pi motion setup from various different networks but sometimes if I switch to a different Wifi network that the Pi cannot connect to, I will get dead but permanently ESTABLISHED TCP connections on the Pi's network stack.
For example, this has been ESTABLISHED for days yet the remote client IP is not on the network:

$ netstat -an | grep 8081
tcp 0 0 0.0.0.0:8081 0.0.0.0:* LISTEN
tcp 0 0 192.168.0.126:8081 192.168.0.114:60536 ESTABLISHED

This issue is well described here https://blog.cloudflare.com/when-tcp-sockets-refuse-to-die . It seems that adding the TCP_USER_TIMEOUT option in src/netcam_http.c is an elegant solution and you can see one example of it here: https://stackoverflow.com/questions/70695939/does-tcp-user-timeout-apply-when-trying-to-establish-a-connection . So, I'm ultimately requesting if Motion might consider enabling this by default?

[Mr-Dave]

netcam_http.c is generally for use when ffmpeg is not installed and only applicable for few cameras. The default has already been changed to use the ffmpeg libs for connecting to all cameras such that netcam_http.c isn't used.

[dranch]

This is using a Raspberry Pi Camera v1.2 with everything else set to default.

As a follow up to my previous message, I find that if I first connect to the Motion server on 192.168.0.126:8081 first, two TCP connections are created to the client machine. If I then close the browser session on the client (Android phone), it's leaving one of the TCP connections still open! Alternatively, if I connect on 192.168.0.126:8080 and then click on the thumbnail, there is now only one TCP connection and once I close the web client (Android), the one TCP session is closed as expected! Maybe there is a different issue here than I originally suspected.

[dranch]

As another follow up, this seems to be the relevant part regarding ffmpeg when starting motion:

[0:motion] [NTC] [STR] [Apr 11 17:13:36] webu_start_strm: Starting all camera streams on port 8081
[0:motion] [NTC] [STR] [Apr 11 17:13:36] webu_strm_ntc: Started camera 0 stream on port 8081
[0:motion] [NTC] [STR] [Apr 11 17:13:36] webu_start_ctrl: Starting webcontrol on port 8080
[0:motion] [NTC] [STR] [Apr 11 17:13:36] webu_start_ctrl: Started webcontrol on port 8080
[0:motion] [NTC] [ENC] [Apr 11 17:13:36] ffmpeg_global_init: ffmpeg libavcodec version 58.91.100 libavformat version 58.45.100
[0:motion] [NTC] [ALL] [Apr 11 17:13:36] translate_init: Language: English
[0:motion] [NTC] [ALL] [Apr 11 17:13:36] motion_start_thread: Camera ID: 0 is from /etc/motion/motion.conf
[0:motion] [NTC] [ALL] [Apr 11 17:13:36] motion_start_thread: Camera ID: 0 Camera Name: (null) Device: /dev/video0
[0:motion] [NTC] [ALL] [Apr 11 17:13:36] main: Waiting for threads to finish, pid: 5361
[1:ml1] [NTC] [ALL] [Apr 11 17:13:36] motion_init: Camera 0 started: motion detection Enabled
[1:ml1] [NTC] [VID] [Apr 11 17:13:36] vid_start: Opening V4L2 device
[1:ml1] [NTC] [VID] [Apr 11 17:13:36] v4l2_device_open: Using videodevice /dev/video0 and input -1
[1:ml1] [NTC] [VID] [Apr 11 17:13:36] v4l2_device_capability: - VIDEO_CAPTURE
[1:ml1] [NTC] [VID] [Apr 11 17:13:36] v4l2_device_capability: - VIDEO_OVERLAY
[1:ml1] [NTC] [VID] [Apr 11 17:13:36] v4l2_device_capability: - READWRITE
[1:ml1] [NTC] [VID] [Apr 11 17:13:36] v4l2_device_capability: - STREAMING
[1:ml1] [NTC] [VID] [Apr 11 17:13:36] v4l2_input_select: Name = "Camera 0"- CAMERA
[1:ml1] [NTC] [VID] [Apr 11 17:13:36] v4l2_norm_select: Device does not support specifying PAL/NTSC norm
[1:ml1] [NTC] [VID] [Apr 11 17:13:36] v4l2_pixfmt_set: Testing palette YU12 (2592x1944)
[1:ml1] [NTC] [VID] [Apr 11 17:13:36] v4l2_pixfmt_set: Using palette YU12 (2592x1944)
[1:ml1] [INF] [VID] [Apr 11 17:13:36] v4l2_fps_set: Trying to set fps to 2
[1:ml1] [INF] [VID] [Apr 11 17:13:36] v4l2_fps_set: Device set fps to 2

[Mr-Dave]

It is not clear what you are referencing. The netcam_http.c is for Motion connecting to the camera. The log seems like you are connecting to a v4l2 device and your note seems to be indicating connecting to Motion.

The connection to Motion is in the webu_ modules. For this Motion uses libmicrohttpd so that lib manages the connections.

[dranch]

Maybe my initial grep was incorrect. What I'm talking about is connecting from Chrome on Android to Motion running on a Raspberry Pi on TCP port 8081. If the Android phone disappears on the network, it seems like Motion leaves a TCP connection to the client running forever and it never times out. From my initial research, it seems that using the TCP_USER_TIMEOUT socket option within the Motion application might help this time out. The first URL in this post describes my scenario pretty well.

[Mr-Dave]

Ok. Now I understand. Revising the title / request as appropriate.

Add MHD_OPTION_CONNECTION_TIMEOUT and a user parameter.

[dranch]

Ok.. thank you for your patience. Any thoughts on this behavior of two resulting TCP connections if I connect to port :8081 but I don't see that behavior if I connect to port :8080?