Re: [tcpdump-workers] Speed specific Link-Layer Header Types for USB 2.0
--- Begin Message --- On Sun, May 8, 2022 at 11:15 PM Guy Harris wrote: > On May 8, 2022, at 1:30 PM, Michael Richardson wrote: > > I guess I would have thought that a physical bus could have a mix of > > different devices which operate at different speeds. As such, I wondered if > > you really needed pcapng to be able to mix LINKTYPES in the same file, or > > a different bit of meta-data to indicate bus speed for each frame captured. In most cases all the packets will be at the same speed. The only corner case is how the full/low speed is being handled. This dates back to the original USB 1.0 specification and is kept for compatibility reasons. > > But, maybe I'm wrong and that actually requires there to be a USB hub out > > there. The hub is the complex part. Between host and device, with no intermediate hubs in the path, all packets are always sent at the same speed. > I think a point-to-point connection between the host and another entity may > always run at a single speed, as well as a connection between a hub and a > function. > > It might also be the case that a hub-to-hub connection also runs at a single > speed. Section 11.14 "Transaction Translator" says: > > A hub has a special responsibility when it is operating in high-speed > and has full-/low-speed devices connected on downstream facing ports. In this > case, the hub must isolate the high-speed signaling environment from the > full-/low-speed signaling environment. This function is performed by the > Transaction Translator (TT) portion of the hub. > > so if you have a full-speed or low-speed device plugged into a USB 2.0 hub, > and that hub is connected to a host, the host-to-hub link is high-speed, and > the hub-to-device link is full-speed or low-speed, and the hub does the > translation. That way, you can plug a high-speed device and a full-speed or > low-speed device into the hub, and the host will be able to talk at high > speed to the high-speed device. All packets between high speed host and high speed hub are at high speed (including the packets that are intended for a full or low speed devices). Transaction Translator basically buffers the data and sends/receives packets to/from downstream devices at the correct speed (full/low). Determining the target device speed during (the high speed traffic from host to hub) dissection is simple as the speed is indicated in the SPLIT packet. > USB isn't a shared bus like non-switched Ethernet; it's more like switched > Ethernet or point-to-point Ethernet, with links being point-to-point, either > a direct connection between end nodes or connections to a switching device > that handles speed translation if two end nodes of different speed > capabilities are communicating. Note that end nodes cannot directly communicate with each other. The communication is always between host and a device. Device to device communication is not possible. If Transaction-Translator is involved, it essentially fulfills the speed translation from host (when reading from downstream device Transaction Translator does keep issuing IN until the device responds with data or stalls the endpoint; as long as NAKs are received Transaction Translator will keep responding to the host SPLIT COMPLETE with NYET). --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Speed specific Link-Layer Header Types for USB 2.0
--- Begin Message --- On Sun, May 8, 2022 at 8:53 PM Guy Harris wrote: > At least from a quick look at section 5.2.3 "Physical Bus Topology" of the > USB 2.0 spec, a given bus can either be a high-speed bus or a full/low-speed > bus. The full/low-speed bus applies only to upstream link from full speed hub. > The idea, then, is presumably that a capture tool is capturing on a single > bus (single wire), so it's either capturing on a high-speed bus or a > full/low-speed bus. I assume that by single wire you meant "single wire pair" (differential pair). USB 2.0 has only single differential pair, formed by D+ and D- signal wires, so the high/full/low speed communication always occurs on the same wire pair. > It looks as if a high-speed bus will always run at 480 Mb/s, so that capture > would be a LINKTYPE_USB_2_0_HIGH_SPEED capture. Is that correct? Yes. If you connect high-speed hub to high-speed host (or super-speed host, but super-speed host essentially contains high-speed host, aka dual-bus) the communication on the connecting wires will be at high speed (480 Mb/s). Similarly if high-speed device is connected to high-speed host (or hub) then the communication will be at high speed. > For full/low-speed buses, will those also always run at full peed or low > speed, so that there would never be a mixture of full-speed and low-speed > transactions? If you capture at the connection between low speed device and host/hub, there will only ever be low speed packets. It would be a LINKTYPE_USB_2_0_LOW_SPEED capture. The problematic case (and the reason why full/low-speed bus is mentioned) is the LINKTYPE_USB_2_0_FULL_SPEED. It is the case when you capture at the connection between full speed hub and the host (and possibly full speed device connected to a full speed hub if there are low speed devices connected to the full speed hub). If there is low speed device connected to downstream hub port, then when the host wants to send packets to the low speed device, these will be sent at low speed to the hub. However, there will be PRE packet (sent at full speed) before every low speed transaction. Hopefully I have recently found full-speed only hub (thanks to Linux kernel bug report [1]), so I have all the equipment necessary to check how the OpenVizsla deals with the problematic case. [1] https://bugzilla.kernel.org/show_bug.cgi?id=213839 --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Speed specific Link-Layer Header Types for USB 2.0
--- Begin Message --- On May 8, 2022, at 1:30 PM, Michael Richardson wrote: > I guess I would have thought that a physical bus could have a mix of > different devices which operate at different speeds. As such, I wondered if > you really needed pcapng to be able to mix LINKTYPES in the same file, or > a different bit of meta-data to indicate bus speed for each frame captured. > > But, maybe I'm wrong and that actually requires there to be a USB hub out > there. "Bus" is a bit weird here. To quote section 4.1.1 "Bus Topology" of the USB 2.0 pec: The USB connects USB devices with the USB host. The USB physical interconnect is a tiered star topology. A hub is at the center of each star. Each wire segment is a point-to-point connection between the host and a hub or function, or a hub connected to another hub or function. Figure 4-1 illustrates the topology of the USB. and Figure 5-6 "Multiple Full-speed Buses in a High-speed System" seems to use the term "bus" to refer to wire segments. I think a point-to-point connection between the host and another entity may always run at a single speed, as well as a connection between a hub and a function. It might also be the case that a hub-to-hub connection also runs at a single speed. Section 11.14 "Transaction Translator" says: A hub has a special responsibility when it is operating in high-speed and has full-/low-speed devices connected on downstream facing ports. In this case, the hub must isolate the high-speed signaling environment from the full-/low-speed signaling environment. This function is performed by the Transaction Translator (TT) portion of the hub. so if you have a full-speed or low-speed device plugged into a USB 2.0 hub, and that hub is connected to a host, the host-to-hub link is high-speed, and the hub-to-device link is full-speed or low-speed, and the hub does the translation. That way, you can plug a high-speed device and a full-speed or low-speed device into the hub, and the host will be able to talk at high speed to the high-speed device. USB isn't a shared bus like non-switched Ethernet; it's more like switched Ethernet or point-to-point Ethernet, with links being point-to-point, either a direct connection between end nodes or connections to a switching device that handles speed translation if two end nodes of different speed capabilities are communicating.--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Speed specific Link-Layer Header Types for USB 2.0
--- Begin Message --- On May 8, 2022, at 4:48 AM, Tomasz Moń via tcpdump-workers wrote: > 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. To quote a comment of yours in the Wireshark issue: > I should have gone for three separate link-layer header types for "USB > 1.0/1.1/2.0 packets" each at different capture speed (low/full/high). I think > technically we can still add these alongside the current "unknown speed" one. > The reason behind having separate link-layer header types is that the capture > tool must know the capture link speed (agreed speed does not change during > the transmission, and the handshaking is not on packet level) and the capture > link speed is useful when analyzing packets. At least from a quick look at section 5.2.3 "Physical Bus Topology" of the USB 2.0 spec, a given bus can either be a high-speed bus or a full/low-speed bus. The idea, then, is presumably that a capture tool is capturing on a single bus (single wire), so it's either capturing on a high-speed bus or a full/low-speed bus. It looks as if a high-speed bus will always run at 480 Mb/s, so that capture would be a LINKTYPE_USB_2_0_HIGH_SPEED capture. Is that correct? For full/low-speed buses, will those also always run at full peed or low speed, so that there would never be a mixture of full-speed and low-speed transactions?--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Speed specific Link-Layer Header Types for USB 2.0
--- Begin Message --- 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
