Extra connections when attempting to read an SRT stream with incorrect credentials

[r-nov]

Which version are you using?

v1.8.2

Which operating system are you using?

• Linux amd64 standard
• Linux amd64 Docker
• Linux arm64 standard
• Linux arm64 Docker
• Linux arm7 standard
• Linux arm7 Docker
• Linux arm6 standard
• Linux arm6 Docker
• Windows amd64 standard
• Windows amd64 Docker (WSL backend)
• macOS amd64 standard
• macOS amd64 Docker
• Other (please describe)

Describe the issue

When I try to read an SRT stream with incorrect credentials (tested with ffmpeg, VLC, and GStreamer), mediamtx continues to receive authentication requests even after the first one fails. This blocks receiving any other requests for a significant amount of time. In the case of ffmpeg, it's 8 requests, which means you can't read the stream again for about 16 seconds. If during the processing of these requests there are additional requests with incorrect credentials, the wait time will increase further until mediamtx processes all these requests. So after a few attempts with incorrect credentials, mediamtx will be blocked for minutes, and you won't be able to read the stream even with the correct credentials.
I guess this is an ffmpeg "feature" since VLC/GStreamer usually sends only 2-4 requests if you stop immediately after the first attempt, and mediamtx behaviour is correct, but it still prevents the normal use of mediamtx.

These are the logs when I try to read the stream with ffmpeg.

2024/05/24 10:16:09 INF MediaMTX v1.8.2
2024/05/24 10:16:09 INF configuration loaded from ***/mediamtx.yml
2024/05/24 10:16:09 DEB path manager created
2024/05/24 10:16:09 INF [SRT] listener opened on :8890 (UDP)
2024/05/24 10:16:27 INF [SRT] [conn 172.17.160.1:60176] opened
2024/05/24 10:16:29 INF [SRT] [conn 172.17.160.1:60176] closed: authentication failed: authentication failed
2024/05/24 10:16:29 INF [SRT] [conn 172.17.160.1:60176] opened
2024/05/24 10:16:31 INF [SRT] [conn 172.17.160.1:60176] closed: authentication failed: authentication failed
2024/05/24 10:16:31 INF [SRT] [conn 172.17.160.1:60176] opened
2024/05/24 10:16:33 INF [SRT] [conn 172.17.160.1:60176] closed: authentication failed: authentication failed
2024/05/24 10:16:33 INF [SRT] [conn 172.17.160.1:60176] opened
2024/05/24 10:16:35 INF [SRT] [conn 172.17.160.1:60176] closed: authentication failed: authentication failed
2024/05/24 10:16:35 INF [SRT] [conn 172.17.160.1:60176] opened
2024/05/24 10:16:37 INF [SRT] [conn 172.17.160.1:60176] closed: authentication failed: authentication failed
2024/05/24 10:16:37 INF [SRT] [conn 172.17.160.1:60176] opened
2024/05/24 10:16:39 INF [SRT] [conn 172.17.160.1:60176] closed: authentication failed: authentication failed
2024/05/24 10:16:39 INF [SRT] [conn 172.17.160.1:60176] opened
2024/05/24 10:16:41 INF [SRT] [conn 172.17.160.1:60176] closed: authentication failed: authentication failed
2024/05/24 10:16:41 INF [SRT] [conn 172.17.160.1:60176] opened
2024/05/24 10:16:43 INF [SRT] [conn 172.17.160.1:60176] closed: authentication failed: authentication failed

Describe how to replicate the issue

1. Start the server with default config and user/pass added to authInternalUsers
2. Read the SRT stream with ffmpeg (VLC/GStreamer) using incorrect credentials

Did you attach the server logs?

yes (see previous section)

Did you attach a network dump?

yes
srt.zip

[aler9]

related to datarhei/gosrt#59

[aler9]

Thanks for reporting the bug, this is fixed by #3534

[github-actions]

This issue is mentioned in release v1.8.4 🚀
Check out the entire changelog by clicking here

[github-actions]

This issue is being locked automatically because it has been closed for more than 6 months.
Please open a new issue in case you encounter a similar problem.