USB gadget kernel module with RPi zero

[creitzel]

Alright, I guess I'm done with this experiment.  I can't figure out how to change the device descriptor on the pi (in fact I haven't seen anything that looks like its even doable). 

Win10 is now recognizing the device as a generic usb hub, still reporting the device descriptor error, and Ubuntu reports it as a usb hub as well. 

Based on the fact that there are several write-ups where people have claimed to get this working, my guess is that the current versions of Ubuntu, and Win10 have changed how they query devices, and that the g_ether code isn't up to date with those changes.

I guess I'll go back to trying to get ssh working via bluetooth.

[Rich]

Hi creitzel
Did you load the  g_ether.ko  driver:

Code: [Select]

modprobe g_ether
Have you looked at this:
https://www.olimex.com/forum/index.php?topic=8239.0

[creitzel]

Hi Rich,

yes I loaded the g_ether module.  I included a line in bootlocal.sh which did that modprobe statement.  Everything looks great on the pi-zero side, no errors, and I can verify that the dwc2 and g_ether modules are loaded using lsmod. 

The problem is when I connect the usb to a host computer, both Win10, and Ubuntu Mate 22.04 are identifying the pi as a "generic usb hub", rather than an RNDIS Ethernet device.  This appears to be a common problem from what I've read on the internet, and the solution posted in all of those threads is to just force windows to load the proper driver for the device. 

That said, Win10 no longer allows you to do this.  I have been trying all night to get Win10 to allow me to install the RNDIS driver, and it just won't allow it.  It looks like maybe they've beefed up security or something, to disallow it. 

I don't know that there is much more I can do with it.  It appears to me that the g_ether module, and the gadget framework might be out of date with what the newer versions of the OS's are doing to query device descriptors or something.

[Juanito]

Is it worth trying usb modeswitch?

[Rich]

Hi creitzel
This link looks kind of interesting:
https://wiki.t-firefly.com/en/Firefly-Linux-Guide/demo_usb_ethernet.html

This section mentions load order of the modules is important:
https://wiki.t-firefly.com/en/Firefly-Linux-Guide/demo_usb_ethernet.html#kernel-settings

This section also appears to be relevant:
https://wiki.t-firefly.com/en/Firefly-Linux-Guide/demo_usb_ethernet.html#network-sharing-to-realize-pc-internet-access
To check  net.ipv4.ip_forward  execute this:

Code: [Select]

tc@E310:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0
tc@E310:~$To enable it, execute this:

Code: [Select]

tc@E310:~$ sudo sysctl net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1
tc@E310:~$

[creitzel]

Is it worth trying usb modeswitch?

Juanito, I'm not sure that util is available for windows.  Usually it's the windows device manager that you use to assign drivers to usb devices.

Hi creitzel
This link looks kind of interesting:...

Rich, I read through that article, and it seems to cover the same things that the articles I've been finding cover.  Things I've already tried.  The order thing seems to be out of my control as well, as I'm just loading the g_ether.ko module, and it appears to be loading the others, in whatever order it thinks is appropriate.

One thing I just discovered about the device from the windows side is that it is declaring itself to be a vendor id of 1a40 and a product id of 0101.  When I google for this vendor/product pair, it comes back with a Terminus Technology Inc. USB Hub, which is why windows and linux are trying to install hub drivers for it, I think. 

Do either of you know if I can change the Vendor Id and/or Product Id, somewhere in the configuration files of piCore?  Maybe through parameters to the g_ether module?  I think if I can get the pi to report a vendor id/product id for an RNDIS network device, windows should load the appropriate driver, and I might be in business.

Thanks again for sticking it out with me, and answering questions.  Much appreciated!   

[creitzel]

Ok, so it looks like, from what I've read, that if I use

Code: [Select]

sudo insmod /{path to g_ether}/g_ether.ko idVendor=0000 idProduct=0000

where the 0000's are replaced with appropriate values, and the path is the correct path, that I should be able to start g_ether with parameters for the vendor and product id.  That said, I've tried it every different way from sunday that I can think of, and I just keep getting

Code: [Select]

insmod: can't insert '/usr/local/lib/modules/5.10.77-piCore/kernel/drivers/usb/gadget/legacy/g_ether.ko': unknown symbol in module, or unknown parameter

am I doing this wrong?

Also, I came across an article on the linux gadget system in general, and it appears that you can mount a config filesystem to pass parameters into the gadget kernel layer.  I haven't tried this one yet, because it looks like you have to completely define the gadget, and I don't know what the default config is for g_ether.

so, no luck so far at changing the vendor and product id's.   

[Rich]

Hi creitzel
What happens if you try it like this:

Code: [Select]

sudo modprobe libcomposite.ko
sudo modprobe u_ether.ko
sudo modprobe usb_f_ecm_subset.ko
sudo modprobe usb_f_rndis.ko
sudo modprobe usb_f_ecm.ko
sudo modprobe usb_f_eem.ko
sudo modprobe g_ether.ko idVendor=0000 idProduct=0000

[creitzel]

Hi creitzel
What happens if you try it like this: ...

Hi Rich.  I didn't know you could pass module params through modprobe.  When I read the help for it, it didn't look like it accepted them.  That is why I was trying to use insmod. 

But, I tried this, and it appears that there's no difference.  By that, I mean that the pi appears to load everything fine, with no errors in dmesg.  I don't know of a way to see if if actually took the idVendor and idProduct parameters, but it didn't complain about them.  And then on the Win10 box, it's still reporting an unknown usb device/usb hub, with VendorID= 1a40 and ProductID= 0101.  So, if it did in fact take the parameters, it seems to be ignoring them/not using them.

From everything I've read, this seems to work for a lot of people, and none of them seem to be having the same trouble I am.  Maybe I'm barking up the wrong tree here.  Maybe there's just some simple step I've missed or something.  Although, I've been through this a bunch of times, and I'm not seeing it lol.

[creitzel]

Ok, I think I now understand why it was reporting a usb hub to the win10 box.  I have a little usb hub that connects to the pi zero, and it's been a while since I actually installed it, and I thought that it was connected via the gpio, but it's not.  It actually mounts like a HAT, but it has little plunger connectors that actually connect right to the zero's usb connector (there's 2 little contacts right by the connector that it connects to). 

Anyway, I basically threw a dart, and said, I wonder if this would work if I took the hub off the zero.  So, I uninstalled the hub, and tried again, and poof now it's not reporting a hub to the win10 box anymore.  It briefly reported an RNDIS/Ethernet gadget (which is obviously what I want), but then quickly changed it to a serial port.  So now I'm at the point, where it is creating a new COM port (COM3), which doesn't actually work, because I'm running g_ether, and not g_serial.  lol.  Anyways, it's progress I guess.  Now to figure out how to make it stop switching to a usb serial device.

[Juanito]

With usb modeswitch on the RPi?

[creitzel]

With usb modeswitch on the RPi?

I think I see what is going on now.  Windows has changed it's usb detection code, and there is more needed on the pi side now.  Several people have encountered the problem of g_ether being misidentified as a serial device.  Here's a link that describes the problem

https://answers.microsoft.com/en-us/windows/forum/all/windows-10-vs-remote-ndis-ethernet-usbgadget-not/cb30520a-753c-4219-b908-ad3d45590447

one of the answers on there led to a script file using the configfs that supposedly handles this problem (see the comment by  dlech).  I adapted the script file for piCore, and it did indeed make Windows see the device as an RNDIS device, the first couple of times I plugged it in.  Then it went back to recognizing it as a serial device, and at one point actually killed the wifi support on the pi, so I had to go back to using an HDMI/Keyboard setup to access it again.

I think I've had enough fun with this approach.  Ultimately, all I'm looking for is an easy way (other than wifi) to access the pi via ssh.  I think I'll switch back over to my bluetooth investigations, and see if I can't get something going there.  I'd actually prefer to use bluetooth if I can, because when the project is done, I don't want to have to disasseble the case to get access to the usb port on the pi.

[curaga]

BT is a huge stack too, with lots that can go wrong. If I may suggest changing the hw, get a regular Pi that has an ethernet port too, would be the simplest solution.

[creitzel]

BT is a huge stack too, with lots that can go wrong. If I may suggest changing the hw, get a regular Pi that has an ethernet port too, would be the simplest solution.

Yeah, I'm familiar with regular pi's too, I've had a few pi zeros, a few pi 3's and even have a pi 4.  I got the pi zero for this project, specifically for it's size.   

It's not really a big deal if I can't get some kind of SSH/maintenance interface going through usb/bluetooth.  I've done a couple of projects with pi zero's already, but it would just be a nicety for me, if I didn't have to pull the pi out and hook it up to HDMI/keyboard to work on it.  On the projects I've already done, I just keep 2 different sets of wifi settings on the zero, one which brings up the AP and allows users to connect, and one that disables the AP and connects to my home wifi, so that I only have to boot it once with HDMI/Keyboard, switch to the settings for my home network, and then I can ssh into it. 

Also, it was a chance to explore and learn a bit more about pi's, as I've never done anything with the usb gadget interface or bluetooth before now.