User data length when proto = binary

[traderlopez]

Maybe a little bug, and a question. Thanks in advance for your support.

I send binary data from server to device in the mesh. Header length is 16, total length 18.

When I use espconn_mesh_get_usr_data, reported user data length is 1 instead of 2. Returned pointer for data is pointing to 17th byte (&buffer[16]), which seems correct, but the length should be 2.

I want to know as well if this function is using any dynamic allocation to return the buffer for user data, or just positions the user data pointer where the user data starts.


This is an example of the information being sent towards a node in the mesh:

sending:
40 11 11 00 5c cf 7f c1 0b 64 c0 a8 00 64 58 1b 60 3e


Thanks very much.
Francisco Lopez.

[ESP_Alen]

Maybe a little bug, and a question. Thanks in advance for your support.

I send binary data from server to device in the mesh. Header length is 16, total length 18.

When I use espconn_mesh_get_usr_data, reported user data length is 1 instead of 2. Returned pointer for data is pointing to 17th byte (&buffer[16]), which seems correct, but the length should be 2.

I want to know as well if this function is using any dynamic allocation to return the buffer for user data, or just positions the user data pointer where the user data starts.


This is an example of the information being sent towards a node in the mesh:

sending:
40 11 11 00 5c cf 7f c1 0b 64 c0 a8 00 64 58 1b 60 3e


Thanks very much.
Francisco Lopez.

1. the total length in mesh packet header is 0x0011, so the data length is 1.
40 11 11 00 5c cf 7f c1 0b 64 c0 a8 00 64 58 1b 60 3e
2. the function just positions the user data pointer where the user data starts.

[traderlopez]

I'm not sure where I messed up the computation right now, I'll review it once again. It seems very obvious now that 0x11 - 0x10 (16) is 1, so the reported length is perfect.

Thanks very much for your support, Alen.

[ESP_Alen]

I'm not sure where I messed up the computation right now, I'll review it once again. It seems very obvious now that 0x11 - 0x10 (16) is 1, so the reported length is perfect.

Thanks very much for your support, Alen.

Welcome.