| 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: <4E0CD0B8.6030405@freemail.hu> Date: Thu, 30 Jun 2011 21:38:32 +0200 From: Németh Márton <nm127@...email.hu> To: Matt Chen <machen@...ell.com> 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 Matt Chen wrote: > 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. I've already sent everything I have. Nothing remained unsent from my side. > 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