1. 08 Jul, 2019 20 commits
  2. 07 Jul, 2019 8 commits
  3. 06 Jul, 2019 12 commits
    • David S. Miller's avatar
      Merge tag 'wireless-drivers-next-for-davem-2019-07-06' of... · 437fde6c
      David S. Miller authored
      Merge tag 'wireless-drivers-next-for-davem-2019-07-06' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
      
      Kalle Valo says:
      
      ====================
      wireless-drivers-next patches for 5.3
      
      Second, and last, set of patches for 5.3.
      
      Major changes:
      
      mt76
      
      * use NAPI polling for tx cleanup on mt7603/mt7615
      
      * add support for toggling edcca on mt7603
      
      * fix rate control / tx status reporting issues on mt76x02/mt7603
      
      * add support for eeprom calibration data from mtd on mt7615
      
      * support configuring tx power on mt7615
      
      * per-chain signal reporting on mt7615
      
      iwlwifi
      
      * Update the FW API for Channel State Information (CSI)
      
      * Special Specific Absorption Rate (SAR) implementation for South Korea
      
      ath10k
      
      * fixes for SDIO support
      
      * add support for firmware logging via WMI
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      437fde6c
    • Sean Wang's avatar
      Bluetooth: btusb: Add protocol support for MediaTek MT7663U USB devices · 9ce67c32
      Sean Wang authored
      This adds the support of enabling MT7663U Bluetooth function running
      on the top of btusb driver.
      
      The information in /sys/kernel/debug/usb/devices about the Bluetooth
      device is listed as the below.
      
      T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  5 Spd=5000 MxCh= 0
      D:  Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs=  1
      P:  Vendor=0e8d ProdID=7663 Rev= 1.00
      S:  Manufacturer=MediaTek Inc.
      S:  Product=Wireless_Device
      S:  SerialNumber=000000000
      C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=160mA
      A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=125us
      E:  Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
      Signed-off-by: default avatarSean Wang <sean.wang@mediatek.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      9ce67c32
    • Sean Wang's avatar
      Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB devices · a1c49c43
      Sean Wang authored
      This adds the support of enabling MT7668U Bluetooth function running
      on the top of btusb driver.
      
      The information in /sys/kernel/debug/usb/devices about the Bluetooth
      device is listed as the below.
      
      T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=5000 MxCh= 0
      D:  Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs=  1
      P:  Vendor=0e8d ProdID=7668 Rev= 1.00
      S:  Manufacturer=MediaTek Inc.
      S:  Product=Wireless_Device
      S:  SerialNumber=000000000
      C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=160mA
      A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=125us
      E:  Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
      Signed-off-by: default avatarSean Wang <sean.wang@mediatek.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      a1c49c43
    • Josua Mayer's avatar
      Bluetooth: 6lowpan: always check destination address · 688d94fd
      Josua Mayer authored
      BLE based 6LoWPAN networks are highly constrained in bandwidth.
      Do not take a short-cut, always check if the destination address is
      known to belong to a peer.
      
      As a side-effect this also removes any behavioral differences between
      one, and two or more connected peers.
      Acked-by: default avatarJukka Rissanen <jukka.rissanen@linux.intel.com>
      Tested-by: default avatarMichael Scott <mike@foundries.io>
      Signed-off-by: default avatarJosua Mayer <josua.mayer@jm0.eu>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      688d94fd
    • Josua Mayer's avatar
      Bluetooth: 6lowpan: check neighbour table for SLAAC · 5636376c
      Josua Mayer authored
      Like any IPv6 capable device, 6LNs can have multiple addresses assigned
      using SLAAC and made known through neighbour advertisements.
      After checking the destination address against all peers link-local
      addresses, consult the neighbour cache for additional known addresses.
      
      RFC7668 defines the scope of Neighbor Advertisements in Section 3.2.3:
      1. "A Bluetooth LE 6LN MUST NOT register its link-local address"
      2. "A Bluetooth LE 6LN MUST register its non-link-local addresses with
      the 6LBR by sending Neighbor Solicitation (NS) messages ..."
      
      Due to these constranits both the link-local addresses tracked in the
      list of 6lowpan peers, and the neighbour cache have to be used when
      identifying the 6lowpan peer for a destination address.
      Acked-by: default avatarJukka Rissanen <jukka.rissanen@linux.intel.com>
      Tested-by: default avatarMichael Scott <mike@foundries.io>
      Signed-off-by: default avatarJosua Mayer <josua.mayer@jm0.eu>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      5636376c
    • Josua Mayer's avatar
      Bluetooth: 6lowpan: search for destination address in all peers · b188b032
      Josua Mayer authored
      Handle overlooked case where the target address is assigned to a peer
      and neither route nor gateway exist.
      
      For one peer, no checks are performed to see if it is meant to receive
      packets for a given address.
      
      As soon as there is a second peer however, checks are performed
      to deal with routes and gateways for handling complex setups with
      multiple hops to a target address.
      This logic assumed that no route and no gateway imply that the
      destination address can not be reached, which is false in case of a
      direct peer.
      Acked-by: default avatarJukka Rissanen <jukka.rissanen@linux.intel.com>
      Tested-by: default avatarMichael Scott <mike@foundries.io>
      Signed-off-by: default avatarJosua Mayer <josua.mayer@jm0.eu>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      b188b032
    • Szymon Janc's avatar
      Bluetooth: Add SMP workaround Microsoft Surface Precision Mouse bug · 1d87b88b
      Szymon Janc authored
      Microsoft Surface Precision Mouse provides bogus identity address when
      pairing. It connects with Static Random address but provides Public
      Address in SMP Identity Address Information PDU. Address has same
      value but type is different. Workaround this by dropping IRK if ID
      address discrepancy is detected.
      
      > HCI Event: LE Meta Event (0x3e) plen 19
            LE Connection Complete (0x01)
              Status: Success (0x00)
              Handle: 75
              Role: Master (0x00)
              Peer address type: Random (0x01)
              Peer address: E0:52:33:93:3B:21 (Static)
              Connection interval: 50.00 msec (0x0028)
              Connection latency: 0 (0x0000)
              Supervision timeout: 420 msec (0x002a)
              Master clock accuracy: 0x00
      
      ....
      
      > ACL Data RX: Handle 75 flags 0x02 dlen 12
            SMP: Identity Address Information (0x09) len 7
              Address type: Public (0x00)
              Address: E0:52:33:93:3B:21
      Signed-off-by: default avatarSzymon Janc <szymon.janc@codecoup.pl>
      Tested-by: default avatarMaarten Fonville <maarten.fonville@gmail.com>
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199461
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      1d87b88b
    • Luiz Augusto von Dentz's avatar
      Bluetooth: L2CAP: Check bearer type on __l2cap_global_chan_by_addr · 00f62726
      Luiz Augusto von Dentz authored
      The spec defines PSM and LE_PSM as different domains so a listen on the
      same PSM is valid if the address type points to a different bearer.
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      00f62726
    • Luiz Augusto von Dentz's avatar
      Bluetooth: Use controller sets when available · 1d0fac2c
      Luiz Augusto von Dentz authored
      This makes use of controller sets when using Extended Advertising
      feature thus offloading the scheduling to the controller.
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      1d0fac2c
    • csonsino's avatar
      Bluetooth: validate BLE connection interval updates · c49a8682
      csonsino authored
      Problem: The Linux Bluetooth stack yields complete control over the BLE
      connection interval to the remote device.
      
      The Linux Bluetooth stack provides access to the BLE connection interval
      min and max values through /sys/kernel/debug/bluetooth/hci0/
      conn_min_interval and /sys/kernel/debug/bluetooth/hci0/conn_max_interval.
      These values are used for initial BLE connections, but the remote device
      has the ability to request a connection parameter update. In the event
      that the remote side requests to change the connection interval, the Linux
      kernel currently only validates that the desired value is within the
      acceptable range in the Bluetooth specification (6 - 3200, corresponding to
      7.5ms - 4000ms). There is currently no validation that the desired value
      requested by the remote device is within the min/max limits specified in
      the conn_min_interval/conn_max_interval configurations. This essentially
      leads to Linux yielding complete control over the connection interval to
      the remote device.
      
      The proposed patch adds a verification step to the connection parameter
      update mechanism, ensuring that the desired value is within the min/max
      bounds of the current connection. If the desired value is outside of the
      current connection min/max values, then the connection parameter update
      request is rejected and the negative response is returned to the remote
      device. Recall that the initial connection is established using the local
      conn_min_interval/conn_max_interval values, so this allows the Linux
      administrator to retain control over the BLE connection interval.
      
      The one downside that I see is that the current default Linux values for
      conn_min_interval and conn_max_interval typically correspond to 30ms and
      50ms respectively. If this change were accepted, then it is feasible that
      some devices would no longer be able to negotiate to their desired
      connection interval values. This might be remedied by setting the default
      Linux conn_min_interval and conn_max_interval values to the widest
      supported range (6 - 3200 / 7.5ms - 4000ms). This could lead to the same
      behavior as the current implementation, where the remote device could
      request to change the connection interval value to any value that is
      permitted by the Bluetooth specification, and Linux would accept the
      desired value.
      Signed-off-by: default avatarCarey Sonsino <csonsino@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      c49a8682
    • Spoorthi Ravishankar Koppad's avatar
      Bluetooth: Add support for LE ping feature · 302975cb
      Spoorthi Ravishankar Koppad authored
      Changes made to add HCI Write Authenticated Payload timeout
      command for LE Ping feature.
      
      As per the Core Specification 5.0 Volume 2 Part E Section 7.3.94,
      the following code changes implements
      HCI Write Authenticated Payload timeout command for LE Ping feature.
      Signed-off-by: default avatarSpoorthi Ravishankar Koppad <spoorthix.k@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      302975cb
    • Matias Karhumaa's avatar
      Bluetooth: Check state in l2cap_disconnect_rsp · 28261da8
      Matias Karhumaa authored
      Because of both sides doing L2CAP disconnection at the same time, it
      was possible to receive L2CAP Disconnection Response with CID that was
      already freed. That caused problems if CID was already reused and L2CAP
      Connection Request with same CID was sent out. Before this patch kernel
      deleted channel context regardless of the state of the channel.
      
      Example where leftover Disconnection Response (frame #402) causes local
      device to delete L2CAP channel which was not yet connected. This in
      turn confuses remote device's stack because same CID is re-used without
      properly disconnecting.
      
      Btmon capture before patch:
      ** snip **
      > ACL Data RX: Handle 43 flags 0x02 dlen 8                #394 [hci1] 10.748949
            Channel: 65 len 4 [PSM 3 mode 0] {chan 2}
            RFCOMM: Disconnect (DISC) (0x43)
               Address: 0x03 cr 1 dlci 0x00
               Control: 0x53 poll/final 1
               Length: 0
               FCS: 0xfd
      < ACL Data TX: Handle 43 flags 0x00 dlen 8                #395 [hci1] 10.749062
            Channel: 65 len 4 [PSM 3 mode 0] {chan 2}
            RFCOMM: Unnumbered Ack (UA) (0x63)
               Address: 0x03 cr 1 dlci 0x00
               Control: 0x73 poll/final 1
               Length: 0
               FCS: 0xd7
      < ACL Data TX: Handle 43 flags 0x00 dlen 12               #396 [hci1] 10.749073
            L2CAP: Disconnection Request (0x06) ident 17 len 4
              Destination CID: 65
              Source CID: 65
      > HCI Event: Number of Completed Packets (0x13) plen 5    #397 [hci1] 10.752391
              Num handles: 1
              Handle: 43
              Count: 1
      > HCI Event: Number of Completed Packets (0x13) plen 5    #398 [hci1] 10.753394
              Num handles: 1
              Handle: 43
              Count: 1
      > ACL Data RX: Handle 43 flags 0x02 dlen 12               #399 [hci1] 10.756499
            L2CAP: Disconnection Request (0x06) ident 26 len 4
              Destination CID: 65
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 12               #400 [hci1] 10.756548
            L2CAP: Disconnection Response (0x07) ident 26 len 4
              Destination CID: 65
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 12               #401 [hci1] 10.757459
            L2CAP: Connection Request (0x02) ident 18 len 4
              PSM: 1 (0x0001)
              Source CID: 65
      > ACL Data RX: Handle 43 flags 0x02 dlen 12               #402 [hci1] 10.759148
            L2CAP: Disconnection Response (0x07) ident 17 len 4
              Destination CID: 65
              Source CID: 65
      = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o..   10.759447
      > HCI Event: Number of Completed Packets (0x13) plen 5    #403 [hci1] 10.759386
              Num handles: 1
              Handle: 43
              Count: 1
      > ACL Data RX: Handle 43 flags 0x02 dlen 12               #404 [hci1] 10.760397
            L2CAP: Connection Request (0x02) ident 27 len 4
              PSM: 3 (0x0003)
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 16               #405 [hci1] 10.760441
            L2CAP: Connection Response (0x03) ident 27 len 8
              Destination CID: 65
              Source CID: 65
              Result: Connection successful (0x0000)
              Status: No further information available (0x0000)
      < ACL Data TX: Handle 43 flags 0x00 dlen 27               #406 [hci1] 10.760449
            L2CAP: Configure Request (0x04) ident 19 len 19
              Destination CID: 65
              Flags: 0x0000
              Option: Maximum Transmission Unit (0x01) [mandatory]
                MTU: 1013
              Option: Retransmission and Flow Control (0x04) [mandatory]
                Mode: Basic (0x00)
                TX window size: 0
                Max transmit: 0
                Retransmission timeout: 0
                Monitor timeout: 0
                Maximum PDU size: 0
      > HCI Event: Number of Completed Packets (0x13) plen 5    #407 [hci1] 10.761399
              Num handles: 1
              Handle: 43
              Count: 1
      > ACL Data RX: Handle 43 flags 0x02 dlen 16               #408 [hci1] 10.762942
            L2CAP: Connection Response (0x03) ident 18 len 8
              Destination CID: 66
              Source CID: 65
              Result: Connection successful (0x0000)
              Status: No further information available (0x0000)
      *snip*
      
      Similar case after the patch:
      *snip*
      > ACL Data RX: Handle 43 flags 0x02 dlen 8            #22702 [hci0] 1664.411056
            Channel: 65 len 4 [PSM 3 mode 0] {chan 3}
            RFCOMM: Disconnect (DISC) (0x43)
               Address: 0x03 cr 1 dlci 0x00
               Control: 0x53 poll/final 1
               Length: 0
               FCS: 0xfd
      < ACL Data TX: Handle 43 flags 0x00 dlen 8            #22703 [hci0] 1664.411136
            Channel: 65 len 4 [PSM 3 mode 0] {chan 3}
            RFCOMM: Unnumbered Ack (UA) (0x63)
               Address: 0x03 cr 1 dlci 0x00
               Control: 0x73 poll/final 1
               Length: 0
               FCS: 0xd7
      < ACL Data TX: Handle 43 flags 0x00 dlen 12           #22704 [hci0] 1664.411143
            L2CAP: Disconnection Request (0x06) ident 11 len 4
              Destination CID: 65
              Source CID: 65
      > HCI Event: Number of Completed Pac.. (0x13) plen 5  #22705 [hci0] 1664.414009
              Num handles: 1
              Handle: 43
              Count: 1
      > HCI Event: Number of Completed Pac.. (0x13) plen 5  #22706 [hci0] 1664.415007
              Num handles: 1
              Handle: 43
              Count: 1
      > ACL Data RX: Handle 43 flags 0x02 dlen 12           #22707 [hci0] 1664.418674
            L2CAP: Disconnection Request (0x06) ident 17 len 4
              Destination CID: 65
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 12           #22708 [hci0] 1664.418762
            L2CAP: Disconnection Response (0x07) ident 17 len 4
              Destination CID: 65
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 12           #22709 [hci0] 1664.421073
            L2CAP: Connection Request (0x02) ident 12 len 4
              PSM: 1 (0x0001)
              Source CID: 65
      > ACL Data RX: Handle 43 flags 0x02 dlen 12           #22710 [hci0] 1664.421371
            L2CAP: Disconnection Response (0x07) ident 11 len 4
              Destination CID: 65
              Source CID: 65
      > HCI Event: Number of Completed Pac.. (0x13) plen 5  #22711 [hci0] 1664.424082
              Num handles: 1
              Handle: 43
              Count: 1
      > HCI Event: Number of Completed Pac.. (0x13) plen 5  #22712 [hci0] 1664.425040
              Num handles: 1
              Handle: 43
              Count: 1
      > ACL Data RX: Handle 43 flags 0x02 dlen 12           #22713 [hci0] 1664.426103
            L2CAP: Connection Request (0x02) ident 18 len 4
              PSM: 3 (0x0003)
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 16           #22714 [hci0] 1664.426186
            L2CAP: Connection Response (0x03) ident 18 len 8
              Destination CID: 66
              Source CID: 65
              Result: Connection successful (0x0000)
              Status: No further information available (0x0000)
      < ACL Data TX: Handle 43 flags 0x00 dlen 27           #22715 [hci0] 1664.426196
            L2CAP: Configure Request (0x04) ident 13 len 19
              Destination CID: 65
              Flags: 0x0000
              Option: Maximum Transmission Unit (0x01) [mandatory]
                MTU: 1013
              Option: Retransmission and Flow Control (0x04) [mandatory]
                Mode: Basic (0x00)
                TX window size: 0
                Max transmit: 0
                Retransmission timeout: 0
                Monitor timeout: 0
                Maximum PDU size: 0
      > ACL Data RX: Handle 43 flags 0x02 dlen 16           #22716 [hci0] 1664.428804
            L2CAP: Connection Response (0x03) ident 12 len 8
              Destination CID: 66
              Source CID: 65
              Result: Connection successful (0x0000)
              Status: No further information available (0x0000)
      *snip*
      
      Fix is to check that channel is in state BT_DISCONN before deleting the
      channel.
      
      This bug was found while fuzzing Bluez's OBEX implementation using
      Synopsys Defensics.
      Reported-by: default avatarMatti Kamunen <matti.kamunen@synopsys.com>
      Reported-by: default avatarAri Timonen <ari.timonen@synopsys.com>
      Signed-off-by: default avatarMatias Karhumaa <matias.karhumaa@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      28261da8