RE: Trying to understand the Bytes of a message sent, during a connection.

Higo — Tue, 02 Jul 2024 22:07:24 GMT

Hi Amanda Hsieh, thanks for your information. I feel like I'm evolving

1.1)

I do not define the CONFIG_BT_CTLR_DATA_LENGTH_MAX macro in my tests.

So I believe it is the default for 27 Bytes.

But I was able to send 26 Bytes (uint8_t) from one Node to another Node, plus the two bytes of the OPCODE that you mentioned previously, a total of 28 Bytes.

Shouldn't I only be able to send 23 Bytes? which is the size of the MTU...

[00:00:10.793,060] <dbg> bt_mesh_transport_legacy: bt_mesh_trans_send: len 28: 82030001010101010101010101010101010101010101010101010101
[00:00:10.793,212] <dbg> bt_mesh_transport_legacy: send_seg: src 0x5bf0 dst 0xffff app_idx 0x0000 aszmic 1 sdu_len 36
[00:00:10.793,243] <dbg> bt_mesh_transport_legacy: send_seg: SeqZero 0x0000 (segs: 3)
[00:00:10.793,273] <dbg> bt_mesh_transport_legacy: send_seg: seg 0: ad9295f24dac37ad5ae5e4c5
[00:00:10.793,334] <dbg> bt_mesh_transport_legacy: send_seg: seg 1: 266e5bd5fce110ff95e0ce96
[00:00:10.793,395] <dbg> bt_mesh_transport_legacy: send_seg: seg 2: e84be52f3708cb620b7665b2

1.2)

I still have doubts whether in this case that I showed above, a Bluetooth package was sent or 3 packages were sent?

And if it was segmented into 3 packets and sent, how would these bytes of each packet be organized?

I tried setting the CONFIG_BT_CTLR_DATA_LENGTH_MAX macro in the prj.conf file to 251Bytes, as shown below

CONFIG_BT_CTLR_DATA_LENGTH_MAX=251

but nothing has changed.

I expected that I would be able to send more bytes per message.

I am studying the access.c and transport_legacy.c methods to understand how the code considers having successfully received a message or not.

I see that there are many LOG_ERR checks until finally printing the content.

Do you have any suggestions on how I can check whether the message arrived complete at the destination node or not?

main.c
bt_mesh_model_send() - access.c
LOG_ERR("Model not bound to AppKey 0x%04x", ctx->app_idx);
bt_mesh_access_send() - access.c
LOG_ERR("Local node is not yet provisioned");
bt_mesh_trans_send() - transport_legacy.c
LOG_ERR("Zero-length SDU not allowed");
LOG_ERR("Message too big: %u", msg->len);
  LOG_ERR("Insufficient tailroom for Transport MIC");
  LOG_ERR("TTL too large (max 127)");
  LOG_ERR("Invalid destination address");
    send_seg(tx, msg, cb, cb_data, NULL);
send_unseg(tx, msg, cb, cb_data, NULL);

bt_mesh_trans_recv() - transport_legacy.c
trans_seg() - transport_legacy.c
or
trans_unseg() - transport_legacy.c
sdu_recv() - transport_legacy.c
bt_mesh_model_recv() - access.c
element_model_recv - access.c
LOG_ERR("No OpCode 0x%08x for elem 0x%02x", opcode, elem->addr);
LOG_ERR("Wrong key");
LOG_ERR("Invalid address 0x%02x", ctx->recv_dst);
LOG_ERR("Too short message for OpCode 0x%08x", opcode);
LOG_ERR("Invalid message size for OpCode 0x%08x", opcode);

I would like to print all bytes of a message, including protocol header bytes,

and not just OPCODE and PAYLOAD.

Would you have a suggestion for this?

Thanks for the support

RE: Trying to understand the Bytes of a message sent, during a connection.

Amanda Hsieh — Mon, 01 Jul 2024 20:42:44 GMT

Hi,

[quote user=""]1.1) Are these 2 Bytes that I mentioned previously the header? What would they be headers? Is it the PDU header? Should the MIC bytes not appear?[/quote]

The two extra bytes seem likely the opcode of the message. In Bluetooth Mesh, each message is associated with an opcode that identifies the type of the message. Here, you're using OP_ONOFF_SET_UNACK as the opcode. This opcode is added to the message when you call bt_mesh_model_msg_init().

When you receive the message, the opcode is extracted from the message by the Mesh stack before it's passed to your application, so you only see the payload of the message, not the opcode or the MIC (Message Integrity Check).

[quote user=""]1.2) What would this Payload be?
[00:00:28.784,820] <dbg> bt_mesh_transport_legacy: bt_mesh_trans_recv: Payload 7883531e2dcf6c5067[/quote]

The received data. See this line.

[quote user=""]2) Is there any method I can use to know if the "data length" is set to 27 bytes or 251 bytes?[/quote]

You can check the CONFIG_BT_CTLR_DATA_LENGTH_MAX value in the .config under build/zephyr

[quote user=""]3.1) Does this log mean that the message was broken into 2 parts?[/quote]

Yes, as the log indicated seg 0 and seg 1:

[00:04:28.040,252] <dbg> bt_mesh_transport_legacy: send_seg: SeqZero 0x0028 (segs: 2)
[00:04:28.040,283] <dbg> bt_mesh_transport_legacy: send_seg: seg 0: 87df25f0ff7f237ea4c8770e
[00:04:28.040,344] <dbg> bt_mesh_transport_legacy: send_seg: seg 1: 9ac0f04d47e48947

[quote user=""]3.2) Does this log mean that the first part is being sent?
[00:04:28.040,405] <dbg> bt_mesh_transport_legacy: seg_tx_send_unacked: Sending 0/1[/quote]

Correct.

[quote user=""]3.3) what content is this?
[00:04:28.040,283] <dbg> bt_mesh_transport_legacy: send_seg: seg 0: 87df25f0ff7f237ea4c8770e
[00:04:28.040,344] <dbg> bt_mesh_transport_legacy: send_seg: seg 1: 9ac0f04d47e48947[/quote]

The content in these logs is the encrypted payload of each segment of the message. In Bluetooth Mesh, each message is encrypted before it's sent over the air. The content you're seeing is the result of this encryption. When you receive the message, the Mesh stack decrypts the payload before it's passed to your application, so you see the original, unencrypted payload.

[quote user=""]3.4) What would this account be? result 20
[00:04:28.105,285] <dbg> bt_mesh_transport_legacy: trans_seg: Target len 1 * 12 + 8 = 20[/quote]

Set the expected final buffer length. See this line.

Regards,
Amanda H.