7 7
tkaiser

g_ether driver (H3 device as Ethernet dongle)

Recommended Posts

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: http://kaiser-edv.de/tmp/4U4tkD/Armbian_3.4.112_g_ether_kernel.tar.bz2

 

To get the idea please read through Igor2's Readme: http://igor2.repo.hu/tmp/opi_usb_gadget.txt

 

You should run a recent Armbian installation (apt-get update/upgrade), then extract the contents of the tar archive above somewhere, install the stuff using dpkg and then reboot:

tar xf Armbian_3.4.112_g_ether_kernel.tar.bz2
sudo dpkg -i linux-*.deb
sudo reboot

Then to be able to use the OTG as Ethernet Gadget device I found that we need a slight modification (since it's not /sys/bus/platform/devices/sunxi_usb_udc/role but /sys/bus/platform/devices/sunxi_usb_udc/otg_role):

echo -n 0 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role
modprobe g_ether
echo -n 2 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role

Et voilà: In the very same moment the MacBook that powers the BPi M2+ I test with notified me that a new network device appeared and this looks like:

bash-3.2# system_profiler SPUSBDataType
[...]
        RNDIS/Ethernet Gadget:

          Product ID: 0xa4a2
          Vendor ID: 0x0525  (PLX Technology, Inc.)
          Version: 3.33
          Speed: Up to 480 Mb/sec
          Manufacturer: Linux 3.4.112-sun8i with sunxi_usb_udc
          Location ID: 0x14200000 / 5
          Current Available (mA): 500
          Current Required (mA): 2
          BSD Name: en6

So from now on I can use the H3 board as network interface en6 :)

 

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.

 

I wonder whether we should not enable this one-line patch and the appropriate kernel config by default...

Share this post


Link to post
Share on other sites

Update: Adding g_ether to /etc/modules and adding 

lsmod | grep -q g_ether && echo -n 2 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role \
        || (sleep 10 && echo -n 2 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role)

to /etc/rc.local also works since with Armbian defaults we configure the OTG port as host port (so when the g_ether module is loaded /sys/bus/platform/devices/sunxi_usb_udc/otg_role is set to 1)

Share this post


Link to post
Share on other sites

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:

root@bananapim2plus:~# cat /etc/network/interfaces.g_ether
auto lo
iface lo inet loopback

# Wired adapter #1
auto eth0
iface eth0 inet dhcp

auto usb0
iface usb0 inet dhcp
hwaddress ether 82:bc:09:47:28:a9
pre-up /bin/sh -c 'echo 2 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role'

auto br0
iface br0 inet dhcp
bridge_ports eth0 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:

bash-3.2# ifconfig en6
en6: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	ether 6a:95:6f:ac:30:2b 
	inet6 fe80::6895:6fff:feac:302b%en6 prefixlen 64 scopeid 0xe 
	inet 192.168.83.200 netmask 0xffffff00 broadcast 192.168.83.255
	nd6 options=1<PERFORMNUD>
	media: autoselect (10baseT/UTP <full-duplex>)
	status: active

bash-3.2# netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            192.168.83.1       UGSc           13        0     en6
127                127.0.0.1          UCS             0        0     lo0
127.0.0.1          127.0.0.1          UH              8    10366     lo0
169.254            link#14            UCS             0        0     en6
192.168.83         link#14            UCS             2        0     en6
192.168.83.1/32    link#14            UCS             1        0     en6
192.168.83.1       bc:5:43:be:c1:e1   UHLWIir        14      506     en6   1169
192.168.83.200/32  link#14            UCS             0        0     en6
192.168.83.245     0:c:29:9c:17:3a    UHLWIi          1   306068     en6   1200

So time to test raw throughput to another GBit connected OS X machine (192.168.83.245): ~115 Mbits/sec in both directions. This is the limitation of the g_ether device since BPi M2+'s GBit Ethernet device eth0 isn't here the bottleneck (680/930 Mbits/sec between BPi M2+ and the Mac Mini). So network performance of the g_ether device slightly outperforms a Fast Ethernet port (below 100 Mbits/sec). Nice.

Share this post


Link to post
Share on other sites

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:

 

 

root@bananapim2plus:~# cat /etc/network/interfaces.g_ether_static
auto lo
iface lo inet loopback

# Wired adapter #1
auto eth0
iface eth0 inet dhcp

allow-hotplug usb0
iface usb0 inet static
hwaddress ether 82:bc:09:47:28:a9
address 192.168.172.2
netmask 255.255.255.0
pre-up /bin/sh -c 'echo 2 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role' 

 

 

 

This results in somewhat weird settings (hwaddress being ignored) but since everything's working fine I don't care that much:

 

 

View from Linux side:

root@bananapim2plus:/home/tk# ifconfig usb0
usb0      Link encap:Ethernet  HWaddr 42:25:4d:9a:5b:78  
          inet addr:192.168.172.2  Bcast:192.168.172.255  Mask:255.255.255.0
          inet6 addr: fe80::4025:4dff:fe9a:5b78/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:393658 errors:0 dropped:0 overruns:0 frame:0
          TX packets:634621 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:164061426 (156.4 MiB)  TX bytes:889006074 (847.8 MiB) 

View from OS X side:

bash-3.2# ifconfig en6
en6: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	ether 9e:16:a1:bc:fe:af 
	inet6 fe80::9c16:a1ff:febc:feaf%en6 prefixlen 64 scopeid 0x11 
	inet 192.168.172.3 netmask 0xffff0000 broadcast 192.168.255.255
	nd6 options=1<PERFORMNUD>
	media: autoselect (10baseT/UTP <full-duplex>)
	status: active 

 

 

 

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)

 

Potential use cases:

  • Simple wired interconnection: You have an OPi Lite and don't want to use an Ethernet dongle: Make the Lite the dongle. In g_ether mode all that's needed is connecting the Lite via USB to a second device and the Lite appears there to be an external USB-Ethernet adapter. You get transfer speeds that slightly exceed Fast Ethernet just using a simple USB cable
  • USB-to-Ethernet adapter: Use an NanoPi M1 or BPi M2+ as external USB-to-Ethernet dongle (needs bridging -- see above). Both boards can be powered through the Micro USB OTG port (but then you have to take care to limit max cpufreq to approx 600 MHz to not exceed 500mA consumption. Or you use a device known to provide more amperage: USB3 ports have to provide 900mA and with Apple MacBooks from 2012 or younger you get 1100mA on the USB ports)
  • Wi-Fi dongle: Using the same method you can attach any OPi Lite (or any of the other boards having a Wi-Fi interface) via USB to a host and using a bridged connection between wlan0 and usb0 the H3 SBC starts to act like a WiFi dongle.

The last 2 use cases above are pretty boring or even weird. Now the fun stuff:

  • Use a cheap H3 device like OPi One between a slow router and the internet to offload VPN encryption (zador came up with this link a few weeks ago. You get the idea even just by looking at the pictures)
  • Use a cheap H3 device as secure VPN endpoint (allow accesses to your VPN only when they originate from a sealed H3 device that will be used as Ethernet adapter from Windows machines... where tampering/installing software might not be allowed by an IT department or you simply can't trust them)
  • Use Linux' transparent proxy support to implement an ad filter on a cheap H3 device between host and Internet (pretty easy using eg. squid and the gazillions of available tutorials)

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: http://blog.atx.name/orange-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)

Share this post


Link to post
Share on other sites

All right and back to human speech...

If am right It can save me network cables between my H3 boards and network switch or I can hung up more those devices on that one switch.

Which cable do I need to connect H3 boards? Or I can solder it directly to save resources.

If I am right I need only 4 wire cable connected/soldered on pins see description below:

 

1<->1,2<->2,3<->3,nothing,4<->4

 

Description (borrowed from wikipedia):

1     VBUS     Red     +5 V
2     D−     White     Data−
3     D+     Green     Data+
4     ID     No wire     On-The-Go ID distinguishes cable ends:
5     GND     Black     Signal ground

 

I will try to test it/make cable soon ...

Share this post


Link to post
Share on other sites

@tkaiser

 

Brilliant - works right out of the box without breaking anything. Performance measured between two OPI ONEs linked by USB/microUSB compared to directly linked RJ45/RJ45 is very pleasing.

 

USB-link

-----------

 

iperf -c 192.168.5.167        
[  3]  0.0-10.0 sec   148 MBytes   124 Mbits/sec

iperf -c 192.168.5.167 --dualtest

[  5]  0.0-10.0 sec   109 MBytes  90.9 Mbits/sec
[  4]  0.0-10.2 sec   112 MBytes  92.2 Mbits/sec

LAN-patch
-------------

iperf -c 192.168.3.167

[  3]  0.0-10.1 sec   116 MBytes  96.1 Mbits/sec

iperf -c 192.168.3.167 --dualtest

[  5]  0.0-10.0 sec   110 MBytes  92.6 Mbits/sec
[  4]  0.0-10.2 sec   108 MBytes  88.7 Mbits/sec

 

Two use cases pop up immediately :

 

- OPI ONE el cheapo portable router/firewall/proxy

 

- Simple headless access with static IP independent from working DHCP/LAN/WLAN.

Share this post


Link to post
Share on other sites

If am right It can save me network cables between my H3 boards and network switch or I can hung up more those devices on that one switch.

Which cable do I need to connect H3 boards? Or I can solder

 

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):

 

