0

We have an IoT company and we shipped more than 10.000 products around the world. We have some of our customers (around 5%) that cannot connect their product to MQTT.

Our infrastructure is really easy. Once the user send WiFi credentials to our product via bluetooth, it connects to the WiFi and sends a request to our server. The server respond with the certificates to connect to the MQTT broker (AWS IoT Core), as soon as the product has this certificates it connects to MQTT broker and starts the communication but this connection never happen.

The problem is that we cannot replicate this kind of problem in any way. We tried to buy the same routers of our customers but everything works fine.

The port used by the device is the 8883 and the authentication uses X.509 client certificates.

Do you have any idea of which could be the issue?

Thank you so much!

2
  • Non standard ports are often blocked for a variety of reasons. This is more common on enterprise and public networks rather than home networks, but based on some combination of ISP, router, firewall, or other security settings, it’s far from impossible. Is the first request to the server of http or https? If those work but not MQTT port blocking may be a reason. Are there commonalities between customers facing the issue (ISP, router, consumer vs business...)?
    – jcaron
    Nov 8 '20 at 13:22
  • If it is easily reproducible by your customers, proper field diagnostics should yield a solution very quickly. What do your logs say? I presume your server logs say they responded. Can you enable more diagnostics in your "product", eg. via a run-time switch? Can you run wireshark? Nov 9 '20 at 12:53
3

Do you know if the nodes being provisioned have proper date/time set? In my experience with similar situation, it turned out that NTP is often blockedby ISPs and IoT nodes could not fetch network time. It is necessary for the certificate expiration verifications.

1

Assuming you have an app to push the WiFi credentials to the device, can you test the MQTT connection from the app over the same network?

This would give you access to the errors thrown by the MQTT stack as it tries to connect.

Alternatively can the device log errors that could be collected by the app via Bluetooth in the case of a failure. Or since HTTP (assumed) is working (to retrieve the cert) you could also have the device report errors via HTTP post to see the reported reasons for the failure.

3
  • 1
    Hi Ben, thank you for your comment. We already have a "diagnostic" feature inside the application but everything seems to work fine. Unfortunately right now we cannot get verbose errors from our WiFi module but we are working on it. From our logs it seems that the MQTT connection doesn't go well but we don't have enough information to understand the cause. Could it be that some ISPs block the MQTT port (8883)? Nov 5 '20 at 14:54
  • 1
    It's possible that some ISPs may be trying to transparent proxy everything as HTTP (usual reason is v low cost doing advert injection) This is what testing MQTT (on 8883) from the app would check for. I'd look for any common ISP from across the failures
    – hardillb
    Nov 5 '20 at 15:30
  • @marksaint, did you find out what the cause was ? It would perhaps be useful for others if you state what you learned. Mar 26 at 16:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.