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

Thanks for your reply. However, I am not using a broker inside the TRB. The link you refer to is about the broker inside the TRB which I am not using. The right documentation link is this: https://wiki.teltonika-networks.com/view/TRB245_Data_to_Server#Protocol_MQTT

I just want to publish to a remote broker on the internet. My question is not about the MQTT menu but the DATA TO SERVER menu. By my knowledge, and experience with the brokers I mentioned, you only need a ca-file (which I attached) because I am not (yet) working with client certificates. Client certificates should be optional. This is mentioned as optional on the help texts the web configuration page of the TRB and the wiki https://wiki.teltonika-networks.com/view/TRB245_Data_to_Server#Protocol_MQTT

by anonymous
Hello,

The same scenario will apply it must have a certificate of authority file, certificate file, and certificate key to make it work.

Regards,

Jerome
by anonymous
Thanks for your comment

sorry but your comment does not make sense to me.

The client certificate is optional can be left empty as stated by the wiki and the help text. And this make sense as this also works with any other mqtt client (but not the TRB).

I hope someone can help how to get TLS working with just server certificate, which should be common practice

regards,

Dick
by anonymous
Hello,

You are doing Data to Server not the MQTT protocol. Data to server will be able to send the MQTT data to server without any authentication method but it will depend on the server if it doesn't require any TLS authentication. As you mentioned turning off the TLS authentication the server was able to get the data. So the main issue is not with the router but on the TLS part since you are missing the Client Certificate and Client key it must match with your Server TLS files.

The connecting device (Client) will need the Certificate Authority file, Client Certificate, and Client key in order for the server to accept the Data sent to your server. This one is what is the common communication process with the use of TLS.

Thank you and have a nice day

Regards,

Jerome
by anonymous

Hi 

Thanks for your reply. 

In general, client certificates/key should not be required in order to be able to use TLS. It can be set/enforced by the broker configuration but this is not done mostly.

I am able to publish over tls using just the server certificate with mosquitto_pub (linux), mqttbox (windows) and other clients. I am not creating and installing any client certificates on these and still it works (as expected). Both for my own broker and the emqx using the mentioned certificates. 

regards, 

Dick

by anonymous
Hello,

I will share your feedback with our RnD Team and check this matter.

Regards,

Jerome
by anonymous
Hi Jerome

Thanks a lot!

kind regards,

Dick Oort
by anonymous
Hello,

I have received feedback from HQ. It should be working on the latest firmware available on our wiki page.

https://wiki.teltonika-networks.com/view/TRB245_Firmware_Downloads

Could you re-flash your firmware and check if it is able to send data.

If you're still having the same issue kindly share me a copy of your troubleshoot file.

Regards,
Jerome
by anonymous

dear Jerome, 

Thanks again for your effort. However I think this is the version I already have on my device...

What if you / your collegues try to demo/test with an independend mqtt test endpoint that I also would be able to use: 

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

thanks in advance... 

TRB2_R_00.02.05.2
Firmware build date 2020-11-19 15:09:19
Modem firmware version EC25EUXGAR08A02M1G
Kernel version 4.14.171

by anonymous

Hello, 

Could you try doing this method and let me know if it works.

-> Navigate to System -> Administration -> Certificates -> Certificates Manger and upload his .pem file;
-> Then in the Data to Server configuration window enable Certificate file from device and see if it will solve the issue.

Regards,
Jerome

by anonymous

Hello Jerome, 

Thanks for the suggestion. I had tried this already. I retried and also did it for the emqx broker / certificate

Unfortunately, no luck... 

I also tried to look in system logging but can't find messages

But.....

I installed mosquitto-clients by login using putty / ssl in the trb and put the command

opkg install mosquitto-client-ssl

thereafter I put

mosquitto_pub -h mqtt.remate.eu -u <myuser> -P <mypassword> -t teltonikadata -m 'whatevertestdatamessage on the TRB245' -d --cafile /etc/certificates/rematemqtt.pem -p 8883 

OUTPUT:

Client mosqpub|31174-Teltonika sending CONNECT

Client mosqpub|31174-Teltonika received CONNACK (0)

Client mosqpub|31174-Teltonika sending PUBLISH (d0, q0, r0, m1, 'teltonikadata', ... (35 bytes))

Client mosqpub|31174-Teltonika sending DISCONNECT

And received in client/subscriber

whatever is coming from the TRB 245

qos : 0, retain : false, cmd : publish, dup : false, topic : teltonikadata, messageId : , length : 50, Raw payload : 1191049711610111810111432105115329911110910511010332102114111109321161041013284826632505253

The same is working for the emqx broker:

mosquitto_pub -h broker.emqx.io -t teltonikadata1234 -m "whatever from TRB245 using emqx" -d --cafile /etc/certificates/brokeremqxioca.crt -p 8883

Hence, this proves to me that servers and certificates are all OK and that we now would want to take a look at the modbus_data_sender module. Unfortunately, no source was to be found in the sdk. But the first step would be to acquire some detailed logging from this process and see where it goes wrong exactly.

Hope this helps!

kind regards, 

Dick Oort

by anonymous
Hello,

Thank you for the feedback forwarded to our HQ team. Once I received  have feedback I will let you know.

Regards,
Jerome
by anonymous
Thanks again.

Overall I like the module very much and when this obstacle is out of the way we foresee many opportunities for integration!

kind regards,

Dick
by anonymous
Hello,

Any update on this issue?  Thanks!
by anonymous
Hello,

I am still waiting for updates from our HQ. Once I receive feedback from them, I'll let you know.

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