[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
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 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 Mon, May 9, 2022 at 9:21 AM Guy Harris wrote: > On May 8, 2022, at 11:09 PM, Tomasz Moń wrote: > > Note that end nodes cannot directly communicate with each other. The > > communication is always between host and a device. > > Those two sentences, when combined, imply that either > > 1) a host is not an end node > > or > > 2) a device is not an end node > > or both. Which is the case? I would go with 1. However, the "end node" is not defined in USB and I think this term should be avoided in USB context. > > Device to device communication is not possible. > > Is the idea that the topology of USB is a tree, with the host at the root, > and only the leaf nodes (devices, right?) are end nodes? To some degree, yes. Note that the hubs are devices as well. The hubs present their DEVICE and CONFIGURATION descriptors to the host just like other devices. Also, hub gets address (from 1 to 127; address 0 is reserved for the not yet configured device and only one device can be in such state at any given time) assigned from host just like any other device. > And, given that this means that "end node" is not the correct term for a > piece of equipment that isn't a hub, what *is* the correct term? The equipment that isn't a hub, is "device" of the "function" class. >From Universal Serial Specification Revision 2.0, 4.8.2 Device Descriptions: Two major divisions of device classes exist: hubs and functions. Only hubs have the ability to provide additional USB attachment points. Functions provide additional capabilities to the host. --- 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 Mon, May 9, 2022 at 9:17 AM Guy Harris wrote:
> On May 8, 2022, at 10:47 PM, Tomasz Moń wrote:
> > 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.
>
> So what happens if you plug a low-speed keyboard or mouse into a host that
> supports USB 2.0? Does that link not run at low speed?
The link will run at low speed.
> "super-speed" is USB 3.0, right? No LINKTYPE_/DLT_ has been proposed for the
> 3.0 link layer, as far as I know.
Yes, "super-speed" is USB 3.0. I don't know of any open source sniffer
nor any tools that would really want to export the packets to pcap
format. Hopefully USB 3.0 is a completely separate matter.
> But no full-speed or low-speed will go over that connection, either, so it's
> never the case that, in a capture on a USB cable, there will be both
> high-speed and full/low-speed traffic, right?
Yes. You either get solely high-speed traffic or full/low-speed traffic.
> (And presumably this is for captures on a single USB cable; if you're
> capturing on more than one cable, that's with more than one capture
> interface, so that's a job for pcapng, with different interfaces having
> different link-layer types.)
Yes, combining multiple capture interfaces should be handled by pcapng.
> So, as per a few paragraphs above ("If you connect high-speed hub to
> high-speed host ... the communication on the connecting wires will be at high
> speed (480 Mb/s)."), if you have a high-speed hub connected to a high-speed
> host, and the high-speed hub has full-speed or low-speed devices downstream,
> the packets from the host to the hub, ultimately intended for the full-speed
> or low-speed device, are sent as high-speed traffic, and only the downstream
> traffic from the host to the full-speed or low-speed device is full-speed or
> low-speed?
If by "downstream traffic from the host" you mean "downstream traffic
from the hub", then this is correct.
> However, if you have a full-speed hub connected to a full-speed or high-speed
> host, and the full-speed hub has low-speed devices downstream, the packets
> from the host to the hub, ultimately intended for the low-speed device, are
> sent as a full-speed PRE packet followed by a transaction sent as low-speed
> traffic?
Yes, and only the low-speed traffic will get passed through to the
downstream low speed devices. That is, on the cable connecting to the
low speed device there is only low speed traffic.
--- 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 Mon, May 9, 2022 at 2:48 PM Michael Richardson wrote: > Tomasz Moń via tcpdump-workers wrote: > Guy> "super-speed" is USB 3.0, right? No LINKTYPE_/DLT_ has been > Guy> proposed for the 3.0 link layer, as far as I know. > > > Yes, "super-speed" is USB 3.0. I don't know of any open source sniffer > > nor any tools that would really want to export the packets to pcap > > format. Hopefully USB 3.0 is a completely separate matter. > > Are you saying that the tools use a proprietary format, or are you saying > that they would all prefer pcapng? All USB 3.0 analyzers I know of are closed systems with proprietary hardware and software. --- 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 Mon, 2022-05-09 at 07:47 +0200, Tomasz Moń wrote: > 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 arelow speed devices connected to the full speed hub). The low speed packets (after the PRE packet) intended for low-speed device connected to full-speed hub downstream port, do appear on the link between full-speed hub and full-speed device. > 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 OpenVizsla does not handle this case. While the PRE packet is correctly captured, the low-speed data is just exported by gateware as invalid packet. Similarly, the LambdaConcept USB2 sniffer does not handle this. LCSniff displays the "ERR/PRE Packet" colored in red (with no indication of the low-speed data). When OpenVizsla is configured to capture low-speed connection with the capture cable connected between host and full-speed hub, the data is just garbled. The only way to capture the low-speed data (with OpenVizsla configured to capture low-speed) is to capture it between the full-speed hub downstream port and low-speed device. I am not really surprised that both OpenVizsla and LambdaConcept USB2 sniffer fail at this problematic case. This is a corner case really, and it is not that much relevant nowadays where majority of hubs are high-speed capable. When the high-speed hub is connected to high-speed host, there is no problem with full/low speed packets as each downstream port receives data at target device speed. I am not sure if the capture problem can be solved with current OpenVizsla and LambdaConcept USB2 sniffer design. If possible, then the necessary changes would require gateware modifications. --- 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 Mon, 2022-05-09 at 08:44 -0400, Michael Richardson wrote: > A capture from a host to a hub with a mix of downstream devices would > seem to include transmissions at different speeds. The problem is only when capturing at full-speed where either the host or hub is full-speed only (i.e. not high-speed capable) and there is low-speed device connected to the hub. I think the corner case is not going to be experienced by majority of users. The fact that both OpenVizsla and LambdaConcept USB2 Sniffer fail to capture such links (and there is not even an issue reported at these projects issue trackers) supports my opinion. As long as you have high-speed hub and host, the full-speed/low-speed problem is not going to hit you. > PCAP format can not mix LINKTYPES in the same file. > That is the *major* feature that pcapng has. > tcpdump/libpcap can't write pcapng files *yet*, and it would seem > that you'd > need that if you want to mark the speed using different LINKTYPEs. Yes, I think this is fine. > I'm happy to allocate the new LINKTYPEs you want, as long as you > understand the limitations. The pcap format limitations are fine with me. > I would personally make the speed an attribute of a > speed-independant linktype. That would require defining pseudoheader that would have to be included in every packet. And it would only solve the corner case that the currently available open-source friendly sniffers do not presently handle. I think it is fine to assume that any tool that would create full-speed captures that contain both full-speed and low-speed data should be able to write pcapng file (or simply create two separate pcap files). --- 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 Mon, 2022-05-09 at 11:52 -0700, Guy Harris wrote: > On May 9, 2022, at 1:58 AM, Tomasz Moń wrote: > > > On Mon, May 9, 2022 at 9:17 AM Guy Harris > > wrote: > > > On May 8, 2022, at 10:47 PM, Tomasz Moń > > > wrote: > > > > 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. > > > > > > So what happens if you plug a low-speed keyboard or mouse into a > > > host that supports USB 2.0? Does that link not run at low speed? > > > > The link will run at low speed. > > So what kind of bus is that link? High-speed, full/low-speed, or > low-speed? The reason for "full/low-speed" bus is because the original USB 1.0 and 1.1 only supported full and low speed. The hub was really operating like a network hub, and the slight speed difference between full and low speed (8x) was handled by the PRE packets and blocking of downstream ports. With the USB 2.0 release, the high-speed bus was added. There the hub is operating more like a network switch. The downstream ports no longer receive full or low speed data - the host selects only one port that the full/low-speed traffic should be relayed to. There is no such thing as "low-speed bus" because low-speed is only allowed for non-hub devices. USB hosts and hubs *must* support atleast full and high speed. USB devices are allowed to be low-speed (such devices can operate *only* at low speed). The high-speed device can operate as full-speed or high-speed devices depending on host/hub the device is connected to. High-speed or Full- speed device cannot ever operate at low-speed (the full-speed hub related traffic, e.g. control transfers to hub, are always full-speed). It is important that the analysis engine know whether the packets were full or low-speed as there are slightly different rules. There is not so clear distinction between layers as USB does not really use ISO/OSI model. So I think it definitely makes sense to have separate link types for full-speed and low-speed. > > > But no full-speed or low-speed will go over that connection, > > > either, so it's never the case that, in a capture on a USB cable, > > > there will be both high-speed and full/low-speed traffic, right? > > > > Yes. You either get solely high-speed traffic or full/low-speed > > traffic. > > OK, so it makes sense to have a separate link-layer type for high- > speed traffic, rather than a single link-layer type for "USB link- > layer with metadata header, with the per-packet metadata header > indicating the speed". > > But, if, as you said earlier: > > > 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. > > can there be separate link-layer types for full-speed and low-speed > traffic, or does there need to be a single type for full/low-speed > traffic, with a per-packet metadata header indicating the speed"? I am definitely in favour of the separate link-layer types for full- speed and low-speed traffic. The mixed full-speed and low-speed on single cable (when there is full- speed hub involved) is there for backwards compatibility and you have to actually try hard to trigger it these days. But even if you do trigger, there is simple workaround: * if you are interested in full-speed traffic, simply set sniffer capture speed to full-speed and *ignore* the invalid packets reported after PRE packets * if you are interested in low-speed traffic, set sniffer capture speed to low-speed and *connect* the cable between hub downstream port and the low-speed device (this cable only ever sees low-speed traffic) If the user is debugging issues related to handling PRE packets by full-speed hub, then oscilloscope (or logic analyzer) is much better option than packet-level capture like OpenVizsla. --- 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 Mon, 2022-05-09 at 12:02 -0700, Guy Harris wrote: > On May 9, 2022, at 7:41 AM, Tomasz Moń wrote: > > > That would require defining pseudoheader that would have to be > > included in every packet. > > Is that really a great burden? I think it would make it harder to understand the protocol for newcomers that use tools like Wireshark to try to make sense of USB. > > And it would only solve the corner case that the > > currently available open-source friendly sniffers do not presently > > handle. > > The point isn't to just handle what currently available open-source > friendly sniffers handle. I'd prefer to leave room for future > sniffers that *do* handle it. > > > I think it is fine to assume that any tool that would create full- > > speed > > captures that contain both full-speed and low-speed data should be > > able > > to write pcapng file (or simply create two separate pcap files). > > I think that, if you're capturing on a link between a full/low-speed > host and a full/low-speed hub, with low-speed devices plugged into > that hub, it would not make sense to treat that link as two > interfaces, with one interface handling full-speed packets and one > interface handling low-speed packets; I see that as an ugly > workaround. > > So I see either > > 1) a link-layer type for full/low-speed traffic, with a per- > packet pseudo-header > > or > > 2) don't support full/low-speed traffic capture, just support > full-speed-only and low-speed-only traffic capture > > as the reasonable choices. The choice number 2 is essentially what the OpenVizsla does. --- 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 Mon, 2022-05-09 at 12:52 -0700, Guy Harris wrote: > On May 9, 2022, at 12:40 PM, Tomasz Moń wrote: > > > On Mon, 2022-05-09 at 12:02 -0700, Guy Harris wrote: > > > On May 9, 2022, at 7:41 AM, Tomasz Moń wrote: > > > > > > > That would require defining pseudoheader that would have to be > > > > included in every packet. > > > > > > Is that really a great burden? > > > > I think it would make it harder to understand the protocol for > > newcomers that use tools like Wireshark to try to make sense of > > USB. > > In what fashion would it do so? The same as why URB level captures are confusing. Maybe not to the same level as that would be just a single byte (and the URB metadata contains way more information), but it would still raise the questions like "where in USB specification this byte is defined?", "Why this doesn't match all the documents on USB that I have read?". --- 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 Mon, 2022-05-09 at 13:19 -0700, Guy Harris wrote: > On May 9, 2022, at 1:02 PM, Tomasz Moń wrote: > > > The same as why URB level captures are confusing. Maybe not to the > > same > > level as that would be just a single byte (and the URB metadata > > contains way more information), but it would still raise the > > questions > > like "where in USB specification this byte is defined?", > > To what extent are people analyzing 802.11 captures raising the > question "where in the 802.11 specification are the fields of the > radiotap header defined?" Probably low, as the 802.11 is *really* complex. > If the answer is "to a minimal extent" or "it doesn't happen", what > about USB would make the answer different? I would say the differentiating factor between network protocols and USB is the fact that USB does not adhere to Open Systems Interconnection model (OSI model) but network protocols generally do. For USB you can check [1], but it was presented before usbll dissector was written. Not sure much much it answers your question though. > > "Why this doesn't match all the documents on USB that I have > > read?". > > What is the "this" that wouldn't match? Packet Bytes as shown by Wireshark. Also Wireshark would have to show "USB Full/Low speed capture" section with only the single byte denoting full or low speed, followed by "USB Link Layer" (as shown currently for usbll captures). [1] https://youtu.be/67swnr1NCP4?t=321 --- 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 Tue, May 10, 2022 at 6:57 AM Guy Harris wrote: > On May 9, 2022, at 9:41 PM, Tomasz Moń wrote: > > Also Wireshark would have to show "USB Full/Low speed capture" section with > > only the single byte denoting > > full or low speed, followed by "USB Link Layer" (as shown currently for > > usbll captures). > > No, it wouldn't. It would just display that as an item in "USB Link Layer". If you displayed that in USB Link Layer, without marking it as Wireshark generated field (and it shouldn't be marked as Wireshark generated because it was in capture file) it would be confusing. Currently everything that is shown under the USB Link Layer except the clearly marked Wireshark-generated fields, are the actual contents of what USB calls a packet. --- 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 Mon, May 9, 2022 at 10:17 PM Guy Harris wrote: > On May 9, 2022, at 12:31 PM, Tomasz Moń wrote: > > There is no such thing as "low-speed bus" because low-speed is only > > allowed for non-hub devices. USB hosts and hubs *must* support atleast > > full and high speed. USB devices are allowed to be low-speed (such > > devices can operate *only* at low speed). > > So what is the term used for a cable between a low-speed-only device and > either a host or a hub? Universal Serial Bus Specification Revision 2.0: 6.6 Cable Mechanical Con figuration and Material Requirements does specify: High-/full-speed and low-speed cables differ in data conductor arrangement and shielding. and then it specifies: 7.1.1.2 Low-speed (1.5 Mb/s) Driver Characteristics A low-speed device must have a captive cable with the Series A connector on the plug end. So the term is "low-speed cable" and that cable is not removable (captive cable is attached to the circuit board). > The USB 2.0 spec appears to use "bus" for an "edge", in the graph-theory > sense: > > https://en.wikipedia.org/wiki/Glossary_of_graph_theory#edge > > rather than for the entire tree. In USB 1.x the "bus" did stand for the entire tree. Then it diverged in subsequent revisions :-) > What *is* the correct term to use for a single cable, the traffic on which > one might be sniffing? "Low-speed cable" and "High-/full-speed cable" (hopefully this discussion does not cover later revisions where the cabling is way more complicated). > > It is important that the analysis engine know whether the packets were > > full or low-speed as there are slightly different rules. There is not > > so clear distinction between layers as USB does not really use ISO/OSI > > model. > > > > So I think it definitely makes sense to have separate link types for > > full-speed and low-speed. > > It makes sense to indicate whether packets are full-speed or low-speed; > nobody is arguing otherwise. > > The question is whether the right way to do that is to have separate link > types, so that you can't have a mix of full-speed and low-speed packets in a > single pcap capture or on a single interface in a pcapng capture, or to have > a single link-layer type with a per-packet full-speed/low-speed indicator. I think the separate link types are the way to go. The full to low speed transition is not technically a packet, but rather a "Preamble". While the transceivers, e.g. the one used in OpenVizsla, have special mode to send that preamble together with low-speed packet, they do not have a mode to capture low-speed transactions. The handling logic has to be bundled in specialized hub chip (and only there, the non-hub full speed devices will happily discard what they see as garbage). --- 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 Tue, 2022-05-10 at 07:28 +0200, Tomasz Moń wrote: > On Mon, May 9, 2022 at 10:17 PM Guy Harris wrote: > > On May 9, 2022, at 12:31 PM, Tomasz Moń wrote: > > > It is important that the analysis engine know whether the packets > > > were > > > full or low-speed as there are slightly different rules. There is > > > not > > > so clear distinction between layers as USB does not really use > > > ISO/OSI > > > model. > > > > > > So I think it definitely makes sense to have separate link types > > > for > > > full-speed and low-speed. > > > > It makes sense to indicate whether packets are full-speed or low- > > speed; nobody is arguing otherwise. > > > > The question is whether the right way to do that is to have > > separate link types, so that you can't have a mix of full-speed and > > low-speed packets in a single pcap capture or on a single interface > > in a pcapng capture, or to have a single link-layer type with a > > per-packet full-speed/low-speed indicator. > > I think the separate link types are the way to go. > > The full to low speed transition is not technically a packet, but > rather a "Preamble". While the transceivers, e.g. the one used in > OpenVizsla, have special mode to send that preamble together with > low-speed packet, they do not have a mode to capture low-speed > transactions. The handling logic has to be bundled in specialized hub > chip (and only there, the non-hub full speed devices will happily > discard what they see as garbage). It should be noted that when (and if) low-speed traffic is received on full-speed device differential pair (D+/D-), it is never intended for the full-speed device and the full-speed device never acts upon it (full-speed hub simply forwards low-speed traffic, non-hub devices simply ignore it). When user does full-speed only capture using hardware sniffer, the user intends to see full-speed packets. If the resulting capture includes PRE token, it is clear that there was some low-speed traffic. And it is clear that the low-speed traffic was not in any way related to any full-speed function. When low-speed capture is performed, it has to be performed at the leaf (in graph-theory sense) connection. Full-speed traffic never make it to the low-speed cables, so the capture will contain only low-speed packets. --- 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 Tue, 2022-05-10 at 21:31 +0200, Tomasz Moń wrote: > On Tue, 2022-05-10 at 07:28 +0200, Tomasz Moń wrote: > > On Mon, May 9, 2022 at 10:17 PM Guy Harris wrote: > > > It makes sense to indicate whether packets are full-speed or low- > > > speed; nobody is arguing otherwise. > > > > > > The question is whether the right way to do that is to have > > > separate link types, so that you can't have a mix of full-speed and > > > low-speed packets in a single pcap capture or on a single interface > > > in a pcapng capture, or to have a single link-layer type with a > > > per-packet full-speed/low-speed indicator. > > > > I think the separate link types are the way to go. > > > > The full to low speed transition is not technically a packet, but > > rather a "Preamble". While the transceivers, e.g. the one used in > > OpenVizsla, have special mode to send that preamble together with > > low-speed packet, they do not have a mode to capture low-speed > > transactions. The handling logic has to be bundled in specialized hub > > chip (and only there, the non-hub full speed devices will happily > > discard what they see as garbage). > > It should be noted that when (and if) low-speed traffic is received on > full-speed device differential pair (D+/D-), it is never intended for > the full-speed device and the full-speed device never acts upon it > (full-speed hub simply forwards low-speed traffic, non-hub devices > simply ignore it). > > When user does full-speed only capture using hardware sniffer, the user > intends to see full-speed packets. If the resulting capture includes > PRE token, it is clear that there was some low-speed traffic. And it is > clear that the low-speed traffic was not in any way related to any > full-speed function. > > When low-speed capture is performed, it has to be performed at the leaf > (in graph-theory sense) connection. Full-speed traffic never make it to > the low-speed cables, so the capture will contain only low-speed > packets. Is there anything still to discuss here? I have opened the pull requests [1] [2] few weeks ago. I have also prepared Wireshark [3] change that I would like to merge before Wireshark 4.0 release. I think I have summed up whole discussion in the libpcap commit message. High-speed and Low-speed are pretty much clear, as these links never observe other speed packets. Full-speed is the only disputable one, but I believe the PRE packets are really a corner case that is not worth per-packet speed encoding. If the user has obsolete setup to trigger the corner case in the first place, then such user will definitely know to just capture at the downstream link for low-speed traffic. >From packet level analysis point of view, it is simply enough to know that there was some low-speed transaction that is not included in the capture as the full-speed devices ignore the low-speed transactions anyway. This is what the PRE packet (just one byte) in full-speed capture means. If there is something wrong with the PRE packet handling in full-speed hub, then packet analyzer is not really the right tool. The right tool would be 4 channel oscilloscope with 2 channels connected to upstream D+/D- and 2 channels to downstream D+/D-. [1] https://github.com/the-tcpdump-group/libpcap/pull/1109 [2] https://github.com/the-tcpdump-group/tcpdump-htdocs/pull/29 [3] https://gitlab.com/wireshark/wireshark/-/merge_requests/7045 --- 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 Tue, 2022-06-14 at 10:49 -0400, Michael Richardson wrote: > Tomasz Moń via tcpdump-workers wrote: > > I think I have summed up whole discussion in the libpcap commit > > message. High-speed and Low-speed are pretty much clear, as these links > > never observe other speed packets. Full-speed is the only disputable > > one, but I believe the PRE packets are really a corner case that is not > > worth per-packet speed encoding. If the user has obsolete setup to > > trigger the corner case in the first place, then such user will > > definitely know to just capture at the downstream link for low-speed > > traffic. > > I think that Guy and I thought that you'll be better off with a single > LINKTYPE with a subtype header, but if you want to go with three, I don't > object. I don't see any value (and according to information theory there is no information) in per packet subtype header that would be set to exactly the same value for *every single packet* captured on Low- or High-speed link. It would also be the same value for every single packet captured on Full-speed link with either OpenVizsla or LambdaConcept USB2Sniffer as it is impossible for these sniffers to capture both Full- and Low- speed packets during single capture session. If, for whatever reason, the user wants to merge multiple captures, then pcapng format should be used as pcapng can preserve the information that the packets came from different sources (pcap format cannot do that). I have updated ovextcap draft pull request [1] to present low-speed- only, full-speed-only and high-speed-only capture options when run with Wireshark version that supports the speed specific linktypes. This matches the "don't support full/low-speed traffic capture, just support full-speed-only and low-speed-only traffic capture" reasonable choice mentioned in Guy Harris email sent on 9 May 2022. [1] https://github.com/matwey/libopenvizsla/pull/26 --- 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 Mon, 2022-06-20 at 08:34 -0400, Michael Richardson wrote: > Tomasz Moń wrote: > > On Tue, 2022-06-14 at 10:49 -0400, Michael Richardson wrote: > >> Tomasz Moń via tcpdump-workers wrote: > >> > I think I have summed up whole discussion in the libpcap commit > >> > message. High-speed and Low-speed are pretty much clear, as > these links > >> > never observe other speed packets. Full-speed is the only > disputable > >> > one, but I believe the PRE packets are really a corner case that > is not > >> > worth per-packet speed encoding. If the user has obsolete setup > to > >> > trigger the corner case in the first place, then such user will > >> > definitely know to just capture at the downstream link for > low-speed > >> > traffic. > >> > >> I think that Guy and I thought that you'll be better off with a single > >> LINKTYPE with a subtype header, but if you want to go with three, I > don't > >> object. > > > I don't see any value (and according to information theory there is no > > information) in per packet subtype header that would be set to exactly > > the same value for *every single packet* captured on Low- or High-speed > > link. > > That's fine with me. > I will merge the pull request this afternoon. A week has passed and the pull requests are still pending. Is there anything left to do on my end? Best Regards, Tomasz --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
