Hello,

i have an usb ethernet adapter recognized as  (lsusb :

Bus 005 Device 002: ID 0fe6:9700 Kontron (Industrial Computer Source / ICS Advent) DM9601 Fast Ethernet Adapter 

which is recognized and running fine on linux mint 17 ( kernel 3.16.0-38 - 52 ubuntu 14.04.01) but i can't find a way to make it work on any distro on OPi Lite.

 

1/ i tried nightly armbian xenial ( Armbian_5.27.170327_Orangepilite_Ubuntu_xenial_dev_4.10.3) , it ended up with a continuous message , a kind of kernel panic :

[22.272075] dm9601 5-1:1.0 enx00e04c534458: kevent 4 may have been dropped

 

2/i tried armbian 3.4.113 and followed all instructions in this post  , module g_ether is inserted and there is even dm9601 (lsmod) but no IP and no led blinking on adapter  if /etc/network/interfaces contains :

auto usb0

iface usb0 inet static

address 192.168.1.9

netmask 255.255.255.0

pre-up /bin/sh -c 'echo 2 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role'

and if i replace usb0 with eth0, led blinks, i have the assigned IP but no connection.

 

3/ i found that a patch for this problem was available and inserted in kernel branch 4.4 according to this post , so i tried to compile it using Igor's script. i pasted the file "dm9601-bug.patch" under ~/userpatches/kernel/sun8i-default and even ~/userpatches/kernel/sun8i-dev but both images (regular end dev) lead to error in this patch :

image

 

4/ I tried  image Armbian_5.27_Orangepilite_Debian_jessie_dev_4.10.3 created using same script without trying to apply the patch, the adapter is working very slowly and ping yields to over 30% packet loss on local network between to linux machines. ssh connection is very slow, so i have sometimes to wait between characters.

 

5/ i tried finally to compile version 5.25 with 3.4.113 kernel using this steps :

git clone --depth 1 git://github.com/raspberrypi/linux.git
git clone https://github.com/kmtaylor/rpi_patches.git
cd linux
patch -p1 < ../rpi_patches/dm9601-bug.patch
 KERNEL_SRC=/home/user/linux/
  sudo modprobe configs
   zcat /proc/config.gz > .config
  make menuconfig  # here i selected usb ethernet support and all necessary modules with M or *
  make -j4 uImage modules # i took almost 1h30
  sudo make modules_install
  
                                           

after that i have this content, but can't find how to use it since compiling kernel for arm is different from x86 cause there is no grub to choose the kernel to boot, and i can't find any methods on how to compile kernel (to enable a feature or apply a patch) for armbian except the whole compilation using Igor's script.

Copying zImage to /boot didn't work and gives an error related to /boot /.next and dtb.

sc@orangepilite:~/linux$ ls -l arch/arm/boot/
total 15960
-rwxr-xr-x 1 sc sc 11194368 Mar 27 12:39 Image
-rw-r--r-- 1 sc sc     2816 Mar 27 10:55 Makefile
drwxr-xr-x 2 sc sc     4096 Mar 27 10:55 bootp
drwxr-xr-x 2 sc sc     4096 Mar 27 12:39 compressed
drwxr-xr-x 4 sc sc    69632 Mar 27 10:55 dts
-rw-r--r-- 1 sc sc     1648 Mar 27 10:55 install.sh
-rwxr-xr-x 1 sc sc  5064592 Mar 27 12:39 zImage

So why is this network adapter working on older kernel in Linux mint, and is compilation the right way to make it work?

how to complete the compilation steps described in 5/ ?

any help appreciated

 

 

 

 

 

 

6 minutes ago, rogus said:

0fe6:9700

 

Open the bin and throw your device inside: http://elinux.org/RPi_USB_Ethernet_adapters (the one and only device listed as 'Problem Ethernet adapter'). BTW: g_ether stuff is something completely different.

As a replacement my personal recommendation is RTL8153: https://forum.armbian.com/index.php?/topic/1440-h3-devices-as-nas/

 

You find them for as less as $10 on eBay (or even just $7) or in combination with a VL812 (Rev B2 or newer recommended) as GbE + 3 port hub combo. 

 

i know this is cheap and crap chinese adapter, i bought it cause it was the only one available and easy to deliver, but why is it working on pc on linux mint and may be completing compilation steps could give results.

just take a look, it is working on raspberry here

 

this RTL8153 seems very interesting and at reasonable price. i'll certainly take one from there and of course wait delivery at least one month. but for now i'll continue trying with this bad ethernet gadget.

is there any tuto on how to compile just the kernel for armbian from a running OPI or other card without performing all the steps in crosscompiling ?

4 minutes ago, rogus said:

i know this is cheap and crap chinese adapter, i bought it cause it was the only one available and easy to deliver, but why is it working on pc on linux mint and may be completing compilation steps could give results.

just take a look, it is working on raspberry here

Raspberry Pi kernel applies "dm9601-bug.patch" which is a hack and not a proper solution according to the found info and patch contents. And since there are no USB quirks for this device it's easier to replace it than to modify whole USB Ethernet stack.

 

31 minutes ago, rogus said:

how to complete the compilation steps described in 5/ ?

 

https://github.com/igorpecovnik/lib

Documentation is also linked there.

Please note that the patch you linked applies only to specific kernel versions, so you'll have to recreate the patch that will apply on the selected kernel (3.4.x or 4.10.x).

 

1 minute ago, rogus said:

is there any tuto on how to compile just the kernel for armbian from a running OPI or other card without performing all the steps in crosscompiling ?

Only cross-compilation is officially supported, though you can apply the patches manually and compile the kernel natively on the device.

4 minutes ago, zador.blood.stained said:

Please note that the patch you linked applies only to specific kernel versions, so you'll have to recreate the patch that will apply on the selected kernel (3.4.x or 4.10.x)

 

I threw the patch into userpatches dir and let a legacy kernel build and at least it applies without errors reported (whatever that means):

 

[ o.k. ] ... [u][c] dm9601-bug.patch [ succeeded ]

Here you go: opi-lite-crippled-usb-legacy-5.27.tgz

 

After unpacking a 'dpkg -i linux-image-sun8i_5.27_armhf.deb' should be all that's needed. To check/load driver please use 'modinfo dm9601' and 'modprobe dm9601' and if that works add 'dm9601' to /etc/modules (and then order some RTL8153 to replace this crap since next kernel update from apt.armbian.com will kill the patch anyway  )

1 hour ago, zador.blood.stained said:

Raspberry Pi kernel applies "dm9601-bug.patch" which is a hack and not a proper solution according to the found info and patch contents. And since there are no USB quirks for this device it's easier to replace it than to modify whole USB Ethernet stack.

 

https://github.com/igorpecovnik/lib

Documentation is also linked there.

Please note that the patch you linked applies only to specific kernel versions, so you'll have to recreate the patch that will apply on the selected kernel (3.4.x or 4.10.x).

 

Only cross-compilation is officially supported, though you can apply the patches manually and compile the kernel natively on the device.

i've read that this patch (hack) corrects some buffer overflow, but since there is no other solution we have to deal with it. I know the easiest way is to buy an RTL based chip adapter as advised by Tkaiser and that's what i'm gonna do but remember the first philosophy of raspberry or arm based nano cards at the beginning; it was to use old or cheap hardware such as keyboard mouse and 15 years old crt screen. Many people purchased that 1,5$ chinese adapter and since OPi lite contains 2usb and 1 OTG, i think statistically many people will face this problem in the future.

I have read documentation about user provided patches under user configuration, and despite the patch was in the right place i did not succeed.

i really don't know what to change in that patch, in the kmtaylor git there are a few lines of code, ?

compiling the kernel natively should be more documented or a short tuto (step by step) could help to avoid bandwidth consumption at each entire cross-compilation.

 

1 hour ago, tkaiser said:

Here you go: opi-lite-crippled-usb-legacy-5.27.tgz

 

After unpacking a 'dpkg -i linux-image-sun8i_5.27_armhf.deb' should be all that's needed. To check/load driver please use 'modinfo dm9601' and 'modprobe dm9601' and if that works add 'dm9601' to /etc/modules (and then order some RTL8153 to replace this crap since next kernel update from apt.armbian.com will kill the patch anyway  )

how did you succeed in applying the patch? i'm gonna try it . for now i'm running 5.25 but that should apply since it is the same kernel.

for sure i will order the RTL based adapter, to avoid headache in the future, but i'm pretty sure many people will face this issue in the future until xunlong developp a OPi one with 2usb +1 OTG.

2 minutes ago, rogus said:

how did you succeed in applying the patch?

 

From my shell's history on my Armbian build host:

 2017  git clone https://github.com/kmtaylor/rpi_patches.git
 2019  cp -p rpi_patches/dm9601-bug.patch userpatches/kernel/sun8i-default/
 2028  ./compile.sh KERNEL_ONLY=yes KERNEL_CONFIGURE=no PROGRESS_DISPLAY=plain RELEASE=xenial COMPRESS_OUTPUTIMAGE=no BRANCH=default BOARD=orangepilite
 2029  cd output/debs/
 2031  tar cf - linux-u-boot-orangepilite_5.27_armhf.deb linux-firmware-image-sun8i_5.27_armhf.deb linux-headers-sun8i_5.27_armhf.deb linux-image-sun8i_5.27_armhf.deb | gzip -c >opi-lite-crippled-usb-legacy-5.27.tgz

BTW: this was a one time try just to get feedback. We will surely neither integrate such broken patches by default nor spend any time on provoding help to do a full kernel compile on an SBC (since it's an insane waste of time). We spent a lot of time to ease driver compilation and this should work out of the box simply by following documentation: https://docs.armbian.com/User-Guide_Advanced-Features/#how-to-build-a-wireless-driver

 

This case was different since instead of using a fixed driver your proposed patch based on drivers/net/usb/usbnet.c -- I'm only interested whether this works for you now but the real solution is to throw away broken hardware (USB 1.1 capable devices announcing themselve as USB 2.0 capable are just this).

 

For anyone else stumbling accross this. My 1st link above mentions a 'real fix' here: https://github.com/raspberrypi/linux/issues/1045 (no idea, I did not read through since I don't want to waste my time with crappy hardware). But in case there's a fixed driver then obvisouly the simple solution is to follow Armbian's documentation and build just the driver. Apart from that I'm not overly concerned about 'buy cheap, buy twice' decisions made by users since the proper fix is encoded already in the sentence (realize that you have to buy again)  

7 minutes ago, tkaiser said:

realize that you have to buy again

you're right ! i bought it almost one year ago, so a long time before opi lite appears. if i knew....

1 hour ago, rogus said:

bought it almost one year ago, so a long time before opi lite appears

 

While I still don't understand the relationship with OPi Lite (the adapter is the problem  ) I'm still interested in results now. Did you already install the patched kernel and tried to load the module? And did some 'stress testing' (we include iperf3 by default to do stuff like this)?

Well there is no direct relationship between Opi lite and this adapter, the choice of Opi lite is just for the number of usb compared to Opi one, and since the adapter was already present, i thought it will do the trick.

about the tests, after installing the patched kernel (adapter not plugged in)

root@orangepilite:~# modinfo dm9601
filename:       /lib/modules/3.4.113-sun8i/kernel/drivers/net/usb/dm9601.ko
license:        GPL
description:    Davicom DM9601 USB 1.1 ethernet devices
author:         Peter Korsgaard <jacmet@sunsite.dk>
alias:          usb:v0A46p9000d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v0FE6p9700d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v0FE6p8101d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v0A47p9601d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v0A46p8515d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v0A46p0268d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v0A46p6688d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v0A46p9601d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v07AAp9601d*dc*dsc*dp*ic*isc*ip*
depends:        usbnet
intree:         Y
vermagic:       3.4.113-sun8i SMP preempt mod_unload modversions ARMv7 p2v8 

root@orangepilite:~# modprobe dm9601
root@orangepilite:~# lsmod
Module                  Size  Used by
dm9601                  6431  0 
usbnet                 14100  1 dm9601
bluetooth             174097  0 
pcf8591                 3363  0 
bmp085                  3487  0 
ir_lirc_codec           3650  0 
lirc_dev                7834  1 ir_lirc_codec
ir_mce_kbd_decoder      2885  0 
ir_sanyo_decoder        1480  0 
ir_sony_decoder         1422  0 
ir_jvc_decoder          1452  0 
ir_rc6_decoder          1941  0 
ir_rc5_decoder          1412  0 
ir_nec_decoder          1556  0 
g_serial               27617  2 
sunxi_cir               1601  0 
rc_core                12727  10 ir_lirc_codec,ir_rc5_decoder,ir_nec_decoder,ir_sony_decoder,sunxi_cir,ir_mce_kbd_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_sanyo_decoder
8189fs               1050451  0 
btrfs                 712409  0 

after that i disabled wifi settings in /etc/network/interfaces and left the file blank and restarted OPI : i can log in normally, but once the adapter is plugged in the OTG port, there is no IP

ifconfig gives lo and wlan0 only and i cannot log out or restart the Opi.

 

i edited /etc/network interfaces to

auto lo

auto eth0

iface eth0 inet dhcp

 

ifup eth0 gives cannot find device.

lsmod now gives

.......

dm9601  6431   0

qf9700    5954   0

usbnet    14100  2 dm9601,qf9700

.......

with the above configuration the board hangs up at restart if adapter is plugged, i can login, then after password it hangs.

i changed the port from OTG to normal USB, and it finally worked.

ifconfig gives lo, eth0 (with local ip) and wlan0 and i can normally restart or halt the board.

i tested ping on local machine and it gives between 30-40% packet loss. i don't think we can use iperf3 with such results....

i really don't understand why it worked on raspberry according to previous links.

 

 

                          

 

2 hours ago, rogus said:

i don't think we can use iperf3 with such results....

 

It was not about performance but reliability/stability. If iperf3 locks up the board then nothing is fixed and you might look into compiling a fixed driver or simply accept that an USB 1.1 device (12Mbps) that negiotiates Fast Ethernet connections is broken by design anyway.

 

The reason I recommend RTL8153 above and not even any USB2 devices is simple. The risk to get fake crap (cloned ASICs) is minimized. Just read through this to get the idea: https://projectgus.com/2013/03/anatomy-of-a-cheap-usb-ethernet-adapter/ 

I've read this page months ago, may be last year before purchasing this crap adapter. I'm looking on ebay and aliexpress for an RTL8153 based as you advised  and while waiting for shipping time i'm gonna take a look at driver compilation and perform some tests.

just one more question is asix AX88179 supported like RTL8153 in armbian? there's one sample here

 

 

15 minutes ago, rogus said:

just one more question is asix AX88179 supported like RTL8153 in armbian?

 

Don't think so. RTL8153 has good driver support in every major OS, has been added upstream to mainline kernel with 3.12 or 3.14 but has also been backported by many SoC vendors to older kernel variants (eg. sun8i legacy kernel -- performance isn't that great but hey...)

 

I ordered one AX88179 just recently even if I know about the drawbacks (need to compile the driver myself and reported driver hassles especially with small files on various platforms). Will share my results then as usual but that won't change much regarding the only recommended GbE dongle: still RTL8153.

 

For anyone else reading this or stumbling accross through a web search: Support of a specific hardware 'in Armbian' is always a question of the kernel used. And since Armbian supports two kernels (legacy/mainline) on most boards it may depend. It's rather easy: If you can choose between 2 alternatives (with GbE and USB3 it's exactly that: either AX88179 or RTL8153) and one has its driver mainlined (in official kernel including peer review process and so on) and the other not... you choose the former without thinking twice

