The current state of BT-LE?

S

Swithun

Sorry if this isn't the correct place for such a question.

I am wondering what the current state of Bluetooth Low Energy is. IIRC there was some talk about improving this and WiFi. I could be mistaken. I did find this repo: https://github.com/takawata/FreeBSD-BLE (not yet tried). While doing some DDG searches "FreeBSD Bluetooth LE" I haven't found a whole load of information about the current state of things related to BTLE.

My specific hardware-related issue is a Logitech MX Master and connecting via BT.
 
Hey,
did you ever solve the issue with the MX Master?

I'm currently also struggling with this, but with the MX Master 3s (Mac). I tried the code https://github.com/rhaberkorn/FreeBSD-BLE (newer Fork) and the mouse shows up after executing
le_enable

also executing the hccontrol commands directly shows the device:

Code: 
hccontrol le_enable enable
hccontrol le_set_scan_enable enable
hccontrol read_neighbor_cache
hccontrol le_set_scan_enable disable

But when i try to pair then i receive a HCI_RECV: Operation timed out error (xxxxxx shows the real BTADDR, but i removed it for posting here)

Code: 
./hid-pair.sh MX Master

LE enabled
LE Scan: Enabled
Connecting to Bluetooth address xxxxxx...
LE Scan: Disabled
connect: Operation now in progress
HCI_RECV: Operation timed out
HCI_RECV: Operation timed out
HCI_RECV: Operation timed out
 
I am currently trying around some stuff. I'll keep posting my attempts and results in this thread. Maybe someone finds this and has some good suggestions, or, if am successful in finding the culprit, this thread can help anybody else out there with the same problem
 
The pairing itself seems to work, but it seems that there are issues with the information exchange between the mouse and the BT dongle (ASUS BT-500)
I dumped the pairing process with
hcidump -x -w <file> to a file and opened the dump in wireshark

The pairing process is running, crypto is set up etc. But then, when the ATT_READ_BY_GROUP_TYPE_REQ PDU is issued, i think the fun begins:

Code: 
Frame 79: 16 bytes on wire (128 bits), 16 bytes captured (128 bits)
    Encapsulation type: Bluetooth H4 with linux header (99)
    Arrival Time: Feb 18, 2025 17:47:03.295977000 CET
    UTC Arrival Time: Feb 18, 2025 16:47:03.295977000 UTC
    Epoch Arrival Time: 1739897223.295977000
    [Time shift for this packet: 0.000000000 seconds]
    [Time delta from previous captured frame: 0.017431000 seconds]
    [Time delta from previous displayed frame: 0.017431000 seconds]
    [Time since reference or first frame: 14.876260000 seconds]
    Frame Number: 79
    Frame Length: 16 bytes (128 bits)
    Capture Length: 16 bytes (128 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    Point-to-Point Direction: Received (1)
    [Protocols in frame: bluetooth:hci_h4:bthci_acl:btl2cap:btatt]
Bluetooth
    [Source: xxxx (xxxx)]
    [Destination: 00:00:00_00:00:00 (00:00:00:00:00:00)]
Bluetooth HCI H4
    [Direction: Rcvd (0x01)]
    HCI Packet Type: ACL Data (0x02)
Bluetooth HCI ACL Packet
    .... 0000 0001 0000 = Connection Handle: 0x010
    ..10 .... .... .... = PB Flag: First Automatically Flushable Packet (2)
    00.. .... .... .... = BC Flag: Point-To-Point (0)
    Data Total Length: 11
    Data
    [Connect in frame: 74]
    [Source BD_ADDR: xxx (xxxx)]
    [Source Device Name: MX Master]
    [Source Role: Unknown (0)]
    [Destination BD_ADDR: 00:00:00_00:00:00 (00:00:00:00:00:00)]
    [Destination Device Name: ]
    [Destination Role: Unknown (0)]
    [Current Mode: Unknown (-1)]
Bluetooth L2CAP Protocol
    Length: 7
    CID: Attribute Protocol (0x0004)
Bluetooth Attribute Protocol
    Opcode: Read By Group Type Request (0x10)
        0... .... = Authentication Signature: False
        .0.. .... = Command: False
        ..01 0000 = Method: Read By Group Type Request (0x10)
    Starting Handle: 0x0001
    Ending Handle: 0xffff
    UUID: Primary Service (0x2800)

According to the Bluetooth Corespec (Page 1498) the ATT_READ_BY_GROUP_TYPE_REQ PDU should set it's UUID to "Primary Service", "Starting Handle: 0x0001" and "End Handle: 0xffff". This is what happens in the request above. But, according to the Spec, the Server (in this case the mouse) should return either "ATT_READ_BY_GROUP_TYPE_RSP" or "ATT_-ERROR_RSP PDU". But i can not find either of this responses in the dump.

The Spec also mentions that:

The ATT_READ_BY_GROUP_TYPE_-
REQ PDU shall be issued again with the Starting Handle set to one greater
than the last End Group Handle in the ATT_READ_BY_GROUP_TYPE_RSP
PDU.
This sub-procedure is complete when the ATT_ERROR_RSP PDU is received
and the Error Code parameter is set to Attribute Not Found (0x0A) or when the
End Group Handle in the Read by Type Group Response is 0xFFFF.
Click to expand...

According to the dump, the ATT_READ_BY_GROUP_TYPE_REQ PDU is issued again, but not with the incremented handles, but the same values for "Starting Handle" and "Ending Handle", which leads me to the idea, that it is issued again, because no response has been received

Going on, the client invokes a ATT_FIND_INFORMATION_REQ:

Code: 
Frame 78: 14 bytes on wire (112 bits), 14 bytes captured (112 bits)
    Encapsulation type: Bluetooth H4 with linux header (99)
    Arrival Time: Feb 18, 2025 17:47:03.278546000 CET
    UTC Arrival Time: Feb 18, 2025 16:47:03.278546000 UTC
    Epoch Arrival Time: 1739897223.278546000
    [Time shift for this packet: 0.000000000 seconds]
    [Time delta from previous captured frame: 0.000701000 seconds]
    [Time delta from previous displayed frame: 8.381085000 seconds]
    [Time since reference or first frame: 14.858829000 seconds]
    Frame Number: 78
    Frame Length: 14 bytes (112 bits)
    Capture Length: 14 bytes (112 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    Point-to-Point Direction: Sent (0)
    [Protocols in frame: bluetooth:hci_h4:bthci_acl:btl2cap:btatt]
Bluetooth
    [Source: 00:00:00_00:00:00 (00:00:00:00:00:00)]
    [Destination: xxx (xxx)]
Bluetooth HCI H4
    [Direction: Sent (0x00)]
    HCI Packet Type: ACL Data (0x02)
Bluetooth HCI ACL Packet
    .... 0000 0001 0000 = Connection Handle: 0x010
    ..00 .... .... .... = PB Flag: First Non-automatically Flushable Packet (0)
    00.. .... .... .... = BC Flag: Point-To-Point (0)
    Data Total Length: 9
    Data
    [Connect in frame: 74]
    [Source BD_ADDR: 00:00:00_00:00:00 (00:00:00:00:00:00)]
    [Source Device Name: ]
    [Source Role: Unknown (0)]
    [Destination BD_ADDR: xxx (xxx)]
    [Destination Device Name: MX Master]
    [Destination Role: Unknown (0)]
    [Current Mode: Unknown (-1)]
Bluetooth L2CAP Protocol
    Length: 5
    CID: Attribute Protocol (0x0004)
Bluetooth Attribute Protocol
    Opcode: Find Information Request (0x04)
        0... .... = Authentication Signature: False
        .0.. .... = Command: False
        ..00 0100 = Method: Find Information Request (0x04)
    Starting Handle: 0x0001
    Ending Handle: 0xffff

According to specification on Page 1505 the request should contain:


The ATT_FIND_INFORMATION_REQ PDU shall be used with the Starting
Handle set to the handle of the specified characteristic value + 1 and the
Ending Handle set to the ending handle of the specified characteristic.
Click to expand...

But the values are again "0x0001" and "0xffff". Maybe, because there is no "ATT_READ_BY_GROUP_TYPE_RSP", the client has no idea what to query (and how to set "Starting Handle" and "End Handle")
 
You must log in or register to reply here.
Back
Top