Investigating USB Hub + Ethernet dongles

[fd_]

Hi all!
This is my first post on this forum

Introduction
I’m a Computer Science student and recently got into Raspberry Pi. It’s been a very exciting journey so far learning about physical computing and the Linux kernel!

I’m having trouble getting the Raspberry Pi to recognize a cheap USB hub + ethernet dongle. Interestingly, it is correctly recognized on a Windows and a macOS machine. Also, it seems like other users successfully use the same dongle on their Raspberry Pis.

I have already ordered a more expensive dongle, but I just kept wondering what it might have been that caused the issues I’ll describe below. Given I already considered the Pi as a venture into the lands of physical computing, I figured I might as well take this mysterious USB dongle issue as another opportunity to learn more about the hardware side of computers, about electronics and about the Linux kernel.
As I unfortunately still don’t know much about electronics and the Linux kernel, I decided to ask here on the Forum. I’m already looking forward to learning from you

The challenge
Now about the problem: I purchased a USB hub that has an ethernet adapter built in. The same dongle seems to be available from multiple vendors on the Internet, for just a few dollars. The product is unbranded, the only label it carries says "1PortUSB Network with 3PortUSB HUB". The PCB inside is labelled "QTS308-6".
Reading the reviews for the device, I was confident its cheap ethernet chip would provide the Raspberry Pi with a network connection, albeit at slow speed.



Unfortunately though, I could not get the ethernet to work on a RPi Zero nor a RPi 3B+. Interestingly, the hub component of the dongle is listed in lsusb (and devices attached to it work), but not the ethernet chip that is effectively pre-soldered to one of the hub’s downstream ports.
At this point, I already assumed that the ethernet chip was just faulty, but it got a bit more interesting:
The very same adapter works on a Windows machine just fine, and is also correctly recognized by a macOS computer (although macOS doesn’t seem to have drivers for the ethernet chip).
Additionally, I found the RPi correctly detects the ethernet chip when started with dwc_otg.speed=1 in the cmdline.txt, which I found very interesting. (I couldn’t get any keyboard or mouse working while enforcing USB1.1, so that wasn’t really a fix for the problem)
As the reviews found online eg for http://a.co/d/dDFxqej suggest, the (likely) same adapter (just with micro USB plug instead of normal USB) is working fine with the RPi for some users, but others seem to have similar issues.

Setup
I tested on a Pi Zero and on a Pi 3B+, with two different power supplies.
I always connected the dongle directly into the Pi. I also tried supplying power to the hub via the barrel socket, but the result didn't change.
I’m running a fresh install of Raspbian, with newest kernel:

Code: Select all

uname -a
Linux raspberrypi 4.14.78-v7+ #1156 SMP Tue Oct 23 14:34:39 BST 2018 armv7l GNU/Linux

Investigation
When the dongle is attached to the Raspberry Pi, the following kernel messages are logged:

Code: Select all

[   68.131540] usb 1-1.3: new high-speed USB device number 8 using dwc_otg
[   68.262202] usb 1-1.3: New USB device found, idVendor=1a40, idProduct=0101
[   68.262217] usb 1-1.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[   68.262225] usb 1-1.3: Product: USB2.0 HUB
[   68.265403] hub 1-1.3:1.0: USB hub found
[   68.266375] hub 1-1.3:1.0: 4 ports detected
[   68.581541] usb 1-1.3.2: new full-speed USB device number 9 using dwc_otg
[   68.681553] usb 1-1.3.2: device descriptor read/64, error -32
[   68.901535] usb 1-1.3.2: device descriptor read/64, error -32
[   69.121531] usb 1-1.3.2: new full-speed USB device number 10 using dwc_otg
[   69.221528] usb 1-1.3.2: device descriptor read/64, error -32
[   69.441534] usb 1-1.3.2: device descriptor read/64, error -32
[   69.561630] usb 1-1.3-port2: attempt power cycle
[   70.221589] usb 1-1.3.2: new full-speed USB device number 11 using dwc_otg
[   70.661591] usb 1-1.3.2: device not accepting address 11, error -32
[   70.761596] usb 1-1.3.2: new full-speed USB device number 12 using dwc_otg
[   71.201611] usb 1-1.3.2: device not accepting address 12, error -32
[   71.201718] usb 1-1.3-port2: unable to enumerate USB device

The same pattern is repeated many times, with Linux increasing the offered address. It seems error -32 indicates a broken pipe, whatever that means exactly in this context.

lsusb only reports the hub, but not the ethernet chip:

Code: Select all

Bus 001 Device 008: ID 1a40:0101 Terminus Technology Inc. Hub
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         1 Single TT
  bMaxPacketSize0        64
  idVendor           0x1a40 Terminus Technology Inc.
  idProduct          0x0101 Hub
  bcdDevice            1.00
  iManufacturer           0 
  iProduct                1 
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           25
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 Full speed (or root) hub
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              12

Bus 001 Device 005: ID 0424:7800 Standard Microsystems Corp. 
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.10
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass         0 
  bDeviceProtocol       255 
  bMaxPacketSize0        64
  idVendor           0x0424 Standard Microsystems Corp.
  idProduct          0x7800 
  bcdDevice            3.00
  iManufacturer           0 
  iProduct                0 
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           39
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                2mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0 
      bInterfaceProtocol    255 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval               4

Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         2 TT per port
  bMaxPacketSize0        64
  idVendor           0x0424 Standard Microsystems Corp.
  idProduct          0x2514 USB 2.0 Hub
  bcdDevice            b.b3
  iManufacturer           0 
  iProduct                0 
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           41
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                2mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      1 Single TT
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              12
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       1
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      2 TT per port
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              12

Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         2 TT per port
  bMaxPacketSize0        64
  idVendor           0x0424 Standard Microsystems Corp.
  idProduct          0x2514 USB 2.0 Hub
  bcdDevice            b.b3
  iManufacturer           0 
  iProduct                0 
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           41
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                2mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      1 Single TT
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              12
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       1
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      2 TT per port
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              12

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         1 Single TT
  bMaxPacketSize0        64
  idVendor           0x1d6b Linux Foundation
  idProduct          0x0002 2.0 root hub
  bcdDevice            4.14
  iManufacturer           3 
  iProduct                2 
  iSerial                 1 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           25
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 Full speed (or root) hub
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0004  1x 4 bytes
        bInterval              12

Next, I used WireShark to capture the communication between the dongle and the Pi. I could see the normal hub initialization, but as soon as Linux tries to get the device descriptor of the device on port 2 (the ethernet chip), the hub responds with an URB that has the URB status set to -32. So far, my interpretation is that the USB hub chip wasn’t able to query the ethernet chip in time, so the hub reported this error message to the kernel. Comparing the Dongle<->RPi capture with a Dongle<->macOS capture revealed that macOS doesn’t seem to do anything fundamentally different in setting up the dongle, yet the ethernet chip happily reports its device descriptor there.


A screenshot of the captured USB communication between the dongle and the Raspberry Pi. The selected packet is the device descriptor response that contains the Broken pipe status.


So, it seems like the issue must be somewhere on the lower (physical) layer.
Digging through the kernel source code, I recompiled it with verbose logging in the dwc_otg module, but I couldn’t make any sense of the tons of information it logged. At least I couldn’t find any big red warnings.

I then cracked open the casing of the adapter to have a look at its internals. Inside, I found a PCB labelled "QTS308-6". On the PCB:

• A USB hub chip labelled SL2.2s USB 2.0 HUB TT0509A18
• An ethernet chip labelled CoreChip SR9700, which seems to be a cheap copy of the Kontron DM9601
• A crystal (oscillator? resonator?) near the USB chip, labelled 12 000, which probably means 12 MHz
• Another crystal, near the ethernet chip, unlabelled
• 2 LEDs
• Lots of resistors and capacitors

The bottom of the dongle's PCB. On the left is the ethernet port, on the right you can see the cables to the USB plug. The left chip is the ethernet chip, the right one is the hub chip.


The top of the dongle's PCB. The crystal on the right is labelled 12 000. The one on the left isn't labelled. The black cube at the very right is a barrel-type socket for an optional power supply.

I was able to find the datasheet of the CoreChip ethernet chip: https://wenku.baidu.com/view/075fe3d258 ... 666cf.html
From there, it seems like the unlabelled crystal is 25 MHz.

Questions
My current theory is that the 25MHz crystal is probably not exact enough to derive a USB clock that meets the specs. Probably, the RPi is more picky about the timing of USB accessories than the macOS and Windows machines I tested.
However, the ethernet chip operates at USB 1.1, so I guess timing should not be that much of an issue at this low speed. Additionally, this wouldn’t explain why it works when enforcing USB 1.1 on the Pi.

At this point, I don’t really intend to fix the dongle (As mentioned, I already ordered a replacement). Rather, I’m curious about the possible causes for this odd behavior. I’m hoping to learn more about the internals of electronics.

Now, I am wondering:

• What could be causing these issues?
• Why is the ethernet chip recognized on Windows and macOS, but not on the Pi?
• Why is the ethernet chip recognized when enforcing USB 1.1 with dwc_otg.speed=1?
• Why is the (supposedly) same dongle working with the RPi for some people?

Any ideas are greatly appreciated!

[FTrevorGowen]

Given the chipset used in the dongle, you may be seeing a variant of this known, believed to fixed** , old issue:
http://www.cpmspectrepi.uk/raspberry_pi ... ver_issues
FWIW the main section of the above web pages contains my notes on a few "tested" USB-to-Ethernet adapters, some including hubs:
http://www.cpmspectrepi.uk/raspberry_pi ... pters.html
You may also find this sticky thread of interest: viewtopic.php?f=28&t=53832
Trev.
** But, of course, not checked with all possible variants so you may have one that's, unfortunately, incompatible.

[fd_]

Thanks for your reply!

Given the chipset used in the dongle, you may be seeing a variant of this known, believed to fixed** , old issue:
http://www.cpmspectrepi.uk/raspberry_pi ... ver_issues

AFAICT, the issue you are referring to would result in kernel panics while communicating via the ethernet chip.
However, the problem I'm seeing is different: The dongle cannot even be enumerated in the first place.
I have found multiple sources that report issues with the chip. However, it seems the problems with this chip were always either (a) kernel panics due to a bug in the driver or (b) its slow speed (because the DM9700 is only USB1.1).
It seems my issues differ from both of these.

For reference:
http://romanhosek.cz/fix-raspberry-pi-z ... et-dm9601/
viewtopic.php?t=215133

FWIW the main section of the above web pages contains my notes on a few "tested" USB-to-Ethernet adapters, some including hubs:
http://www.cpmspectrepi.uk/raspberry_pi ... pters.html

I've read through your page before, but I was a bit disappointed you didn't seem to have come across the issue I'm seeing (Well, lucky you, I guess )

You may also find this sticky thread of interest: viewtopic.php?f=28&t=53832
Trev.

I have read this post, tried the workarounds it explains and tried to follow the tips while writing my post.
As mentioned, dwc_otg.speed=1 did allow the RPi to recognise the ethernet chip, but I couldn't get any mouse nor keyboard to work in that mode.

[PhatFil]

Am following this with interest as i bought 3 x similar devices (usb micro plug) for use with my pi-0's after an evenings googleing i came up with 2-3 driver options to try but nothing definitely stood out as THE solution, and each involved a kernel rebuild and road maps for differing distro's so the dongles got shelved for a cold winter sunday otherwise spent twiddling my thumbs.. ..

looking forward to reaping the rewards of your hard work.

Go on my lad, attaboy!!

[fd_]

Am following this with interest as i bought 3 x similar devices (usb micro plug) for use with my pi-0's after an evenings googleing i came up with 2-3 driver options to try but nothing definitely stood out as THE solution, and each involved a kernel rebuild and road maps for differing distro's so the dongles got shelved for a cold winter sunday otherwise spent twiddling my thumbs.. ..

Well, from what I've read in reviews, if you're using a current Raspbian build, the dongle should be plug-and-play, nothing to recompile. Unless you have some adapter that performs as oddly as mine does, that is.

Have you checked whether your dongles are correctly recognised by the Pi? Is the ethernet chip listed in lsusb? Would be very interesting to know, since if none of your 3 units works properly, it must be some large-scale production quality issues or major incompatibility with the Pi's OTG chip. And then I don't understand why it seems to be working for some users. I'm pretty sure all of the dirt-cheap (~3$) of these hub+ethernet combos are of the same make and use the same chips.

In total, I know of three different chip styles of this adapter:

• RD9700 chip, costs about 3-5$ on Ebay or AliExpress, shell like in the picture above
• RTL8152 (clone) chip, costs about 5-15$ from AliExpress[1] (same shell as cheap one, but additional 2.0 label above ethernet socket) or AdaFruit (different shell, sticker on side opposing the USB sockets?)
• AX88772A (clone) chip, costs about 7-15$, rather rare, available from AliExpress[2] (exact same shell as cheapest one) or various Pi-related online shops

