search

u-blox / ubxlib

Portable C libraries which provide APIs to build applications with u-blox products and services. Delivered as add-on to existing microcontroller and RTOS SDKs.
Apache License 2.0
313 stars 98 forks source link

Unable to connect to MQTT broker #26

Closed alexmaron81 closed 3 years ago

alexmaron81 commented 3 years ago

the following structure is ... iot device: ESP32 with sara-r412m 02b network connection is established via the provider 1nce.com. There is a vpn tunnel between 1nce and my server. the vpn ip address of the server is used in the iot device.

I have another device based on pycom fipy. There a connection to the mqtt is successfully established by itself. Therefore I rule out an error on my server side. mqtt_connection_failed.txt

RobMeades commented 3 years ago

It seems that the secure MQTT login request is being sent to the server but is failing; from the SARA-R4 AT manual:

Login to the MQTT server will have two responses, an immediate "+UMQTTC: 1,1" response that indicates that the module has sent the MQTT login request to the MQTT server. The MQTT server's login response will happen asynchronously when the MQTT server has finished processing the MQTT login request and decided whether or not to accept it.

Assuming that the username/password and IP address are correct, and since MQTT itself is indicating no error (+UMQTTER: 0,0), first suspicion would have to be that TLS security negotiation is failing. What is the approximate time between the OK response to the AT+UMQTTC=1 command and the +UUMQTTC: 1,0 arriving?

Would your server accept a non-TLS connection (purely as an experiment)?

philwareublox commented 3 years ago

Looks like there is a bug in the ubxlib handling of the unique SARA-R41x MQTTC URC response.

With SARA-R41x modules the server response URC uses as the parameter. This provides a non-zero value for errors, and ZERO for success.

Number Result of an MQTT login request. Allowed values: * 0: connection accepted * 1: the server does not support the level of the MQTT protocol requested by the client * 2: the client identifier is correct UTF-8 but not allowed by the server * 3: the network connection has been made but the MQTT service is unavailable * 4: the data in the user name or password is malformed * 5: the client is not authorized to connect * 6-255: reserved for future use This is of course different to our SARA-N3, SARA-R5 and I believe the SARA-R422 modules where the URC parameter is for the login, and other communication AT commands (Publish, subscribe etc).
RobMeades commented 3 years ago

Ah, yes, Phil is right, and MQTT on SARA-R4xx is currently marked as not supported, see this line here:

https://github.com/u-blox/ubxlib/blob/master/cell/src/u_cell_private.c#L94

@alexmaron81: have you modified that line to include MQTT support on SARA-R4xx, or are you using unmodified code, in which case I should investigate why you are even getting to a login attempt.

In terms of testing the MQTT support on R41x, I can look at that but I'm afraid it might not be for a week or two.

alexmaron81 commented 3 years ago

Yes RobMeades, I had commented out the four lines in the u_cell_private.c.

What would you suggest how I should proceed to get a connection?

RobMeades commented 3 years ago

What needs to happen is that the ubxlib MQTT tests need to pass with those lines present, which will take a little debugging. If you fancy it you can have a go yourself, but the differences between SARA versions ref. MQTT can be a bit "interesting" and will likely require some fettling.

If I can get my current thing out of the way this evening there's a chance I could have a go at this myself over the next few days, since I do now have a SARA-R412M-02B in the test system with the correct FW version loaded onto it.

What is your deadline?

alexmaron81 commented 3 years ago

my deadline has actually expired ;-) I wanted to finish establishing the connection two weeks ago and would have "celllocate" at the next step. Unfortunately, the library for cellocate has not yet been expanded.

The subject of at commands is new to me and that's why I selected a module like u-blox, because I saw that the library "ubxlib" was available for the esp32.

Thanks for the help, at the same time I use the time and try to understand the at commands.

RobMeades commented 3 years ago

Well, the thing I am working on right now is the location APIs and I am actually testing the completed Cell Locate API implementation as we speak.

You're welcome to continue with AT commands of course but I would estimate that the location APIs will be ready by the end of August and I can test/debug the MQTT API on SARA-R142M-02B in the same timeframe if that is useful to you.

alexmaron81 commented 3 years ago

That sounds good! I would like to deal intensively with iot, can you recommend a source of information about the at commands or general data transmission via the mobile network?

RobMeades commented 3 years ago

For AT commands I'd just go to either the u-blox AT command manual or, if you prefer, to 3GPP 27.007, but then you will need to check if we support that particular AT command.

On data transmission over the mobile network, and one that covers the vagaries of NBIoT/cat-M1 I'm not sure what to suggest: @philwareublox, do you have any recommendations?

philwareublox commented 3 years ago

The Application Development Guides on our u-blox website for each cellular module is a good starting point for understanding what is required for writing IoT applications with Cellular technology.

https://www.u-blox.com/en/ubx-viewer/view/SARA-R42-Application-Development_AppNote_UBX-20050829?url=https%3A%2F%2Fwww.u-blox.com%2Fsites%2Fdefault%2Ffiles%2FSARA-R42-Application-Development_AppNote_UBX-20050829.pdf

https://www.u-blox.com/en/ubx-viewer/view/Internet-applications-development-guide_AppNote_UBX-20032566?url=https%3A%2F%2Fwww.u-blox.com%2Fsites%2Fdefault%2Ffiles%2FInternet-applications-development-guide_AppNote_UBX-20032566.pdf

The main issue with the R41x version of MQTT is that the URC that is emitted is both for URC and the response to the 'read message' command. Because of this the AT parsing of this needs to know the difference between. The first URC starts the read message process, and then the next same text that appear is for the messages.

With the other modules the URC is different to the AT header which is used for reading the messages.

alexmaron81 commented 3 years ago

I just do not get any further. I don't know where to start looking for the error. Do you have a suggestion where I should look first?

RobMeades commented 3 years ago

Simplest thing would be to use the code that I will release at the end of August. The code is complete and tested but I am on holiday this week and it has not yet passed review so I cannot merge it however, if you cannot wait, then I have pushed it to a preview branch where you can try it out. I will delete this branch when I have merged the code so this is not a permanent solution for you, only useful if you really want to try something out immediately.

alexmaron81 commented 3 years ago

great, it worked for the test!

RobMeades commented 3 years ago

Hopefully this is addressed by this commit. I will delete the preview branch now and close this issue: please open a new issue if you believe there is more to do.