libusb_open returns error codes other than LIBUSB_ERROR_ACCESS

[mcuee]

libusb_open can return error codes other than the expected LIBUSB_ERROR_ACCESS.

For example, it can return LIBUSB_ERROR_NOT_FOUND or LIBUSB_ERROR_NOT_SUPPORTED under Windows. At least I think LIBUSB_ERROR_NOT_FOUND is really unexpected.

	/** Access denied (insufficient permissions) */
	LIBUSB_ERROR_ACCESS = -3,

	/** Entity not found */
	LIBUSB_ERROR_NOT_FOUND = -5,

	/** Operation not supported or unimplemented on this platform */
	LIBUSB_ERROR_NOT_SUPPORTED = -12,

Reference discussions.

• Run tests for AppVeyor too #1360
• 1.0.27-rc1 test matrix #1372

[mcuee]

To be confirmed:

1. NetBSD --> libusb_open can return LIBUSB_ERROR_IO.

• stress_mt fails on NetBSD 9.3 Virtual Machine #1390

2. OpenBSD --> libusb_open can return LIBUSB_ERROR_OTHER (maybe a false alarm).

• stress_mt fails on OpenBSD 7.4 on PVE 8.0 Virtual Machine but not Physical Machine #1389

[mcuee]

Questions for Windows.

1. Is the default error code LIBUSB_ERROR_IO a good choice here?
   

   libusb/libusb/os/windows_winusb.c

   Lines 2588 to 2610 in 37dee8f

   	// WinUSB requires a separate handle for each interface
   	for (i = 0; i < USB_MAXINTERFACES; i++) {
   	if ((priv->usb_interface[i].path != NULL)
   	&& (priv->usb_interface[i].apib->id == USB_API_WINUSBX)) {
   	file_handle = windows_open(dev_handle, priv->usb_interface[i].path, GENERIC_READ | GENERIC_WRITE);
   	if (file_handle == INVALID_HANDLE_VALUE) {
   	usbi_err(HANDLE_CTX(dev_handle), "could not open device %s (interface %d): %s", priv->usb_interface[i].path, i, windows_error_str(0));
   	switch (GetLastError()) {
   	case ERROR_FILE_NOT_FOUND: // The device was disconnected
   	return LIBUSB_ERROR_NO_DEVICE;
   	case ERROR_ACCESS_DENIED:
   	return LIBUSB_ERROR_ACCESS;
   	default:
   	return LIBUSB_ERROR_IO;
   	}
   	}
   	handle_priv->interface_handle[i].dev_handle = file_handle;
   	}
   	}
   	return LIBUSB_SUCCESS;
   	}

And here?

libusb/libusb/os/windows_winusb.c

Lines 3972 to 4001 in 37dee8f

	for (i = 0; i < USB_MAXINTERFACES; i++) {
	if ((priv->usb_interface[i].path != NULL)
	&& (priv->usb_interface[i].apib->id == USB_API_HID)) {
	hid_handle = windows_open(dev_handle, priv->usb_interface[i].path, GENERIC_READ | GENERIC_WRITE);
	/*
	* http://www.lvr.com/hidfaq.htm: Why do I receive "Access denied" when attempting to access my HID?
	* "Windows 2000 and later have exclusive read/write access to HIDs that are configured as a system
	* keyboards or mice. An application can obtain a handle to a system keyboard or mouse by not
	* requesting READ or WRITE access with CreateFile. Applications can then use HidD_SetFeature and
	* HidD_GetFeature (if the device supports Feature reports)."
	*/
	if (hid_handle == INVALID_HANDLE_VALUE) {
	usbi_warn(HANDLE_CTX(dev_handle), "could not open HID device in R/W mode (keyboard or mouse?) - trying without");
	hid_handle = windows_open(dev_handle, priv->usb_interface[i].path, 0);
	if (hid_handle == INVALID_HANDLE_VALUE) {
	usbi_err(HANDLE_CTX(dev_handle), "could not open device %s (interface %d): %s", priv->path, i, windows_error_str(0));
	switch (GetLastError()) {
	case ERROR_FILE_NOT_FOUND: // The device was disconnected
	return LIBUSB_ERROR_NO_DEVICE;
	case ERROR_ACCESS_DENIED:
	return LIBUSB_ERROR_ACCESS;
	default:
	return LIBUSB_ERROR_IO;
	}
	}
	priv->usb_interface[i].restricted_functionality = true;
	}
	handle_priv->interface_handle[i].api_handle = hid_handle;
	}
	}

[mcuee]

return LIBUSB_ERROR_NOT_FOUND; is used in many places for Windows. Maybe that is the reason we see this error code often.

[mcuee]

Known issues where libusb_open will return LIBUSB_ERROR_NOT_SUPPORTED.

• libusb Windows can not access second or later interface as part of an Interface group without IAD #1238 (comment)

[mcuee]

To be confirmed:

1. NetBSD --> libusb_open can return LIBUSB_ERROR_IO.

• stress_mt fails on NetBSD 9.3 Virtual Machine #1390

2. OpenBSD --> libusb_open can return LIBUSB_ERROR_OTHER (maybe a false alarm).

• stress_mt fails on OpenBSD 7.4 on PVE 8.0 Virtual Machine but not Physical Machine #1389

Both issues are considered as invalid since they are caused by Proxmox and not libusb.