Support TLS endpoint with InfluxDB #1569

sumptersmartt · 2020-11-24T16:45:54Z

The InfluxDB output works well when using an http connection. Using telegraf I can emulate an influx or influx v2 listener. I'm currently using telegraf as a proxy of sorts to send data on up to a free instance of influx cloud. It only listens on HTTPS.

After successfully testing sending unencrypted traffic, with and without requiring a token, to the local telegraf endpoint, I set up a valid letsencrypt certificate and added a hosts entry to point 'telegraf.dadops.net' to 127.0.0.1. I can confirm in a browser that the cert is valid/trusted (see screenshot below). Additionally, I can run
rtl_433 -M newmodel -F "influx://telegraf.dadops.net:8086/api/v2/write?org=dadops&bucket=rtl433" -C customary
and everything works/forwards as expected. However, once I enable TLS in telegraf and run
rtl_433 -M newmodel -F "influxs://telegraf.dadops.net:8086/api/v2/write?org=dadops&bucket=rtl433" -C customary
I see the following:

rtl_433 -M newmodel -F "influxs://telegraf.dadops.net:8086/api/v2/write?org=dadops&bucket=rtl433" -C customary
rtl_433 version unknown inputs file rtl_tcp RTL-SDR
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "/home/pi/.config/rtl_433/rtl_433.conf"...
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
Trying conf file at "/etc/rtl_433/rtl_433.conf"...
Publishing data to InfluxDB (https://telegraf.dadops.net:8086/api/v2/write?org=dadops&bucket=rtl433)
Registered 145 out of 175 device decoding protocols [ 1-4 8 11-12 15-17 19-21 23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119 121 124-128 130-149 151-161 163-168 170-175 ]
Found Rafael Micro R820T tuner
Exact sample rate is: 250000.000414 Hz
[R82XX] PLL not locked!
Sample rate set to 250000 S/s.
Tuner gain set to Auto.
Tuned to 433.920MHz.
Allocating 15 zero-copy buffers
Connect to InfluxDB (https://telegraf.dadops.net:8086/api/v2/write?org=dadops&bucket=rtl433) failed

I know that influxs:// isn't documented but I do see that it attempts to connect via https instead of http. This is the same error I see when attempting to connect to influx cloud. Eliminating the need for telegraf would simplify my deployment significantly and allow a direct, secure connection over the public internet.

The easiest way to test this would be to set up a free influx cloud instance and configure a bucket/token. Should take just a few minutes and you don't have to worry about managing certificates.

rtl_433 -M newmodel -F "influxs://us-central1-1.gcp.cloud2.influxdata.com/api/v2/write?org=dadops&bucket=rtl433,token=REDACTED" -C customary

rtl_433 version unknown inputs file rtl_tcp RTL-SDR
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "/home/pi/.config/rtl_433/rtl_433.conf"...
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
Trying conf file at "/etc/rtl_433/rtl_433.conf"...
Publishing data to InfluxDB (https://us-central1-1.gcp.cloud2.influxdata.com/api/v2/write?org=dadops&bucket=rtl433)
Registered 145 out of 175 device decoding protocols [ 1-4 8 11-12 15-17 19-21 23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119 121 124-128 130-149 151-161 163-168 170-175 ]
Found Rafael Micro R820T tuner
Exact sample rate is: 250000.000414 Hz
[R82XX] PLL not locked!
Sample rate set to 250000 S/s.
Tuner gain set to Auto.
Tuned to 433.920MHz.
Allocating 15 zero-copy buffers
Connect to InfluxDB (https://us-central1-1.gcp.cloud2.influxdata.com/api/v2/write?org=dadops&bucket=rtl433) failed
Connect to InfluxDB (https://us-central1-1.gcp.cloud2.influxdata.com/api/v2/write?org=dadops&bucket=rtl433) failed

The text was updated successfully, but these errors were encountered:

zuckschwerdt · 2020-11-24T17:24:55Z

If you set MG_ENABLE_SSL for cmake and link in OpenSSL this could work. This will be a security hole though as we have no provision to validate certs let alone anything like e.g. pinning them (HPKP).

sumptersmartt · 2020-11-24T20:03:11Z

I'm not super familiar with building from source. If you don't mind, can you elaborate on what I'd need to do when building to make it work? I tried -DMG_ENABLE_SSL=ON but I receive a warning saying the manually-specified variables won't be used. I'm doing this on a raspberry pi if it makes any difference.

zuckschwerdt · 2020-11-24T20:26:35Z

Maybe just insert it into the include/mongoose.h and then add the ssl stuff to src/CMakeLists.txt, target_link_libraries(rtl_433 ssl crypto) I guess.

sumptersmartt · 2020-12-07T21:20:40Z

I was able to get this to work by adding target_link_libraries on line 196 of src/CMakeLists.txt

target_link_libraries(rtl_433 r_433)
target_link_libraries(rtl_433 ssl crypto)

and in include/mongoose.h I modified line 3631 to be

#define MG_ENABLE_SSL 1

This works for my purposes and I wanted to make sure anyone else trying to accomplish this had a quick answer, but it would still be great if it was natively supported and actually validated the certificate. I know that may be a tall order on many devices rtl_433 runs on but for endpoints that require authentication I think it's a reasonable request. Thanks for your help, rtl_433 is a truly excellent program.

milkpirate · 2022-12-27T17:05:19Z

@zuckschwerdt I habe the same problem as sumptersmartt. Is it still necessary to do the tweaks in the header and cmake files? My binary version is:

rtl_433 version 22.11-29-gb860de9e branch master at 202212271629 inputs file rtl_tcp RTL-SDR with TLS
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...

and it seems to supporting TLS.

How can I debug what is the reason for failing? I tried rtl_433 -vvvv -F log -F influxs://... but its not really verbose 😢

zuckschwerdt · 2022-12-27T17:41:24Z

No, with TLS in the version line indicates all the above changes.

If there were connect or send errors then those would show always:
"InfluxDB connect error: ..."
"InfluxDB replied HTTP code: .. with message: ..."
"Connect to InfluxDB (...) failed"

So I guess the requests go through okay but don't actually write to the db?
Maybe sprinkle fprintf's into output_influx.c to narrow it down. Or use a test webserver (e.g. python3 -m http.server 8080) as target and watch what comes in.

The new logging system just landed a few days ago, we might want to add more logging everywhere now. E.g. level=trace to see the influx requests in detail.

milkpirate · 2022-12-27T23:02:15Z

@zuckschwerdt Ok, rtl_433 does not seem to make any http(s) call at all:

$ docker run -u0 -it -v /etc/ssl/certs/ca-certificates.crt:/etc/ssl/certs/ca-certificates.crt --network=host --device  /dev/bus/usb/001/006 rtl sh
/ # apk add curl
fetch https://dl-cdn.alpinelinux.org/alpine/v3.16/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.16/community/x86_64/APKINDEX.tar.gz
(1/4) Installing brotli-libs (1.0.9-r6)
(2/4) Installing nghttp2-libs (1.47.0-r0)
(3/4) Installing libcurl (7.83.1-r5)
(4/4) Installing curl (7.83.1-r5)
Executing busybox-1.35.0-r17.trigger
OK: 13 MiB in 25 packages
/ # curl https://nuc.local:8000/
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
        "http://www.w3.org/TR/html4/strict.dtd">
<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html;charset=utf-8">
        <title>Error response</title>
    </head>
    <body>
        <h1>Error response</h1>
        <p>Error code: 501</p>
        <p>Message: Unsupported method ('GET').</p>
        <p>Error code explanation: HTTPStatus.NOT_IMPLEMENTED - Server does not support this operation.</p>
    </body>
</html>
/ #  rtl_433 -vvvv -F log -F 'influxs://nuc.local:8000/write?db=rtl433&u=user&p=pass'
rtl_433 version 22.11-29-gb860de9e branch master at 202212271629 inputs file rtl_tcp RTL-SDR with TLS
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "/root/.config/rtl_433/rtl_433.conf"...
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
Trying conf file at "/etc/rtl_433/rtl_433.conf"...
Publishing data to InfluxDB (https://nuc.local:8000/write?db=rtl433&u=user&p=pass)
Found Rafael Micro R820T tuner
Exact sample rate is: 250000.000414 Hz
[R82XX] PLL not locked!
Allocating 15 zero-copy buffers
Connect to InfluxDB (https://nuc.local:8000/write?db=rtl433&u=user&p=pass) failed
Connect to InfluxDB (https://nuc.local:8000/write?db=rtl433&u=user&p=pass) failed
Connect to InfluxDB (https://nuc.local:8000/write?db=rtl433&u=user&p=pass) failed

Since the server logs just registered the first manual curl:

$ python
Python 3.10.6 (main, Nov 14 2022, 16:10:14) [GCC 11.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from http.server import HTTPServer, BaseHTTPRequestHandler
>>> import ssl
>>>
>>> httpd = HTTPServer(('192.168.1.45', 8000), BaseHTTPRequestHandler)
httpd.socket = ssl.wrap_socket (httpd.socket, certfile='/tmp/venv/nuc.pem', server_side=True)
>>> httpd.socket = ssl.wrap_socket (httpd.socket, certfile='/tmp/venv/nuc.pem', server_side=True)
<stdin>:1: DeprecationWarning: ssl.wrap_socket() is deprecated, use SSLContext.wrap_socket()
>>> httpd.serve_forever()

192.168.1.45 - - [27/Dec/2022 23:54:46] code 501, message Unsupported method ('GET')
192.168.1.45 - - [27/Dec/2022 23:54:46] "GET / HTTP/1.1" 501 -

nuc.local resolves to 192.168.1.45
cert (nuc.pem) is self signed and added to hosts ca-certificates.crt
does rtl_433 honor the ca-certificates.crt, like curl does?
shall I move that to a separate issue/bug?

EDIT:
Without TLS everything works fine:

...
/ # curl http://nuc.local:8000/
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Directory listing for /</title>
</head>
<body>
<h1>Directory listing for /</h1>
<hr>
<ul>
...
</ul>
<hr>
</body>
</html>
/ # rtl_433 -vvvv -F log -F 'influx://nuc.local:8000/write?db=rtl433&u=user&p=pass'
rtl_433 version 22.11-29-gb860de9e branch master at 202212271629 inputs file rtl_tcp RTL-SDR with TLS
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "/root/.config/rtl_433/rtl_433.conf"...
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
Trying conf file at "/etc/rtl_433/rtl_433.conf"...
Publishing data to InfluxDB (http://nuc.local:8000/write?db=rtl433&u=user&p=pass)
Found Rafael Micro R820T tuner
Exact sample rate is: 250000.000414 Hz
[R82XX] PLL not locked!
Allocating 15 zero-copy buffers
InfluxDB replied HTTP code: 501 with message:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
        "http://www.w3.org/TR/html4/strict.dtd">
<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html;charset=utf-8">
        <title>Error response</title>
    </head>
    <body>
        <h1>Error response</h1>
        <p>Error code: 501</p>
        <p>Message: Unsupported method ('POST').</p>
        <p>Error code explanation: HTTPStatus.NOT_IMPLEMENTED - Server does not support this operation.</p>
    </body>
</html>
...
/ #

Server logs:

$ python -m http.server 8000
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
192.168.1.45 - - [28/Dec/2022 00:10:27] "GET / HTTP/1.1" 200 -

192.168.1.45 - - [28/Dec/2022 00:11:52] code 501, message Unsupported method ('POST')
192.168.1.45 - - [28/Dec/2022 00:11:52] "POST /write?db=rtl433&u=user&p=pass HTTP/1.1" 501 -
192.168.1.45 - - [28/Dec/2022 00:12:50] code 501, message Unsupported method ('POST')
192.168.1.45 - - [28/Dec/2022 00:12:50] "POST /write?db=rtl433&u=user&p=pass HTTP/1.1" 501 -
...

zuckschwerdt · 2022-12-28T09:24:33Z

Ok, that's a good trace. Should be a TLS problem.

rtl_433 won't read any cert files. The options are mentioned in #1633 -- but not implemented for influxs. I'll see if I can add that now.

To get more detauiled info you can change

rtl_433/src/output_influx.c

Lines 110 to 113 in 707b51e

    
           struct mg_connect_opts opts = {.user_data = ctx}; 
        
           if ((ctx->conn = mg_connect_http_opt(ctx->mgr, influx_client_event, opts, ctx->url, ctx->extra_headers, buf->buf)) == NULL) { 
        
               fprintf(stderr, "Connect to InfluxDB (%s) failed\n", ctx->url); 
        
           }

to

-    struct mg_connect_opts opts = {.user_data = ctx};
+    char const *error_string = NULL;
+    struct mg_connect_opts opts = {.user_data = ctx, .error_string = &error_string};
     if ((ctx->conn = mg_connect_http_opt(ctx->mgr, influx_client_event, opts, ctx->url, ctx->extra_headers, buf->buf)) == NULL) {
-        fprintf(stderr, "Connect to InfluxDB (%s) failed\n", ctx->url);
+        fprintf(stderr, "Connect to InfluxDB (%s) failed (%s)\n", ctx->url, error_string);
     }

zuckschwerdt · 2022-12-28T10:19:32Z

With fa9047f TLS options are now available for InfluxDB output.

milkpirate · 2022-12-28T22:08:23Z

@zuckschwerdt

Just had a look at your comment and made the changes to the master (7d512978) and realized the same: it works! Great! So I guess 22.11 was just not supporting it. Looking forward for the new release. Thanks 😄

Another thing: when starting the rtl_433 leaks the password. I tried starting it via the config file, so its not ending up in ps or so, but rtl_433 still prints the influxdb (and I guess the others like mqtt) URL including the password. I guess its hard to write a parser to find the password for all the different configuration options, to extract and replace it with **** or so, but having an option not to print the connection URL would do fine. This would be a feature worth implementing as I think.

zuckschwerdt · 2022-12-28T22:33:29Z

Thanks for confirming the new Influx TLS support.

You are the first to mention password hiding, but yes that would be a nice feature.

milkpirate · 2023-01-02T21:43:38Z

@zuckschwerdt ok I ran my setup a while and realized, that it doesnt seem to work with a real influxdb server:

InfluxDB: Connect to InfluxDB (https://influxdb:8086/write?db=rtl433&u=user&p=pass) failed (Invalid PSK settings)

while

/ # curl https://influxdb:8086/write
Method Not Allowed

works... at least TLS wise. Are you using libcurl to make these calls?

Details:

/ # curl -vi https://influxdb:8086/write
*   Trying 2003:...:a:8086...
* Connected to influxdb (2003:...:a) port 8086 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: ...
*  start date: Dec  3 23:13:56 2022 GMT
*  expire date: Nov 30 23:13:56 2032 GMT
*  subjectAltName: host "influxdb" matched cert's "influxdb"
*  issuer: ...
*  SSL certificate verify ok.
> GET /write HTTP/1.1
> Host: influxdb:8086
> User-Agent: curl/7.83.1
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Mark bundle as not supporting multiuse
< HTTP/1.1 405 Method Not Allowed
HTTP/1.1 405 Method Not Allowed
< Allow: OPTIONS, POST
Allow: OPTIONS, POST
< Content-Type: text/plain; charset=utf-8
Content-Type: text/plain; charset=utf-8
< X-Content-Type-Options: nosniff
X-Content-Type-Options: nosniff
< X-Influxdb-Build: OSS
X-Influxdb-Build: OSS
< X-Influxdb-Version: 1.8.10
X-Influxdb-Version: 1.8.10
< Date: Mon, 02 Jan 2023 21:41:32 GMT
Date: Mon, 02 Jan 2023 21:41:32 GMT
< Content-Length: 19
Content-Length: 19

<
Method Not Allowed
* Connection #0 to host influxdb left intact
/ #

zuckschwerdt · 2023-01-02T21:52:53Z

No curl, it's somewhat plain OpenSSL. Are you sure you are using PSK right? Did you test that? I don't think that PSK is commonly used on TLS.

milkpirate · 2023-01-02T22:19:08Z

Not really, I created a root CA and signed several other "domains" certs/keys with it (e.g. influxdb) the crt portion of the root CA is added to the systems trusted root certs. The signed cert/key is supplied to the influxdb server. curl or wegt they can talk to it just like to any other server (like google or so) without disabling certificate (via -k or --no-check-certificate) verification.

zuckschwerdt · 2023-01-02T22:23:33Z

So you are not using tls_psk_identity or tls_psk_key but It still tries to use PSK? Make sure you are not passing empty strings accidentally.

milkpirate · 2023-01-02T22:37:54Z

No, I am not... or at least not as far as I know. I am not an expert on TLS and root CA, but I am not creating a key/crt for each client. to auth against the server.

I just have several "servers" like influx, mosquitto aso. I want to communicate in my local LAN via TLS. Each server gets its key and cert to do TLS (like any other server in the web does).

For convenience they are all are signed with a common cert/key (root CA - not sure if the terminology is right). And only the cert portion of the root CA is installed on the clients of those servers. Never any key. So ist not really a PSK infrastructure.

Make sure you are not passing empty strings accidentally.

What do you mean? How? Where?

zuckschwerdt · 2023-01-02T22:50:39Z

I meant to confirm that you are not using tls_psk_identity or tls_psk_key anywhere, not even "empty", say tls_psk_key="" or tls_psk_key=
If that's confirmed, then the code path to "Invalid PSK settings" should never been taken, strangely.

zuckschwerdt · 2023-01-02T22:53:09Z

Or in other words: the only option you should be using is tls_ca_cert=your_root.cert

milkpirate · 2023-01-02T23:03:47Z

Ok, but where do I check that that there is no tls_psk_key="" for instance? In the command line or config file of rtl_433? Neither of those options seems to be documented. Sorry for being slow 😞 but I am not sure what you want me to do.

zuckschwerdt · 2023-01-02T23:37:53Z

Your output option must include ,tls_ca_cert=the_root.cert but not any other tls option, e.g.
-F 'influxs://influxdb:8086/write?db=rtl433&u=user&p=pass,tls_ca_cert=the_root.cert'
But if that is already the case then this PSK thing is a bug, can't spot it right away though.

milkpirate · 2023-01-02T23:50:48Z

Ok, I tried:

rtl_433 -F log -F 'influxs://influxdb:8086/write?db=rtl433&u=user&p=pass'
rtl433            | rtl_433 version 22.11-33-g083dcca4 branch  at 202212281345 inputs file rtl_tcp RTL-SDR with TLS
rtl433            | Use -h for usage help and see https://triq.org/ for documentation.
rtl433            | Trying conf file at "rtl_433.conf"...
rtl433            | Trying conf file at "/home/user/.config/rtl_433/rtl_433.conf"...
rtl433            | Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
rtl433            | Trying conf file at "/etc/rtl_433/rtl_433.conf"...
rtl433            | InfluxDB: Publishing data to InfluxDB (https://influxdb:8086/write?db=rtl433&u=user&p=pass)
rtl433            | Protocols: Registered 192 out of 223 device decoding protocols [ 1-4 8 11-12 15-17 19-23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119-121 124-128 130-149 151-161 163-168 170-175 177-197 199 201-215 217-223 ]
rtl433            | SDR: Found 1 device(s)
rtl433            | SDR: trying device  0:  Realtek, RTL2838UHIDIR, SN: 00000001
rtl433            | Found Rafael Micro R820T tuner
rtl433            | Exact sample rate is: 250000.000414 Hz
rtl433            | SDR: Using device 0: Generic RTL2832U OEM
rtl433            | [R82XX] PLL not locked!
rtl433            | Allocating 15 zero-copy buffers
rtl433            | InfluxDB: Connect to InfluxDB (https://influxdb:8086/write?db=rtl433&u=user&p=pass) failed (Invalid PSK settings)

and

$ rtl_433 -F log -F 'influxs://influxdb:8086/write?db=rtl433&u=user&p=pass,tls_ca_cert=/etc/ssl/root_ca.crt'
rtl433            | rtl_433 version 22.11-33-g083dcca4 branch  at 202212281345 inputs file rtl_tcp RTL-SDR with TLS
rtl433            | Use -h for usage help and see https://triq.org/ for documentation.
rtl433            | Trying conf file at "rtl_433.conf"...
rtl433            | Trying conf file at "/home/user/.config/rtl_433/rtl_433.conf"...
rtl433            | Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
rtl433            | Trying conf file at "/etc/rtl_433/rtl_433.conf"...
rtl433            | InfluxDB: Publishing data to InfluxDB (https://influxdb:8086/write?db=rtl433&u=user&p=pass)
rtl433            | Protocols: Registered 192 out of 223 device decoding protocols [ 1-4 8 11-12 15-17 19-23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119-121 124-128 130-149 151-161 163-168 170-175 177-197 199 201-215 217-223 ]
rtl433            | SDR: Found 1 device(s)
rtl433            | SDR: trying device  0:  Realtek, RTL2838UHIDIR, SN: 00000001
rtl433            | Found Rafael Micro R820T tuner
rtl433            | SDR: Using device 0: Generic RTL2832U OEM
rtl433            | Exact sample rate is: 250000.000414 Hz
rtl433            | [R82XX] PLL not locked!
rtl433            | Allocating 15 zero-copy buffers
rtl433            | InfluxDB: Connect to InfluxDB (https://influxdb:8086/write?db=rtl433&u=user&p=pass) failed (Invalid PSK settings)

Same result :/

zuckschwerdt · 2023-01-03T09:02:38Z

Thanks for confirming. That is really strange. This "Invalid PSK settings" should not be active, I need to investigate.

metrafonic · 2023-02-05T13:18:02Z

I also have the Invalid PSK settings show up when using -F mqtts://xxxx:8883,user=xxx,pass=xxx against a mosquitto server with a tls cert from letsencrypt. This is via the hertzg/rtl_433:latest docker image

zuckschwerdt · 2023-02-05T14:03:42Z

Is this also rtl_433 version 22.11-33-g083dcca4? It seems to be a memory bug I can't reproduce.

zuckschwerdt · 2023-02-07T15:05:25Z

@milkpirate @metrafonic please try with the latest version. (should be 22.11-88-g2122f8dbor newer)

There is now a debug info like this:

MQTT: mqtts (TLS) parameters are: tls_cert=(null) tls_key=(null) tls_ca_cert=*
 tls_cipher_suites=(null) tls_server_name=(null) tls_psk_identity= tls_psk_key=(null)

If you see anything but (null) for tls_psk_identity or tls_psk_key (like the above tls_psk_identity=) then that's some memory bug. Otherwise there should be no way to produce the Invalid PSK settings error.

metrafonic · 2023-02-07T16:17:12Z

@zuckschwerdt I built the latest version (22.11-88-g2122f8db) from source on a RPI3 (with TLS support) and it seems that MQTT with TLS is working great. The APT package however does not work (MQTT connecting, MQTT disconnected messages).

The docker image i was using (where the invalid PSK message appears) is running rtl_433 version 22.11 (2022-11-19) inputs file rtl_tcp RTL-SDR with TLS

I checked out the 22.11 tag from git, built that from source and it also works.

I suspect the issue of TLS with MQTT lies in the hertzg/rtl_433:latest implementation

zuckschwerdt · 2023-02-07T16:23:47Z

Thanks for the investigation. Yes, I suspect as much. There is either a config for psk key or identity somewhere or an uninitialized memory bug in a specific kind of build. Really strange.

milkpirate · 2023-02-25T23:31:23Z

@zuckschwerdt 😢 I am still getting the same error, even with the commit you mentioned:

Attaching to rtl433
rtl433  | rtl_433 version 22.11-88-g2122f8db branch  at 202302071601 inputs file rtl_tcp RTL-SDR with TLS
rtl433  | Use -h for usage help and see https://triq.org/ for documentation.
rtl433  | InfluxDB: Publishing data to InfluxDB (https://influxdb:8086/write?db=rtl433&u=rtl433_writer&p=pass)
rtl433  | Protocols: Registered 192 out of 237 device decoding protocols [ 1-4 8 11-12 15-17 19-23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119-121 124-128 130-149 151-161 163-168 170-175 177-197 199 201-215 217-223 ]
rtl433  | SDR: Found 1 device(s)
rtl433  | SDR: trying device  0:  Realtek, RTL2838UHIDIR, SN: 00000001
rtl433  | Detached kernel driver
rtl433  | Found Rafael Micro R820T tuner
rtl433  | SDR: Using device 0: Generic RTL2832U OEM
rtl433  | Exact sample rate is: 250000.000414 Hz
rtl433  | [R82XX] PLL not locked!
rtl433  | Allocating 15 zero-copy buffers
...
rtl433  | Auto Level: Current signal level -12.4 dB, estimated noise -20.0 dB
rtl433  | InfluxDB: Connect to InfluxDB (https://influxdb:8086/write?db=rtl433&u=rtl433_writer&p=pass) failed (Invalid PSK settings)
^CGracefully stopping... (press Ctrl+C again to force)
Aborting on container exit...

zuckschwerdt · 2023-02-26T00:01:02Z

With the commit you would see this output

MQTT: mqtts (TLS) parameters are: tls_cert=(null) tls_key=(null) tls_ca_cert=*
 tls_cipher_suites=(null) tls_server_name=(null) tls_psk_identity= tls_psk_key=(null)

You might have started an old version, not the current one with that debug output. But the new version would not show that bug, so the best guess is that something is wrong with the 22.11 package you are using.

milkpirate · 2023-02-27T01:03:08Z

I might be wrong but that does not seem to be fixed for influx.

rtl433  | rtl_433 version 22.11-88-g2122f8db branch  at 202302071601 inputs file rtl_tcp RTL-SDR with TLS
...
rtl433  | markisol_decode: bits_per_row[0] = 25
rtl433  | InfluxDB: influxs (TLS) parameters are: tls_cert=(null) tls_key=(null) tls_ca_cert=* tls_cipher_suites=(null) tls_server_name=(null) tls_psk_identity=(null) tls_psk_key=(null)
rtl433  | InfluxDB: Connect to InfluxDB (https://influxdb:8086/write?db=rtl433&u=rtl433_writer&p=pass) failed (Invalid PSK settings)
rtl433  | x10_rf_callback: DECODE_ABORT_LENGTH, Received message length=36
...

zuckschwerdt · 2023-02-27T09:53:43Z

Thanks for the log output. This nails it down finally.

I just noticed: if psk id or key are unset (they are null here) all is well:
https://github.com/merbanan/rtl_433/blob/master/src/mongoose.c#L5011
except if it is LibreSSL, then we get an automatic error.
https://github.com/merbanan/rtl_433/blob/master/src/mongoose.c#L5047

Can you confirm using LibreSSL instead of OpenSSL? I'm afraid we don't support LibreSSL currently, but a patch shouldn't be complicated.

milkpirate · 2023-02-27T11:00:14Z

Ok, so then the base image (I run it in a container) should have OpenSSL install (instead of LibreSSL). Will try that.

zuckschwerdt · 2023-02-27T11:03:18Z

It's fixed now. What a chase. That OpenSSL was replaced with LibreSSL would have been critical to know.

milkpirate · 2023-02-27T11:04:20Z

Searching for how to figure that out, which I use, do you have a command handy?

EDIT:
Indeed!!

/ # apk info | grep ssl
libssl1.1
libressl3.5-libcrypto
libressl3.5-libssl
libressl3.5-libtls
libressl

zuckschwerdt · 2023-02-27T11:39:37Z

Thanks, yes. It's not a runtime choice but a build choice. To show linked libs use ldd usr/bin/rtl_433
That's Alpine, right? So one of these packages? https://pkgs.alpinelinux.org/packages?name=rtl_433

milkpirate · 2023-02-27T11:44:58Z

Yeah, Alpine, but I built it myself. Finally its just my problem😄:

rtl433  | InfluxDB: InfluxDB replied HTTP code: 401 with message:
rtl433  | {"error":"authorization failed"}
rtl433  |

Fixes "Invalid PSK settings" error using LibreSSL when no PSK is used

zuckschwerdt mentioned this issue Jan 28, 2021

Request to support TLS on MQTT #1633

Closed

zuckschwerdt closed this as completed in febe5d8 Jan 28, 2021

zuckschwerdt reopened this Jan 4, 2023

zuckschwerdt added the todo Maintainers should do something, but there is no defect label Jan 4, 2023

metrafonic mentioned this issue Feb 7, 2023

Invalid PSK settings for TLS MQTT hertzg/rtl_433_docker#68

Closed

zuckschwerdt closed this as completed in 7cc2623 Feb 27, 2023

ravngr mentioned this issue Aug 31, 2023

Debian builds actually based upon Alpine hertzg/rtl_433_docker#88

Closed

andrewjw pushed a commit to andrewjw/rtl_433 that referenced this issue Sep 29, 2023

Fix: LibreSSL PSK error (closes merbanan#1569)

bcac45e

Fixes "Invalid PSK settings" error using LibreSSL when no PSK is used

Support TLS endpoint with InfluxDB #1569

Support TLS endpoint with InfluxDB #1569

Comments

sumptersmartt commented Nov 24, 2020

zuckschwerdt commented Nov 24, 2020 • edited Loading

sumptersmartt commented Nov 24, 2020

zuckschwerdt commented Nov 24, 2020

sumptersmartt commented Dec 7, 2020

milkpirate commented Dec 27, 2022

zuckschwerdt commented Dec 27, 2022

milkpirate commented Dec 27, 2022 • edited Loading

zuckschwerdt commented Dec 28, 2022

zuckschwerdt commented Dec 28, 2022

milkpirate commented Dec 28, 2022 • edited Loading

zuckschwerdt commented Dec 28, 2022

milkpirate commented Jan 2, 2023 • edited Loading

zuckschwerdt commented Jan 2, 2023

milkpirate commented Jan 2, 2023

zuckschwerdt commented Jan 2, 2023

milkpirate commented Jan 2, 2023

zuckschwerdt commented Jan 2, 2023 • edited Loading

zuckschwerdt commented Jan 2, 2023

milkpirate commented Jan 2, 2023

zuckschwerdt commented Jan 2, 2023 • edited Loading

milkpirate commented Jan 2, 2023

zuckschwerdt commented Jan 3, 2023

metrafonic commented Feb 5, 2023

zuckschwerdt commented Feb 5, 2023

zuckschwerdt commented Feb 7, 2023

metrafonic commented Feb 7, 2023

zuckschwerdt commented Feb 7, 2023

milkpirate commented Feb 25, 2023

zuckschwerdt commented Feb 26, 2023

milkpirate commented Feb 27, 2023

zuckschwerdt commented Feb 27, 2023

milkpirate commented Feb 27, 2023 • edited Loading

zuckschwerdt commented Feb 27, 2023

milkpirate commented Feb 27, 2023 • edited Loading

zuckschwerdt commented Feb 27, 2023

milkpirate commented Feb 27, 2023

zuckschwerdt commented Nov 24, 2020 •

edited

Loading

milkpirate commented Dec 27, 2022 •

edited

Loading

milkpirate commented Dec 28, 2022 •

edited

Loading

milkpirate commented Jan 2, 2023 •

edited

Loading

zuckschwerdt commented Jan 2, 2023 •

edited

Loading

zuckschwerdt commented Jan 2, 2023 •

edited

Loading

milkpirate commented Feb 27, 2023 •

edited

Loading

milkpirate commented Feb 27, 2023 •

edited

Loading