Re: [tcpdump-workers] Speed specific Link-Layer Header Types for USB 2.0
--- Begin Message ---
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 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.
Sorry - that's "wire" in the sense of "cable", not in the literal sense.
>> 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.
"super-speed" is USB 3.0, right? No LINKTYPE_/DLT_ has been proposed for the
3.0 link layer, as far as I know.
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?
(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.)
>> 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.
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?
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?--- 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 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? > 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? 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? --- 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 May 9, 2022, at 1:33 AM, Tomasz Moń wrote: > On Mon, May 9, 2022 at 9:21 AM Guy Harris wrote: >> On May 8, 2022, at 11:09 PM, Tomasz Moń wrote: >> >>> 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. (So "communication is not possible" in "Device to device communication is not possible." preferably refers not to sending USB link layer messages from device to device, but refers to higher protocol layers; otherwise, you wouldn't be able to plug a disk, network device, keyboard, mouse, etc. into a hub and have it communicate with a host also plugged into the hub.) --- 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 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? >> "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. And, if there ever *are* (I see no reason to rule it out), they can ask for another link-layer type when they need it. >> 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"?--- 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 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? > 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. (Note that both tcpdump and Wireshark still have their Token Ring dissection code; heck, Wireshark has even had 3MB Xerox PARC Ethernet dissection code for a while now!)--- 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 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? --- 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 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? 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. What *is* the correct term to use for a single cable, the traffic on which one might be sniffing? > 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. --- 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 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?" If the answer is "to a minimal extent" or "it doesn't happen", what about USB would make the answer different? > "Why this doesn't match all the documents on USB that I have read?". What is the "this" that wouldn't match? --- 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 May 9, 2022, at 9:41 PM, Tomasz Moń wrote: > On Mon, 2022-05-09 at 13:19 -0700, Guy Harris wrote: >> On May 9, 2022, at 1:02 PM, Tomasz Moń wrote: >> >>> "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. OK, thet suggests that it's time to finally default to *NOT* showing metadata in the packet bytes pane of Wireshark and in hex dump data in tcpdump, as the only time its raw content is of interest is if you're debugging either 1) software that generates those headers or 2) software that dissects those headers. *That* will quite effectively prevent people from asking where that byte is defined in a USB spec, as that byte won't be there in the first place. > 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". --- 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 May 9, 2022, at 10:05 PM, Tomasz Moń wrote: > 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. Then show it as "USB physical layer information", similar to what's done for "802.11 radio layer information". --- 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