I still suspect that the device works with the Pi in principle, though my unit has some hardware fault that makes it somehow not communicate properly with the Pi. Thus I'm hoping for some thoughts on my crystal inaccuracy theory.

[1]: https://www.aliexpress.com/item/USB-Hub ... 82633.html
[2]: https://www.aliexpress.com/store/produc ... 49678.html

[PhatFil]

cheers @fd
iirc my output from list usb showed nothing for the ethernet h/w only the usb hub. ?mantrox? thats not right but there was an 'M' in it.. Which i confirmed with a pull relist and reinsert and relist.. with the micro usb plug testing with my lappy wasnt an option.. i need to get an adaptor in order to do that)

the devices arrived with 7cm driver cds 2x of which were blank/unreadable, the 3rd contained drivers including a 'linux' folder with a number of directories (saved on another puter atm) tho the folder names formed an aspect of my google searches for roadmaps,, 9700? GT7500? after a quick attempt and fail to build from the sources in the linux driver directories

i did find 1 x reference in an old forum query regarding using the network aspect in a similar device without an additional 5v input, and as i also didnt/dont have a suitable plug to fit the device to test if the nic appeared when supplied with an additional power input I shelved the venture..
I could crack the case and hard wire in a 2nd 5v supply independent from the pi-o..

edit The lappy i saved the driver cd to isnt within reach for a week or so i did mean to dropbox the files but ....

[ejolson]

I’m having trouble getting the Raspberry Pi to recognize a cheap USB hub + ethernet dongle. Interestingly, it is correctly recognized on a Windows and a macOS machine. Also, it seems like other users successfully use the same dongle on their Raspberry Pis.

Have you tried booting a live Linux DVD or thumb drive on the Windows or Macintosh to see whether x86 Linux works with the Ethernet part of the hub?

[fd_]

Thanks for your input!

cheers @fd
iirc my output from list usb showed nothing for the ethernet h/w only the usb hub. ?mantrox? thats not right but there was an 'M' in it.. Which i confirmed with a pull relist and reinsert and relist.. with the micro usb plug testing with my lappy wasnt an option.. i need to get an adaptor in order to do that)

the devices arrived with 7cm driver cds 2x of which were blank/unreadable, the 3rd contained drivers including a 'linux' folder with a number of directories (saved on another puter atm) tho the folder names formed an aspect of my google searches for roadmaps,, 9700? GT7500? after a quick attempt and fail to build from the sources in the linux driver directories

i did find 1 x reference in an old forum query regarding using the network aspect in a similar device without an additional 5v input, and as i also didnt/dont have a suitable plug to fit the device to test if the nic appeared when supplied with an additional power input I shelved the venture..
I could crack the case and hard wire in a 2nd 5v supply independent from the pi-o..

edit The lappy i saved the driver cd to isnt within reach for a week or so i did mean to dropbox the files but ....

Thanks for the info! Please let me know when you tried your adapters again! Also, interestingly, my unit didn't come with a driver cd, so after all, it might be possible that there are multiple manufacturers producing the (visually) same dongle. If you ever crack open the casing and have a look at the internals, please take some pictures and post them here for comparison!

Have you tried booting a live Linux DVD or thumb drive on the Windows or Macintosh to see whether x86 Linux works with the Ethernet part of the hub?

I just tried that. Interestingly, the Raspbian x86 image correctly recognises the ethernet chip, so the problem must be specific to the dwc_otg chip or driver. I already tried tweaking the dwc_otg driver's parameters in cmdline.txt:

• Setting dwc_otg.fiq_enable to 0 and 1
• Setting dwc_otg.fiq_fsm_enable to 0 and 1
• Setting dwc_otg.fiq_fsm_mask to any value between 0x0 and 0x10
• Setting dwc_otg.speed to 1 (as mentioned, the chip is recognised, but no keyboard nor mouse)

(For reference: viewtopic.php?t=70437)

Unfortunately, I couldn't find a solution this way, nor any hint on what might be the problem.

[fd_]

I somehow found a very interesting thread on this forum [1] that suggested that there is another kernel module called dwc2 that essentially implements the same functionality as the dwc_otg module, sans the Pi-specific modifications (termed FSM - Flying Spaghetti Monster).
Luckily, that dwc2 module (it's the one that can also be used for putting the Pi0 into gadget mode) is already included in the Raspbian Linux kernel and can be enabled by adding dtoverlay=dwc2 to /boot/cmdline.txt.

Now, using this module, I was able to get the ethernet chip enumerated. Unfortunately, before I could get too excited about it, I found the dwc2 module has its own issues and is not used by default for a reason: Its performance is so bad that the Pi0's CPU usage literally shoots from 1 to 100% as soon as I attach any USB devices to the ethernet-hub-dongle's downstream port or attach the dongle to a network cable.

I've found another user is seeing the same issues with the dwc2 module [2].
At least it has become evident now that the issues must be specific to the dwc_otg driver and not the Pi's USB OTG chip itself. Probably I should open an issue on the GitHub issue tracker for the Pi firmware.

[1]: viewtopic.php?t=179259#p1140921
[2]: https://raspberrypi.stackexchange.com/q ... -really-do

[fd_]

I’ve now scanned the GitHub issue list for relevant entries and found these notable issues:

• https://github.com/raspberrypi/linux/issues/2692 and https://github.com/raspberrypi/firmware/issues/64 are about usb enumeration failure, but with error code -71. This code seems to indicate hub errors due to spec USB spec violation or USB 1.1 over a 3.0 hub.
• https://github.com/raspberrypi/linux/issues/1045 is the issue that lead to kernel panics with the DM9601/RD9700 chip. That particular problem is fixed and not the same as the one I describe here.
• https://github.com/raspberrypi/linux/issues/2021 mentions the exact same error message as I'm seeing ("device descriptor read/64, error -32"), though it is about issues with a cheap hub. The issue was "resolved" by using a different hub.
• https://github.com/raspberrypi/linux/issues/2024 is interesting, because it mentions a similar hub chip as used in my ethernet+hub dongle (Terminus Tech single-TT hub (FE1.1s)). The problems there were linked to the fact that the chip only has a single TT (needed for talking to USB1.1 devices over USB2.0 hub). This might be relevant here, as the RD9700 ethernet chip is USB1.1. However, the issue appears to have been fixed.

[fd_]

In the meantime, I've opened a ticket in the Github issue tracker here:
https://github.com/raspberrypi/linux/issues/2734

So far, it seems like the problem is specific to the Pi talking to a USB 1.1 device via the Terminus Technology SL2.2s USB 2.0 HUB TT0509A18 chip.

[fd_]

News from the Github issue discussion:
The problem in fact seems to be with the hub chip on the dongle. Turns out Terminus Technology doesn't produce an SL2.2s chip. In fact, the chip on the dongle appears to be some knock-off from another company, that just mimics the behaviour of the genuine Terminus Technology FE1.1s chip. I was able to locate a datasheet of the SL2.2s chip: https://archive.org/details/SL2.2sDatasheetV12. Unfortunately, it is in Chinese and displays the characteristic brevity of Chinese datasheets, so I guess it isn't of much help.

Another user reported to have the same problems with this hub chip and USB 1.1 devices. It appears the chip is also used in cheap USB hubs (sans the ethernet).

@6by9 was kind enough to provide some pictures of a dongle that from the outside appears to be the same as mine, except that it works with the Raspberry Pi. Comparing the PCBs, we found that my dongle was not only worse in terms of general production quality, but actually lacks some of the components that are only required for safe operation of the product, so were removed to lower production costs. Seems like my dongle was cheaper than @6by9's for a reason. Most notably, the working dongle uses a genuine Terminus Tech FE1.1s chip and includes a proper ethernet isolation transformer.

@6by9 also bought the dongle from ebay, though back in December of 2015, for about £5. I bought mine a few weeks ago from ebay for about 3$. So, it seems like there isn't really a way to know which of these you get before making the purchase on ebay. My recommendation would thus be to buy from a trusted reseller or at least from a place where there's a sufficient amount of reviews.

Finally, I've created some pictures that show all differences that I could spot:



I guess I won't do any more research into this at this point, but I'll further follow the discussion on Github.

[PhatFil]

Cheers your pics prompted me to finally crack the case on one of mine.. and its a match with your failing pics although the crystals seem to be better aligned on mine.. in addition to the badly secured wires from the usb connector the one i cracked also has some loss of insulation scrapped off its 4 x wires.. - lost cause , i shall dig deeper and buy the expensive jobies from a UK re-seller ho hum!!

[fd_]

Cheers your pics prompted me to finally crack the case on one of mine.. and its a match with your failing pics although the crystals seem to be better aligned on mine.. in addition to the badly secured wires from the usb connector the one i cracked also has some loss of insulation scrapped off its 4 x wires.. - lost cause , i shall dig deeper and buy the expensive jobies from a UK re-seller ho hum!!

@P33M (from the foundation) over on Github said that he'd have a look at the issue if he had such a failing unit, so if you happen to be located in the UK, maybe you'd consider it worth sacrificing one of your dongles?

[PhatFil]

Cheers your pics prompted me to finally crack the case on one of mine.. and its a match with your failing pics although the crystals seem to be better aligned on mine.. in addition to the badly secured wires from the usb connector the one i cracked also has some loss of insulation scrapped off its 4 x wires.. - lost cause , i shall dig deeper and buy the expensive jobies from a UK re-seller ho hum!!

@P33M (from the foundation) over on Github said that he'd have a look at the issue if he had such a failing unit, so if you happen to be located in the UK, maybe you'd consider it worth sacrificing one of your dongles?

I have dropped a post in that thread offering a hub for sacrifice..

[fd_]

I have dropped a post in that thread offering a hub for sacrifice..

Thanks! Fingers crossed @P33M is still willing to help!

I have now received my replacement unit that was only marginally more expensive than the failing dongle. From the outside, the only thing that differentiates the new dongle from the failing one is an additional "2.0" label. However, the PCB inside, labelled "SL-000 RTL8152B", looks completely different. It uses a Realtek RTL8152B ethernet chip and a HS8836A usb hub chip. Also, it seems to include proper network isolation magnetics and an EEPROM so it actually has a unique MAC address.
Functionality-wise, this new dongle appears to work almost perfectly (UPDATE: has issues, see below): The ethernet chip really supports USB 2.0, instead of the USB 1.1 CoreChips IC that just pretended to be USB 2.0, so it provides about the same networking speed as the Pi2/3's built-in ethernet. All USB ports work fine as well.
It cost me 4.39$ including shipping from AliExpress: https://www.aliexpress.com/item/USB-Hub ... 82633.html

Here are some pictures of this "perfect" (UPDATE: has issues, see below) adapter:

[fd_]

Actually, the new dongle isn't perfect either: It has to be disconnected and reconnected after boot, otherwise it won't be recognised by the Pi0.

[fd_]

I've ordered yet another of these dongles. This time, I tried to find a dongle that looks similar to the one sold by Pimoroni and Adafruit. Based on information I found on the Internet, the model number "YS-LAN26" and a unibody plastic shell with a sticker are indicative of this type of dongle PCB. According to forum information, it uses the Terminus Tech FE1.1s, a USB hub chip known for its generally good compatibility with the Pi. As the problems with my previous dongles were always linked to the hub chip, I figured a dongle with that chipset might actually work.

One has to be careful when shopping for these dongles on AliExpress or Ebay, as sellers often ship different products than depicted in the listing. On paper, there isn't any difference in functionality between the "2.0" dongle I ordered previously and the "YS-LAN26" I wanted to get. However, it seems only the "YS-LAN26" works without issues with the Pi.

I did some web research about the different build variants of these adapters and now think there are actually quite a few factories producing the same products (literally almost identical-looking). I guess the PCB designs of the adapters are shared between multiple PCB factories. These then sell the unpopulated PCBs to factories that place the SMD components on the boards. The assembled PCBs might then be sold to yet more companies, which buy (or produce) the plastic casing and solder on the USB cable (sourced from some other company). One just needs to do some research on Alibaba to find more than a dozen manufacturers for the visually same adapters (though I'm not sure how many just claim to be manufacturers when in fact they're trading companies).

Based on my research, I found the combined USB+TYPE-C adapters always use the unibody shell and on some pictures, the label even says "YS-LAN26". I don't need the USB Type-C plug, but I figured buying one of these would at least increase the probability to actually get a "YS-LAN26"-type dongle.

I eventually bought a dongle from AliExpress that had illustrated reviews showing the sticker mention the "YS-LAN26" model. The listing for the product I bought is at https://www.aliexpress.com/item/Adroit- ... 46908.html. When I bought it, it cost 4.38$. It seems like the price has increased since then, but likely, it's going to decrease again.

When the dongle arrived, I found the sticker on my unit didn't mention "YS-LAN26", but instead said: "FOR MACBOOK". Nevertheless, it seems to also include the FE1.1s hub chip. Once I had opened the dongle's casing, I found the model number "YS-LAN26" printed on the PCB, so it might be the model number of the PCB, not of the whole product.

From the outside, the dongle looks like this:

You can see the sticker on the side opposing the USB sockets.

The top of the PCB looks like this:

You can see the dongle uses a proper network isolator (and even a brand product, it seems; might be counterfeit). The general layout is the same as for the two other dongles, though the routing and placement details differ far enough to suggest this is an independent PCB design, not just a modification of one of the other two.

The bottom of the PCB is where it gets interesting:

You can see we have the "YS-LAN26" silkscreen at the very left. The biggest chip then is the USB hub chip, which reads "FE1.1s USB 2.0 HUB". Interestingly, the chip doesn't carry the Terminus capital "T" logo, so it's likely a cheap clone. Anyway, as long as it mimics the original closely enough, I don't care. The square chip is the ethernet chip, a Realtek 8152B. This one is probably genuine, though I would expect a Realtek chip to carry their logo, not just their name. Lastly, the chip at the right is, I believe, a flash chip containing the MAC address. Not sure about that.

I wonder whether some of the "YS-LAN26" dongles use genuine FE1.1 hub chips. In the spirit of my production chain theory (see above), it's likely that different assembling factories source different SMD components for populating the plain PCBs.

So far, this dongle is working fine. My initial tests show it at least doesn't exhibit the same problems as its predecessors. I'll report back if I find any other issues with it. A minor disadvantage with this adapter is that it doesn't include a barrel socket for external power supply. On the positive side, the included hub chip seems to work much better than the others (eg it works with a USB keyboard that didn't with the other two).

At this point, a little note on the mentioned adapters from Adafruit and Pimoroni: If you want a Pi-compatible USB Hub + Ethernet dongle, it's probably the easiest to get one from there. You get fast shipping, warranty and guaranteed compatibility. However, it seems they're just importing these from China as well, and I'm not willing to spend more than 3x (including shipping) of what the Pi Zero costs on what I consider an accessory.

Lastly: If anyone has similar dongles, please post pictures of the PCB here! Maybe we can make this thread the go-to spot for finding Pi-compatible USB Hub + Ethernet dongles

[fd_]

Great news from the GitHub issue discussion: @P33M was able to locate and fix the bug with my original dirt-cheap Kontron Hub+Ethernet dongle. Turned out the USB host driver (dwc_otg) was only able to properly deal with USB 1.1 devices attached to cheap hubs (single transaction translator) if they were attached to port 1.
For more information, have a look at the discussion here: https://github.com/raspberrypi/linux/issues/2734

[sora03]

Hi, I am having problems with 7 port no name USB Hub externally powered, it has 2 single TT USB as shown on the lsusb -vvv.

If I plug in a Webcam. USB 3G Dongle and a USB DVB-T reciever. it resets the Pi's USB HDD and this result in an I/O error. Can this be fixed by rpi-update? I may create a new thread for this issue and a github issue as well for the linux kernel of the raspberry pi

