public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
* Usb IP Failing to connect depending of program being runned even when the connection talks are identical
@ 2024-10-17 21:05 Angel D Raygoza
  2024-10-18  5:53 ` Greg KH
  0 siblings, 1 reply; 5+ messages in thread
From: Angel D Raygoza @ 2024-10-17 21:05 UTC (permalink / raw)
  To: linux-usb

Dear USB Linux Mailing List.

I have been trying to write a USB IP Virtual Device  as your protocol
(https://docs.kernel.org/usb/usbip_protocol.html).


Currently I am in the step of writing the code that responds to the
OP_REQ_IMPORT package, I have been writing the code accordingly to the,
previously mentioned, documentation,
https://docs.kernel.org/usb/usbip_protocol.html, and some USB resources
https://www.usb.org/defined-class-codes.


When attaching my USB IP Virtual Device as here `sudo usbip --debug
--tcp-port 3000 attach --remote=localhost -d 2-2` I get the following error

```

usbip: debug: usbip_network.c:28:[usbip_setup_port_number] parsing port
arg '3000'

usbip: info: using port 3000 ("3000")

usbip: debug: usbip.c:129:[run_command] running command: `attach'

libusbip: debug: vhci_driver.c:269:[usbip_vhci_driver_open] available
ports: 16

libusbip: debug: vhci_driver.c:281:[usbip_vhci_driver_open] available
controllers: 1

libusbip: debug: vhci_driver.c:128:[refresh_imported_device_list]
controller 0

libusbip: debug: vhci_driver.c:67:[parse_status] hub hs port 0 status 4
speed 0 devid 0

libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0

libusbip: debug: vhci_driver.c:67:[parse_status] hub hs port 1 status 4
speed 0 devid 0

libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0

libusbip: debug: vhci_driver.c:67:[parse_status] hub hs port 2 status 4
speed 0 devid 0

libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0

libusbip: debug: vhci_driver.c:67:[parse_status] hub hs port 3 status 4
speed 0 devid 0

libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0

libusbip: debug: vhci_driver.c:67:[parse_status] hub hs port 4 status 4
speed 0 devid 0

libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0

libusbip: debug: vhci_driver.c:67:[parse_status] hub hs port 5 status 4
speed 0 devid 0

libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0

libusbip: debug: vhci_driver.c:67:[parse_status] hub hs port 6 status 4
speed 0 devid 0

libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0

libusbip: debug: vhci_driver.c:67:[parse_status] hub hs port 7 status 4
speed 0 devid 0

libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0

libusbip: debug: vhci_driver.c:67:[parse_status] hub ss port 8 status 4
speed 0 devid 0

libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0

libusbip: debug: vhci_driver.c:67:[parse_status] hub ss port 9 status 4
speed 0 devid 0

libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0

libusbip: debug: vhci_driver.c:67:[parse_status] hub ss port 10 status 4
speed 0 devid 0

libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0

libusbip: debug: vhci_driver.c:67:[parse_status] hub ss port 11 status 4
speed 0 devid 0

libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0

libusbip: debug: vhci_driver.c:67:[parse_status] hub ss port 12 status 4
speed 0 devid 0

libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0

libusbip: debug: vhci_driver.c:67:[parse_status] hub ss port 13 status 4
speed 0 devid 0

libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0

libusbip: debug: vhci_driver.c:67:[parse_status] hub ss port 14 status 4
speed 0 devid 0

libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0

libusbip: debug: vhci_driver.c:67:[parse_status] hub ss port 15 status 4
speed 0 devid 0

libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0

libusbip: debug: vhci_driver.c:104:[parse_status] exit

usbip: debug: usbip_attach.c:100:[import_device] got free port 0

libusbip: debug: vhci_driver.c:367:[usbip_vhci_attach_device2] writing:
0 3 131074 2

libusbip: debug: vhci_driver.c:372:[usbip_vhci_attach_device2] attach
attribute path: /sys/devices/platform/vhci_hcd.0/attach

libusbip: debug: vhci_driver.c:380:[usbip_vhci_attach_device2] attached
port: 0

```

(With a success code of 0)

Which I have not found very informative, but when attaching this
https://github.com/bulwarkid/virtual-fido.git USB IP Virtual Device, I
found success.

This I proceeded to reverse engineer the working USB IP Device with
Wireshark, which led mo to the fact that the connection start with the
interchange

```

OP_REQ_IMPORT:

00000000 01 11 80 03 00 00 00 00 .......

00000008 32 2d 32 00 00 00 00 00 00 00 00 00 00 00 00 00 2-2..... ........

00000018 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........

OP_REP_IMPORT:

00000000 01 11 00 03 00 00 00 00 2f 64 65 76 69 63 65 2f ........ /device/

00000010 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0....... ........

00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........

00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........

00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........

00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........

00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........

00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........

00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........

00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........

000000A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........

000000B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........

000000C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........

000000D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........

000000E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........

000000F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........

00000100 00 00 00 00 00 00 00 00 32 2d 32 00 00 00 00 00 ........ 2-2.....

00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........

00000120 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 02 ........ ........

00000130 00 00 00 02 00 00 00 00 00 00 00 00 00 00 01 01 ........ ........

```

And replicating the same exact behavior in my application in my
application, I get the same exact error, and is actually error that I
share in the start of this email.


So I would appreciate any help that could help mo to get out of thick
wall brick where I found myself now.


As an extra remark, I have not understood yet which are supposed to
contain the fields: transfer_flags, setup and transfer buffer. I guess
it has something to do with the USB specification
(https://www.usb.org/document-library/usb-20-specification), Which have
to still finish reading.


Cordially, Pixiae


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Usb IP Failing to connect depending of program being runned even when the connection talks are identical
  2024-10-17 21:05 Usb IP Failing to connect depending of program being runned even when the connection talks are identical Angel D Raygoza
@ 2024-10-18  5:53 ` Greg KH
  2024-10-18 16:56   ` Pixiae
  0 siblings, 1 reply; 5+ messages in thread
From: Greg KH @ 2024-10-18  5:53 UTC (permalink / raw)
  To: Angel D Raygoza; +Cc: linux-usb

On Thu, Oct 17, 2024 at 03:05:43PM -0600, Angel D Raygoza wrote:
> Dear USB Linux Mailing List.
> 
> I have been trying to write a USB IP Virtual Device  as your protocol
> (https://docs.kernel.org/usb/usbip_protocol.html).

Why not just use the in-kernel device code instead of creating your own?
Is there something wrong with that implementation?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: Usb IP Failing to connect depending of program being runned even when the connection talks are identical
  2024-10-18  5:53 ` Greg KH
@ 2024-10-18 16:56   ` Pixiae
  2024-10-19  6:47     ` Greg KH
  0 siblings, 1 reply; 5+ messages in thread
From: Pixiae @ 2024-10-18 16:56 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-usb

Dear Greg KH,


 > Why not just use the in-kernel device code instead of creating your own?

Do you mean that, why I don't write a kernel module?
If that is what you mean, I don't want to have to share the code of my 
device if I ever want to share my device, would be one reason.
Another is that I want it to be portable to multiple kernels, like 
the FreeBSD's kernel, even thought I would also have to write a USB IP 
implementation for the FreeBSD's kernel as looks so far they are missing 
it.

 > Is there something wrong with that implementation?

Could I know what implementation you refer to?

Cordially, Pixiae.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Usb IP Failing to connect depending of program being runned even when the connection talks are identical
  2024-10-18 16:56   ` Pixiae
@ 2024-10-19  6:47     ` Greg KH
  2024-10-19 14:38       ` Alan Stern
  0 siblings, 1 reply; 5+ messages in thread
From: Greg KH @ 2024-10-19  6:47 UTC (permalink / raw)
  To: Pixiae; +Cc: linux-usb

On Fri, Oct 18, 2024 at 10:56:45AM -0600, Pixiae wrote:
> Dear Greg KH,
> 
> 
> > Why not just use the in-kernel device code instead of creating your own?
> 
> Do you mean that, why I don't write a kernel module?

Yes, what's wrong with the existing usbip client code in Linux?

> If that is what you mean, I don't want to have to share the code of my
> device if I ever want to share my device, would be one reason.

Then it's going to be hard, if not impossible, for us to help you,
sorry, as this is a group for Linux kernel issues.

best of luck!

greg k-h

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Usb IP Failing to connect depending of program being runned even when the connection talks are identical
  2024-10-19  6:47     ` Greg KH
@ 2024-10-19 14:38       ` Alan Stern
  0 siblings, 0 replies; 5+ messages in thread
From: Alan Stern @ 2024-10-19 14:38 UTC (permalink / raw)
  To: Pixiae; +Cc: linux-usb

On Sat, Oct 19, 2024 at 08:47:23AM +0200, Greg KH wrote:
> On Fri, Oct 18, 2024 at 10:56:45AM -0600, Pixiae wrote:
> > Dear Greg KH,
> > 
> > 
> > > Why not just use the in-kernel device code instead of creating your own?
> > 
> > Do you mean that, why I don't write a kernel module?
> 
> Yes, what's wrong with the existing usbip client code in Linux?
> 
> > If that is what you mean, I don't want to have to share the code of my
> > device if I ever want to share my device, would be one reason.
> 
> Then it's going to be hard, if not impossible, for us to help you,
> sorry, as this is a group for Linux kernel issues.

You might get some more useful information by writing directly to the 
maintainers of the USB Over IP kernel driver (see the MAINTAINERS file 
in the kernel source).

Alan Stern

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2024-10-19 14:38 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-10-17 21:05 Usb IP Failing to connect depending of program being runned even when the connection talks are identical Angel D Raygoza
2024-10-18  5:53 ` Greg KH
2024-10-18 16:56   ` Pixiae
2024-10-19  6:47     ` Greg KH
2024-10-19 14:38       ` Alan Stern

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox