Wyze cam 454, fixed in rtsp-simple-proxy

[Alfiegerner]

Which version are you using?

v0.16.0 latest Docker image from docker hub

Which operating system are you using?

OS

• [ x] Linux
• Windows
• macOS

Architecture

• [ x] amd64
• arm64
• arm7
• arm6

Describe the issue

Description

Attempting to proxy to a Wyze cam i am getting 454 Session errors. This issue was also seen here in rtsp-simple-proxy project .

I am seeing the same symptoms using the code in this project:

2021/05/21 10:10:27 I [0/0] [path driveway] [rtsp source] ERR: wrong status code: 454 (Session Not Found)

I have confirmed that this is fixed in the rtsp-simple-proxy project.

Describe how to replicate the issue

WIth the correct cam, e.g. Wyze pan scan, this can be replicated with the following config:

paths:
  driveway:
    source: rtsp://rtsp:rtsp@192.168.86.61/live

Did you attach a network dump?

No.

[dorinclisu]

It looks like it's mostly likely an issue with the camera, and less with the rss.

Have you tried ffmpeg, gstreamer or VLC on the same source (rtsp://rtsp:rtsp@192.168.86.61/live) ?

If it works with any of the above we know the problem is with rss, case in which you will have to attach a network dump, otherwise the problem cannot be fixed.

[Alfiegerner]

Thank you @dorinclisu . It does work with ffmpeg, and as mentioned with the rtsp-simple-proxy. I'll attach dump later.

[Alfiegerner]

Having an odd issue here - running docker on ubuntu I get the 454s, but running binaries on Ubunutu or on Windows (and also running docker on Windows) I'm getting 401's unauthorised.

I don't think I can run wireshark on my ubuntu servers as it's minimal and I'm getting what looks like 'I need a visual desktop warning'. So I've attached logs and pcap from Windows laptop, even though it's not the 454 the 401 might be related. Also attached my config.

rtsp-simple-server_config.zip
wyze_pcap.zip
output.log

Thanks.

[dorinclisu]

Try this and see what happens:

paths:
  driveway:
    source: rtsp://rtsp:rtsp@192.168.86.61/live
    sourceProtocol: tcp

At least for me, without the TCP contraint almost nothing works well in docker container.

[Alfiegerner]

Thanks @dorinclisu , setting tcp fixes it.

[aler9]

From the logs, it seems that this happens:

1. The server is correctly able to connect to the camera, and asks the camera to receive the streams with UDP
2. The server doesn't receive any UDP packet (since UDP packets can't received inside Docker, unless --network=host is used) and switches automatically to TCP
3. for some reason, credentials (username and password) are lost during the UDP->TCP transition

Therefore this is a bug that must be solved.

[aler9]

added to v0.16.2

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