Seeing this thread, that's reminded me that I have a DM9601 sitting in one of my junk boxes ...

I gave it a try with Mainline, and it worked out-of-the-box, it is even currently part of the kernel (not as modules).

 

3 hours ago, tkaiser said:

Will share my results then as usual but that won't change much regarding the only recommended GbE dongle: still RTL8153.

ok, then my choice is done: it will be the RTL based, it seems widely used, much more than the AX88179 which is sold by only one dealer.

 

1 hour ago, martinayotte said:

and it worked out-of-the-box,

Is it original dm9601 or chinese copy recognized as dm9601 ? and it worked on armbian based 5.27 with kernel 4.10.3?

I didn't opened the casing, but I presume it is a clone since I've purchased it in China thru eBay.

 

On 27/03/2017 at 7:07 PM, tkaiser said:

As a replacement my personal recommendation is RTL8153: https://forum.armbian.com/index.php?/topic/1440-h3-devices-as-nas/

 

You find them for as less as $8 on eBay $10 on eBay or in combination with a VL812 (Rev B2 or newer recommended) as GbE + 3 port hub combo. 

 

Beware of the USB3 hub Ethernet combo.

I tried one with very poor Ethernet performance.

Hub seems OK but doesn't allow for external power supply.

6 hours ago, Ford Prefect said:

Beware of the USB3 hub Ethernet combo.

 

'The'? There are thousands available...

 

Would you mind posting lsusb output to get a clue which device you use?

Hi

here it is:

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 002: ID 0e8f:2517 GreenAsia Inc.
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 003: ID 0bda:8153 Realtek Semiconductor Corp.
Bus 004 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 148f:2573 Ralink Technology, Corp. RT2501/RT2573 Wireless Adapter
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0ccd:0097 TerraTec Electronic GmbH Cinergy T RC MKII
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

It is seen as Realtek

I believe "Green Asia" is my wireless keyboard dongle

bilou@orangepipc:~$ sudo ifconfig
eth0      Link encap:Ethernet  HWaddr 7e:c3:14:57:e7:b1
          inet addr:192.168.1.95  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::7cc3:14ff:fe57:e7b1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4217 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3219 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1010982 (987.2 KiB)  TX bytes:374340 (365.5 KiB)
          Interrupt:114

eth1      Link encap:Ethernet  HWaddr 00:e0:4c:68:13:06
          inet6 addr: fe80::2e0:4cff:fe68:1306/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 TX bytes:90 (90.0

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:4 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:200 (200.0 TX bytes:200 (200.0

 

here is the tail of dmesg when connecting the device

 

[  300.469091] ehci_irq: highspeed device connect
[  300.730076] usb 4-1: new high-speed USB device number 2 using sunxi-ehci
[  300.883751] hub 4-1:1.0: USB hub found
[  300.884323] hub 4-1:1.0: 4 ports detected
[  301.160120] usb 4-1.1: new high-speed USB device number 3 using sunxi-ehci
[  301.307001] cdc_ether 4-1.1:2.0: eth1: register 'cdc_ether' at usb-sunxi-ehci                           -1.1, CDC Ethernet Device, 00:e0:4c:68:13:06
[  301.307544] usbcore: registered new interface driver cdc_ether
b

 

1 hour ago, Ford Prefect said:

Bus 004 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub

 

Thanks! That's the USB2.0 part of a Genesys Logic GL3520. I wrote above of ' VL812 (Rev B2 or newer recommended)'

 

BTW: Genesys Logic is also the creator of the most crappy USB-to-SATA bridge known: http://www.cnx-software.com/2017/03/16/suptronics-x800-2-5-sata-drive-expansion-board-and-cases-for-raspberry-pi-23-and-odroid-c2-boards/#comment-540247 (GL830 is not only slow as hell but also broken! But still used on new gadgets and also present on some SBC that should be avoided for that reason alone)

 

Edit: Maybe I should elaborate on that? All that really matters in some electronic gadgets is the chipset(s) used. As it's exactly the case with Hub+Ethernet combos. IMO a great way to get the right gadget is to do a google search for '8153 via812 site:amazon.com' in this case since you find

 

• only products listed that mention the chipsets (sometimes in comments/reviews only then you should be careful since then the manufacturer might replace the chip(s) in a new product revision without notice!)
• reviews/ratings you can read through (the only real advantage using Amazon IMO)
• even a manufacturer/seller you might start to trust in. I for example discovered by accident that I shopped a lot of stuff from the same german 'manufacturer'within the last 2 or 3 years. It seems they focus on choosing quality ingredients, import the stuff from China and sell them with useful product descriptions and documentation through Amazon oder eBay -- example (but no recommendation, I don't have this device)

Small follow-up on the Gigabit Ethernet + USB hub combo. As already recommended above I would only use the combination of a VIA812 hub with RTL8153 even on USB2 ports. Since numbers are fine.

 

This is two times the same setup: An Orange Pi Zero 2 (the one without Ethernet at all) with an Intel 540 SSD behind an JMS567 USB-to-SATA bridge on USB port 2 and on USB port 3 an RTL8153. The first times directly, the second time behind a VIA812 (it's an ORICO combo thingie for 20 bucks). It's a NAS benchmark done with mainline kernel, a recent Netatalk and macOS version as client:

 

RTL8153 directly connected:

And now RTL8153 in the ORICO hub and behind the VIA812:

Numbers are more or less the same (performance decrease is negligible  )