[Bug]: USB passthrough (Windows host): device-initiated reset/re-enumeration is not propagated to the guest; captured device stalls all requests until usbdetach/usbattach

未關閉
  • 哪裡不對？
#922 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 6 天內回覆

還沒有人認領這個 Issue。

評估

難度
4/5
預估耗時
3-5 天
新手友好度
42/100
Issue 類型
缺陷
描述清晰度
基本清楚
活躍度
活躍
技術堆疊
c, linux
領域
desktop, operating-systems

研究方向

Start by tracing the Windows USB proxy and VBoxSVC device enumeration path described in the report; the issue does not name source files or tests. Compare how a physical unplug and replug reaches the VM with the same-path re-enumeration after the FT4222 reset. Done means the guest sees the captured device disconnect and return, and its requests work again without manually running usbdetach and usbattach.

由索引模型根據 Issue 內容生成。

描述

bug
Version

7.2.20

Host OS Type

Windows

Host OS name + version

Windows 11 Enterprise 10.0.26200 (x64), Hyper-V/VBS active (VirtualBox runs on Hyper-V/NEM)

Host Architecture

x86

Guest OS Type

Linux

Guest Architecture

x86

Guest OS name + version

AlmaLinux 9.8, kernel 5.14.0-687.5.3.el9_8.x86_64, xHCI controller, libusb-1.0.30

Component

USB and Serial Ports

What happened?
Component USB
Version VirtualBox 7.2.20 r175154
Host Windows 11 Enterprise 10.0.26200 (x64), Hyper-V/VBS active (VirtualBox runs on Hyper-V/NEM)
Guest AlmaLinux 9.8, kernel 5.14.0-687.5.3.el9_8.x86_64, xHCI controller, libusb-1.0.30
Reproducible Always (7 of 7), across four VM boots, before and after a host reboot

Summary

A USB device that resets itself on request (drops off the bus and re-enumerates)
works on bare-metal Linux and natively on the Windows host. When the device is
captured by a VM, the re-enumeration never reaches the guest. The guest sees no
disconnect, and every later control request to the device fails with STALL
(LIBUSB_ERROR_PIPE), even requests that worked a moment before. The device
stays in that state until the host runs usbdetach and usbattach.

The host does notice the change: VBoxSVC starts a USB enumeration 0.8 s after
the reset. It then finds the device "still captured" under the same VBoxUSB path
and does not tell the VM.

Device

FTDI FT4222H (0403:601C, bcdDevice 18.00), full speed behind a USB 2.0 hub
(0403:6017).

The reset is FTDI's documented FT4222_ChipReset (libft4222), a vendor OUT
request:

bmRequestType bRequest wValue wIndex wLength
0x40 0x21 0x0080 0 0

The chip then reloads its configuration and re-enumerates with a new address,
but with the same VID, PID and serial number.

Steps to reproduce

  1. Create a USB device filter for 0403:601C, start the VM and let the device be
    captured.
  2. In the guest (libusb), send a read, for example C0 20 0000 0000, length 12.
    It succeeds.
  3. Send the reset 40 21 0080 0000, length 0. It returns OK (in one of seven
    runs it returned STALL instead).
  4. Wait 20 s, then send the read from step 2 again.

Expected

The device disappears from the guest and comes back with a new address within
1–2 s, as on bare metal. After that, requests succeed.

Actual

  • Step 4 returns STALL (LIBUSB_ERROR_PIPE). All further requests stall,
    including a second reset request.
  • Guest dmesg: no USB disconnect and no new enumeration. The device keeps
    its address.
  • VBox.log: no VUSB: Detached or Attached lines.
  • Windows: the device stays as "VirtualBox USB Driver"
    (USB\VID_80EE&PID_CAFE\...) with no PnP change. VBoxManage list usbhost
    shows it as Captured.
  • libusb_reset_device() from the guest makes the guest re-enumerate it
    (device firmware changed, string descriptor 0 read error: -32), but it
    still stalls.

Comparison

Setup Result
Windows host, device not captured (filter inactive), same request via FTDI D2XX FT_VendorCmdSet(0x80) Device gone after 0.2 s, back after 1.2–2.1 s, works
Bare-metal Linux (AlmaLinux 9.8), same libusb code Re-enumerates after about 0.4 s, works
Physical unplug and replug while captured Works: Detached/Attached logged, recaptured in about 2.3 s
USBPcap filter driver removed from the USB class UpperFilters, host rebooted No change

What the logs show

Attached run on 2026-10-20. All times are UTC.

Time Event
11:30:40.039 Guest sends the reset request (OK)
11:30:40.824 VBoxSVC.log: usbLibGetDevices: Starting USB device enumeration (VBoxSVC relative 00:01:21.634). The host noticed a device change 0.8 s after the reset. It finds the device still captured under the same VBoxUSB path \\?\usb#vid_80ee&pid_cafe#5926400002#{00873fdf-...} (Found 12 USB devices, 2 captured, as before). Nothing else happens, and VBox.log has no Detached or Attached lines
11:31:00.046 Guest request returns STALL
11:31:00.552 usbdetach (VBox.log: VUSB: Detached ... proxy 0403:601c)
11:31:03.416 usbattach (VBox.log: VUSB: Attached ... to port 2)
11:31:05 Guest requests work again

The VM was started with
VBOX_RELEASE_LOG=+usb_proxy.e.l.l2.l3.f+drv_vusb.e.l.l2.f+dev_xhci.e.l.f, but
the release build logs nothing more than the lines above for this sequence.

Our reading

The device drops off the bus and comes back within about 1 s with the same VID,
PID and serial number, so it reappears under VBoxUSB with the same instance path.
VBoxSVC sees "the same captured device" and does not notify the VM. The VM's USB
proxy keeps its old handle and state for a device that has been reset
(unconfigured, address 0), which explains the stalls.

A possible fix: VBoxUSB or VBoxSVC detects the re-arrival of a captured device
(a new device object or a PnP arrival) and re-attaches it to the VM, as it already
does for a physical unplug and replug.

Workaround

On the host, run VBoxManage controlvm <vm> usbdetach <uuid>, then
usbattach <uuid>. The filter does not recapture the device by itself after
usbdetach. The guest then sees the device anew and it works normally. The host
has to do this after every reset.

Attachments

User name, domain and DNS servers are redacted.

File Content
VBox.log VM log. Reset at 11:30:40.039 UTC (VM relative 00:01:17.879), usbdetach at 11:31:00.552 (00:01:38.393), usbattach at 11:31:03.416 (00:01:41.257)
VBoxSVC.log Host-side log. Enumeration after the reset at 00:01:21.634 (11:30:40.824 UTC), usbdetach and usbattach at 00:01:41.36–00:01:44.12

Guest timestamps come from the guest clock (chrony: less than 1 ms from NTP time).

VBox.log
VBoxSVC.log

How can we reproduce this?

See the "What happened" field.

Did you upload all of your necessary log files, screenshots, etc.?
  • Yes, I've uploaded all pertinent files to this issue.
主要語言
C
星號
1.4k
分支
219
30 天內沒有已合併 PR

環境準備

  • 沒有 Dockerfile 或 Docker Compose 檔案
  • 沒有 Pull Request 範本
  • 閱讀貢獻指南

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

VirtualBox/virtualbox 的其他 Issue

查看 VirtualBox/virtualbox 的全部 Issue

相似的 Issue

更多 C Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。