Kernel Bug Tracker – Bug 22182
usbmon: completed ISO packet content is not fully arriving with mmap
Last modified: 2011-03-30 23:37:59 UTC
The ISO data in a completed URB is not necessarily begins at the first ISO block. When the URB is submitted then each ISO blcok is set to the maximal size.
In the attached example capture (which was created with Wireshark) we can see two captured packets: the first one is the submitted URB and the second one is the completed URB. The submitted URB has 24 ISO descriptor, 800 bytes each. This URB is captured all right.
The second packet contains the completed URB. In the user space we see that there are 1000 data bytes in this URB. This data is spread between ISO blocks 0...5 giving 155+160+185+174+156+170=1000. ISO desc 6...12 have zero length each. ISO desciptors 13..23 are not completed (-EXDEV). The problem is that the first 1000 bytes transfered from the kernel contains 800 bytes from the isodesc 0 out of 155 bytes are used. The next 800 bytes are not transfered completely, only the first 200 bytes out of 16 bytes are used. Then isodesc 2...5 are not transfered at all.
The reason might be that in drivers/usb/mon/mon_bin.c, in function mon_bin_event() the possible gaps are not taken into account together with memory mapped operation.
Created attachment 36312 [details]
example Wireshark capture
Created attachment 36322 [details]
Parsed content of the capture file
I could imagine different expected behaviours:
(a) the transfered size equals to 800+800+800+800+800+170=4170 bytes, so the iso desc 0...4 are fully transfered and the useful data from isodesc 5
(b) the transfered size equals to 800+800+800+800+800+800=4800 bytes, so the iso desc 0...5 are fully transfered
(c) the transfered size equals to maximum possible size always, in this case 24*800=19200 bytes
Created attachment 36362 [details]
2nd example Wireshark capture
In this second example we have an URB submitted with 24 ISO descritors, 800 bytes each.
The completed URB contains 242+101+177+156=767 data bytes. The ISO blocks 0...19 contains no data. The data is spread in ISO blocks 20..23.
Created attachment 36372 [details]
Parsed content of the 2nd capture file
Proposed patch sent, see http://lkml.org/lkml/2010/11/13/148 .
Created attachment 38712 [details]
Suggested fix #2 (contra original)
merged in .38-rc1:
Author: Pete Zaitcev <firstname.lastname@example.org>
Date: Tue Nov 16 21:51:19 2010 -0700
usbmon: correct length for isochronous