Making MQTT Publisher example work on Raspberry Pi 4

[AguirreGENROD]

Hi, like the title says I am having trouble implementing the MQTT Publisher example found in the nRF5 SDK for Thread and Zigbee v4.1.0 . I'm using a Raspberry Pi 4 with the latest Raspbian OS available (Kernel version 5.10). For the BLE device I'm using a BMD-340 Evaluation Board which has the nRF52840 chip.

I want to make the example work without TLS (It doesn´t work using TLS either but I figured trying to make the simplest version work first and then add TLS).

I followed this guide for the changes needed to make the example work without TLS, and this one for checking all the settings corresponding to the Raspberry Pi (except those corresponding to kernel building given that for newer versions it is not necessary because modules are already present), from that guide I also read that I had to set BLE_6LOWPAN_LEGACY_MODE in sdk_config.h to 0 because of kernel version being newer than 4.12.

The BLE connection sets up fine, I can see bt0 interface with the 2001:db8::1/64 IP and I can ping the device just fine. The problem seems to be related to the mqtt connection.

When trying to connect to the MQTT broker, it detects the connection:

[10:37:21]: New connection from 2001:db8::70:dfff:fe39:d5e8 on port 1883.
[10:37:21]: New client connected from 2001:db8::70:dfff:fe39:d5e8 as nrfPublisher (p1, c1, k60).                        
[10:37:21]: No will message specified.
[10:37:21]: Sending CONNACK to nrfPublisher (0, 0)                                                                      
[10:38:51]: Client nrfPublisher has exceeded timeout, disconnecting. 

but from the device I get an error:

I am using tshark to check Raspberry Pi's incoming and outcoming packets and a sniffer to check the connection on air and it seems like TCP packets from the Raspberry Pi are not getting to air.

I'll attach the full captures, but what the sniffer sees is this:

and packets from the Raspberry Pi are seen like this:

Because the guide may have not been updated recently I'm thinking maybe there is some configuration missing somewhere, I'd appreciate any help.

Thanks

NOTLS_Sniffer1.pcapngNOTLS_tshark1.pcapng

[Jørgen Holmefjord]

Hi,

Have you tried increasing the log level for the example to DEBUG, to see if you can get more information about why the IPv6 interface goes down?

It does not look like the BLE link is disconnected on the sniffer trace.

Best regards,
Jørgen

[AguirreGENROD]

Hi! I wanted to give you an update.

Apparently there was an error during BLE connections that closes connections after 40s, I found a solution in this post. This could explain the behaviour found in past attached logs that showed a timeout disconnection.

I now created a few more captures with that problem solved. The device still can´t connect to MQTT, broker logs are still the same: 

2021-05-06T15:30:12: New connection from 2001:db8::70:dfff:fe39:d5e8:49153 on port 1883.
2021-05-06T15:30:12: New client connected from 2001:db8::70:dfff:fe39:d5e8:49153 as nrfPublisher (p1, c1, k60).
2021-05-06T15:30:12: No will message specified.
2021-05-06T15:30:12: Sending CONNACK to nrfPublisher (0, 0)
2021-05-06T15:31:44: Client nrfPublisher has exceeded timeout, disconnecting.

But the device doesn´t disconnect after pressing Button 1 one time, it waits for the CONNACK packet that the RPi never sends. When pressing the button a second time, it crashes.

From the RPi side I am now also capturing from btmon, because it gives a few more low-level details. I noticed tshark captures are the only ones showing the CONNACK packet, with a few retransmission attempts. 

I'll attach a few new captures so you can take a look and tell me if you think about anything with this new information.

Thanks in advance, will be waiting for your response.

RPi4B_Buster_Publisher_BMDLog.log

RPi4B_Buster_Publisher_Btmon.pcap

RPi4B_Buster_Publisher_Sniffer.pcapng

RPi4B_Buster_Publisher_Tshark.pcap

[Jørgen Holmefjord]

Hi, sorry for not getting back to you on this one. Are you still needing help with resolving this issue?

I see that your application log shows "Fatal Error". Can you try building the application in debug configuration (with DEBUG and DEBUG_NRF preprocessor symbols set)? That should reveal at which file/line and error code the application crashes.