F28 on 2 boxes [root@sky ~]# uname -a Linux sky.lan 4.18.7-200.fc28.x86_64 #1 SMP Mon Sep 10 15:44:45 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux [root@sky ~]# rpm -q kernel-core usbip kernel-core-4.18.7-200.fc28.x86_64 usbip-4.15.10-1.fc28.x86_64 [root@sky ~]# modprobe usbip_host [root@sky ~]# usbip list -l - busid 1-3 (1b1c:0c03) Corsair : unknown product (1b1c:0c03) - busid 1-7 (0b05:1825) ASUSTek Computer, Inc. : Qualcomm Bluetooth 4.1 (0b05:1825) [root@sky ~]# usbip bind -b 1-3 usbip: info: bind device on busid 1-3: complete [root@sky ~]# usbip list -r localhost Exportable USB devices ====================== - localhost 1-3: Corsair : unknown product (1b1c:0c03) : /sys/devices/pci0000:00/0000:00:14.0/usb1/1-3 : (Defined at Interface level) (00/00/00) --- 2nd machine --- [root@mini ~]# modprobe vhci_hcd [root@mini ~]# usbip list -l [root@mini ~]# usbip list -r sky Exportable USB devices ====================== - sky 1-3: Corsair : unknown product (1b1c:0c03) : /sys/devices/pci0000:00/0000:00:14.0/usb1/1-3 : (Defined at Interface level) (00/00/00) [root@mini ~]# usbip attach -r sky -b 1-3 libusbip: error: udev_device_get_sysattr_value failed usbip: error: open vhci_driver usbip: error: query strace on that shows: lstat("/sys/devices/platform/vhci_hcd.0/status", {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0 openat(AT_FDCWD, "/sys/devices/platform/vhci_hcd.0/status", O_RDONLY|O_CLOEXEC) = 4 fstat(4, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0 fstat(4, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0 read(4, "hub port sta spd dev sockfd"..., 4096) = 637 read(4, "", 4096) = 0 close(4) = 0 lstat("/sys/devices/platform/vhci_hcd.0/status.1", 0x7ffe91fe3b90) = -1 ENOENT (No such file or directory) getrandom("\xf7\xb1\x12\x3c\x13\x24\x2e\xab\x98\xc2\x5c\xc5\x75\x3b\x20\x7b", 16, GRND_NONBLOCK) = 16 write(2, "libusbip: error: udev_device_get"..., 54libusbip: error: udev_device_get_sysattr_value failed ) = 54 write(2, "usbip: error: open vhci_driver\n", 31usbip: error: open vhci_driver ) = 31 write(2, "usbip: error: query\n", 20usbip: error: query ) = 20 exit_group(1) = ? +++ exited with 1 +++ So presumably problem is lack of '/sys/devices/platform/vhci_hcd.0/status.1' possibly due to .1 suffix
I pulled out usbip from the 4.18.9 kernel, and after some #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wstringop-truncation" strncpy(d, s, 32); #pragma GCC diagnostic pop fixes (per https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice) since I couldn't think of anything better, I've reached: # src/usbip attach -r sky -b 1-3 libusbip: error: udev_device_get_sysattr_value failed usbip: error: open vhci_driver Additionally commenting out the 'status.%d' for 'status' replacement: libsrc/vhci_driver.c: static int refresh_imported_device_list(void) { const char *attr_status; char status[MAX_STATUS_NAME+1] = "status"; int i, ret; for (i = 0; i < vhci_driver->ncontrollers; i++) { //if (i > 0) // snprintf(status, sizeof(status), "status.%d", i); appears to be enough to make it work. (side note: why isn't this a build output of the kernel build process?)
ah! and the bug is the existence of /sys/devices/platform/w83627hf.656 which is lexicographically after vhci_hcd. fix for that is: static int vhci_hcd_filter(const struct dirent *dirent) { return !strncmp(dirent->d_name, "vhci_hcd", 8); }
that's still not enough to get it to actually support > 1 controller... since vhci_hcd.0 is basically hard-coded into a macro.
Thanks for reporting this. I haven't actually used USB/IP for a while, but let me look into this. Just to clarify, USB/IP doesn't ever work or it doesn't work if you add more than one controller?
(In reply to Maciej Żenczykowski from comment #1) > (side note: why isn't this a build output of the kernel build process?) See the last part of https://bugzilla.redhat.com/show_bug.cgi?id=1169478#c6 and https://bugzilla.redhat.com/show_bug.cgi?id=1169478#c11.
I have no idea how to add an extra controller, so no: I only had one. The problem is an elementary code bug in usbip's vhci_hcd_filter(). It does strcmp(dirent->d_name, "vhci_hcd") >= 0 instead of !strncmp(dirent->d_name, "vhci_hcd", 8) for prefix matching. (and on my system it causes it to detect a fan controller that starts with 'w' and is thus after 'vhci_hcd' as an extra vhci_hcd controller. In general the code doesn't look anywhere near ready to actually handle a 2nd controller.
btw. I was hoping to use this to actually expose a device with no Linux driver to a windows 10 box (intending to maybe trace the communication and figure out how to write a native driver)... but it doesn't look like the windows portion works at all.
(In reply to Maciej Żenczykowski from comment #7) > btw. I was hoping to use this to actually expose a device with no Linux > driver to a windows 10 box (intending to maybe trace the communication and > figure out how to write a native driver)... but it doesn't look like the > windows portion works at all. That sounds like a great way to use this. Have you looked at https://github.com/Oxalin/usbip_windows?
Ok, I've done a scratch build for F28 that I've tested locally. It's available here: https://koji.fedoraproject.org/koji/taskinfo?taskID=29776726 Can you please verify that it fixes the problem for you. The only thing I changed was the line in comment #6. If it fixes the problem, I'll push it out to all active Fedora releases.
(In reply to Jonathan Dieter from comment #8) > (In reply to Maciej Żenczykowski from comment #7) > > btw. I was hoping to use this to actually expose a device with no Linux > > driver to a windows 10 box (intending to maybe trace the communication and > > figure out how to write a native driver)... but it doesn't look like the > > windows portion works at all. > > That sounds like a great way to use this. Have you looked at > https://github.com/Oxalin/usbip_windows? And, on further reading, it looks like the driver has been ported and works fine, but the userspace changes are still in the process of being ported to Windows.
[root@mini usbip]# rpm -hvU usbip-4.18.9-1.fc28.x86_64.rpm Verifying... ################################# [100%] Preparing... ################################# [100%] Updating / installing... 1:usbip-4.18.9-1.fc28 ################################# [ 50%] Cleaning up / removing... 2:usbip-4.15.10-1.fc28 ################################# [100%] [root@mini usbip]# usbip usbip usbipd [root@mini usbip]# usbip list -r sky Exportable USB devices ====================== - sky 1-3: Corsair : unknown product (1b1c:0c03) : /sys/devices/pci0000:00/0000:00:14.0/usb1/1-3 : (Defined at Interface level) (00/00/00) : 0 - Vendor Specific Class / unknown subclass / unknown protocol (ff/00/00) [root@mini usbip]# usbip attach -r sky -b 1-3 libusbip: error: udev_device_new_from_subsystem_sysname failed usbip: error: open vhci_driver
ok, that was user error - need to load kernel module [root@mini usbip]# modprobe vhci-hcd [root@mini usbip]# usbip list -r sky Exportable USB devices ====================== - sky 1-3: Corsair : unknown product (1b1c:0c03) : /sys/devices/pci0000:00/0000:00:14.0/usb1/1-3 : (Defined at Interface level) (00/00/00) : 0 - Vendor Specific Class / unknown subclass / unknown protocol (ff/00/00) [root@mini usbip]# usbip attach -r sky -b 1-3 [root@mini usbip]# lsusb Bus 007 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 006 Device 003: ID 1b1c:0c03 Corsair Bus 006 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub [root@mini usbip]# usbip detach -p 0 usbip: info: Port 0 is now detached! [root@mini usbip]# lsusb Bus 007 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 006 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
And thinking about it some more: # cat usbip-4.18.9-compare-actual-name.patch diff -urb usbip-4.18.9a/libsrc/vhci_driver.c usbip-4.18.9b/libsrc/vhci_driver.c --- usbip-4.18.9a/libsrc/vhci_driver.c 2018-09-19 20:41:37.000000000 +0000 +++ usbip-4.18.9b/libsrc/vhci_driver.c 2018-09-20 10:11:10.843791788 +0000 @@ -150,7 +150,7 @@ static int vhci_hcd_filter(const struct dirent *dirent) { - return strcmp(dirent->d_name, "vhci_hcd") >= 0; + return !strncmp(dirent->d_name, "vhci_hcd", 8); } static int get_ncontrollers(void) that should probably be: + return !strncmp(dirent->d_name, "vhci_hcd.", 9);
Woohoo! I was kicking myself for a moment there, trying to figure out what I did wrong. Ok, I'm going to fix the patch and push it out as an update for all current Fedora releases. Did I understand correctly that you do kernel development? Did you want to do submit the patch upstream or do you want me to?
No! You did nothing wrong... it was entirely my fault - I simply failed to modprobe vhci-hcd - I fixed that and followed up with comment #12. Your package works. Comment #13 is just a minor nitpick to myself - mostly - it doesn't *really* matter. And I just sent: https://lkml.org/lkml/2018/9/20/1124 (and yeah I do kernel dev on the linux networking stack, but am an utter noob when it comes to windows, hence the presence of source code that may or may not work isn't helpful ;-) )
Great! I've done the Fedora builds and will push them to testing. Thanks so much for fixing this! I would have spent forever trying to figure out why it didn't work for you and did work for me.
usbip-4.18.9-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-488a63aef8
usbip-4.18.9-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-75b15af646
usbip-4.18.9-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-28dce2eeba
usbip-4.18.9-2.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-488a63aef8
usbip-4.18.9-2.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-28dce2eeba
usbip-4.18.9-2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-75b15af646
usbip-4.18.9-2.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
usbip-4.18.9-2.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
usbip-4.18.9-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.