g_ether_in_action.jpg

 

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).

 

So to interconnect a bunch of H3 devices this way they have to be connected to a host that is able to bridge interfaces (OS X can be configured to do this automagically as soon as a new network interface/cable is inserted :) ). In case I would use 3 more SBC connected to my laptop using the g_ether method and an USB hub then 3 more Ethernet devices would be created there automatically. And only if I let them join a bridge device together with another real network device networking on any of the H3 devices would feel 'normal':

bridge0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	options=63<RXCSUM,TXCSUM,TSO4,TSO6>
	ether a2:99:9b:00:3f:00 
	Configuration:
		id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0
		maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
		root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0
		ipfilter disabled flags 0x2
	member: en1 flags=3<LEARNING,DISCOVER>
	        ifmaxaddr 0 port 5 priority 0 path cost 0
	member: en6 flags=3<LEARNING,DISCOVER>
	        ifmaxaddr 0 port 6 priority 0 path cost 0
	member: en7 flags=3<LEARNING,DISCOVER>
	        ifmaxaddr 0 port 7 priority 0 path cost 0
	member: en8 flags=3<LEARNING,DISCOVER>
	        ifmaxaddr 0 port 8 priority 0 path cost 0
	member: en9 flags=3<LEARNING,DISCOVER>
	        ifmaxaddr 0 port 9 priority 0 path cost 0
	nd6 options=1<PERFORMNUD>
	media: <unknown type>
	status: active

(en1 is a Wi-Fi interface connected to my normal network -- in the above example all 4 H3 devices appearing as USB network devices en6 to en9 are connected at network layer 2 to the Wi-Fi through my laptop, get DHCP lease and network settings from the router and use the Laptop as 'software switch' to access each other and the outside/internet)

 

That's the tricky part: The host to which the H3 devices are connected via USB has to bridge the various devices and then starts to act as a multi port bridgge (a so called switch ;) ) but isn't doing this on a fast ASIC but at the software layer. This works flawlessly on OS X where the configd is responsible for getting the link state of appearing/disappearing network devices, setting them up and adding/removing them to/from a bridge device. Same might be true for Linux or *BSD (no idea, when doing networking there I focus on static configs) or Windows (no idea at all).

 

But that's a basic requirement to interconnect g_ether attached devices: Bridging between the individual USB network interfaces at the host (you can also try to solve this problem on layer 3 and above -- TCP/IP -- but you will get lost in routing and mad for sure).

 

@tkaiser: off-topic, create a similar topic about 4th pin header USB on M2+. It is useful as this post!

 

Why? There are not much reasons to buy a BPi M2+ anyway. 2 unique selling points: 5MP camera (that no one got in a working state so far and no one knows if it will ever work) and BT (that does not work on any of their provided OS images since they're not skilled enough or too lazy or simply not caring as usual).

 

Please keep in mind:

If a dedicated post regarding BPi M2+ will happen anytime soon then it's the announcement to drop Armbian support for this device entirely since it's in the same tradition of being an almost useless device (when you compare specs, reality and prices) as M2 and M3 :)

Share this post


Link to post
Share on other sites

If am right It can save me network cables between my H3 boards and network switch or I can hung up more those devices on that one switch.

 

Just to elaborate on this one more time. The topology using the g_ether mode is rather limited since the connected Ethernet gadget device just appears as an external USB-to-Ethernet dongle. As an example: One Orange Pi Plus 2E (3 real USB host ports) is connected via Gbit Ethernet to a GbE network switch (using his eth0 interface). On each USB port an Orange Pi Lite is connected using an USB-to-Micro-USB cable.

 

Each Lite therefore appears on the USB bus as another 'Netchip Technology, Inc. Linux-USB Ethernet/RNDIS Gadget':

root@orangepiplus2e:~# lsusb
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 002: ID 0525:a4a2 Netchip Technology, Inc. Linux-USB Ethernet/RNDIS Gadget
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 0525:a4a2 Netchip Technology, Inc. Linux-USB Ethernet/RNDIS Gadget
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 0525:a4a2 Netchip Technology, Inc. Linux-USB Ethernet/RNDIS Gadget
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

And this is how each 'USB device' looks like in detail:

 

 

Bus 004 Device 002: ID 0525:a4a2 Netchip Technology, Inc. Linux-USB Ethernet/RNDIS Gadget
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            2 Communications
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0525 Netchip Technology, Inc.
  idProduct          0xa4a2 Linux-USB Ethernet/RNDIS Gadget
  bcdDevice            3.33
  iManufacturer           1 Linux 3.4.112-sun8i with sunxi_usb_udc
  iProduct                2 RNDIS/Ethernet Gadget
  iSerial                 0 
  bNumConfigurations      2
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           75
    bNumInterfaces          2
    bConfigurationValue     2
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower                2mA
    Interface Association:
      bLength                 8
      bDescriptorType        11
      bFirstInterface         0
      bInterfaceCount         2
      bFunctionClass          2 Communications
      bFunctionSubClass       6 Ethernet Networking
      bFunctionProtocol       0 
      iFunction               5 RNDIS
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol    255 Vendor Specific (MSFT RNDIS?)
      iInterface              3 RNDIS Communications Control
      CDC Header:
        bcdCDC               1.10
      CDC Call Management:
        bmCapabilities       0x00
        bDataInterface          1
      CDC ACM:
        bmCapabilities       0x00
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval               9
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              4 RNDIS Ethernet Data
      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     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           88
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower                2mA
    Interface Association:
      bLength                 8
      bDescriptorType        11
      bFirstInterface         0
      bInterfaceCount         2
      bFunctionClass          2 Communications
      bFunctionSubClass       6 Ethernet Networking
      bFunctionProtocol       0 
      iFunction               9 CDC ECM
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      6 Ethernet Networking
      bInterfaceProtocol      0 
      iInterface              6 CDC Ethernet Control Model (ECM)
      CDC Header:
        bcdCDC               1.10
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1 
      CDC Ethernet:
        iMacAddress                      8 9E16A1BCFEAF
        bmEthernetStatistics    0x00000000
        wMaxSegmentSize               1514
        wNumberMCFilters            0x0000
        bNumberPowerFilters              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval               9
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              0 
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       1
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              7 CDC Ethernet Data
      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     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            2 Communications
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  bNumConfigurations      2
Device Status:     0x0001
  Self Powered 

 

 

When you connect any Lite using USB dmesg will then show something like this on the Plus 2E:

[   58.720602] ehci_irq: highspeed device connect
[   58.990070] usb 4-1: new high-speed USB device number 2 using sunxi-ehci
[   59.195750] cdc_ether 4-1:1.0: usb0: register 'cdc_ether' at usb-sunxi-ehci-1, CDC Ethernet Device, 9e:16:a1:bc:fe:af
[   59.195909] usbcore: registered new interface driver cdc_ether
[   59.197665] usbcore: registered new interface driver cdc_subset

So this Lite will appear as new NIC called usb0 (the next connected Lite will be usb1 and the 3rd usb2). The only reasonable mode to deal with this is to work on network layer 2 (bridging) and forget about TCP/IP (layer 3 -- routing) at all. So we would now set up one bridge device br0 on the Plus 2E that consists of eth0, usb0, usb1 and usb2. This way every Lite will use the Plus 2E as a simple 4 port switch interconnecting the Lites and also connecting them with the Ethernet network behind eth0. This simple config (entry in /etc/network/interfaces) on every Opi Lite should suffice:

auto usb0
iface usb0 inet dhcp
pre-up /bin/sh -c 'echo 2 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role'

The Plus 2E acts then as a multi port bridge (switch) between the different Ethernet gadget devices so DHCP requests will reach the router, a DHCP lease will be assigned and they can access devices on the Ethernet, the internet if default gateway is set up correctly and also each other. One minor flaw: In this case (using DHCP) using a static MAC address would be preferable.

 

