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

Đang mở
  • Có gì không ổn?
#922 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 6 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
42/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
c, linux
Lĩnh vực
desktop, operating-systems

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.
Ngôn ngữ chính
C
Star
1.4k
Fork
219
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của VirtualBox/virtualbox

Tất cả issue của VirtualBox/virtualbox

Issue tương tự

Thêm issue về C

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.