Hi Thibaud,
On Thu, Jan 7, 2021 at 4:12 AM Thibaud Roussillat
<thibaud.roussillat@xxxxxxxxx> 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