Anyway: As can be seen setups using multiple g_ether connections aren't that useful or get pretty complicated pretty fast. This Ethernet gadget mode is more useful for directly connected H3 devices serving the host they're connected to (see use cases above by Rodolfo and me)

 

Looking forward regarding potential performance tuning (tweaking some basic network tunables might increase performance drastically), solving the random MAC address issue and compatibility reports (does the necessary one-line patch affects reliability of the OTG port used in host mode?)

Share this post


Link to post
Share on other sites

The last 2 use cases above are pretty boring or even weird. Now the fun stuff:

...

  • Use a cheap H3 device as secure VPN endpoint (allow accesses to your VPN only when they originate from a sealed H3 device that will be used as Ethernet adapter from Windows machines... where tampering/installing software might not be allowed by an IT department or you simply can't trust them)

...

Just a thought: if tampering/installing software might not be allowed by an IT department, you probably won't be able to install RNDIS drivers and configure network parameters to make this work  :)

Share this post


Link to post
Share on other sites

Just a thought: if tampering/installing software might not be allowed by an IT department, you probably won't be able to install RNDIS drivers and configure network parameters to make this work  :)

 

Is it really necessary to install drivers on Windows for this or adjust network configuration?! Serious question, I only deal with Windows servers from time to time that I do not have to administrate.

Share this post


Link to post
Share on other sites
compatibility reports (does the necessary one-line patch affects reliability of the OTG port used in host mode?)

 

Patched OPI ONE running in host mode with LAN1000 dongle on OTG-port ( eth1 ) works reliably as before with pleasing performance.

 

LAN performance of OPI ONE

 

1) RJ45 direct link ( eth0 )                             95 Mbits/s                        

 

2) OTG port in device mode ( usb0 )                     124 Mbits/s

 

2) LAN1000 dongle on OTG port in host mode ( eth1 )     277 Mbits/s

 

Enjoy !

Share this post


Link to post
Share on other sites

Is it really necessary to install drivers on Windows for this or adjust network configuration?!

Yes, and if we are talking about work environment, usually installation of devices other than mass storage will be disabled - otherwise anybody can plug in their phone and share mobile internet to the PC.

 

RNDIS drivers are a pain in the butt to deal with - you need either to change module parameters to use USB VID and PID to some "known" values (you can also also add MAC address to module parameters), or find "universal" RNDIS .inf file and edit it to include "your" VID/PID pair, or install generic RNDIS driver available in modern Windows versions (this method was tested with Opi Plus 2E on Win8.1 by me, iperf3 speed is ~92MBit/s).

Share this post


Link to post
Share on other sites

Patched OPI ONE running in host mode with LAN1000 dongle on OTG-port ( eth1 ) works reliably as before with pleasing performance.

 

Thx, I will do another test with an attached disk later. But if that succeeds we really might apply this patch by default and enable the gadget modules since especially the ultra cheap H3 boards are perfect for such USB gadget stuff -- please see also http://forum.armbian.com/index.php/topic/1089-usbootpi/

 

usually installation of devices other than mass storage will be disabled - otherwise anybody can plug in their phone and share mobile internet to the PC. RNDIS drivers are a pain in the butt to deal with [...]

 

Ok, thx for discouraging me. I was too naive since they currently use 3G USB dongles on their laptops but most probably config is fixed as well as allowed VID/PID. Then time to deal with their IT department  :wacko:

Share this post


Link to post
Share on other sites

Thx, I will do another test with an attached disk later.

 

Ok, wasted another hour of my live with crap hardware. I tried to connect the same Seagate Barracuda I used for disk tests on the OTG port of an OPi Plus 2E a few days ago to BPi M2+'s OTG port and test with the new gadget kernel patch: Performance horrible. So I downloaded latest BPi M2+ Armbian image, burned that to eMMC (to get rid of my kernel patch), tested again: performance horrible. I then tried a normal host port just to realize that the type A receptacles on BPi M2+ are really tight: Performance again horrible (800 KB/s instead of +30 MB/s). So for yet unknown reasons USB performance with this device is horrible.

 

As a reference performance with OPi Plus 2: http://forum.banana-pi.org/t/con1-sip2-254-and-usb-dm3-usage/1865/3?u=tkaiser  (just confirmed connecting the disk to Beelink X2: Same results as with OPi Plus 2E back then). Note to myself: Stop dealing with rotten Bananas.

Edited by wildcat_paris
stop rotten Bananas, juicy Vitamin-C Oranges are better

Share this post


Link to post
Share on other sites

tkaiser said : "But that's a basic requirement to interconnect g_ether attached devices: Bridging between the individual USB network interfaces at the host (you can also try to solve this problem on layer 3 and above -- TCP/IP -- but you will get lost in routing and mad for sure)."

 

I use proxy arp to do level 3 transparent routing without any need to maintain routing tables (The concentrating host reply for arp requests for attached devices). (e. g. /usr/sbin/arp -i eth0 -Ds 192.168.1.194 eth0 pub). You just need to subnet attached devices with a few more bits, enable routing on your concentrating host and make it default router on attached hosts.

 

I already do it with pan (bluetooth bnep) networking to use PIs as IOT solutions.

 

I have got a bpi m2+ a few days ago for the eMMC. I wanted to use it as desktop but stopped test when I found out that it could not handle 4:3 video mode out of the box. So I will try to use it in replacement of a rpi 1 as firewall+proxy+gateway+wifi/bt-AP that need storage for cache. The possibility to interconnect my 2 bpi M1 and my new M2plus is important for me, so I am looking for having ip over usb desperately on bpi M1 and bpi M2+.

 

Btw I have a problem : my new bpi M2+ don't boot when powered threw jack ?!? It seems to hang when initializing disp or just before. (No drop on voltage mesured on gpio). So I must at present power it threw micro-usb and cannot test plug in and out. I compliled g_ether with igor modif 'static u8 is_udc_enable = 1;' yesterday, could not configure it as module, got usb0 interface but no device detection at other end (with usbnet and cdc_ether) ? I will try your kernel asap.

Share this post


Link to post
Share on other sites

my new bpi M2+ don't boot when powered threw jack ?!? It seems to hang when initializing disp or just before.

 

I had similar symptoms before, boot stalled almost everytime 2-3 seconds after the kernel started (last message something with USB). I then replaced the PSU with another one where barrel plug fitted somewhat tighter and subsequent boots were fine. Maybe that's the culprit?

 

Powering through Micro USB wasn't a problem as long as I didn't used my special 'well known crap cable' (too long and resistance too high), then either the booting stopped at the same stage or I ran into strange symptoms later -- Linux losing connection to the rootfs for example, only hard shutoff helped). Insufficient powering is always a guarantee for troubles :)

Share this post


Link to post
Share on other sites

tkaiser said : " I then replaced the PSU with another one where barrel plug fitted somewhat tighter and subsequent boots were fine. Maybe that's the culprit?"

 

I use to power my RPI threw GPIO. I never tried with BPI. I dont have the schematics for BPI M2+. (On RPI it shunts the fuse). I will try to add a capacitor (the PSUs can have bad noise level) and power threw GPIO. I'll tell you if my BPI survive ...

Share this post


Link to post
Share on other sites

I dont have the schematics for BPI M2+. (On RPI it shunts the fuse). I will try to add a capacitor (the PSUs can have bad noise level) and power threw GPIO. I'll tell you if my BPI survive ...

 

I added (partially wrong) schematics to the wiki page a few weeks ago. And in any case please update this topic in the vendor's forum since @sinovoip as usual does not answer user questions even of this severity: http://forum.banana-pi.org/t/possible-header-configurations-and-rtc-question/1862/15

 

Do you have a v1.0 or v1.1 PCB revision?

Share this post


Link to post
Share on other sites

As a reference performance with OPi Plus 2: http://forum.banana-pi.org/t/con1-sip2-254-and-usb-dm3-usage/1865/3?u=tkaiser  (just confirmed connecting the disk to Beelink X2: Same results as with OPi Plus 2E back then). Note to myself: Stop dealing with rotten Bananas.

 

Ok, now used an OPi PC Plus for the tests. First round is without the gadget patch, 2nd run with the patch (most recent Armbian 5.14). 3.5" Seagate Barracuda with external PSU connected to USB OTG port in host mode:

iozone -e -I -a -s 100M -r 4k -r 16k -r 32k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
iozone -e -I -a -s 2048M -r 16384k -i 0 -i 1

Without patch:
                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     7828     7817     7871     7670     1019      940
          102400      16    17661    19774    20620    19238     3697     4052
          102400      32    25169    25125    24097    25341     6638     8868
          102400     512    32938    33206    34594    35201    26041    32246
          102400    1024    33516    33818    32088    35921    29861    27631
          102400   16384    36943    36927    37071    37750    37478    36729
         2097152   16384    36979    36566    37379    37389

With patch:
                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     7561     7854     7847     7933      991     1036
          102400      16    17543    20442    20862    21076     3692     4048
          102400      32    25067    25172    25286    25573     6587     8854
          102400     512    34132    34313    35693    36046    26870    33684
          102400    1024    33938    34324    35700    36006    29804    27771
          102400   16384    36863    37155    37303    37770    37472    36829
         2097152   16384    36929    37729    37476    37506

Results identical. I feel we should enable this patch and enable g_ether driver as module (or anyone more familiar than me able to figure out what to patch else to get the other gadget modes also working on legacy sun8i should take over)

 

I would assume the problem with BPi M2+ before was power related since the board failed to boot several times and showed strange USB disk performance on both host and OTG ports. An insufficient power supply situation (be it PSU or cable between) is always guarantee for lots of 'fun'.

Share this post


Link to post
Share on other sites

@tkaiser

 

I can confirm OTG port with patch applied works equally well in host mode. Read/write performance for HDD on powered SATA adapter is around 35MB/s. When permanently adding the patch and setting OTG gadget mode as default, it might be worthwhile to add a default static IP for usb0. This would add a simple interface independent of working LAN / WAN / DHCP setup for ssh-ing into headless boards.

Share this post


Link to post
Share on other sites

OK Your kernel works for my BPI m2+ PCB rev 1.1

 

I get g_ether loading and link detect, so I manage to make IP over USB : 121 Mbits/sec.

 

Power threw gpio or jack is always erratic so far. Dupont connectors can be blamed but I soldered (big) wires on jack input on the PCB and add a huge capacitor with a 2 amps PSU and still got inconsistant results (reboot, fail to read .verbose ...) ?!?

 

BTW what about g_ether on A20/bpi M1. Does it really need 4.4 kernel ? (I can spare 1 bt dongle, 1 ethernet switch and 1 usb to eth adaptor with that)

Share this post


Link to post
Share on other sites

Power threw gpio or jack is always erratic so far. Dupont connectors can be blamed but I soldered (big) wires on jack input on the PCB and add a huge capacitor with a 2 amps PSU and still got inconsistant results (reboot, fail to read .verbose ...) ?!?

 

It's a SinoVoip product. I bought many M1 (good product), tried to buy M1+ (not possible back then, European distributor as weird as vendor), bought M2 (crap) just to donate it to linux-sunxi community so that at least mainline kernel support is ok now, bought Lamobo R1 (crap) and wasted many hours/days to get this up and running since SinoVoip refused to hand out hardware information, then decided to never buy anything else than M1 from them ever again.

 

Please report your issues here: http://forum.banana-pi.org/c/Banana-pi-BPI-M2and maybe open up an own thread here in the H3 section to discuss SinoVoip hardware issues.

Share this post


Link to post
Share on other sites

i got the driver installed on windows but it shows "no network cable"

ifconfig also shows the usb0 not having any ip or transmitted data

 

seems to be less straightforward on anything except a *nix system

Share this post


Link to post
Share on other sites

@Xer0

 

"no network cable"

 

Perhaps is it true ? I've got a lot of USB-A micro USB cables, but half of them come from PSU and only wire V+ and GND ...

Share this post


Link to post
Share on other sites

yes i also got lots of errors in dmesg, something about "already xyz"

 

@arox: then it wont even detect the device id and load drivers for it

Share this post


Link to post
Share on other sites

Meanwhile using OS X:

 
By adding g_ether to /etc/modules and the following to /etc/network/interfaces any Armbian H3 device connected through USB this way can be accessed easily:
allow-hotplug usb0
iface usb0 inet static
address 169.254.1.1
netmask 255.255.0.0
pre-up /bin/sh -c 'echo 2 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role'
By using a 'link local' address (169.254.0.0/16) no further network setup is needed. OS X will choose a random IP address from within this range and network connectivity will be established without any hassles:
 
Bildschirmfoto%202016-06-19%20um%2017.50
 
Doing currently a Time Machine backup to an OPi Lite that received the first TM backup through an RTL8153 GbE dongle, now connected locally using the g_ether network approach and will later test backup performance using OPi Lite's Wi-Fi as access point:
 
Bildschirmfoto%202016-06-19%20um%2017.40

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
7 7