Reputation: 175
I am trying to create a bridge with Azure IoT Hub. The configuration of mosquitto bridge is following:
connection Azure
address <my_hub_name>.azure-devices.net:8883
# error | information | notice | warning | all | debug
log_dest stdout
log_type all
## Auth Info
remote_username <my_hub_name>.azure-devices.net/<my_dev_name>/?api-version=2018-06-30
remote_password <SAS>
remote_clientid <my_dev_name>
bridge_cafile cert.pem
## some config
try_private false
cleansession true
start_type automatic
bridge_insecure false
bridge_protocol_version mqttv311
bridge_tls_version tlsv1.2
notifications false
## Topics
topic devices/<my_dev_name>/messages/events/# out
And I get the following output:
Opening ipv6 listen socket on port 1883.
Bridge local.<my_dev_name> doing local SUBSCRIBE on topic devices/<my_dev_name>/messages/events/#
Connecting bridge Azure (<my_hub_name>.azure-devices.net:8883)
Bridge <my_dev_name> sending CONNECT
Received CONNACK on connection local.<my_dev_name>.
Bridge local.<my_dev_name> sending UNSUBSCRIBE (Mid: 1, Topic: devices/<my_dev_name>/messages/events/#)
Received UNSUBACK from local.<my_dev_name>
Socket error on client local.<my_dev_name>, disconnecting.
Bridge local.<my_dev_name> doing local SUBSCRIBE on topic devices/<my_dev_name>/messages/events/#
Connecting bridge Azure (<my_hub_name>.azure-devices.net:8883)
Bridge <my_dev_name> sending CONNECT
Received CONNACK on connection local.<my_dev_name>.
Bridge local.<my_dev_name> sending UNSUBSCRIBE (Mid: 1, Topic: devices/<my_dev_name>/messages/events/#)
Received UNSUBACK from local.<my_dev_name>
Socket error on client local.<my_dev_name>, disconnecting.
...
Wireshark shows that for unknown reason Azure sends me a packet with FIN bit set, which results into connection reset.
At the same time mosquitto_pub is able to send a packet with same parameters (host, username, password). The utility mosquitto_sub also works without errors, but does not receive any of messages published by mosquitto_pub.
Spent several days trying to figure out the correct configuration without any success (including, of course, search on stackoverflow). I will be very appreciated for any hints.
As far as I know, nobody could connect to our IoT Hub before, so probably there maybe an issue with created hub. Unfortunately, learn.microsoft.com looks more like a quest rather than a help. EDITED: corrected the topic parameter in configuration from "in" to "out".
Upvotes: 0
Views: 1399
Reputation: 175
Almost all connection errors were resolved by accurate setup of certificate and broker configuration. Except one and its description follows. We create a bridge with above credentials (certificate, SAS login/password/clientid) - everything works fine. The bridge is configured with following topic rule:
topic # both 0 /devices/ devices/<my_dev_name>/messages/events/
If I publish the following to my local broker:
mosquitto_pub \
-h 10.0.2.15 -p 1883 \
-t "/devices/foobar" \
-m "{\"foo\" : \"bar\"}" \
-d
everything is fine. But if I publish a bit more long topic
mosquitto_pub \
-h 10.0.2.15 -p 1883 \
-t "/devices/foo/foobar" \
-m "{\"foo\" : \"bar\"}" \
-d
I get connection reset error:
1607623721: Received PUBLISH from mosq-52yqOrz6C6riwvUUF3 (d0, q0, r0, m0, '/devices/foo/foobar1', ... (16 bytes))
1607623721: Sending PUBLISH to local.<my_dev_name> (d0, q0, r0, m0, 'devices/<my_dev_name>/messages/events/foo/foobar1', ... (16 bytes))
1607623721: Received DISCONNECT from mosq-52yqOrz6C6riwvUUF3
1607623721: Client mosq-52yqOrz6C6riwvUUF3 disconnected.
1607623721: Socket error on client local.<my_dev_name>, disconnecting.
I do not understand why Azure disconnects my bridge. I can make about a hundred messages to the topic /devices/foobar
in 2-3 seconds without any complaints, but only one message to /devices/foo/foobar
results into immediate socket error.
Probably, there is some restriction, but I can not find any of them, except the total maximum number of messages during one day.
Upvotes: 0
Reputation: 59751
As inferred from the comments.
The problem will be that the 2 bridges will have generated the same client id.
Client IDs need to be unique across all clients connected to the broker. If a second client connects with the same client id the spec says the broker must disconnect the fist one.
The disconnected client then tries to reconnect and this results in the other broker being kicked off, which then starts a feedback loop with each client kicking the other off as it reconnects.
Upvotes: 1