Re: Odd l2cap_sock.c Code?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux