I am trying to decode a camera rtsp stream using ffmpeg_libs within a ubuntu docker container. The ffmpeg debug output seems to show that it successfully negotiates the rtsp-digest authentication (ie. RTSP/1.0 200 OK), and receives an SPS (nalu 7) and PPS (nalu 8), but nothing after that. It times out, retries, etc. That doesn’t really make sense to me.
The same code compiled and run locally (not in docker) works fully.
Also, if I decode a file, the code works fine both locally and in docker container. So, the basic ffmpeg_lib decode is working. The difficulty is with the stream interface running in docker.
Is there additional authentication through the docker interface, or maybe port access, or something? I’m not much of a networking guy, so I’m really lost at this point.
The ffmpeg logs is below, and my docker run command is:
docker run -it --name VideoRx videorx:latest (also tried with -p 554)
Any help will be very much appreciated.
Thanks,
Wayne
avformat_version(): 3756900 Build: 3756900 Ident: Lavf57.83.100
avformat_open_input(): rtsp://admin:public_pwd#192.168.1.237
Probing rtsp score:100 size:0
[tcp # 0x56263b430a20] No default whitelist set
[rtsp # 0xaddr1] Sending:
OPTIONS rtsp://192.168.1.237:554 RTSP/1.0
... [snipped]
Initial authentication handshake (OPTIONS, DESCRIBE, SETUP).
All success, server replies: 'RTSP/1.0 200 OK'
....
[rtsp # 0xaddr1] Sending:
PLAY rtsp://192.168.1.237:554/ RTSP/1.0
Range: npt=0.000-
CSeq: 5
User-Agent: Lavf57.83.100
Session: 420467284
Authorization: Digest username="admin", realm="IP Camera(C1003)", nonce="129b254c8da4e0ffb530f64f79938bcd", uri="rtsp://192.168.1.237:554/", response="82c6c0f1fadea3739846866e8e50e855"
--
[rtsp # 0xaddr1] line='RTSP/1.0 200 OK'
[rtsp # 0xaddr1] line='CSeq: 5'
[rtsp # 0xaddr1] line='Session: 420467284'
[rtsp # 0xaddr1] line='RTP-Info: url=rtsp://192.168.1.237:554/trackID=1;seq=43938;rtptime=4022155312'
[rtsp # 0xaddr1] line='Date: Thu, Aug 02 2018 15:53:00 GMT'
[rtsp # 0xaddr1] line=''
avformat_open_input(): Success erc: 0
avformat_find_stream_info()
[h264 # 0xaddr2] nal_unit_type: 7, nal_ref_idc: 3
[h264 # 0xaddr2] nal_unit_type: 8, nal_ref_idc: 3
[rtsp # 0xaddr1] UDP timeout, retrying with TCP
[rtsp # 0xaddr1] ...
... Stalls waiting for additional packets
Related
I have a uwsgi process running a flask application. There is haproxy (running in mode http) sitting between the client and the application.
I am seeing occational haproxy termination state as "SD--" and the Tc = 0 and Tr = -1, and the returned http code is -1. This means that the haproxy encountered a explicit tcp disconnection from the uwsgi server.
Looking at the uwsgi logs, I found that the server was normally processing requests at the same time. But the affected request never reached the server.
Only thing strange about the uwsgi logs at that point of time is that
the Number of requests managed by the current uwsgi worker is greater than the sum total of requests managed by the whole uwsgi app.
like this:
[pid: 22759|app: 0|req: **47188**/**47178**] * POST * => generated 84 bytes in 970 msecs (HTTP/1.1 200) 2 headers in 71 bytes (3 switches on core 98)
I am wondering if this is abnormal, or what what scenarios can these counters be so?
I have a Deluge client (in a docker container - that's likely irrelevant).
I want to be able to connect to the daemon from the outside world while having it behind a reverse proxy.
I don't necessarily need TLS, but I suspect http2 may require it.
What works:
connecting locally on the network to the Deluge RPC with a Deluge desktop, Android and WebUI client works well.
sending requests to the nginx server is OK (I can see logs as I hit nginx)
All the networking around (firewalls, port forwardings, DNS are fine)
What doesn't work:
Deluge client can't connect to the http server
nginx config:
server {
server_name deluge.example.com;
listen 58850;
location / {
proxy_pass grpc://localhost:58846;
}
ssl_certificate /etc/ssl/nginx/example.com.pem;
ssl_certificate_key /etc/ssl/nginx/example.com.key;
proxy_request_buffering off;
gzip off;
charset utf-8;
error_log /var/log/nginx/nginx_deluge.log debug;
}
Major edit:
As it turns out, I believed the JSON RPC and gRPC are more similar than just the "RPC" in the name. Hence my "original" issue "nginx deluge rpc doesn't work", is no longer relevant.
Unfortunately, the "same" issue still prevails. I still can't connect to the proxy even when using a regular HTTP proxy while I can make HTTP requests locally.
I will surely post an update or even an answer should I figure it out in the next days...
When I try to connect with the Deluge client, I get this error message in the log file:--
2022/06/14 16:59:55 [info] 1332115#1332115: *7 client sent invalid method while reading client request line, client: <REDACTED IPv4>, server: deluge.example.com, request: " Fu�Uq���U����a(wU=��_`. a��¹�(���O����f�"
2022/06/14 16:59:55 [debug] 1332115#1332115: *7 http finalize request: 400, "?" a:1, c:1
2022/06/14 16:59:55 [debug] 1332115#1332115: *7 event timer del: 17: 243303738
2022/06/14 16:59:55 [debug] 1332115#1332115: *7 http special response: 400, "?"
2022/06/14 16:59:55 [debug] 1332115#1332115: *7 http set discard body
2022/06/14 16:59:55 [debug] 1332115#1332115: *7 HTTP/1.1 400 Bad Request
Server: nginx/1.22.0
Date: Tue, 14 Jun 2022 16:59:55 GMT
Content-Type: text/html
Content-Length: 157
Connection: close
When I change the line listen 58850; to listen 58850 http2;, as I probably should, I get the following error: (log verbosity set to "debug")
2022/06/14 15:04:00 [info] 1007882#1007882: *3654 client sent invalid method while reading
client request line, client: <REDACTED IPv4>,
server: deluge.example.com, request: "x�;x��;%157?O/3/-�#�D��"
The gibberish there is seemingly identical when trying to connect from a different network from a different device. It was Dx�;x��;%157?O/3/-�#�E�, (there is a D as first character now) but all other attempts are again without the leading D.
or this error: (log verbosity set to "info")
2022/06/14 17:09:13 [info] 1348282#1348282: *14 invalid connection preface while processing HTTP/2 connection, client: <REDACTED IPv4>, server: 0.0.0.0:58850
I tried decoding the gibberish between various encodings, in hoping it would be just bad encoding of a better error message or a lead to a solution.
I looked through the first two pages of Google hoping the error messages were pointing me to a solution someone else has had to my problem.
environment:
Docker version 20.10.17, build 100c70180f
nginx version: nginx/1.22.0
deluged 2.0.5
libtorrent: 2.0.6.0
I've got a build of the OpenVPN3 client library (https://github.com/OpenVPN/openvpn3) connecting to an OpenVPN 2 server (2.4.4). This is working for my mac and windows builds, but failing when the client is iOS.
The iOS client appears to connect, in the sense that I get my custom up script invoked and I can see what I assume are keepalive/heartbeat packets going back and forth between client and server. The client doesn't time out as long as these packets are allowed to continue. However, as soon as the client attempts to access any web page over the tunnel, I get packets dropped on the server side with errors like the following:
Fri Mar 15 20:08:27 2019 11e9-475e-04b1a640-b6f1-dda173e0051f/10.101.172.10:65334 IP packet with unknown IP version=10 seenFri Mar 15 20:08:28 2019 11e9-475e-04b1a640-b6f1-dda173e0051f/10.101.172.10:65334 IP packet with unknown IP version=7 seen
Fri Mar 15 20:08:29 2019 11e9-475e-04b1a640-b6f1-dda173e0051f/10.101.172.10:65334 IP packet with unknown IP version=5 seen
Fri Mar 15 20:08:30 2019 11e9-475e-04b1a640-b6f1-dda173e0051f/10.101.172.10:65334 IP packet with unknown IP version=9 seen
Fri Mar 15 20:08:31 2019 11e9-475e-04b1a640-b6f1-dda173e0051f/10.101.172.10:65334 IP packet with unknown IP version=8 seen
Fri Mar 15 20:08:32 2019 11e9-475e-04b1a640-b6f1-dda173e0051f/10.101.172.10:65334 IP packet with unknown IP version=2 seen
Fri Mar 15 20:08:34 2019 11e9-475e-04b1a640-b6f1-dda173e0051f/10.101.172.10:65334 IP packet with unknown IP version=13 seen
Fri Mar 15 20:08:38 2019 11e9-475e-04b1a640-b6f1-dda173e0051f/10.101.172.10:65334 IP packet with unknown IP version=7 seen
I'm using the same server and client configs for iOS as I was using when the client was Mac and Windows.
Server configs:
port 1194
proto udp
dev tun
ca /opt/certs/ca-cert.pem
cert /opt/certs/server.pem
key /opt/certs/server-key.pem
dh /opt/certs/dh2048.pem
tls-auth /opt/certs/ta.key 0
server 10.8.0.0 255.255.0.0
keepalive 5 15
verb 3
script-security 3
client-connect "/usr/local/bin/sdp-updown"
client-disconnect "/usr/local/bin/sdp-updown"
cipher AES-256-CBC
tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
comp-lzo
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
Client configs:
dev tun
proto udp
remote ... server and port omitted
remote-cert-tls server
key-direction 1
server-poll-timeout 5
cipher AES-256-CBC
tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
comp-lzo
... routes omitted
<ca>
... CA omitted
</ca>
<cert>
... cert omitted
</cert>
<key>
... private key omitted
</key>
<tls-auth>
... OpenVPN static key omitted
</tls-auth>
I've tried a number of different settings for cipher and tls-cipher. When those settings are set to values that are supported on both sides I can get connected, but get the same IP packet with unknown IP version error. Obviously when either cipher or tls-cipher isn't supported on either server or client we fail to negotiate TLS and don't get connected at all.
I found a number of troubleshooting forum posts regarding this error and most of them are resolved by setting the compression settings to the same value on both ends. My iOS client build seems to think that it has no ability to perform compression, even though I think I've linked successfully against the LZ4 library. I compiled the LZ4 library for iOS, and included the LZ4=1 when building a dylib for OpenVPN itself. However, when the iOS client connects it reports settings like:
ENV[IV_AUTO_SESS] = 1
ENV[IV_COMP_STUBv2] = 1
ENV[IV_COMP_STUB] = 1
ENV[IV_LZO_STUB] = 1
ENV[IV_PROTO] = 2
ENV[IV_TCPNL] = 1
ENV[IV_NCP] = 2
ENV[IV_PLAT] = ios
ENV[IV_VER] = 3.1.2
I notice that this does not include IV_LZ4, which I take to mean that the client thinks it can't perform compression. That said, even when my configs include disabled compression I get the same results. I tried omitting any compression setting at all, comp-lzo no, compress stub, and compress stub-v2. None of these resulted in any different behavior.
My questions are thus:
What could be the cause of my IP packet with unknown IP version errors when actually sending packets over the data channel?
If what I'm seeing is actually a compression setting error, how do I convince OpenVPN to disable compression entirely? Alternatively, what have I done wrong to link LZ4 into my iOS OpenVPN dylib?
I am using Dockerflow to run parallel tasks through the Google Pipelines API on Google Cloud Platform. I started a single-step task running 1389 VMs in parallel and found that 233 of the VMs were apparently doing nothing and hanging indefinitely.
I did a spot check of the serial console output and repeatedly saw the VMs running into "Getting controller config failed" errors.
When I tried logging into the VMs I received the error: "Connection Failed. We are unable to connect to the VM on port 22".
I am wondering why my VM instances are hanging, and if there is something I can do to avoid running into these issues.
I've included a snippet of the serial console output below
startupscript: +++ readlink -f /usr/share/google-genomics/startup.sh
startupscript: ++ dirname /usr/share/google-genomics/startup.sh
startupscript: + cd /usr/share/google-genomics
startupscript: + ./controller --operation_id <id> --validation_token <token> --base_path https://genomics.googleapis.com
create controller[2905]: Getting controller config
create controller[2905]: Getting controller config failed, will retry: Get <link>: Get <service_account_token_link>: net/http: timeout awaiting response headers
create controller[2905]: Getting controller config failed, will retry: Get <link>: dial tcp 74.125.26.95:443: i/o timeout
collectd[2342]: write_gcm: Asking metadata server for auth token
collectd[2342]: write_gcm: curl_easy_perform() failed: Couldn't connect to server
collectd[2342]: write_gcm: Error -1 from wg_curl_get_or_post
collectd[2342]: write_gcm: wg_transmit_unique_segment failed.
collectd[2342]: write_gcm: wg_transmit_unique_segments failed. Flushing.
there was a temporary networking issue in us-east1-b. All 3 above VMs were in us-east1-b. These minor incidents do not appear in https://status.cloud.google.com/
Serial console output for a successful run looks like:
A Feb 21 19:05:06 ggp-5629907348021283130 startupscript: + ./controller --operation_id --validation_token --base_path https://autopush-genomics.sandbox.googleapis.com
A Feb 21 19:05:06 ggp-5629907348021283130 create controller[2689]: Getting controller config
A Feb 21 19:05:36 ggp-5629907348021283130 create controller[2689]: Getting controller config failed, will retry: Get https://genomics.googleapis.com/v1alpha2/pipelines:getControllerConfig?alt=json&operationId=&validationToken=: dial tcp 173.194.212.81:443: i/o timeout
A Feb 21 19:05:43 ggp-5629907348021283130 controller[2689]: Switching to status: pulling-image
A Feb 21 19:05:43 ggp-5629907348021283130 controller[2689]: Calling SetOperationStatus(pulling-image)
A Feb 21 19:05:44 ggp-5629907348021283130 controller[2689]: SetOperationStatus(pulling-image) succeeded
The "Getting controller config failed, will retry" is fine. It succeeded upon retry. The "SetOperationStatus(pulling-image) succeeded" indicates networking is working.
In theory, you can submit any number of jobs to Pipelines API and the API will take care of queueing.
If these temporary networking hiccups become common, we may consider changing Pipelines API to somehow detect and retry.
there may have been a temporary networking issue. Can you give me some failed operation ids (or failed VM names)?
Have you tried again since then; can you reproduce the problem?
I'm working on a fairly large Rails 3 project that by default is run on localhost:5000 for development. I'm currently migrating our web server from unicorn to puma. However, when I run my development server, I constantly get these kinds of errors:
16:11:39 web.1 | 2015-07-02 16:11:39 -0500: HTTP parse error, malformed request (): #<Puma::HttpParserError: Invalid HTTP format, parsing fails.>
16:11:39 web.1 | 2015-07-02 16:11:39 -0500: ENV: {"rack.version"=>[1, 1], "rack.errors"=>#<IO:<STDERR>>, "rack.multithread"=>true, "rack.multiprocess"=>false, "rack.run_once"=>false, "SCRIPT_NAME"=>"", "CONTENT_TYPE"=>"text/plain", "QUERY_STRING"=>"txtAirPlay&txtRAOP", "SERVER_PROTOCOL"=>"HTTP/1.1", "SERVER_SOFTWARE"=>"2.11.2", "GATEWAY_INTERFACE"=>"CGI/1.2", "REQUEST_METHOD"=>"GET", "REQUEST_PATH"=>"/info", "REQUEST_URI"=>"/info?txtAirPlay&txtRAOP"}
16:11:39 web.1 | ---
Research indicates that this is because OS X Yosemite uses port 5000 for AirPlay streaming. I'm looking for a way to remove these errors from my stdout.
I can't figure out if there's a way to disable AirPlay temporarily, or even if I should be doing that.
I can't feasibly just change the port my application runs on - this is a fairly large project with a lot of contributors. Trying to just change the port locally sends me down a rabbit hole.
Is there a way to either silently reject these requests or just simply filter them from my stdout? I'm worried I'm missing important signals amongst this noise.