All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: "Tomasz Moń" <desowin@gmail.com>
Cc: linux-usb@vger.kernel.org, Pete Zaitcev <zaitcev@redhat.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jonathan Corbet <corbet@lwn.net>
Subject: Re: Use of address 0 in usbmon
Date: Tue, 7 Jan 2020 12:41:52 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.2001071234330.1567-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <CAOHtt39wC1RzRWPi2hb6vS7EZWoVxGGHqeten=3a6M-jYGWkcA@mail.gmail.com>

On Tue, 7 Jan 2020, Tomasz Moń wrote:

> Hello,
> 
> Linux kernel allows submitting URBs directed at Root Hub. These
> include, but are not limited to, the hub port control requests
> (CLEAR_FEATURE, GET_STATUS). While it works fine and simplifies the
> code, such requests gets reported by usbmon as directed to device
> address 0, which is not quite true.

Before the patch you sent in yesterday, usbmon reported these requests
as directed to device number 1 (which is the number assigned to root
hubs since they are the first devices registered on their USB buses),
not 0.

With the change you made, things aren't so simple any more.  The kernel 
does not control the addresses assigned by the xHCI controller, and 
there's no guarantee that the controller won't use all the addresses 
from 1 to 127 for plugged-in devices, leaving no number available to 
represent the root hub.

> The device address 0 is assigned to device after reset. When capturing
> (in hardware) on the USB bus, there are only two requests sent to
> address 0:
>   * GET DESCRIPTOR
>   * SET ADDRESS
> 
> The genuine "address 0" requests can be differentiated from the "Root
> Hub" requests in usbmon by checking if is_root_hub(urb->dev) is true.
> Unfortunately, this information is not available to user-space and
> thus the tools like Wireshark cannot mark the URBs as directed to Root
> Hub.
> 
> Would it be possible to modify the usbmon format, so the
> is_root_hub(urb->dev) flag would be somehow available to the
> user-space tools?

How about using address 255 in the usbmon output to represent root
hubs?  That wouldn't require any format change at all.

By the way, there is one bad aspect to your patch.  Although the device
addresses output by usbmon will now correspond exactly to the physical
addresses on the bus, they will not correspond to the device numbers
used everywhere else in the kernel.  For example, someone monitoring
communcations with /dev/bus/usb/001/005 won't know what device address
to look for in the usbmon output -- it might not be 005.

Alan Stern


  reply	other threads:[~2020-01-07 17:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-07 17:10 Use of address 0 in usbmon Tomasz Moń
2020-01-07 17:41 ` Alan Stern [this message]
2020-01-07 18:12   ` Tomasz Moń
2020-01-07 18:27     ` Alan Stern

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44L0.2001071234330.1567-100000@iolanthe.rowland.org \
    --to=stern@rowland.harvard.edu \
    --cc=corbet@lwn.net \
    --cc=desowin@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=zaitcev@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.