| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <BANLkTinkOApeyeniirchn0gPApzdwHY5ww@mail.gmail.com> Date: Thu, 30 Jun 2011 14:54:47 +0800 From: Matt Chen <machen@...ell.com> To: Németh Márton <nm127@...email.hu> Cc: Greg KH <greg@...ah.com>, Matthew Wilcox <matthew@....cx>, Max Vozeler <max@...eler.com>, Joe Perches <joe@...ches.com>, David Chang <dchang@...ell.com>, linux-usb@...r.kernel.org, usbip-devel@...ts.sourceforge.net, devel@...verdev.osuosl.org, LKML <linux-kernel@...r.kernel.org> Subject: Re: [PATCH, RFC] USBIP protocol documentation Hi Németh and Matt, We are also working on reviewing protocol here. We were wondering if you are available for letting us know which part you've already done. Then we can save the time for doing the same parts. And also we would like to follow your suggesting format to work on it. Then it would make it work much faster. Any suggestion ? 2011/6/30 Németh Márton <nm127@...email.hu> > > Matt Chen wrote: > > Hi Matt, > > > > > > 2011/6/30 matt mooney <mfm@...eddisk.com <mailto:mfm@...eddisk.com>>: > >> On 08:52 Tue 28 Jun , N??meth M??rton wrote: > >>> From: M??rton N??meth <nm127@...email.hu <mailto:nm127@...email.hu>> > >>> > >>> USBIP v1.0.0 protocol documentation. > >>> > >>> Signed-off-by: M??rton N??meth <nm127@...email.hu > > <mailto:nm127@...email.hu>> > >>> --- > >>> > >>> Hi, > >>> > >>> I tried to document the USBIP protocol as implemented in the Linux > > kernel 3.0-rc2. > >> > >> Yeah, thanks for doing this. I am also documenting the protocol but am not > >> finished yet. We can use yours as the base if you would like although > > I have a > >> few suggestions. > >> > >> For one, the grammar needs to be cleaned up, but instead of me > > pointing out all > >> of the needed corrections, I will send in a grammar corrections patch > > on top of > > Please go on with the corrections. I really started documenting the > current USBIP protocol because I think digging in the source code is > not the right way to describe a protocol. I'm happy that the review > of the USBIP protocol description started. Once we have documented the current > USBIP protocol I think we'll see more clearly its weaknesses. > > What I think important to include in the protocol description is to > identify the unused fields and specify an exact value (usually zero) to > use for these fields. This makes possible future extension of the protocol > easy. > > One more random thing which came to my mind is that I tend to think that > the current implementation is buggy when ISO packets are transmitted. > I have a hama AC-150 webcam which is not working well with USBIP. This > webcam usually sends smaller ISO packets so there is a gap between > the ISO packets in one single URB. The problem came up already in case > of usbmon, see https://bugzilla.kernel.org/show_bug.cgi?id=22182 and > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b17ea167c5fb50dcd5dce5b874a467f04eec886d > . > > >> the finished document. I like that you did a time sequence diagram, > > which is > >> something I had neglected to include myself; however, I am not a big > > fan of how > >> you laid out the messages. I was planning on using packet diagrams. > > IMHO, it > >> makes understanding the message composition much easier allowing more > > insight to > >> be gathered from a cursory glance. > >> > >> > >> Message Format > >> -------------- > >> 0 1 2 3 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Version | Opcode | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Status | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> . . > >> . Data . > >> . . > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> Version: 16 bit > >> Binary-coded decimal version number of the usbip-utils package from > >> which the program was built. > >> > >> Opcode: 16 bits > >> ... > >> > > So as you mentioned, the message format is looked like below: > > > > OP_REQ_DEVLIST Message Format > > > > 0 1 2 > > 3 4 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | 0000 0000 1000 0000 | 1000 0000 0000 0101 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > | 0000 0000 0000 0000 0000 0000 0000 0000 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > > > Is this correct ? > > > > Personally, I like this way to describe the protocol. ;-) > > This layout format what is used in other RFCs, too, is really a better > way to show the messages. I think, however, that we don't need to put > the values in binary format, we could just put one hexadecimal number > in the gaps, like this: > > OP_REQ_DEVLIST Message Format > > > 0 1 2 3 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0x0100 | 0x8005 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0x00000000 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >> As you may or may not see, I was going to take a more generic approach > > and then > >> describe the fields on a per-op basis. Of course, the main point here > > is that > >> the protocol is documented, so I am not opposed to a different style > > being used. > >> > >> But if you insist on the current layout, do not put a value for the > > version > >> because it is not constant (and in fact no longer at 1.0.0). And the > > "Meaning" > >> header should be "Description" or something better. > >> > >> Hmm, taking another look the layout just seems to busy... I really do > > think we > >> should find a different way to format the information. > >> > >> Thanks, > >> matt > >> > >>> The description is a preliminary draft only, it may contain mistakes. > > I tried > >>> to document what I have understand from the source code and from the > > actual > >>> captured network traffic when the USBIP is in action. Please review > > it, correct it, > >>> point out the missing parts. > >>> > >>> During I have documented the protocol a question came into my mind: > > why do we > >>> have two different type of package when the URB completition handler > > is called, > >>> namely USB_RET_SUBMIT and USBIP_RET_UNLINK? As far as I can see this > > causes race > >>> condition because for one URB the completition handler is only called > > once. If > >>> the one URB is sent in with USB_CMD_SUBMIT and then unlinked with > > USB_CMD_UNLINK > >>> the completition handler is called only once. In the protocol, > > however, we have > >>> two different type of packets: USB_RET_SUBMIT and USBIP_RET_UNLINK. > > The status > >>> field of these messages may contain anything in this case depending > > on the timing. > >>> > >>> Regards, > >>> > >>> M??rton N??meth > >>> --- > >>> diff -uprN staging-2.6.orig/drivers/staging/usbip/usbip_protocol.txt > > staging-2.6/drivers/staging/usbip/usbip_protocol.txt > >>> --- staging-2.6.orig/drivers/staging/usbip/usbip_protocol.txt > > 1970-01-01 01:00:00.000000000 +0100 > >>> +++ staging-2.6/drivers/staging/usbip/usbip_protocol.txt > > 2011-06-28 08:30:04.000000000 +0200 > >>> @@ -0,0 +1,352 @@ > >>> +PRELIMINARY DRAFT, MAY CONTAIN MISTAKES! > >>> +28 Jun 2011 > >>> + > >>> +The USB/IP protocol follows a server/client architecture. The server > > exports the > >>> +USB devices and the clients imports them. The device driver for the > > exported > >>> +USB device runs on the client machine. > >>> + > >>> +The client may ask for the list of the exported USB devices. To get > > the list the > >>> +client opens a TCP/IP connection towards the server, and sends an > > OP_REQ_DEVLIST > >>> +packet on top of the TCP/IP connection (so the actual OP_REQ_DEVLIST > > may be sent > >>> +in one or more pieces at the low level transport layer). The server > > sends back > >>> +the OP_REP_DEVLIST packet which lists the exported USB devices. > > Finally the > >>> +TCP/IP connection is closed. > >>> + > >>> + virtual host controller usb host > >>> + "client" "server" > >>> + (imports USB devices) (exports USB > > devices) > >>> + | | > >>> + | OP_REQ_DEVLIST | > >>> + | ----------------------------------------------> | > >>> + | | > >>> + | OP_REP_DEVLIST | > >>> + | <---------------------------------------------- | > >>> + | | > >>> + > >>> +Once the client knows the list of exported USB devices it may decide > > to use one > >>> +of them. First the client opens a TCP/IP connection towards the > > server and > >>> +sends an OP_REQ_IMPORT packet. The server replies with > > OP_REP_IMPORT. If the > >>> +import was successful the TCP/IP connection remains open and will be > > used > >>> +to trasfer the URB traffic between the client and the server. The > > client may > >>> +send two types of packets: the USBIP_CMD_SUBMIT to submit an URB, and > >>> +USBIP_CMD_UNLINK to unlink a previously submitted URB. The answers > > of the > >>> +server may be USBIP_RET_SUBMIT and USBIP_RET_UNLINK respectively. > >>> + > >>> + virtual host controller usb host > >>> + "client" "server" > >>> + (imports USB devices) (exports USB > > devices) > >>> + | | > >>> + | OP_REQ_IMPORT | > >>> + | ----------------------------------------------> | > >>> + | | > >>> + | OP_REP_IMPORT | > >>> + | <---------------------------------------------- | > >>> + | | > >>> + | | > >>> + | USBIP_CMD_SUBMIT(seqnum = n) | > >>> + | ----------------------------------------------> | > >>> + | | > >>> + | USBIP_RET_SUBMIT(seqnum = n) | > >>> + | <---------------------------------------------- | > >>> + | . | > >>> + | : | > >>> + | | > >>> + | USBIP_CMD_SUBMIT(seqnum = m) | > >>> + | ----------------------------------------------> | > >>> + | | > >>> + | USBIP_CMD_SUBMIT(seqnum = m+1) | > >>> + | ----------------------------------------------> | > >>> + | | > >>> + | USBIP_CMD_SUBMIT(seqnum = m+2) | > >>> + | ----------------------------------------------> | > >>> + | | > >>> + | USBIP_RET_SUBMIT(seqnum = m) | > >>> + | <---------------------------------------------- | > >>> + | | > >>> + | USBIP_CMD_SUBMIT(seqnum = m+3) | > >>> + | ----------------------------------------------> | > >>> + | | > >>> + | USBIP_RET_SUBMIT(seqnum = m+1) | > >>> + | <---------------------------------------------- | > >>> + | | > >>> + | USBIP_CMD_SUBMIT(seqnum = m+4) | > >>> + | ----------------------------------------------> | > >>> + | | > >>> + | USBIP_RET_SUBMIT(seqnum = m+2) | > >>> + | <---------------------------------------------- | > >>> + | . | > >>> + | : | > >>> + | | > >>> + | USBIP_CMD_UNLINK | > >>> + | ----------------------------------------------> | > >>> + | | > >>> + | USBIP_RET_UNLINK | > >>> + | <---------------------------------------------- | > >>> + | | > >>> + > >>> +The fields are in network (big endian) byte order meaning that the > > most significant > >>> +byte (MSB) is stored at the lowest address. > >>> + > >>> + > >>> +OP_REQ_DEVLIST: Retrieve the list of exported USB devices. > >>> + > >>> + Offset | Length | Value | Meaning > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0 | 2 | 0x0100 | Binary-coded decimal USBIP > > version number: v1.0.0 > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 2 | 2 | 0x8005 | Command code: Retrieve the list > > of exported USB > >>> + | | | devices. > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 4 | 4 | 0x00000000 | Status: unused, shall be set to 0 > >>> + > >>> +OP_REP_DEVLIST: Reply with the list of exported USB devices. > >>> + > >>> + Offset | Length | Value | Meaning > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0 | 2 | 0x0100 | Binary-coded decimal USBIP > > version number: v1.0.0. > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 2 | 2 | 0x0005 | Reply code: The list of exported > > USB devices. > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 4 | 4 | 0x00000000 | Status: 0 for OK > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 8 | 4 | n | Number of exported devices: 0 > > means no exported > >>> + | | | devices. > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x0C | | | From now on the exported n > > devices are described, > >>> + | | | if any. If no devices are > > exported the message > >>> + | | | ends with the previous "number > > of exported > >>> + | | | devices" field. > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + | 256 | | path: Path of the device on the > > host exporting the > >>> + | | | USB device, string closed with > > zero byte, e.g. > >>> + | | | > > "/sys/devices/pci0000:00/0000:00:1d.1/usb3/3-2" > >>> + | | | The unused bytes shall be > > filled with zero > >>> + | | | bytes. > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x10C | 32 | | busid: Bus ID of the exported > > device, string > >>> + | | | closed with zero byte, e.g. > > "3-2". The unused > >>> + | | | bytes shall be filled with zero > > bytes. > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x12C | 4 | | busnum > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x130 | 4 | | devnum > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x134 | 4 | | speed > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x138 | 2 | | idVendor > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x13A | 2 | | idProduct > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x13C | 2 | | bcdDevice > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x13E | 1 | | bDeviceClass > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x13F | 1 | | bDeviceSubClass > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x140 | 1 | | bDeviceProtocol > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x141 | 1 | | bConfigurationValue > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x142 | 1 | | bNumConfigurations > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x143 | 1 | | bNumInterfaces > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x144 | | m_0 | From now on each interface is > > described, all > >>> + | | | together bNumInterfaces times, > > with the > >>> + | | | the following 4 fields: > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + | 1 | | bInterfaceClass > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x145 | 1 | | bInterfaceSubClass > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x146 | 1 | | bInterfaceProtocol > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x147 | 1 | | padding byte for alignment, shall > > be set to zero > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0xC + | | | The second exported USB device > > starts at i=1 > >>> + i*0x138 + | | | with the busid field. > >>> + m_(i-1)*4 | | | > >>> + > >>> +OP_REQ_IMPORT: Request to import (attach) a remote USB device. > >>> + > >>> + Offset | Length | Value | Meaning > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0 | 2 | 0x0100 | Binary-coded decimal USBIP > > version number: v1.0.0 > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 2 | 2 | 0x8003 | Command code: import a remote USB > > device. > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 4 | 4 | 0x00000000 | Status: unused, shall be set to 0 > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 8 | 32 | | busid: the busid of the exported > > device on the > >>> + | | | remote host. The possible > > values are taken > >>> + | | | from the message field > > OP_REP_DEVLIST.busid. > >>> + | | | A string closed with zero, the > > unused bytes > >>> + | | | shall be filled with zeros. > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + > >>> +OP_REP_IMPORT: Reply to import (attach) a remote USB device. > >>> + > >>> + Offset | Length | Value | Meaning > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0 | 2 | 0x0100 | Binary-coded decimal USBIP > > version number: v1.0.0 > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 2 | 2 | 0x0003 | Reply code: Reply to import. > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 4 | 4 | 0x00000000 | Status: 0 for OK > >>> + | | | 1 for error > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 8 | | | From now on comes the details of > > the imported > >>> + | | | device, if the previous status > > field was OK (0), > >>> + | | | otherwise the reply ends with > > the status field. > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + | 256 | | path: Path of the device on the > > host exporting the > >>> + | | | USB device, string closed with > > zero byte, e.g. > >>> + | | | > > "/sys/devices/pci0000:00/0000:00:1d.1/usb3/3-2" > >>> + | | | The unused bytes shall be > > filled with zero > >>> + | | | bytes. > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x108 | 32 | | busid: Bus ID of the exported > > device, string > >>> + | | | closed with zero byte, e.g. > > "3-2". The unused > >>> + | | | bytes shall be filled with zero > > bytes. > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x128 | 4 | | busnum > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x12C | 4 | | devnum > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x130 | 4 | | speed > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x134 | 2 | | idVendor > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x136 | 2 | | idProduct > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x138 | 2 | | bcdDevice > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x139 | 1 | | bDeviceClass > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x13A | 1 | | bDeviceSubClass > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x13B | 1 | | bDeviceProtocol > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x13C | 1 | | bConfigurationValue > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x13D | 1 | | bNumConfigurations > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x13E | 1 | | bNumInterfaces > >>> + > >>> +USBIP_CMD_SUBMIT: Submit an URB > >>> + > >>> + Offset | Length | Value | Meaning > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0 | 4 | 0x00000001 | command: Submit an URB > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 4 | 4 | | seqnum: the sequence number of > > the URB to submit > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 8 | 4 | | devid > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0xC | 4 | | direction: 0: USBIP_DIR_IN > >>> + | | | 1: USBIP_DIR_OUT > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x10 | 4 | | ep: endpoint number, possible > > values are: 0...15 > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x14 | 4 | | transfer_flags: possible values > > depend on the > >>> + | | | URB transfer type, see below > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x18 | 4 | | transfer_buffer_length > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x1C | 4 | | start_frame: specify the selected > > frame to > >>> + | | | transmit an ISO frame, ignored > > if URB_ISO_ASAP > >>> + | | | is specified at transfer_flags > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x20 | 4 | | number_of_packets: number of ISO > > packets > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x24 | 4 | | interval: maximum time for the > > request on the > >>> + | | | server-side host controller > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x28 | 8 | | setup: data bytes for USB setup, > > filled with > >>> + | | | zeros if not used > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x30 | | | URB data. For ISO transfers the > > padding between > >>> + | | | each ISO packets is not > > transmitted. > >>> + > >>> + > >>> + Allowed transfer_flags | value | control | interrupt | bulk > > | isochronous > >>> + > > -------------------------+------------+---------+-----------+----------+------------- > >>> + URB_SHORT_NOT_OK | 0x00000001 | only in | only in | only > > in | no > >>> + URB_ISO_ASAP | 0x00000002 | no | no | no > > | yes > >>> + URB_NO_TRANSFER_DMA_MAP | 0x00000004 | yes | yes | yes > > | yes > >>> + URB_NO_FSBR | 0x00000020 | yes | no | no > > | no > >>> + URB_ZERO_PACKET | 0x00000040 | no | no | only > > out | no > >>> + URB_NO_INTERRUPT | 0x00000080 | yes | yes | yes > > | yes > >>> + URB_FREE_BUFFER | 0x00000100 | yes | yes | yes > > | yes > >>> + URB_DIR_MASK | 0x00000200 | yes | yes | yes > > | yes > >>> + > >>> + > >>> +USBIP_RET_SUBMIT: Reply for submitting an URB > >>> + > >>> + Offset | Length | Value | Meaning > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0 | 4 | 0x00000002 | command > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 4 | 4 | | seqnum: URB sequence number > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 8 | 4 | | devid > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0xC | 4 | | direction: 0: USBIP_DIR_IN > >>> + | | | 1: USBIP_DIR_OUT > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x10 | 4 | | ep: endpoint number > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x14 | 4 | | status: zero for successful URB > > transaction, > >>> + | | | otherwise some kind of error > > happened. > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x18 | 4 | n | actual_length: number of URB data > > bytes > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x1C | 4 | | start_frame: for an ISO frame the > > actually > >>> + | | | selected frame for transmit. > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x20 | 4 | | number_of_packets > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x24 | 4 | | error_count > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x28 | 8 | | setup: data bytes for USB setup, > > filled with > >>> + | | | zeros if not used > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x30 | n | | URB data bytes. For ISO transfers > > the padding > >>> + | | | between each ISO packets is not > > transmitted. > >>> + > >>> +USBIP_CMD_UNLINK: Unlink an URB > >>> + > >>> + Offset | Length | Value | Meaning > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0 | 4 | 0x00000003 | command: URB unlink command > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 4 | 4 | | seqnum: URB sequence number to > > unlink: FIXME: is this so? > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 8 | 4 | | devid > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0xC | 4 | | direction: 0: USBIP_DIR_IN > >>> + | | | 1: USBIP_DIR_OUT > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x10 | 4 | | ep: endpoint number: zero > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x14 | 4 | | seqnum: the URB sequence number > > given previously > >>> + | | | at USBIP_CMD_SUBMIT.seqnum field > >>> + > >>> +USBIP_RET_UNLINK: Reply for URB unlink > >>> + > >>> + Offset | Length | Value | Meaning > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0 | 4 | 0x00000004 | command: reply for the URB unlink > > command > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 4 | 4 | | seqnum: the unlinked URB sequence > > number > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 8 | 4 | | devid > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0xC | 4 | | direction: 0: USBIP_DIR_IN > >>> + | | | 1: USBIP_DIR_OUT > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x10 | 4 | | ep: endpoint number > >>> > > +-----------+--------+------------+--------------------------------------------------- > >>> + 0x14 | 4 | | status: This is the value > > contained in the > >>> + | | | urb->status in the URB > > completition handler. > >>> + | | | FIXME: a better explanation needed. > >>> > >> _______________________________________________ > >> devel mailing list > >> devel@...uxdriverproject.org <mailto:devel@...uxdriverproject.org> > >> http://driverdev.linuxdriverproject.org/mailman/listinfo/devel > >> > > > > > > > > -- > > Thanks ~ > > Matt Chen > > > > > > > -- Thanks ~ Matt Chen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists