Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Libcomposite USB Ethernet devices stopped working with 5.x kernels #3862

Closed
hardillb opened this issue Sep 20, 2020 · 19 comments
Closed

Libcomposite USB Ethernet devices stopped working with 5.x kernels #3862

hardillb opened this issue Sep 20, 2020 · 19 comments

Comments

@hardillb
Copy link

hardillb commented Sep 20, 2020

Describe the bug
When using a Raspberry Pi (Pi Zero or Pi 4) as a USB ECM Ethernet device (a USB Gadget not a host) the Pi starts correctly and sets up usb0 device. The device enumerates correctly on the host device (testing with a Ubuntu 18.04 laptop) and passes enough data to do a DHCP handshake but then no other data is passed after the IP address is assigned

To reproduce

  • Build a SD card image using https://github.com/hardillb/rpi-gadget-image-creator (This script takes a standard raspbian image and boots it under qemu, installs dnsmasq and then adds some scripts and config files using expect). Easy enough to do the same by hand if needed.
  • connect Pi Zero or Pi4 to usb port on host machine (USB-C on the Pi 4 or the left most micro usb socket on Pi Zero)
  • Allow to boot and then try ssh [email protected] (pi should hand out addresses in the 10.55.0.1/255.255.255.248 range to the host)

Expected behaviour
Pi should enumerate as a Ethernet device and the link should be stable.

Actual behaviour
Pi enumerates but the Ethernet link but very little data is passed

System
Copy and paste the results of the raspinfo command in to this section. Alternatively, copy and paste a pastebin link, or add answers to the following questions:

  • Which model of Raspberry Pi? e.g. Pi3B+, PiZeroW
    PiZeroW (but also on Pi4 & PiZero)
  • Which OS and version (cat /etc/rpi-issue)?
    Raspberry Pi reference 2020-08-20
    Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 9a3a10bf1019ebb2d59053564dc6b90068bad27d, stage2
  • Which firmware version (vcgencmd version)?
    Aug 19 2020 17:40:15
    Copyright (c) 2012 Broadcom
    version e90cba19a98a0d1f2ef086b9cafcbca00778f094 (clean) (release) (start)
  • Which kernel version (uname -a)?
    Linux raspberrypi 5.4.51+ I2c1_baudrate being overridden by i2c.conf in 25-Feb-2016 distribution #1333 Mon Aug 10 16:38:02 BST 2020 armv6l GNU/Linux
    Logs
    If applicable, add the relevant output from dmesg or similar.

Additional context
I get same behaviour if I upgrade to the latest available kernel

@pelwell
Copy link
Contributor

pelwell commented Sep 21, 2020

Has this ever worked? If so, in which kernel version?

@hardillb
Copy link
Author

Yes, it works with all the 4.9.x kernel based raspbian buster builds. I'll get you an exact kernel version when I get back home

@aallan
Copy link

aallan commented Sep 21, 2020

Can confirm, this used to work.

@pelwell
Copy link
Contributor

pelwell commented Sep 21, 2020

4.9? I hope you find something more recent...

@hardillb
Copy link
Author

Works on 4.19.97+ from the 2020-02-13-raspbian-buster-lite.img

@pelwell
Copy link
Contributor

pelwell commented Sep 21, 2020

Thanks - that's something to work with.

@hardillb
Copy link
Author

@pelwell
Copy link
Contributor

pelwell commented Sep 28, 2020

Can you explain where the sudden interest has come from? If the breakage occurred between 4.9 and 4.14, why has the problem only just been noticed? Or is the link not as relevant as you suggested it might be?

@hardillb
Copy link
Author

hardillb commented Sep 28, 2020

The link was only because they appeared to have narrowed down the change more closely, if that's misleading I apologise, it definitely works with 4.19.97

The interest is because I had to rebuild a SD card recently and noticed it didn't work, combined with the magpi article about my instructions on how to set this up is likely to lead to a LOT more people trying this and it just not working.

But also this is an obvious regression, it used to work its now broken, that should be good enough.

@pelwell
Copy link
Contributor

pelwell commented Sep 28, 2020

It's working for me on 5.4.51+ - I'm getting ~105Mb/s throughput using iperf -c <server> -d. The host is a 4B running dnsmasq to allocate the dhcp addresses, the client is a Zero running a script to bring up the ethernet and serial gadgets, then dhclient usb1. ssh is also fine.

@pelwell
Copy link
Contributor

pelwell commented Sep 28, 2020

@aallan Can you confirm that it no longer works?

@aallan
Copy link

aallan commented Sep 28, 2020

I can try and find some time tomorrow to test.

@urbanserj
Copy link

I hit the same issue with usb linux gadget on linux 5.4 and reported it in "Moving Linux Kernel to 5.4" thread, both, g_* and usb libcomposite, are broken. Please see kernel backtraces in this comment, I got them via UART. rpi-update e1050e94821a70b2e4c72b318d6c6c968552e9a2 installs 4.19.118 which works just fine.

BTW, I had the same issue with a sunxi-based board on latest debian build of linux 5.4.

@hardillb
Copy link
Author

OK, I've tried again starting with a 2020-02-13 image and upgrading to latest and greatest available via apt (5.4.51) and it's still showing the same problem of getting a DHCP address then failing to route anything over the link.

I can log into the Pi Zero W over the wifi and try to ping the host machine and I get nothing. I've doubled check the firewall on the host machine and it's not dropping packets.

I can get it to work if I use the usb-gadget.sh-alternative (which fires up a rndis ethernet device via libcomposite) but not ECM (usb-gadget.sh-orig)

scripts in the usr/local/sbin dir of the repo in the opening comment.

My host machine is a Dell XPS13 running Ubuntu 18.04

@pelwell
Copy link
Contributor

pelwell commented Sep 28, 2020

Thanks for the link - which USB interface does the sunxi board use?

@urbanserj
Copy link

@pelwell the OTG port is a mini USB 2.0 (A10 SoC).

@pelwell
Copy link
Contributor

pelwell commented Sep 28, 2020

So is that the allwinner,sun4i-a10-musb?

@pelwell
Copy link
Contributor

pelwell commented Sep 29, 2020

That's a completely different USB controller - I'm convinced that this problem you are seeing is a due to an upstream change.

Using usb-gadget.sh-orig with one minor change (I changed ifp usb0 to dhclient usb0) it's working as expected.

@hardillb
Copy link
Author

hardillb commented Nov 8, 2020

Just re-tested on a new host machine (new Dell XPS 13 running 18.04 with 5.0.0-1068-oem-osp1 kernel) and it's working.

This points to this possibly being a problem with the original host machine (an older Dell XPS 13 running 4.15.0-110-oem ).

Anyway, thanks for looking at this. I'll close this issue now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants