Usb Ethernet Rndis Gadget Driver
Trinidad Baltzell
I downloaded new version of the drivers from Texas Instruments and recompiled everything. I think that the problem was that the gadget pc had OTG (on the go) enabled, which allows it to switch between host and device mode.
I tried installing the following drivers to resolve the problem:
CONFIG_USB_ETH
CONFIG_USB_ETH_RNDIS
and many other gadget drivers, however I do not think this is the issue as these drivers must be on the target, not the host machine.
Devkit has a OTG port on it. That is the port using for flash, and it is also for usb eth interface. Because such feature is based on usb device mode, it has to be on OTG port. Type A port by its nature cannot work as device mode.
I am not using the Jetson as the device though, the sensor is used as the device. The sensor has a micro usb B port and I have been testing it on the other machines (laptop, Rpi3, VM) using USB A. Also my release is 32.2.1.
Maybe I can get some more details to give a better idea of what is failing. So this is a device, and it uses USB3, and the OTG port is on the device, not the Jetson? This should work using the USB3 port of the Jetson (at least with newer releases, not sure how much USB3 changed from R28.x to R32.x).
Oh I just realized that on the laptop and the raspberry pi 3, the driver used is cdc_eem rather than cdc_subset, which I have not tried enabling on the Jetson. I will try setting cdc_eem as a loadable module and fingers crossed it works.
An Ethernet controller can add lots of complexity and cost to an embedded board, and consume a large amount of PCB real-estate. Most consumer embedded systems omit an Ethernet port completely, as do some development boards (such as the Atmel AT91SAM9RL-EK board). While testing a product or designing a system, it may be desirable to use Ethernet to transmit data to and from the device. Fortunately, the Linux USB gadget subsystem provides a way to leverage existing hardware (many devices have a USB device port) to use utilities such as NFS, SSH, and FTP. This is accomplished by using the g_ether driver.
The g_ether driver can be built into the kernel, or loaded as a module. Once the driver is loaded, it creates an interface called usb0 on the target. Once the USB cable is connected to the host, it creates an interface known as usb0 on the host machine. The host can be either Windows or Linux, but an extra driver is required to see the device on a Windows host. Once the interfaces exist, they can be treated as if they were normal Ethernet interfaces.
As of early last night I was able to connect the BBB via USB to my desktop PC and see the BBB mounted to my PC. There were entries in the device manager for the Beaglebone (under Portable Devices), the Gadget Serial (under Ports COM & LPT), and the Linux RNDIS Ethernet gadget (under Network Adapters and shows up as Linux USB Ethernet/RNDIS Gadget #2 for some reason). The RNDIS entry showed device error 10 saying that the device was not able to start. I have installed the drivers through the BONE_D64 executable as well as by trying to manually update the driver and point it to the RNDIS driver located at F:\Drivers\Windows\src\files\RNDIS. Later last night I tried uninstalling all of the BBB entries I could find within the device manager (the three I listed above) and used bcdedit to allow the installation of digitally unsigned drivers thinking that perhaps Windows was blocking the install somehow. I restarted my PC, installed the drivers, re-enabled driver integrity checks with bcdedit and restarted my PC once again. This was unsuccessful and I was still unable to get the Linux USB Ethernet/RNDIS Gadget to start properly.
I have personally experienced similar issues with the same version of Windows, and my own recourse is just to reinstall. One thing you can do to help facilitate this is to keep the OS separate from your data ( e.g. two partitions, 1 for OS, one for data ). It wont keep the OS from eventually loosing its mind, but it should keep your data safe, and make it very simple to reinstall.
I faced similar problem for the BBB that I bought couple of days back. I was using Windows XP and Windows 7, but could not identify the exact issue. I did reinstalling all the drivers as suggested but did not work.
I have borrow BBW from element14,
Since last 4 months I am doing hands on experience on this devices and goiung good,
But since lase two days this board hase stopped detecting on desktop and Iam unable to solve it ,
Please help on this to solve it.
I am trying to connect RPi Zero from Windows 10, Was following this tutorial -your-raspberry-pi-zero-into-a-usb-gadget/ethernet-gadgetFor some reason laptop is not able to detect USB Ethernet/RNDIS Gadget, What drivers I need to install for this to work.
with TorizonCore 5.4.0 and a configuration file to enable Ethernet-over-USB via gadget/sysfs very similar to the one in this other post, I am able to communicate with a Windows host using RNDIS driver, but I still have to select it manually on the Windows PC (Device Manager > Unknown device > Update driver > Browse manually > Network adapters > Microsoft > Remote NDIS compatible device).
On the other hand, I know Toradex Easy Installer is configured well enough so that Windows is able to select automatically the driver and the Ethernet-over-USB interface goes up without manual driver selection on each board-PC pair.
I had a look at and compared the /sys/kernel/config/usb_gadget/ folders on my setup and TEZI, but I have not understood which settings is critical for that Win driver mechanism. Mine is very similar to the one in the post linked above.
On the other hand, the Toradex Easy Installer was always inducing the correct driver to be picked automatically by Windows. I have tried to reconstruct the configuration steps by TEZI v2.0b6 but I think they are hardcoded in this executable:
Hi @henrique.tx !
Thanks for the answer and the links. Yes of course, you can find my configuration below the signature. It is quite similar to the post you have mentioned. I also had a look at the kernel documentation, as a next step I will dive into it if you cannot find a difference between your closed-source TEZI configuration and mine.
Bests,
ldvp
Hi @ldvp,
The key for me to making Windows load the RNDIS driver automatically without using an INF file was to set the USB class, subclass and protocol to the values that Windows 10 expects an RNDIS device to use, as shown below.
Mike
Since the question came up a few days ago on linux-sunxi IRC and Igor2 provided a nice tutorial to activate Ethernet Gadget mode, I added the necessary one-liner patch to our repo (disabled by default) and built now a kernel with all the necessary stuff patched and enabled: -edv.de/tmp/4U4tkD/Armbian_3.4.112_g_ether_kernel.tar.bz2
If you know how to benefit from something like that (eg. using an USB powered NanoPi M1 -- BPi M2+ is simply too expensive -- as encrypting network device, eg. for offloading OpenVPN stuff), please try the aforementioned stuff out and report back.
Next try: I removed the line from /etc/rc.local and added usb0 to /etc/network/interfaces as outlined here (assigning a static MAC address and changing the port role to OTG from within the 'pre-up' condition). I also added creation of br0 bridge device containing both eth0 and usb0:
(beware: this way the device itself won't be reachable via IP from the network since DHCP will fail with this configuration and it's just a transparent bridge between eth0 and usb0). The usb0 NIC on the Linux side appears as en6 on my MacBook when connected through USB:
Next try. This time I did not use the BPi M2+ (read as: any H3 device featuring an OTG port!) as transparent bridge between its Ethernet and the USB OTG port but configured a working connection between OTG port and USB port of my MacBook using a static IP configuration. On BPi M2+ I used this interface file:
Again approx. 115 Mbits/sec iperf throughput when using a short (AWG20 rated) USB cable between both devices. I also tried out my 'well known crappy cable' (I use normally to demonstrate how bad Micro USB for DC-IN is). This is 1m long instead of 20cm and throughput here is just 109 Mbits/sec (no transmission retries shown via ifconfig so it seems there's either a lower layer involved to verify data integrity or it's just latency due to cable length)
I'll have to test that with Windows soon since a customer of us has the problem that their centralized IT department doesn't allow installation of any software on their road warrior's laptops, they've to deal with a web based application that can't be fixed right now due to IT weirdness but the whole problem seems solveable by providing a bunch of NanoPi M1 that act as intelligent network devices (providing 3G access and fixing the web application on the fly through a transparent proxy approach -- it's just exchanging half a million article numbers )
BTW: NanoPi M1 and BPi M2+ start when powered through the Micro USB OTG port. On every Orange there's a switch in between that needs a small tweak: -pi-pc-first-impressions/ (Orange Pis also accept DC-IN through the Micro USB port but won't start so unless you fix that you need to provide DC-IN either through the barrel jack or GPIO pins)
There's nothing to solder. It's all about a direct connection between OTG port of the H3 device (all H3 SBC use Micro USB here) and a normal host port of another device. So as shown here this is an example where the 'network cable' (Micro USB to USB) is also the power cable (Micro USB to USB -- AWG20 rated and on a port of a computer known to provide 1100mA):
The 'topology' is also rather limited. This is a point-to-point interconnection, in case your host (we stay with a laptop for this example) should connect more than one SBC there will appear more than one more network interface (since the H3 device behaves as a Wi-Fi or Ethernet dongle, just another network capable USB device that appears on the USB bus).
c80f0f1006