Speed specific Link-Layer Header Types for USB 2.0

[Tomasz Moń via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Tomasz Moń <desowin () gmail com>
>
> Date: Sun, 08 May 2022 13:48:20 +0200
>
> Hello,
>
> Back in 2019 I have requested Link-Layer Header Type for USB 2.0 [1].
> Unfortunately, I didn't foresee the problems with dissecting packets at
> effectively "unknown" capture speed. That is, while the host, device
> and capture tool were all aware about the speed, the resulting pcap
> misses that information.
>
> For the most part speed does not really matter. It is the corner cases,
> and especially device and/or host misbehaviour where the speed matters.
> See [2] for example capture where the capture speed information would
> be useful.
>
> Differences between speeds include atleast (list is incomplete):
>   * SPLIT transactions are only allowed at High Speed
>   * Bulk endpoint wMaxPacketSize maximum value is 64 at Full Speed and
> 512 at High Speed (Bulk is not allowed at Low Speed)
>   * SOF is send every 1 ms at Full Speed and every 125 us at High Speed
> (SOF is not send at Low Speed)
>   * SOF is not send at Low Speed
>   * Isochronous endpoint wMaxPacketSize maximum value is 1023 at Full
> Speed and 1024 at High Speed (Isochronous is not allowed at Low Speed)
>
> For existing LINKTYPE_USB_2_0 captures the analysis programs can ask
> the user to specify the capture speed but that is annoyance as the
> speed would have to be provided on per-capture basis.
>
> I would like to remedy the situation by requesting additional speed
> specific link layer header types, for example:
>   * LINKTYPE_USB_2_0_LOW_SPEED
>   * LINKTYPE_USB_2_0_FULL_SPEED
>   * LINKTYPE_USB_2_0_HIGH_SPEED
>
> The description for existing LINKTYPE_USB_2_0 could be updated to
> mention that for new captures, the speed specific link layer header
> types should be used to enable better dissection.
>
> Best Regards,
> Tomasz Moń
>
> [1] https://www.mail-archive.com/tcpdump-workers () lists tcpdump org/msg08785.html
> [2] https://gitlab.com/wireshark/wireshark/-/issues/18062
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers