This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Sending CONNACK to nrfPublisher, but no responses (MQTT)

I am following the MQTT example provided https://infocenter.nordicsemi.com/topic/sdk_nrf5_v16.0.0/iot_sdk_app_mqtt.html?cp=7_5_0_4_2_4_6 with nRFSDK 16.0.0 and nRF52DK

I have similar problem like this thread (I can't find a solution in this thread) but with the non secure port 1883. I established 6lowpan connection with nRF52DK and raspberry pi w. The ping6 shows fine and the LED 1 is ON

ping6 2001:db8::63:f7ff:fe14:8e3 -c 4
PING 2001:db8::63:f7ff:fe14:8e3(2001:db8::63:f7ff:fe14:8e3) 56 data bytes
64 bytes from 2001:db8::63:f7ff:fe14:8e3: icmp_seq=1 ttl=255 time=222 ms
64 bytes from 2001:db8::63:f7ff:fe14:8e3: icmp_seq=2 ttl=255 time=149 ms
64 bytes from 2001:db8::63:f7ff:fe14:8e3: icmp_seq=3 ttl=255 time=122 ms
64 bytes from 2001:db8::63:f7ff:fe14:8e3: icmp_seq=4 ttl=255 time=145 ms

and the interface address is same as the example 2001:db8::1.

Connection changed to non secure with the port 1883

static void app_mqtt_connect(void)
{
    mqtt_client_init(&m_app_mqtt_client);

    memcpy(m_app_mqtt_client.broker_addr.u8, m_broker_addr.u8, IPV6_ADDR_SIZE);
    m_app_mqtt_client.broker_port          = APP_MQTT_BROKER_PORT;
    m_app_mqtt_client.evt_cb               = app_mqtt_evt_handler;
    m_app_mqtt_client.client_id.p_utf_str  = (uint8_t *)m_client_id;
    m_app_mqtt_client.client_id.utf_strlen = strlen(m_client_id);
    m_app_mqtt_client.p_password           = NULL;
    m_app_mqtt_client.p_user_name          = NULL;
    m_app_mqtt_client.transport_type       = MQTT_TRANSPORT_NON_SECURE;
    //m_app_mqtt_client.p_security_settings  = &m_tls_keys;
    m_app_mqtt_client.p_security_settings  = NULL;
    m_app_mqtt_client.protocol_version = MQTT_VERSION_3_1_1;

    UNUSED_VARIABLE(mqtt_connect(&m_app_mqtt_client));
}

And disabled the legacy mode (#define BLE_6LOWPAN_LEGACY_MODE 0)

When pressing button 1 on DK, the mosquitto broker response like this

1610669581: New client connected from 2001:db8::63:f7ff:fe14:8e3 as nrfPublisher (c1, k60).
1610669581: No will message specified.
1610669581: Sending CONNACK to nrfPublisher (0, 0)
1610669671: Client nrfPublisher has exceeded timeout, disconnecting.                                                    1610669671: Socket error on client nrfPublisher, disconnecting.

And tshark listens on port 1883

    1 0.000000000 2001:db8::63:f7ff:fe14:8e3 → 2001:db8::1  TCP 80 49153 → 1883 [SYN] Seq=0 Win=3584 Len=0 MSS=896
    2 0.000313993  2001:db8::1 → 2001:db8::63:f7ff:fe14:8e3 TCP 80 1883 → 49153 [SYN, ACK] Seq=0 Ack=1 Win=64660 Len=0 MSS=1220
    3 0.096899823 2001:db8::63:f7ff:fe14:8e3 → 2001:db8::1  MQTT 102 Connect Command
    4 0.097272815  2001:db8::1 → 2001:db8::63:f7ff:fe14:8e3 TCP 76 1883 → 49153 [ACK] Seq=1 Ack=27 Win=64634 Len=0
    5 0.101568718  2001:db8::1 → 2001:db8::63:f7ff:fe14:8e3 MQTT 80 Connect Ack
    6 0.402768953  2001:db8::1 → 2001:db8::63:f7ff:fe14:8e3 TCP 80 [TCP Retransmission] 1883 → 49153 [PSH, ACK] Seq=1 Ack=27 Win=64634 Len=4
    7 1.012792260  2001:db8::1 → 2001:db8::63:f7ff:fe14:8e3 TCP 80 [TCP Retransmission] 1883 → 49153 [PSH, ACK] Seq=1 Ack=27 Win=64634 Len=4
    8 2.262781237  2001:db8::1 → 2001:db8::63:f7ff:fe14:8e3 TCP 80 [TCP Retransmission] 1883 → 49153 [PSH, ACK] Seq=1 Ack=27 Win=64634 Len=4
    9 4.742809773  2001:db8::1 → 2001:db8::63:f7ff:fe14:8e3 TCP 80 [TCP Retransmission] 1883 → 49153 [PSH, ACK] Seq=1 Ack=27 Win=64634 Len=4
   10 9.622823178  2001:db8::1 → 2001:db8::63:f7ff:fe14:8e3 TCP 80 [TCP Retransmission] 1883 → 49153 [PSH, ACK] Seq=1 Ack=27 Win=64634 Len=4
   11 19.702820089  2001:db8::1 → 2001:db8::63:f7ff:fe14:8e3 TCP 80 [TCP Retransmission] 1883 → 49153 [PSH, ACK] Seq=1 Ack=27 Win=64634 Len=4
   12 39.542833533  2001:db8::1 → 2001:db8::63:f7ff:fe14:8e3 TCP 80 [TCP Retransmission] 1883 → 49153 [PSH, ACK] Seq=1 Ack=27 Win=64634 Len=4
   13 78.582847983  2001:db8::1 → 2001:db8::63:f7ff:fe14:8e3 TCP 80 [TCP Retransmission] 1883 → 49153 [PSH, ACK] Seq=1 Ack=27 Win=64634 Len=4
   14 90.307113109  2001:db8::1 → 2001:db8::63:f7ff:fe14:8e3 TCP 76 1883 → 49153 [FIN, ACK] Seq=5 Ack=27 Win=64634 Len=0

However, there is no response from the nRF52DK, the UART interface shows

<info> app: Physical layer in connectable mode.
<info> app: Physical layer: connected.
<info> app: IPv6 Interface Up.

It seems that the board hangs for ever, even-though the ping6 still works fine, but no more actions with any buttons. Also tried a break point at mqtt_handle_packet() in mqtt_rx.c, but this event is never called.

== Update ==

Enabled mqtt config log (#define MQTT_CONFIG_LOG_ENABLED 1, and #define MQTT_CONFIG_LOG_LEVEL 4) and after pressing button 1 returns this

<debug> mqtt_enc: Encoding Protocol Description. Str:MQTT�0 Size:00000004.

<debug> mqtt_enc: >> pack_utf8_str USL:00000006 BL:0000007B, B:0x20004B7D, O:00000000 A:0000007B

<debug> mqtt_enc: >> pack_uint16 V:0004 BL:0000007B, B:0x20004B7D, O:00000000 A:0000007B

<debug> mqtt_enc: Encoding Protocol Version 04.

<debug> mqtt_enc: >> pack_uint8 V:04 BL:0000007B, B:0x20004B7D, O:00000006

<debug> mqtt_enc: Encoding Keep Alive Time 003C.

<debug> mqtt_enc: >> pack_uint16 V:003C BL:0000007B, B:0x20004B7<debug> mqtt_enc: >> pack_uint8 V:10 BL:00000080, B:0x20004B7B, O:00000000

<debug> mqtt_enc: >> RL:0x00000018 O:00000001 P:0x20004B7B

<debug> mqtt_enc: << RLS:0x00000001

<debug> mqtt_lwip: [0x2000C028]: TCP Write in Progress, length 0x0000001A.

<debug> mqtt_lwip: [0x2000C028]: TCP Write Complete.

And further button 1 press the function "mqtt_connect" returns error code 51460

Parents
  • Hi Ras,

    I will try to recreate your problem, but for your development, I have some questions or suggestions.

    Is your project focus on the application layer or lower layers? Could you explain why you have to use our legacy IoT solution in this example? As you may realize our nRF52 SDK/NCS have switched to a more robust open-source project OpenThread solution lead by Google. There will no further development on this legacy solution, which means you may have trouble getting further support in the future. On another hand, as a transport and network layers solution, Thread is a better choice than you develop your own, maybe it is better to study and modify it if you have other needs. 

     

    Best regards,

    Charlie

  • My application is remote monitoring of a single node. With 6lowpan, I just needed one BLE device with a rasberry pi, possibly a Pi W board. The thread border router needs one BLE chip with raspberry pi. If I can merge the border router with application layer then the Thread is a solution but in the current scenario sensing node is a battery powered device.

    When I looked the Thread solution some time ago, the border router is not supported with raspberry Pi boards other than Pi 3. Maybe it will work with other versions as well.

    I found 6lowpan + MQTT application in the latest Thread + ZigBee SDK.

    I am not very comfortable to use nRFConnect SDK, and slowly migrating.

Reply
  • My application is remote monitoring of a single node. With 6lowpan, I just needed one BLE device with a rasberry pi, possibly a Pi W board. The thread border router needs one BLE chip with raspberry pi. If I can merge the border router with application layer then the Thread is a solution but in the current scenario sensing node is a battery powered device.

    When I looked the Thread solution some time ago, the border router is not supported with raspberry Pi boards other than Pi 3. Maybe it will work with other versions as well.

    I found 6lowpan + MQTT application in the latest Thread + ZigBee SDK.

    I am not very comfortable to use nRFConnect SDK, and slowly migrating.

Children
No Data
Related