FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

14455 questions

17168 answers

28195 comments

0 members

We are migrating to our new platform at https://community.teltonika.lt. Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
+3 votes
1,743 views 29 comments
by anonymous

Hello, 

My modbus sensor data has to be published to a remote mqtt broker (mqtt.remate.eu). 

This runs OK without tls and with username/password. I am receiving the data from the trb245 at my endpoint. 

With TLS I have no succes with the TRB. but it works on other clients. (windows 10 MQTTBox) and rpi mosquitto_pub 

example: mosquitto_pub -h mqtt.remate.eu -u <myusername> -P <mypasword> -t teltonikadata -m 'whatevertestdatamessage' -d --cafile /home/pi/certs/rematemqtt.pem -p 8883 

I uploaded the certificate chain rematemqtt.pem here.  This chain was obtained by concatenating my letsencrypt generated fullchain.pem with the CA chain DST_Root_CA like this cat fullchain.pem DST_Root_CA_X3.pem  > rematemqtt.pem. 

In the TRB I used the settings as below. Note that without TLS on, everything goes OK. The problem starts with TLS ON. What can be wrong?

See image:here

by anonymous

Hi all; Did anybody succesfully test pub to another mqtt broker (with tls)?

Except for my own broker i tested with the public test broker emq:

https://www.emqx.io/mqtt/public-mqtt5-broker

by anonymous
I have simmilar problem. Where i can find log from publish service to diagniose issue?
by anonymous

Just stumbled upon the same issue, with a very similar use case. Using a CA certificate to establish a TLS connection - but not a client certificate/key - seems like a pretty common use case. @mohanjith's patch looks pretty straightforward...would be great to have this incorporated.

Also, like @melanie - I'd be interested in knowing where the MQTT connection log is. Really difficult to troubleshoot this without logs. (in fact, I'd still be scratching my head if it wasn't for this forum)

3 Answers

0 votes
by anonymous
Hello,

Regarding the issues your having you must provide the TRB device the certificate file required.

You may refer to this link for more information:
https://wiki.teltonika-networks.com/view/TRB245_MQTT#Security

In order to make a successful authentication method the TRB devices needs to have the required TLS file that is matching with the broker.

ca file, certificate file and private key is needed to make a successful communication with the server.

Regards,
Jerome
by anonymous

Hello, 

Received information from RnD.It is possible to upload the whole .pem file to our device, but this requires firmware changes.

RnD had made a note of that, and will try to add this feature into TRB firmware.

No current time frame or firmware version when to expect this.

Regards,
Jerome

by anonymous
Hello Jerome,

Thanks for your message.

I am not sure if I understand. What do you mean by  'possible to upload the whole .pem file to our device' ?  Uploading a .pem file is not the issue, is it?

I would say that the issue is that the firmware does not support mqtt publish with one-way TLS?

BTW I haven't tried two-way TLS (e.g. using self signed certificates) has that been tested?

thanks
by anonymous

Hello, 

I have received feedback from our RnD team.

Regarding self-signed certificates, currently, our device cannot download certificates from the server-side.

We added it to our list of "nice to have" features.

When it will be released with firmware - do not know. 

Regards,

Jerome

by
Thanks

What about just getting TLS to work the simplest way?

Like it is working with mosquitto_pub?

Or in any way?

How and when?
by anonymous
Hello,

As of now, you can try working on it via opkg command to install a MQTT service. Then configure everything via CLI.

Regarding how we don't have any details for these yet. But for the said requests in the previous conversation our RnD team
is looking on to it, only that they didn't give us the exact time and date that it will be available.

Sorry for the inconvenience and have a nice day!

Regards,
Jerome
0 votes
by anonymous
update:

TLS seems to work only in two way mode when provided with self-signed ca certificate, client certificate and unencrypted private key. When I have time and people are interested I am happy to provide the solution and a demo for that.

It can be workable for many situations, however it is a very big shortcoming that oneway-tls with trusted ca certificate and omitting client cert/key can not work on the trb.
by anonymous

Here are patches for TRB14x and RUT24x to make client key and certificate optional.

TRB14x

https://gist.github.com/mohavirta/0e3b2948afbe73a6d64b26574f07e7e7

RUT24x

https://gist.github.com/mohavirta/c7407f77256cc9a10d8e1f7795adc40b

I hope Teltonika can apply these patches before the next firmware release.

by anonymous
Thanks a lot mohanjith!!  I will schedule to test this
by anonymous
Thanks for the patch - I tried it and it's good. Though unfortunately it appears to only relate to the "MQTT Publish" functionality, and not the "Data to server" functionality that OP appears to be referring to (and I myself and most in need of).
by anonymous
@svet: maybe configure your  data to server settings to localhost and then bridge to your server ? (I still did not test the patch)
by anonymous
@dickoort thanks for the suggestion - that makes a lot of sense. My preference was to minimize the complexity and only have one process handling the data flow; so in the end I got the "data to server" working with a dummy client certificate (the "answer" I just posted...)
+1 vote
by anonymous

This indeed appears to be a significant flaw with how TLS is set up for the "Data to server" functionality (for e.g. Modbus to MQTT forwarding). There is a silly though straightforward workaround:

You can generate a dummy (but valid) combination of certificate and key, e.g. from https://www.selfsignedcertificate.com. Use those as the client certificate and key in the configuration, along with the broker's CA certificate. This worked for me, against a Mosquitto broker using a self-signed certificate (but no two-way certificate auth).

I'm not sure whether service logs are available anywhere, but you can test the connection manually, by running:

/usr/sbin/modbus_data_sender

on the router (preferably after temporarily disabling the actual "modbus_data_sender" service, to avoid two identical processes running simultaneously).

First the configuration is printed out, and after that if the connection to the broker is successful, you'll get the message

Sender cfgxxxxxx_xxxxxxxxxx is running through a loop

followed by collection and transmission of Modbus data. If there is a connection issue, you'll likely get

Failed to connect

or similar. Finally, if insufficient certificates have been supplied (e.g. you didn't actually provide a client cert and key), you'll probably get

skipping: bad CA file / certificate / key file