Notification data limited to 20 bytes with L2CAP sockets even if MTU is larger

Notification data limited to 20 bytes with L2CAP sockets even if MTU is larger

[Thibaud Roussillat]

Hi,

I'm new to Bluez. I tried some librairies but without succes.

I try to use bluez librairies to test binary transfer over BLE
(peripheral role played by an NRF52832, service Nordic UART). I also
tried some other librairies but without finding the good one so I came
to bluez.

To achieve my test, I modified btgatt-client.c to have the following behaviour :
* Connect to a device
* Send an hexadecimal code (0x00) on the TX characteristic (RX for the
NRF) to start transfer
* Received data through notification
* If received data begin with 0x01, write 0x01 to the TX
* If received data begin with 0x02, do nothing (stop transfer)

Even if MTU is more than 23 bytes, receveid data are troncated.

I tried to do the same thing using bluetoothctl who works with DBus
and the all data are received.

I played with gdb to identified the problem and this is the backtrace
display by bt:

#0  notify_cb (user_data=0x67558, length=20, value=0x67c5b "\001",
value_handle=15) at tools/btgatt-diego.c:1106
#1  notify_cb (value_handle=<optimized out>, value=0x67c5b "\001",
length=<optimized out>, user_data=0x67558) at
tools/btgatt-diego.c:1081
#2  0x0001ed50 in queue_foreach (queue=0x678f0, function=0x16bfc
<notify_handler>, user_data=user_data@entry=0xbefff190) at
src/shared/queue.c:206
#3  0x00019934 in notify_cb (chan=0x67570, chan@entry=0x67628,
opcode=opcode@entry=27 '\033', pdu=0x67c5b, pdu@entry=0x67c59,
length=20, length@entry=22, user_data=0x677e0)
    at src/shared/gatt-client.c:2191
#4  0x00016244 in handle_notify (pdu_len=23, pdu=<optimized out>,
chan=0x67628) at src/shared/att.c:959
#5  can_read_data (io=<optimized out>, user_data=0x67628) at
src/shared/att.c:1050
#6  0x0001dc8c in io_callback (fd=<optimized out>, events=<optimized
out>, user_data=0x675a0) at src/shared/io-mainloop.c:110
#7  0x0001e308 in mainloop_run () at src/shared/mainloop.c:106
#8  0x0001ea5c in mainloop_run_with_signal (func=func@entry=0x11ed0
<signal_cb>, user_data=user_data@entry=0x0) at
src/shared/mainloop-notify.c:188
#9  0x0001184c in main (argc=<optimized out>, argv=<optimized out>) at
tools/btgatt-diego.c:1746


In can_read_data function, bytes_read = read(chan->fd, chan->buf,
chan->mtu); return a value of 20 even if chan->mtu is larger.

I tried to reconfigure the socket as found on some thread by doing this :

        struct l2cap_options opts;
        int optlen = sizeof(opts), err;
        err = getsockopt( sock, SOL_L2CAP, L2CAP_OPTIONS, &opts, &optlen );
        if( ! err ) {
                opts.omtu = opts.imtu = 40;
                err = setsockopt( sock, SOL_L2CAP, L2CAP_OPTIONS,
&opts, optlen );
        }
        else {
                printf("=============> Unable to set socket opt");
        }

This hasn't effect on transfer.

I don't known if I don't understand something or if there is a bug...

Help is welcome.

(last chance is to communicate via DBus but not a lot of time to do this now)

Regards,
Thibaud

Re: Notification data limited to 20 bytes with L2CAP sockets even if MTU is larger

[Luiz Augusto von Dentz]

Hi Thibaud,

On Thu, Jan 7, 2021 at 4:12 AM Thibaud Roussillat
<thibaud.roussillat@gmail.com> wrote:
>
> Hi,
>
> I'm new to Bluez. I tried some librairies but without succes.
>
> I try to use bluez librairies to test binary transfer over BLE
> (peripheral role played by an NRF52832, service Nordic UART). I also
> tried some other librairies but without finding the good one so I came
> to bluez.
>
> To achieve my test, I modified btgatt-client.c to have the following behaviour :
> * Connect to a device
> * Send an hexadecimal code (0x00) on the TX characteristic (RX for the
> NRF) to start transfer
> * Received data through notification
> * If received data begin with 0x01, write 0x01 to the TX
> * If received data begin with 0x02, do nothing (stop transfer)
>
> Even if MTU is more than 23 bytes, receveid data are troncated.
>
> I tried to do the same thing using bluetoothctl who works with DBus
> and the all data are received.
>
> I played with gdb to identified the problem and this is the backtrace
> display by bt:
>
> #0  notify_cb (user_data=0x67558, length=20, value=0x67c5b "\001",
> value_handle=15) at tools/btgatt-diego.c:1106
> #1  notify_cb (value_handle=<optimized out>, value=0x67c5b "\001",
> length=<optimized out>, user_data=0x67558) at
> tools/btgatt-diego.c:1081
> #2  0x0001ed50 in queue_foreach (queue=0x678f0, function=0x16bfc
> <notify_handler>, user_data=user_data@entry=0xbefff190) at
> src/shared/queue.c:206
> #3  0x00019934 in notify_cb (chan=0x67570, chan@entry=0x67628,
> opcode=opcode@entry=27 '\033', pdu=0x67c5b, pdu@entry=0x67c59,
> length=20, length@entry=22, user_data=0x677e0)
>     at src/shared/gatt-client.c:2191
> #4  0x00016244 in handle_notify (pdu_len=23, pdu=<optimized out>,
> chan=0x67628) at src/shared/att.c:959
> #5  can_read_data (io=<optimized out>, user_data=0x67628) at
> src/shared/att.c:1050
> #6  0x0001dc8c in io_callback (fd=<optimized out>, events=<optimized
> out>, user_data=0x675a0) at src/shared/io-mainloop.c:110
> #7  0x0001e308 in mainloop_run () at src/shared/mainloop.c:106
> #8  0x0001ea5c in mainloop_run_with_signal (func=func@entry=0x11ed0
> <signal_cb>, user_data=user_data@entry=0x0) at
> src/shared/mainloop-notify.c:188
> #9  0x0001184c in main (argc=<optimized out>, argv=<optimized out>) at
> tools/btgatt-diego.c:1746
>
>
> In can_read_data function, bytes_read = read(chan->fd, chan->buf,
> chan->mtu); return a value of 20 even if chan->mtu is larger.

Have you completed an exchange MTU procedure?

> I tried to reconfigure the socket as found on some thread by doing this :
>
>         struct l2cap_options opts;
>         int optlen = sizeof(opts), err;
>         err = getsockopt( sock, SOL_L2CAP, L2CAP_OPTIONS, &opts, &optlen );
>         if( ! err ) {
>                 opts.omtu = opts.imtu = 40;
>                 err = setsockopt( sock, SOL_L2CAP, L2CAP_OPTIONS,
> &opts, optlen );
>         }
>         else {
>                 printf("=============> Unable to set socket opt");
>         }
>
> This hasn't effect on transfer.
>
> I don't known if I don't understand something or if there is a bug...
>
> Help is welcome.
>
> (last chance is to communicate via DBus but not a lot of time to do this now)

Actually D-Bus is the only officially supported/qualifiable solution
by BlueZ, Im not sure why you came to the conclusion you can just use
a library and not use the daemon.

-- 
Luiz Augusto von Dentz