hw/usb/bus.c: PCAP adding 0xA in Windows version
commit5e02a4fdebc442e34c5bb05e4540f85cc6e802f0
authorBenjamin David Lunt <benlunt@fysnet.net>
Sun, 25 Feb 2024 19:49:51 +0000 (25 12:49 -0700)
committerThomas Huth <thuth@redhat.com>
Fri, 1 Mar 2024 07:27:33 +0000 (1 08:27 +0100)
tree1b8d9b692c3c7a43c2633d5a9f47f834f6d5a23e
parent8bd3f84d1f6fba0edebc450be6fa2c7630584df9
hw/usb/bus.c: PCAP adding 0xA in Windows version

Since Windows text files use CRLFs for all \n, the Windows version of QEMU
inserts a CR in the PCAP stream when a LF is encountered when using USB PCAP
files. This is due to the fact that the PCAP file is opened as TEXT instead
of BINARY.

To show an example, when using a very common protocol to USB disks, the BBB
protocol uses a 10-byte command packet. For example, the READ_CAPACITY(10)
command will have a command block length of 10 (0xA). When this 10-byte
command (part of the 31-byte CBW) is placed into the PCAP file, the Windows
file manager inserts a 0xD before the 0xA, turning the 31-byte CBW into a
32-byte CBW.

Actual CBW:
  0040 55 53 42 43 01 00 00 00 08 00 00 00 80 00 0a 25 USBC...........%
  0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00       ...............

PCAP CBW
  0040 55 53 42 43 01 00 00 00 08 00 00 00 80 00 0d 0a USBC............
  0050 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 %..............

I believe simply opening the PCAP file as BINARY instead of TEXT will fix
this issue.

Resolves: https://bugs.launchpad.net/qemu/+bug/2054889
Signed-off-by: Benjamin David Lunt <benlunt@fysnet.net>
Message-ID: <000101da6823$ce1bbf80$6a533e80$@fysnet.net>
[thuth: Break long line to avoid checkpatch.pl error]
Signed-off-by: Thomas Huth <thuth@redhat.com>
hw/usb/bus.c