--- 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 di
--- 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
>
--- 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;
--- 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
>
--- 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
>
--- 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, followe
--- 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 metada
--- 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:
> > >
> > > > Tha
--- 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
--- 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:
> > >
--- 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-spee
--- 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 p
--- 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.
>
> >
--- 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
> >>
--- 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,
--- 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
--- 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 ful
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] htt
On Tue, Jul 23, 2019 at 8:27 AM Guy Harris wrote:
> So "USB 2.0" really means "USB 2.0", and we could describe this as something
> such as
>
> LINKTYPE_USB_2_0XXX DLT_USB_2_0 USB 2.0, 1.1, or 1.0
> packet, beginning with a PID, as described by Chapter 8 "Protocol Layer" o
On Tue, Jul 23, 2019 at 3:59 AM Guy Harris wrote:
> The issue isn't the hardware signals.
The link layer protocols are so different that in order for USB 3.0
SuperSpeed devices to be compatible with USB 2.0 hosts, such device
have to implement *both* USB 3.0 link layer and USB 2.0 link layer.
USB
On Sun, Jul 21, 2019 at 10:47 PM Guy Harris wrote:
> It looks as if USB 3.1's packets are different from USB 2.0's packets, so
> this would be 2.0-specific.
USB 3 operates on different hardware signals. USB 3 hubs do contain
USB 3 and USB 2.0 hubs inside them.
The USB 2.0 data is sent on the D+/
Start-
and End-of-Packet delimiters. The packet format is described in
Chapter 8 Protocol Layer of Universal Serial Bus Specification
Revision 2.0.
Best Regards,
Tomasz Moń
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https
On Mon, Mar 25, 2013 at 11:08 AM, Guy Harris wrote:
>> #pragma pack(1)
>> typedef struct
>> {
>> USHORT headerLen; /* This header length */
>> UINT64 irpId; /* I/O Request packet ID */
>
> So headerLen is at an offset of 0, and irpId is at an offset of 2, right?
Exactly.
Hello,
For the USBPcap project I would like to request a new link-layer
header type value:
LINKTYPE_USBPCAP
DLT_USBPCAP
Capture format specification is available at the project website [1]
and could be described as pseudo-header for USB packets captured using
USBPcap on Microsoft Windows.
Regard
24 matches
Mail list logo
