Wireshark-bugs: [Wireshark-bugs] [Bug 12145] New: USB request/response tracking using USBPCap
| Bug ID |
12145
|
| Summary |
USB request/response tracking using USBPCap
|
| Product |
Wireshark
|
| Version |
Git
|
| Hardware |
x86
|
| OS |
Windows 7
|
| Status |
UNCONFIRMED
|
| Severity |
Major
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
bugzilla-admin@wireshark.org
|
| Reporter |
stefan.battmer@matrix-vision.de
|
Created attachment 14346 [details]
Shows request/respose tracking problem
Build Information:
TShark (Wireshark) 2.1.0 (v2.1.0rc0-1941-g3d08acb from master)
Copyright 1998-2016 Gerald Combs <gerald@wireshark.org> and contributors.
License GPLv2+: GNU GPL version 2 or later
<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (32-bit) with WinPcap (4_1_3), with libz 1.2.8, with GLib 2.38.0, with
SMI 0.4.8, with c-ares 1.9.1, with Lua 5.2, with GnuTLS 3.2.15, with Gcrypt
1.6.2, with MIT Kerberos, with GeoIP.
Running on 64-bit Windows 7 Service Pack 1, build 7601, with locale
German_Germany.1252, with WinPcap version 4.1.2 (packet.dll version
4.1.0.2001),
based on libpcap version 1.0 branch 1_0_rel0b (20091008), with GnuTLS 3.2.15,
with Gcrypt 1.6.2.
Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz (with SSE4.2), with 4031MB of
physical memory.
Built using Microsoft Visual C++ 12.0 build 40629
--
Hi there,
my request seems somewhat related to a bugfix made in
https://code.wireshark.org/review/#/c/7781/.
Using the current source code it seems to me that the request/response tracking
using the no built-in USBPCap doesn't seem to work reliably. I attached a
sample capture file that can be used to reproduce the issue. Packets 8 and 9 as
well as 12 and 13 are correctly matched, other are not.
To me it seems that this only works on a random basis. I tried to dig into the
code in packet-usb.c a little:
static gint
dissect_usbpcap_buffer_packet_header(tvbuff_t *tvb, packet_info *pinfo,
proto_tree *tree,
usb_conv_info_t *usb_conv_info, guint32 *win32_data_len, guint64
*irp_id)
{
guint8 transfer_type;
guint8 endpoint_byte;
guint8 transfer_type_and_direction;
guint8 tmp_val8;
proto_tree_add_item(tree, hf_usb_win32_header_len, tvb, 0, 2,
ENC_LITTLE_ENDIAN);
*irp_id = tvb_get_guint64(tvb, 2, ENC_LITTLE_ENDIAN); /// <- This extracts
an ID used for matching
....
case USB_HEADER_USBPCAP:
offset = dissect_usbpcap_buffer_packet_header(tvb, pinfo, tree,
usb_conv_info, &win32_data_len, &usb_id); /// <- This calls the function that
will extract the ID used for matching
....
} else {
/* this is a response */
if (pinfo->fd->flags.visited) {
usb_trans_info = (usb_trans_info_t
*)wmem_tree_lookup32_array(usb_conv_info->transactions, key);
} else {
usb_trans_info = (usb_trans_info_t
*)wmem_tree_lookup32_array_le(usb_conv_info->transactions, key);
if (usb_trans_info) {
if (usb_trans_info->usb_id == usb_id) { /// <- Here the actual
matching is done. However it seems like this only works from time to time when
USBPCap 'by accident' uses the same IRP for 2 consecutive packets
if (usb_trans_info->response_in == 0) {
/* USBPcap generates 2 frames for response; store the first
one */
usb_trans_info->response_in = pinfo->num;
}
wmem_tree_insert32_array(usb_conv_info->transactions, key,
usb_trans_info);
} else {
usb_trans_info = NULL;
}
}
}
When trying the same with a trace recorded under Linux the request/response
tracking works. However here also a different approach is used. Under Linux
there will be 2 packets per USB transaction while under Windows using USBPCap
there is only one packet showing up in Wireshark. This to me raises the
question if under Windows this can work at all. As there is just a single
packet per transaction which packet it shall be matched against? Ideally I
guess this can only be done when knowing the details about a dedicated USB
protocol, thus if a device has something like a request -> ACK protocol these
shall be matched, but this can only be done in a custom protocol aware
dissector, right?
You are receiving this mail because:
- You are watching all bug changes.
