search

merbanan / rtl_433

Program to decode radio transmissions from devices on the ISM bands (and other frequencies)
GNU General Public License v2.0
5.92k stars 1.3k forks source link

mqtt connect: unqualified mDNS hostnames do not resolve #2695

Open haraldhh opened 8 months ago

haraldhh commented 8 months ago

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

zuckschwerdt commented 8 months ago

Did you try to use the intermediate instead of the root cert?

haraldhh commented 8 months ago

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[~] $
zuckschwerdt commented 8 months ago

Did you check with a pass that is just simple alphanums?

haraldhh commented 8 months ago

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.

zuckschwerdt commented 8 months ago

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

haraldhh commented 8 months ago

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.

zuckschwerdt commented 8 months ago

Interesting! If you can find out where the name resolutions goes wrong then we could likely fix that.

haraldhh commented 8 months ago

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.

zuckschwerdt commented 8 months ago

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?

haraldhh commented 8 months ago

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.

zuckschwerdt commented 8 months ago

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?

hbast commented 1 month ago

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.
zuckschwerdt commented 1 month ago

Can you try host homeassistant to get all resolutions?

hbast commented 1 month ago

looks fine...

xyz@sensorpi:~ $ host homeassistant
homeassistant.localdomain has address 192.168.1.58
zuckschwerdt commented 1 month ago

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.

hbast commented 1 month ago

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"}
zuckschwerdt commented 1 month ago

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?

hbast commented 1 month ago

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.

zuckschwerdt commented 1 month ago

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

.localdomain is 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.