rtl_433
rtl_433 copied to clipboard
merbanan
mqtt connect: unqualified mDNS hostnames do not resolve
I'm trying to publish to my mosquitto server with a Let's Encrypt signed cert. I have tried almost everything, but always get "MQTT: MQTT connect error: Unknown error -1".
./rtl_433 -C si -M level -f 433919000 -F 'mqtts://server.com:8883,user=harald,pass=redacted,tls_ca_cert=/usr/share/ca-certificates/mozilla/ISRG_Root_X1.crt,tls_server_name=server.com,devices=/clan/house/[/model][/id],events=/clan/house/[/model][/id]' -F log -F json
All my other tools work. I have used rtl433 with -F json, and then piped it to mosquitto_pub, but I only now realize that I'm missing out on the topics then and really need rtl433 to form the message.
$ ./rtl_433 -V
rtl_433 version 22.11-237-gd34e48de branch master at 202310261106 inputs file rtl_tcp RTL-SDR with TLS
Please help
I'll try that too. I tried with * too as CA-cert, that should disable cert verification if I read somewhere (no the docs) correctly.
No dice.
Input: Reading samples in async mode...
SDR: Tuned to 433.919MHz.
Allocating 15 zero-copy buffers
Baseband: low pass filter for 250000 Hz at cutoff 25000 Hz, 40.0 us
MQTT: MQTT connect error: Unknown error -1
^CSignal caught, exiting!
hostname[~] $
Yes, I had a special char in my original password, removed that but didn't change anything. The password is correct, username too. The password is now matching [A-Za-z0-9].
I would hope that wrong username, password or something like that would generate a sensible error. Unknown error -1 is like screaming at denvercoder9.
edit³: So both a wrong username and password also generates Unknown error -1. Hmm.
edit4: Wrong hostname too generates Unknown error -1. Not easy to figure this out then.
Maybe something like DNS or firewall? I can confirm that this works without problems for me:
rtl_433 -C si -M level -f 433919000 -F 'mqtts://localhost:8883,user=xxx,pass=xxx,tls_ca_cert=localca.crt,tls_server_name=localhost,devices=/clan/house/[/model][/id],events=/clan/house/[/model][/id]' -F log -F json
Thanks for the tip. Its works by entering the IP-address of the server, both IPv4 and IPv6. But not when entering the hostname. Maybe rtl_433 isn't able to choose wisely between IPv4 and IPv6 addresses?
I have mosquitto + SSL working in other applications fine, with both IPv4 and IPv6. And rtl_433 works too, if I give the IP-address (IPv4|IPv6) instead of the hostname.
Interesting! If you can find out where the name resolutions goes wrong then we could likely fix that.
Name resolution works. And returns the correct ip-addresses. getent "host" returns the IPv6 address. 'host', 'dig' and 'nslookup' all return the correct A and AAAA entries. And HA was able to connect with TLS to the IPv6 address. Using mosquitto_sub I can use the hostname, IPv4 and the IPv6 address.
I suspect that mg_connect_opt() https://github.com/merbanan/rtl_433/blob/master/src/mongoose.c#L3257 does not handle address correctly, maybe in mg_parse_address().
Perhaps you can stick some debug printf's in there?
I tried, and failed. It isn't trivial to print a struct from C I think, at least I failed. Please give some example how to do it.
I guess it rather complicated to look into possibly mg_resolve_async_opt() and such -- it's a long chain of calls. Maybe someone else has an idea how to debug?
The problem still exists. I walked in there yesterday. The error information is very cryptic and cost me a lot of time and internet research. Any chance to get this fixed for the future?
Here is some debug information. What else can I provide?
xyz@sensorpi:~ $ ping homeassistant
PING homeassistant.localdomain (192.168.1.58) 56(84) bytes of data.
64 bytes from homeassistant.localdomain (192.168.1.58): icmp_seq=1 ttl=64 time=1.77 ms
64 bytes from homeassistant.localdomain (192.168.1.58): icmp_seq=2 ttl=64 time=0.695 ms
64 bytes from homeassistant.localdomain (192.168.1.58): icmp_seq=3 ttl=64 time=0.697 ms
xyz@sensorpi:~ $ rtl_433 -f 868M -F json -M utc -F 'mqtt://homeassistant:1883,user=mqtt-user,pass=somepassword,retain=0,events=rtl_433[/model][/id]' -R173 -F log -v
rtl_433 version 23.11-129-g5ff470d2 branch master at 202406061310 inputs file rtl_tcp RTL-SDR
New defaults active, use "-Y classic -s 250k" if you need the old defaults
MQTT: Publishing MQTT data to homeassistant port 1883
MQTT: Publishing events info to MQTT topic "rtl_433[/model][/id]".
Protocols: Registered 1 out of 257 device decoding protocols [ 173 ]
Input: The internals of input handling changed, read about and report problems on PR #1978
SDR: Found 1 device(s)
SDR: trying device 0: Realtek, RTL2838UHIDIR, SN: 00000001
Detached kernel driver
Found Rafael Micro R820T tuner
SDR: Using device 0: Realtek, RTL2838UHIDIR, SN: 00000001, "Generic RTL2832U OEM"
Exact sample rate is: 1000000.026491 Hz
[R82XX] PLL not locked!
SDR: Sample rate set to 1000000 S/s.
Input: Bit detection level set to 0.0 (Auto).
SDR: Tuner gain set to Auto.
Input: Reading samples in async mode...
SDR: Tuned to 868.000MHz.
Allocating 15 zero-copy buffers
Baseband: low pass filter for 1000000 Hz at cutoff 200000 Hz, 5.0 us
MQTT: MQTT connect error: Unknown error -1
xyz@sensorpi:~ $ holger@sensorpi:~ $ rtl_433 -f 868M -F json -M utc -F 'mqtt://192.168.1.58:1883,user=mqtt-user,pass=somepassword,retain=0,events=rtl_433[/model][/id]' -R173 -F log -v
rtl_433 version 23.11-129-g5ff470d2 branch master at 202406061310 inputs file rtl_tcp RTL-SDR
New defaults active, use "-Y classic -s 250k" if you need the old defaults
MQTT: Publishing MQTT data to 192.168.1.58 port 1883
MQTT: Publishing events info to MQTT topic "rtl_433[/model][/id]".
Protocols: Registered 1 out of 257 device decoding protocols [ 173 ]
Input: The internals of input handling changed, read about and report problems on PR #1978
SDR: Found 1 device(s)
SDR: trying device 0: Realtek, RTL2838UHIDIR, SN: 00000001
Detached kernel driver
Found Rafael Micro R820T tuner
SDR: Using device 0: Realtek, RTL2838UHIDIR, SN: 00000001, "Generic RTL2832U OEM"
Exact sample rate is: 1000000.026491 Hz
[R82XX] PLL not locked!
SDR: Sample rate set to 1000000 S/s.
Input: Bit detection level set to 0.0 (Auto).
SDR: Tuner gain set to Auto.
Input: Reading samples in async mode...
SDR: Tuned to 868.000MHz.
MQTTAllocating 15 zero-copy buffers
: MQTT Connected...
MQTT: MQTT Connection established.
looks fine...
xyz@sensorpi:~ $ host homeassistant
homeassistant.localdomain has address 192.168.1.58
Just one plain address. I still think that mg_parse_address() in mg_connect_opt() fails somehow. Some needs around there with debug prints.
I would be very helpful to know why this happens. What is different to other system where this doesn't happen? Do you have similar systems where this doesn't happen? Can you find other DNS names that work?
Does -F syslog:homeassistant:1514 work? It's another name resolution path.
The debug messages were captured on a Raspberry Pi 1B with Raspberry Pi OS (Debian) and a self-compiled version of rtl_433. I also tested it on my MacBook Pro (M1), same result.
Other DNS names that work? Well I tried this one; sure there is no mqtt or open port. Looks fine:
xyz@sensorpi:~ $ rtl_433 -f 868M -F json -M utc -F 'mqtt://fritz.box:1883,user=mqtt-user,pass=somepassword,retain=0,events=rtl_433[/model][/id]' -R173 -F log -v
rtl_433 version 23.11-129-g5ff470d2 branch master at 202406061310 inputs file rtl_tcp RTL-SDR
New defaults active, use "-Y classic -s 250k" if you need the old defaults
MQTT: Publishing MQTT data to fritz.box port 1883
MQTT: Publishing events info to MQTT topic "rtl_433[/model][/id]".
Protocols: Registered 1 out of 257 device decoding protocols [ 173 ]
Input: The internals of input handling changed, read about and report problems on PR #1978
SDR: Found 1 device(s)
SDR: trying device 0: Realtek, RTL2838UHIDIR, SN: 00000001
Detached kernel driver
Found Rafael Micro R820T tuner
SDR: Using device 0: Realtek, RTL2838UHIDIR, SN: 00000001, "Generic RTL2832U OEM"
Exact sample rate is: 1000000.026491 Hz
[R82XX] PLL not locked!
SDR: Sample rate set to 1000000 S/s.
Input: Bit detection level set to 0.0 (Auto).
SDR: Tuner gain set to Auto.
Input: Reading samples in async mode...
SDR: Tuned to 868.000MHz.
Allocating 15 zero-copy buffers
MQTT: MQTT connect error: Connection refused
Baseband: low pass filter for 1000000 Hz at cutoff 200000 Hz, 5.0 us
Does -F syslog:homeassistant:1514 work? yes!
xyz@sensorpi:~ $ rtl_433 -f 868M -F json -M utc -F syslog:homeassistant:1514 -R173 -F log -v
rtl_433 version 23.11-129-g5ff470d2 branch master at 202406061310 inputs file rtl_tcp RTL-SDR
New defaults active, use "-Y classic -s 250k" if you need the old defaults
Syslog UDP: Sending datagrams to homeassistant port 1514
Protocols: Registered 1 out of 257 device decoding protocols [ 173 ]
Input: The internals of input handling changed, read about and report problems on PR #1978
SDR: Found 1 device(s)
SDR: trying device 0: Realtek, RTL2838UHIDIR, SN: 00000001
Detached kernel driver
Found Rafael Micro R820T tuner
SDR: Using device 0: Realtek, RTL2838UHIDIR, SN: 00000001, "Generic RTL2832U OEM"
Exact sample rate is: 1000000.026491 Hz
[R82XX] PLL not locked!
SDR: Sample rate set to 1000000 S/s.
Input: Bit detection level set to 0.0 (Auto).
SDR: Tuner gain set to Auto.
Input: Reading samples in async mode...
SDR: Tuned to 868.000MHz.
Allocating 15 zero-copy buffers
Baseband: low pass filter for 1000000 Hz at cutoff 200000 Hz, 5.0 us
{"time" : "2024-06-07 20:16:57", "model" : "Bresser-7in1", "id" : 46082, "temperature_C" : 16.000, "humidity" : 56, "wind_max_m_s" : 0.000, "wind_avg_m_s" : 0.000, "wind_dir_deg" : 306, "rain_mm" : 3.200, "light_klx" : 0.000, "light_lux" : 0.000, "uv" : 0.000, "battery_ok" : 1, "mic" : "CRC"}
So we can narrow it down to: there is a non-FQDN that does not resolve in the Mongoose code (some other FQDN does resolve, other code like syslog does resolve).
Does qualifying the domain work, e.g. mqtt://homeassistant.localdomain...? Since you also mention fritz.box, is that domain also homeassistant.fritz.box? How do you serve/inject localdomain?
mqtt://homeassistant.localdomain:1883 is working. I could have sworn that I started with it and couldn't establish a connection. Ok, one down.
xyz@sensorpi:~ $ rtl_433 -f 868M -F json -M utc -F 'mqtt://homeassistant.localdomain:1883,user=mqtt-user,pass=somepassword,retain=0,events=rtl_433[/model][/id]' -R173 -F log -v
rtl_433 version 23.11-129-g5ff470d2 branch master at 202406061310 inputs file rtl_tcp RTL-SDR
New defaults active, use "-Y classic -s 250k" if you need the old defaults
MQTT: Publishing MQTT data to homeassistant.localdomain port 1883
MQTT: Publishing events info to MQTT topic "rtl_433[/model][/id]".
Protocols: Registered 1 out of 257 device decoding protocols [ 173 ]
Input: The internals of input handling changed, read about and report problems on PR #1978
SDR: Found 1 device(s)
SDR: trying device 0: Realtek, RTL2838UHIDIR, SN: 00000001
Detached kernel driver
Found Rafael Micro R820T tuner
SDR: Using device 0: Realtek, RTL2838UHIDIR, SN: 00000001, "Generic RTL2832U OEM"
Exact sample rate is: 1000000.026491 Hz
[R82XX] PLL not locked!
SDR: Sample rate set to 1000000 S/s.
Input: Bit detection level set to 0.0 (Auto).
SDR: Tuner gain set to Auto.
Input: Reading samples in async mode...
SDR: Tuned to 868.000MHz.
Allocating 15 zero-copy buffers
MQTT: MQTT Connected...
MQTT: MQTT Connection established.
Baseband: low pass filter for 1000000 Hz at cutoff 200000 Hz, 5.0 us
mqtt://homeassistant.fritz.box:1883 is not working. But that doesn't necessarily mean anything, because I only use the Fritz!Box as a gateway/modem. The rest of the network is managed with unifi.
But one more thing occurred to me: sensorpi as well as homeassistant are not hosts configured in any DNS server. They are Unix hostnames, which are then resolved using mDNS (Apple Bonjour). Maybe this will help...
Edit: .localdomain is not served by me. It's part of the mDNS standard.
not hosts configured in any DNS server. They are Unix hostnames, which are then resolved using mDNS
I started to suspect something like this. Either /etc/resolv.conf does not contain search localdomain or the record is not really in .localdomain but a dynamic result of lookup (like mDNS).
.localdomainis not served by me. It's part of the mDNS standard.
Is it? I only know about .local as mDNS TLD.
In summary: If we could get to the error code somehow, we should warn about a failed lookup. Then users have chance to make ti work.
Just ran into this, homeassistant.local resulted in Unknown Error -1, using the IP works
Name resolution on the pi seems to work fine, ping has no trouble with homeassistant.local
I ran into this problem too, but I was using a qualified mDNS name (myhost.local). Seem to me rtl_433 for some reason is bypassing the NSS setup on linux and only looking up information in DNS.
@petterreinholdtsen As Joseph taught Eliza to say, many others have the same sorts of feelings. if you can figure out what library call rtl_433 is making, why it does what it does, whether the OS is corrrect, and what we might do instead, that would be super helpful.
If you want mDNS to work try to enable -DMG_ENABLE_SYNC_RESOLVER=1 -DMG_ENABLE_GETADDRINFO=1 -- easiest by changing mongoose.h in https://github.com/merbanan/rtl_433/blob/master/include/mongoose.h#L3635 and https://github.com/merbanan/rtl_433/blob/master/include/mongoose.h#L3579
And report back if that configuration works and for what platform.
[Greg Troxel]
if you can figure out what library call rtl_433 is making, why it does what it does, whether the OS is corrrect, and what we might do instead, that would be super helpful.
I see someone already proposed to stop using async DNS lookup and instead use the glibc NSS based host lookup, but thought it best to mention that to "figure out what library call rtl_433 is making", you can run
ltrace rtl_433 -F
"mqtt://mdnshost.local:1883,user=mqttuser,pass=mqttpass,retain=0,events=devices/rtl_433[/model][/id]"
It will reqport which library calls are done by the program.
-- Happy hacking Petter Reinholdtsen
It's probably not "glibc" but gethostbyname (3) or getaddrinfo(3). rtl_433 runs on more than GNU/Linux and I think that whenever possible, it should be written to POSIX. But with amending glibc to libc, then agreed. I suppose there needs to be an async wrapper around getaddrinfo that respects nssswitch.conf (common, not specified by POSIX as far as I know).
https://pubs.opengroup.org/onlinepubs/9799919799/functions/freeaddrinfo.html https://pubs.opengroup.org/onlinepubs/9799919799/functions/gethostname.html
We already have gethostbyname andf getaddrinfo implementations. https://github.com/merbanan/rtl_433/blob/master/src/mongoose.c#L2702-L2728