• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 2121 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

beaglebone black: OTG peripheral mode to intercept/forward HUB traffics

Yuangao Zhang71
Prodigy 30 points
Other Parts Discussed in Thread: AM3359

Hi all,

I have a beaglebone black (BBB - currently running kernel v3.12) with OTG in peripheral mode on usb bus#1 and a host port to connect devices
on usb bus#2:
usb bus#1: connect OTG on BBB (mini-B) as a musb peripheral gadget (via gadgetfs) to another PC host (e.g. linux, windows, etc)
usb bus#2: connect a hub to BBB host (type A)
+ using libusb to control the hub
+ relay all traffics from host->musb gadget->libusb->hub->(applicable multiple devices hot-plugged to the hub), and vice versa

So far I'm able to see traffics between the PC host and the hub via OTG musb peripheral before plugging any device into the hub. That is,
    P1 - USB packets for HUB itself: usb traffics for endpoints of the hub itself.
Once I plug in a device into the hub, after certain actions on the hub port, the host will send requests (get_descriptor/set_address) to address 0, which are not forwarded to the gadgetfs user space. When I read the codes in the musb gluer/driver, it seems to me that  MUSB_INTRTXE, MUSB_INTRRXE, and  MUSB_INTRUSBE are registered for callbacks into the gluer (e.g. dsps_interrupt) and musb_core (musb_interrupt). In peripheral mode, the enumerated device endpoint number is inferred from musb_int_tx or musb_int_rx. If the peripheral acts as a hub (instead of a single function device), there will be additionally
    P2 - USB setup request and response packets for default address 0 (before a device inserted to the hub becomes enumerated) and
    P3 - downstream/upstream packets for any enumerated devices inserted into the hub.

Basically I hope OTG musb pheripheral acts as a pipe-through device. I'd like to know:
1. Are P2 traffics for address 0 visible to OTG musb pheripheral on bus#1? What code in musb gluer/core (and even firmware) can be used/revised to retrieve/handle them?
2. To further intercept P3 traffics, what code usage/change in musb gluer/core (and even firmware) would be necessary to further retrieve messages addressed to endpoints of individual devices and relay them to the HUB (so the HUB can broadcast to individual devices), and also forward messages from devices received via hub (with libusb) back to host via OTG musb peripheral gadget?

Thanks a lot in advance,
Yuangao
  • 0
    TI__Guru**** 167361 points

    The wiki http://processors.wiki.ti.com/index.php/Processor_SDK_Linux_USB has a diagram showing the Linux USB driver stack.

    Re #1, I am not sure how you can achieve that. libusb talks to device nodes under /dev/bus/usb/, which are only available after the enumeration. So how libusb can retrieve enumeration packets before the device node is created.

    Re #2, it depends on what exact packets you are interested. most data packets are transferred from/to the class/gadget layer, you could to see them in the core layer. Please take a look at usbmon driver for how to sniffer usb packets.

  • 0 in reply to Bin Liu
    Prodigy 30 points
    Thanks a lot for your response.

    Host_PC <==> (bus1# OTG gadget) BBB (libusb bus#2) <=> hub <=> individual devices

    Re #1 - I was hoping that libusb only need to control the enumerated HUB itself (say at address 10). Once libusb has claimed its interface and detached it from kernel driver, then (hopefully) any devices inserted to the hub will be talking via the HUB (bypassing the kernel/driver on BBB) to the host PC. Which means to pipe-through all packets not addressed to HUB, assuming the host PC can enumerate addresses (say 11, 12) for individual devices inserted into the HUB. Is that possible?

    Re #2 - usbmon is plugged in the host controller and doesn't seem to be able to sniff packets arrive at OTG peripheral port. I can sniff packets on bus#2 (say, when I plug in devices with/without via a hub to BBB), but nothing shows up on bus#1 (traffics between PC host and OTG).

    If OTG peripheral gadget is a single device (in the sense of a single enumerated address, say 10), I can see (all packets targeted to the endpoints of at the enumerated address 10) being transferred from/to the gadgets layer. But I cannot get any packets for other addresses (e.g. default address 0) which I'm interested in. That is, a peripheral targeted packet for address 0 doesn't trigger MUSB_INTRTXE (or MUSB_INTRRXE or MUSB_INTRUSBE).

    Generally speaking, I hope to sniff/transfer any packets (regardless whether or not it is targeted at the gadget) from/to the gadget layer on the OTG connection. What can I change to make it possible?

    Thanks,
    Yuangao
  • 0 in reply to Yuangao Zhang71
    Genius 4680 points

    Hi Yuangao,

    Yuangao Zhang71 said:
    Host_PC <==> (bus1# OTG gadget) BBB (libusb bus#2) <=> hub <=> individual devices

    Unfortunately, above configuration doesn't work as you expect.
    To emulate the downstream segments (hub and individual devices), the BBB (AM3359) should expose multiple USB addresses to the host PC. However, the USB device engine on the BBB accepts just single address at a time. It drops all packets other than specified address. In this reason, BBB can't emulate two or more downstream devices (hub also takes an address).

    If you would connect just single device (without hub) on the downstream port, you may pass the bus traffic over the BBB. This "bridge" should add considerable delay to the traffic.

    Tsuneo

  • 0 in reply to Tsuneo Chinzei
    TI__Guru**** 167361 points

    Tsuneo Chinzei said:
    Yuangao Zhang71
    Host_PC <==> (bus1# OTG gadget) BBB (libusb bus#2) <=> hub <=> individual devices

    Unfortunately, above configuration doesn't work as you expect.
    To emulate the downstream segments (hub and individual devices), the BBB (AM3359) should expose multiple USB addresses to the host PC. However, the USB device engine on the BBB accepts just single address at a time. It drops all packets other than specified address. In this reason, BBB can't emulate two or more downstream devices (hub also takes an address).

    I guess one possible is to implement bus#1 gadget to be a hub device, not sure how much development effort it has, I did not look gadgetfs deeply. And its performance is another concern.

  • 0 in reply to Tsuneo Chinzei
    Prodigy 30 points

    Thank you, Tsuneo. Is it possible to modify the USB device engine on the BBB to accept all packets for OTG peripheral and forward them to the gadget driver to process/drop applicable packets? I'd assume the device engine is part of the firmware under /lib/firmware/. Any suggestions which file(s)/where/what to change?

    Thanks,

    Yuangao