Use of address 0 in usbmon

Use of address 0 in usbmon

[Tomasz Moń]

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.

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?

Best Regards,
Tomasz Moń

Re: Use of address 0 in usbmon

[Alan Stern]

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

Re: Use of address 0 in usbmon

[Tomasz Moń]

On Tue, Jan 7, 2020 at 6:41 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> 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.

Thank you for mentioning this.

> > 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.

Yes, that's one possibility.

> 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.

Initially I have modified also the drivers/usb/core/devices.c to
change the format_topo to use devaddr instead of devnum. Then I
realised it could cause a snowball effect and decided to limit the
change to usbmon only.

I think the solution to would be to extend usbmon format to include
both devnum and devaddr. This unfortunately would require format
change.

Re: Use of address 0 in usbmon

[Alan Stern]

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

> On Tue, Jan 7, 2020 at 6:41 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> > 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.
> 
> Thank you for mentioning this.
> 
> > > 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.
> 
> Yes, that's one possibility.
> 
> > 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.
> 
> Initially I have modified also the drivers/usb/core/devices.c to
> change the format_topo to use devaddr instead of devnum. Then I
> realised it could cause a snowball effect and decided to limit the
> change to usbmon only.
> 
> I think the solution to would be to extend usbmon format to include
> both devnum and devaddr. This unfortunately would require format
> change.

Maybe a better answer is to leave usbmon alone and instead add a new
devaddr attribute file to sysfs, containing the device's physical
address.  Then user programs could easily perform the conversion.

Alan Stern