Re: Speed specific Link-Layer Header Types for USB 2.0

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

> --- Begin Message ---
>
>
> From: Tomasz Moń <desowin () gmail com>
>
> Date: Mon, 9 May 2022 10:33:52 +0200
>
> On Mon, May 9, 2022 at 9:21 AM Guy Harris <gharris () sonic net> wrote:
> > On May 8, 2022, at 11:09 PM, Tomasz Moń <desowin () gmail com> 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