Agent fails to detect bootloader-mode device during UHK 80 firmware flash on Linux (mcuboot/mcumgr path)

[Kyle-D-616]

I have not been able to flash to the new firm where/ agent since 8.0

I cant seam to see new bluetooth connections at this point so id like to get on the new firm.

full disclosure i used AI to trouble shoot and create bug report.

errors have been consistent

Agent fails to detect bootloader-mode device during UHK 80 firmware flash on Linux (mcuboot/mcumgr path)

Environment

• Agent version: 10.1.0 (Linux AppImage)
• OS: Arch Linux, kernel 7.1.7-arch1-1, x86_64
• Device: UHK 80, right half
• Current firmware: 17.2.0 (checksum a34f7a1922f4ea594dd16afac57b7f23)
• Target firmware: checksum 60377aeadc5fb8815761f8897f0d2459
• Flashing method: mcuboot / mcumgr (as reported by Agent: "firmwareUpgradeMethod":"mcuboot")

Summary

Firmware flashing consistently fails with Could not reenumerate as Bootloader. The keyboard does correctly enter bootloader mode at the USB/kernel level (confirmed via dmesg), but Agent's own device-watcher never detects the bootloader-mode device — it only ever reports the normal-mode device (productId 0x9) appearing and disappearing, never productId 0x8 ("UHK 80 right half bootloader"). This looks like a bug in Agent's HID device enumeration/matching logic for this flashing path, not a system permissions or environment issue.

Steps to reproduce

1. Launch UHK Agent 10.1.0 on Arch Linux with the right half connected via USB.
2. Start a firmware update (17.2.0 detected as available).
3. Observe the flash process fail after repeated "Could not find reenumerated device: Bootloader. Waiting..." messages, ending in a timeout.

Expected behavior

Agent detects the bootloader-mode device shortly after triggering reenumeration and proceeds to flash firmware via mcumgr.

Actual behavior

Agent times out waiting for the bootloader device and the flash fails every time, with the keyboard falling back to its currently-installed firmware.

Key evidence

dmesg output during a flash attempt shows the device genuinely entering bootloader mode at the kernel/USB level:

[  226.797923] usb 5-2.4.2: new full-speed USB device number 14 using xhci_hcd
[  226.922750] usb 5-2.4.2: New USB device found, idVendor=37a8, idProduct=0008, bcdDevice= 3.07
[  226.922757] usb 5-2.4.2: Product: UHK 80 right half bootloader
[  226.922759] usb 5-2.4.2: Manufacturer: Ultimate Gadget Laboratories
[  226.922761] usb 5-2.4.2: SerialNumber: 581FFC06C30AF672
[  232.965605] usb 5-2.4.2: USB disconnect, device number 14
[  234.182068] usb 5-2.4.2: new full-speed USB device number 15 using xhci_hcd
[  234.311769] usb 5-2.4.2: New USB device found, idVendor=37a8, idProduct=0009, bcdDevice= 0.01
[  234.311777] usb 5-2.4.2: Product: UHK 80 Right USB

This pattern (bootloader device 0008 appearing, then disconnecting and re-enumerating back to normal-mode 0009) repeats multiple times over the course of a single flash attempt.

Agent's own log for the same window never reports the bootloader device at all — every single Added/Removed device event shows productId 0x9 (normal mode):

Start flashing firmware
...
[UhkOperations] Reenumerate bootloader
[UhkHidDevice] Device communication closing.
[UhkHidDevice] Device communication closed.
[UhkHidDevice] Start reenumeration, mode: Bootloader, timeout: 5000ms
[UhkHidDevice] Available devices unchanged
[UhkHidDevice] Reenumeration error. We hope it would not break the process Error: Cannot write to hid device
    at HIDAsync.<computed> [as write] (.../node_modules/node-hid/nodehid.js:165:54)
    at go.reenumerate (.../electron-main.js:2:707759)
    at async nr.updateFirmwareWithMcuManager (.../electron-main.js:2:738893)
