[usbproxy] Re: USBProxy: relay a HUB

  • From: "Y. Zhang" <ygz999@xxxxxxxxx>
  • To: Dominic Spill <dominicgs@xxxxxxxxx>
  • Date: Thu, 2 Jul 2015 12:19:39 -0700

Hi Dominic,

Thank you very much for your response. There are a few updates inline below
for your reference and I'd appreciate your further comments.

thanks,
Gordon

On Thu, Jul 2, 2015 at 8:15 AM, Dominic Spill <dominicgs@xxxxxxxxx> wrote:

Hi,

I'm sorry that it's taken me so long to get back to you on this, I've
been travelling and email has been building up.

On 19 June 2015 at 19:41, Y. Zhang <ygz999@xxxxxxxxx> wrote:

Attached is the USBpcap from my test made on the host, where packets
10-30
are between the host and USBProxy.

Was this captured with USBProxy using the pcap filter?

I wonder if the unresponded requests will reach gadgetFS of USBProxy at
all.

I would expect the requests to reach the device (as they have passed
through the filter), but I'm interested to know if the device is
responding to them, and if it is, why those responses are being
dropped.

Could you use USBMON to produce a second pcap file from the USB host
controller? (https://www.kernel.org/doc/Documentation/usb/usbmon.txt)
This will give us two pcap files that we can compare so that we can
know if the requests are being sent to the device and if the device is
responding.

- about usbmon: it seems to be able to monitor peripheral traffics only.
In the BBB case, only 2u. The gadgetFS is on bus 1 but nothing shows up on
1u. The usbmon sniffs traffics to hdrc controller only, as such one can
only monitor usb traffics from/to device, not from/to host connected with
gadgetFS.
- the issue with unresponded requests is due to a bug in USBProxy, where
ctl.request==0 is used to imply no control request on
host->control_request(); however, 0 is actually valid (namely get_status).
Since it's dropped, gadgetfs sets POLLHUP (instead of POLLIN) causing any
following requests not being retrieved by USBProxy (by testing POLLIN).

If not,
1- how would one update gadgetFS to have such requests forwarded to
UBSProxy?

I'm not convinced that the requests aren't getting to USBProxy, I
suspect the problem is in relaying them to the device.

2. when (1) becomes possible, what need be addressed to have further
messages relayed between gadgetFS and the HUB device (via libUSB), such
that
the gadgetFS forwards all downstream messages to USBProxy and then to HUB
device (libUSB), which would further broadcast requests to any other
devices
inserted into the HUB and relay messages from such device back to
gadgetFS
(eventually back to host)?

Yes, I think supporting hubs and proxying multiple devices is a very
useful goal, and I think it should be within our reach. One of the
issues is that we build an internal model of the device descriptors
before we initialise gadgetfs, this model only supports a single
device at this stage. We will need to come up with a sensible
replacement for this model, which may be as simple as writing the
descriptors to a buffer rather than building the model.

- after fixing the bug with USBProxy mentioned above, I was able to proceed
a bit further. When I insert a device (say USB stick) into the HUB, the
host starts to perform actions on the port (like set/clear features etc
which seem fine) but eventually gives up due to unresponsive get_descriptor
and/or set_address via address=0. This is one of the major issues. I'd like
your comments on the following:
+ How to retrieve host requests to address 0 (before the host enumerates
the device address)? Apparently address 0 is not the ep0 of the gadgetFS
and I have no idea where to intercept such traffics.
+ If the traffics to address 0 can be handled properly, the next major
issue will be how to intercept traffics to all endpoints (ep0, ...) of the
enumerated device within the gadgetFS (which are in addition to ep0... of
the hub) .


Thanks,
Dominic


Any comments are greatly appreciated!!!

Gordon

Other related posts:

  1. Home
  2. usbproxy
  3. Archive
  4. 07-2015