MQTT Connection ERR 14

Hi!

We have a EMQX broker running behind TLS with a valid certificate, currently in use by several RAK831 rpi based gateways.

When I try to set mqtt settings I get this error:

Wed Jan 15 18:37:07 2020 daemon.info mqttEv[3467]: mqttEvRegister : Register mosquitto event [gwBridgeS Mqtt Client]
Wed Jan 15 18:37:07 2020 daemon.err mqttEv[3467]: mqttEvDisconnectCB : MqttClient [gwBridgeS Mqtt Client] Disconnected : [14]
Wed Jan 15 18:37:07 2020 daemon.err mqttEv[3467]: mqttEvWrReady: mosquitto [[gwBridgeS Mqtt Client]] loop write ERR: 14

Our broker listents behind a reverse proxy (Voyager Ingress controller) on port 8883. TLS version should be 1.2. Am I missing something?

Thanks in advance!

We sill can’t make it work.
Using MQTT windows client with the exact same settings works. TLS1.2, MQTT 3.1, CA signed server certificate, 1.1.0060_Release r198 firmware.
I have to decide which gateways to buy and RAK was the best option…

Does anyone had the same issue?

PD: The broker is behind HAproxy (voyager ingress) using Let’sEncypt certificates

PD: Maybe I need OpenWRT ca-bundle package? can’t install it as it seems that opkg package manager doesnt have repositories configured

I’m still unable to make our RAK gateways work with our ChirpStack instance… is there someone with the same issue? or someone who can give me support?
Thanks in advance!

Hi , can you send me the full log to [email protected]

1 Like

Still no answer from anyone at RAK Wireless. This problem persist and I can’t use any OpenWRT based RAK gatway in our network

Hi @stormforce133 I am on your case. Trying to reproduce it. Can you send me the EMQX log?
Also , which MQTT protocol version are you using?

Thanks @velev!

We’re using EMQX 3.2.3 which supports 3.1, 3.1.1 and 5.0: (from Github)

Starting from 3.0 release, EMQ X broker fully supports MQTT V5.0 protocol specifications and backward compatible with MQTT V3.1 and V3.1.1, as well as other communication protocols such as MQTT-SN, CoAP, LwM2M, WebSocket and STOMP.

EMQX logs doesn’t show much:

2020-01-15 07:51:49.112 [warning] [email protected]:34668 [Channel] Discarded by kerlink1:<0.25620.123>
2020-01-21 19:48:23.309 [warning] [email protected]:36672 [Channel] Discarded by kerlink1:<0.13490.146>
2020-01-25 02:57:18.303 [warning] [email protected]:38168 [Channel] Discarded by RAK_GPE_01:<0.31018.157>
2020-02-02 14:06:51.889 [warning] [SYSMON] long_schedule warning: pid = <0.13698.187>, info: [{timeout,290},{in,{prim_inet,recv0,3}},{out,{gen,do_call,4}}]

Our voyager ingress also doesn’t show much:

I0205 11:57:55.339663      12 reload.go:44] haproxy daemon running (pid 92)
I0205 11:58:25.339567      12 reload.go:44] haproxy daemon running (pid 92)
I0205 11:58:55.339639      12 reload.go:44] haproxy daemon running (pid 92)
I0205 11:59:25.339607      12 reload.go:44] haproxy daemon running (pid 92)
I0205 11:59:55.339578      12 reload.go:44] haproxy daemon running (pid 92)
I0205 12:00:25.339657      12 reload.go:44] haproxy daemon running (pid 92)
I0205 12:00:55.339632      12 reload.go:44] haproxy daemon running (pid 92)
I0205 12:01:25.339606      12 reload.go:44] haproxy daemon running (pid 92)
I0205 12:01:55.341145      12 reload.go:44] haproxy daemon running (pid 92)
I0205 12:02:25.339592      12 reload.go:44] haproxy daemon running (pid 92)
I0205 12:02:55.339557      12 reload.go:44] haproxy daemon running (pid 92)
I0205 12:03:25.339566      12 reload.go:44] haproxy daemon running (pid 92)
I0205 12:03:55.339571      12 reload.go:44] haproxy daemon running (pid 92)
I0205 12:04:25.339630      12 reload.go:44] haproxy daemon running (pid 92)
I0205 12:04:55.339545      12 reload.go:44] haproxy daemon running (pid 92)

Thanks in advance

Hi Has your problem been solved?

Hi @yutao. My problem persists.
I’ve checked our Ingress setup and it works like expected. We’re using Voyager Ingress which uses HAProxy for load balancing.
ChirpStack Gateway Bridge and other clients like MQTT.fx can connect normally to our broker.

Hi there!
I upgraded our EMQX instance to 4.0.2, nicer dashboard but same results.
Also downgraded FW to 1.1.0059_Release r197 (also tried V1.1.0050_Release_r184) with no luck.
Still having ERR 14.

We could try to bypass Voyager ingress and load Let’sEncrypt certificates to EMQX broker but that will take time and downtime for our current services. Also 90day renewal brings a lot of work. This has become a very big issue for us, we need to deploy an indoor network in a new client in 1 week and we’ve decided to use RAK for all of our deployments.

Hi:
Can you contact me by mail? I will assist you remotely to solve this problem.
[email protected]