8000 Making the UHK unpair hosts · Issue #1160 · UltimateHackingKeyboard/firmware · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Making the UHK unpair hosts #1160

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
mondalaci opened this issue Mar 5, 2025 · 5 comments
Open

Making the UHK unpair hosts #1160

mondalaci opened this issue Mar 5, 2025 · 5 comments

Comments

@mondalaci
Copy link
Member

I paired my UHK 80 on Windows 11, then I deleted device pairings on the UHK in Agent.

Afterward, Windows tried aggressively connecting to my UHK. I saw the following twice per second:

Starting advertising, try 0!
Adv: HID "and NUS" advertising successfully started
connected unknown (a8:41:f4:11:a4:08), 3 3
Bt security failed: unknown (a8:41:f4:11:a4:08), level 1, err 2, disconnecting
Bt disconnected from unknown (a8:41:f4:11:a4:08), reason 19

If the key doesn't exist on the UHK, I think the best solution is to make the UHK tell the host to unpair. According to Claude, the following options may work:

  1. SMP Pairing Failed Command: While typically used during the pairing process, it can also be sent during reconnection attempts to signal that the previous bonding should be discarded.
  2. Forced Disconnect with specific reason codes: Certain disconnect reason codes signal to the host that it should not only disconnect but also potentially remove the bonding information.
  3. Delete Bond Information Command: Some BLE stacks also support explicit commands to request deletion of bonding information on the host side.

Full Claude conversation

@benedekkupper Can you provide insight regarding the best solution that should work cross-platform?

@kareltucek Questions:

  1. connected unknown (a8:41:f4:11:a4:08) is featured in the log, yet, in Agent, the 8:a4:11:f4:41:a8 Windows laptop host connection exists. Why is "unknown" displayed instead of "Windows laptop" in the log? We should display the host name whenever available.
  2. Why do you think Agent displays the address in reverse? Is it stored as such, and Robi should reverse it?
@mondalaci
Copy link
Member Author

When unpairing my UHK 80 on Windows 11, Zephyr crashed:

Starting advertising, try 0!
Adv: HID "and NUS" advertising successfully started
connected unknown (a8:41:f4:11:a4:08), 3 3
Supplied connection (0) doesn't correspond to a host connection!
Bt security failed: unknown (a8:41:f4:11:a4:08), level 1, err 2, disconnecting
Bt disconnected from unknown (a8:41:f4:11:a4:08), reason 19
Starting advertising, try 0!
Adv: HID "and NUS" advertising successfully started
connected unknown (a8:41:f4:11:a4:08), 3 3
Supplied connection (0) doesn't correspond to a host connection!
Received passkey pairing inquiry.
Type `uhk passkey xxxxxx` to pair, or `uhk passkey -1` to reject
unknown (a8:41:f4:11:a4:08) conn params: interval=15 ms, latency=0, timeout=9600 ms
unknown (a8:41:f4:11:a4:08) conn params: interval=7 ms, latency=0, timeout=1000 ms
Bt security failed: unknown (a8:41:f4:11:a4:08), level 1, err 9, disconnecting
W: The in-progress pairing has been deleted!
Bt security failed: unknown (a8:41:f4:11:a4:08), level 1, err 9, disconnecting
Pairing of auth conn failed because of 9
Pairing failed: unknown (a8:41:f4:11:a4:08), reason 9
Bt disconnected from unknown (a8:41:f4:11:a4:08), reason 19
W: conn 0x2000bdd0: not connected
ASSERTION FAIL @ WEST_TOPDIR/zephyr/subsys/bluetooth/host/l2cap.c:700
E: r0/a1:  0x00000004  r1/a2:  0x000002bc  r2/a3:  0x20000000
E: r3/a4:  0x00000004 r12/ip:  0x00000000 r14/lr:  0x0003a2b9
E:  xpsr:  0x01000000
E: r4/v1:  0x00003a09  r5/v2:  0x2000d5f8  r6/v3:  0xffffffff
E: r7/v4:  0x20011850  r8/v5:  0x20031418  r9/v6:  0x00070af1
E: r10/v7: 0x00000000  r11/v8: 0x00000000    psp:  0x200313c8
E: EXC_RETURN: 0x0
E: Faulting instruction address (r15/pc): 0x0006e3fa
E: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
E: Current thread: 0x2000d5f8 (sysworkq)

@kareltucek
Copy link
Collaborator
kareltucek commented Mar 6, 2025 •
edited
Loading

connected unknown (a8:41:f4:11:a4:08) is featured in the log, yet, in Agent, the 8:a4:11:f4:41:a8 Windows laptop host connection exists. Why is "unknown" displayed instead of "Windows laptop" in the log? We should display the host name whenever available.

Well, you say you have deleted the pairing, so the name is no longer available in the Host Connections section of the UserConfig, so obviously it is shown as unknown.

In other scenarios this can happen even when the device is still paired. Ble hid devices use different addresses for secured and unsecured connections, meaning that a connection address often changes midway through the connection initiation seuqence. For this reason, we match ble connections against HostConnections only very late in the initiation sequence.

Why do you think Agent displays the address in reverse? Is it stored as such, and Robi should reverse it?

Well, zephyr stores them that way in its settings too. I.e., reverse to what they are stored in RAM as raw addresses.

So yes, I guess Robi should reverse it.

@kareltucek
Copy link
Collaborator
  1. Forced Disconnect with specific reason codes: Certain disconnect reason codes signal to the host that it should not only disconnect but also potentially remove the bonding information.

Well, we have been using this all along.

        bt_conn_disconnect(conn, BT_HCI_ERR_REMOTE_USER_TERM_CONN);

Not sure if that is different from sd_ble_gap_disconnect(BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);.

@mondalaci
Copy link
Member Author

Well, you say you have deleted the pairing, so the name is no longer available in the Host Connections section of the UserConfig, so obviously it is shown as unknown.

The name is still available because the "delete device pairings" button doesn't remove host connections, only keys. The firmware should always use host connection names in the log.

Created UltimateHackingKeyboard/agent#2562

@kareltucek
Copy link
Collaborator

Ah, I see.

Logging uses the peer id of the connection.

  • partly because otherwise we would have to go through all host connections and compare all the addresses, which is costly
  • partly because when rewriting the code, I preferred to log them according to how they are recognized and assigned

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@mondalaci @kareltucek
0