[UhkHidDevice] closing normal keyboard after reenumeration
[UhkHidDevice] Available devices changed.
[UhkHidDevice] Removed: {"vendorId":"0x37A8","productId":"0x9", ...}
[UhkHidDevice] Could not find reenumerated device: Bootloader. Waiting...
[UhkHidDevice] Available devices changed.
[UhkHidDevice] Added: {"vendorId":"0x37A8","productId":"0x9", ...}
... (repeats for ~30+ cycles, always productId 0x9, never 0x8) ...
[UhkHidDevice] Could not find reenumerated device: Bootloader. Timeout
[DeviceService] updateFirmware error {"message":"Could not reenumerate as Bootloader", ...}

The very first error in the sequence — Error: Cannot write to hid device at HIDAsync.write, thrown from within go.reenumerate — occurs when Agent attempts to write the "reboot into bootloader" command to the still-normal-mode device, before the device has switched modes at all.

What's been ruled out

• udev permissions: confirmed /etc/udev/rules.d/50-uhk60.rules is installed and correctly matches vendor 37a8 with a wildcard product ID; confirmed via udevadm info that the currently-connected device carries TAGS=:seat:uaccess:, i.e. the ACL is being applied correctly.
• ModemManager: not installed on this system (systemctl stop ModemManager → "Unit not loaded").
• Stale/corrupted Agent config: reproduced after a full keyboard power-cycle and fresh Agent launch with ~/.config/uhk-agent confirmed owned by the normal user (not left root-owned from an earlier root-privilege test).
• Permissions as root: ran Agent via sudo ... --no-sandbox to eliminate permission timing entirely as a variable; same failure pattern in principle (testing was cut short by an unrelated Electron/root sandboxing crash — terminate called after throwing an instance of 'Napi::Error' — but the pre-flash device polling showed no different behavior as root than as a normal user).
• USB cable/port/hub flakiness: tested on more than one physical port; same pattern each time.

Hypothesis

Given the kernel-level bootloader device clearly exists (confirmed by dmesg) but Agent's HID device-watcher never reports it, the bug likely sits in Agent's node-hid-based device enumeration/polling for the mcuboot flashing path on Linux — either a polling interval that's too coarse to catch a transient bootloader-mode device, or a device-matching filter that isn't correctly recognizing productId 0x8 as the expected bootloader ID for this device profile (connectedDevice.bootloader: [{"vid":14248,"pid":8}], i.e. 0x37A8:0x0008 — which does match what dmesg shows, so the mismatch appears to be in the live enumeration/polling path rather than the static ID configuration).

Additional context

Agent's general connection-state polling (unrelated to flashing) also periodically produces Usb protocol command 4 failed with: 4, garbled field values (data from one field appearing in unrelated fields, e.g. git tag values in checksum fields), and an uncaught TypeError: Cannot read properties of undefined (reading 'slotId') in getHardwareModules/uhkDevicePoller. These may or may not be related to the flashing issue, but are included here in case they're symptomatic of the same underlying USB communication instability with this particular device/firmware combination.

[ert78gb]

Thank you for the very detailed report and sorry for the inconvenience.

The UHK80 bootloader exposed as serial port over USB.

I am missing some tty... entry from the dmesg.
Looks like missing kernel module: ftdi_sio, cp210x, ch341, pl2303, cdc_acm, option. Check lsmod, try modprobe. Custom/embedded kernels often omit USB_SERIAL_*.

You reported the issue earlier. Have you time to check the #2810 (comment) It helps to eliminate root permission if your user has the proper group.

We are preparing the new official release but until you could use the latest master version. https://github.com/UltimateHackingKeyboard/agent/actions/runs/31282142106 it fixes the 'Napi::Error'

[ert78gb]

If you could test with other OS via live CD/USB or virtual machine (VM) also could prove the error is OS or keyboard level.
The live CD solution is easier because the OS has direct access to the keyboard.