lsusb info:

Code: Select all

Bus 001 Device 009: ID 214b:7000  
Bus 001 Device 005: ID 214b:7000 

dmesg

Code: Select all

[    2.402183] usb 1-1.1.3: new high-speed USB device number 5 using dwc_otg
[    2.532549] usb 1-1.1.3: New USB device found, idVendor=214b, idProduct=7000, bcdDevice= 1.00
[    2.537758] usb 1-1.1.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[    2.542989] usb 1-1.1.3: Product: USB2.0 HUB
[    2.548645] hub 1-1.1.3:1.0: USB hub found
[    2.553857] hub 1-1.1.3:1.0: 4 ports detected
...
[    3.712187] usb 1-1.1.3.3: new high-speed USB device number 9 using dwc_otg
[    3.842572] usb 1-1.1.3.3: New USB device found, idVendor=214b, idProduct=7000, bcdDevice= 1.00
[    3.848340] usb 1-1.1.3.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[    3.854099] usb 1-1.1.3.3: Product: USB2.0 HUB
[    3.860247] hub 1-1.1.3.3:1.0: USB hub found
[    3.865885] hub 1-1.1.3.3:1.0: 4 ports detected


uname -a
Linux pi 4.19.58-v7+ #1245 SMP Fri Jul 12 17:25:51 BST 2019 armv7l GNU/Linux

I have not tried dwg.otg_speed and other fixes. But, If I only use 3 devices ont eh Hub it works but there are random usb disconnect messages that triggers the USB HDD to be also disconnected and crashes the whole system due to I/O errors.