Odd l2cap_sock.c Code?

Odd l2cap_sock.c Code?

[Dylan Taft]

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/bluetooth/l2cap_sock.c

Per the bluetooth core spec
https://www.bluetooth.com/specifications/bluetooth-core-specification
Page 2184, section 3.4.2.1 Exchange MTU Request, PDUs may be sent to
negotiate MTU size upon connection

Line 415 in l2cap_sock.c, if address types being used are Bluetooth 2 types,
it looks like setsockopt(xx, SOL_L2CAP, L2CAP_OPTIONS, xx, xx) is
INTENDED to fail with EINVAL errno, but for Bluetooth 2.x connections
it would work fine.

Line 920 - setsockopt(xx,SOL_BLUETOOTH,BT_RCVMTU,xx,xx) looks to be
INTENDED to fail if a connection is already established on the socket

The legacy kernel code goes and sets imtu and omtu without any other code.

Per the bluetooth spec - inbound and outbound MTU should be set to the
minimum MTU between the devices during this ATT PDU handshake.

As it stands right now, it looks like the kernel would require
disconnecting\reconnecting the socket.

I bet it could be changed to mirror the old setsockopt SOL_L2CAP code,
so BT2 behaves like BT4+ - but it's not my code and I'm not a BT guru
so I'd hate to just submit a patch for it.

Is this all intentional?

It seems like both imtu and omtu should be allowed to be set in the
new code, like the legacy code.

Thanks!
Dylan

Re: Odd l2cap_sock.c Code?

[Dylan Taft]

Sorry, I went cross-eyed looking at setsockopt\getsockopt.  Both the
new code and old code do not allow it if the socket is connected, but
the Bluetooth spec does it looks.  Is the only option on receiving an
MTU REQ to drop the connection and re-open with a lower MTU?
It looks like this in an hcidump, what I am referring to.  That MTU is
lower than the default of 672.  The spec says not dealing with it
could lead to problems.  Could the MTU specifically be allowed to be
set on an open socket to no ill effect in the kernel?

< HCI Command: LE Create Connection (0x08|0x000d) plen 25
    bdaddr 00:0B:57:7F:72:BF type 0
    interval 96 window 96 initiator_filter 0
    own_bdaddr_type 0 min_interval 24 max_interval 40
    latency 0 supervision_to 42 min_ce 0 max_ce 0
> HCI Event: Command Status (0x0f) plen 4
    LE Create Connection (0x08|0x000d) status 0x00 ncmd 1
> HCI Event: LE Meta Event (0x3e) plen 19
    LE Connection Complete
      status 0x00 handle 74, role master
      bdaddr 00:0B:57:7F:72:BF (Public)
> ACL data: handle 74 flags 0x02 dlen 7
    ATT: MTU req (0x02)
      client rx mtu 247

Re: Odd l2cap_sock.c Code?

[Dylan Taft]

I think I was able to figure my own confusion out after browsing the
bluez userspace tools.  The kernel does not handle anything above the
L2CAP layer.  This is ATT and that negotiation is in user space,
nothing to do with sockopts!

Re: Odd l2cap_sock.c Code?

[Luiz Augusto von Dentz]

Hi Dylan,
On Mon, Nov 12, 2018 at 7:28 AM Dylan Taft <dylanetaft@gmail.com> wrote:
>
> I think I was able to figure my own confusion out after browsing the
> bluez userspace tools.  The kernel does not handle anything above the
> L2CAP layer.  This is ATT and that negotiation is in user space,
> nothing to do with sockopts!

Yep, there a procedure to set the ATT MTU called Exchange MTU, note
that when ATT is used over BR/EDR it does use the so L2CAP basic mode
so the MTU will be negotiated over L2CAP, Exchange MTU is not allowed
over BR/EDR.

-- 
Luiz Augusto von Dentz