If you use VM then you have to passthrough the whole PCI channel to prevent the host OS grab the reenumerated device earlier than the VM picked up. And qemu shares only devices that available when the VM starts. It is very advanced option. the live CD/USB that I could recommend.

[Kyle-D-616]

Hey @ert78gb I appreciate your help. I was actually able to flash from a windows lap top! glad that worked but hopefully we can get it working on arch. Here are the updates I have

Once again, using AI

Update

Managed to get further by manually loading the cdc_acm kernel module before starting the flash:

sudo modprobe cdc_acm

lsmod | grep cdc_acm showed it wasn't loaded beforehand, and sudo dmesg | grep -iE "cdc_acm|ttyACM" was completely empty across a full flash attempt prior to loading it manually — no cdc_acm binding, no ttyACM device ever created.

Captured the bootloader device's USB descriptors during that state with lsusb -d 37a8:0008 -v. They're standard, well-formed CDC-ACM descriptors — Interface Association Descriptor, a Communications/Abstract-Modem control interface (interface 0) paired with a CDC Data interface (interface 1) with bulk in/out endpoints. Nothing unusual there.

After manually loading cdc_acm and retrying, Agent's log showed it successfully detecting the bootloader device this time:

[UhkHidDevice] Available devices changed.
[UhkHidDevice] Added: {"path":"/dev/ttyACM0","manufacturer":"Ultimate Gadget Laboratories","serialNumber":"581FFC06C30AF672","pnpId":"usb-Ultimate_Gadget_Laboratories_UHK_80_right_half_bootloader_581FFC06C30AF672-if00","vendorId":"0x37A8","productId":"0x0008"}

It then proceeded to the next steps but failed trying to actually open that path:

[UhkOperations] Init SerialPeripheral: /dev/ttyACM0
[UhkOperations] Read UHK 80 right firmware from file
[UhkOperations] Write memory with mcumgr
[DeviceService] updateFirmware error {"message":"Error: No such file or directory, cannot open /dev/ttyACM0","stack":"Error: Error: No such file or directory, cannot open /dev/ttyACM0"}

Separately, dmesg timestamps from earlier attempts (before loading cdc_acm manually) showed the bootloader-mode device (idProduct=0008) present for roughly 1 second before disconnecting and the keyboard re-enumerating back to normal firmware (idProduct=0009) — consistent with an mcuboot handshake timeout.

Also worth noting: I was able to successfully flash this same firmware update on a Windows machine with no issues, so this appears to be Linux/Arch-specific rather than a problem with the firmware image or the keyboard itself.

Environment recap:

• Arch Linux, kernel 7.1.8-arch1-3, x86_64
• Agent 10.1.0 (Linux AppImage)
• UHK 80, right half
• uucp group membership confirmed present
• /etc/udev/rules.d/50-uhk60.rules installed, uaccess tag confirmed applied via udevadm info
• ModemManager not installed on this system

[ert78gb]

hopefully we can get it working on arch.

Me too. Maybe we have to run few turn but we could solve it. So I would like to ask some patients and help from you.

The ~/.config/uhk-agent/uhk-agent.log file contains the log. It has exact timestamp. Please check how much second elapsed between the [UhkOperations] Init SerialPeripheral: /dev/ttyACM0 and [DeviceService] updateFirmware error {"message":"Error: No such file or directory, cannot open /dev/ttyACM0","stack":"Error: Error: No such file or directory, cannot open /dev/ttyACM0"}

The dmesg also contains timing information. I / we dont know why 1 only second bootloader timeout. It should 3-5 seconds in normal circumstances.

I created the https://github.com/UltimateHackingKeyboard/agent/pull/3052/changes PR that decrease the wait time after the reenumeration. You could download the build from
https://github.com/UltimateHackingKeyboard/agent/actions/runs/31786865586/job/94724615988?pr=3052

Same issue reported in #2948 and in this case the 100ms wait time solved the problem. I am afraid from this small value because when the OS first time initialise the device needed more time. I hope the 500ms will good choice