Hi everyone, I only caught this thread a couple of days ago, but have found it pretty useful. For the last few months, I've been trying to get wireless-usb hwa's and dwa's using the wisair chip to work in the kernel, and have found vusb-analyzer + vmware is actually a bit easier to use than wireshark + qemu for logging interpreting wireless usb transactions in a windows vm. What's pretty nice about vusb-analyzer vs. wireshark is that it's really quite straight forward to add specific decoders to vusb-analyzer in python, whereas for wireshark (+tcpdump) it seems a bit more complicated. I'm currently putting together a decoder for the various types of wireless usb requests, and would like to adjust the UI to make it a treeview instead of requiring a double-click to open packet details. Has anyone else given the vmware + vusb-analyzer combination a try? Thoughts? ... For the sake of free-ness, it would be nice to implement a similar usb packet logger format for qemu. The major advantage of having a virtual machine do the logging, is that the number of data bytes is not limited by the usbmon's text interface, and its a bit simpler than writing up a program from scratch that uses the binary interface. Cheers, Chris On Thu, Jun 3, 2010 at 9:17 PM, Pete Zaitcev <zaitcev@xxxxxxxxxx> wrote: > On Tue, 1 Jun 2010 19:39:16 -0400 > Chris Frey <cdfrey@xxxxxxxxxxxxxx> wrote: > >> Can I be sure that the usbmon binary buffers will not drop usb packets >> no matter how busy my system is? > > No, you cannot be sure. That is because the hooks are asynchronous > and cannot exert any flow control. Therefore, a sufficiently persistent > driver on a system that is busy enough will always generate enough > traffic to overflow any buffers, no matter how large. This is especially > sad when you have Windows under a VMM and want to snoop what it's doing. > The solution is to use a multicore system and only let your VM to use > a subset of available CPUs. > > That said, the binary API permits big buffers that absorb just about > any traffic spike. As long as your snooping application is efficient > and you leave enough CPU and I/O on the average, you have nothing > to fear. > > The statistic gathering in the binary API may be not up to snuff though, > honestly I never tested it properly. The packet loss never was a problem > for me, so I never bothered addressing it. Patches are welcome, if any. > >> Side question: It is odd to me that such effort has gone into limiting >> the size of the usbmon text output... even to the extent that an entire >> binary API was created. What is wrong with making the 32 byte size >> configurable? I'm sure I'm not understanding something here. > > Try opening the result with unlimited strings in vi, you'll see. > > -- Pete > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
