C1+ USB OTG Ethernet Gadget

Moderators: mdrjr, odroid

C1+ USB OTG Ethernet Gadget

Unread postby crick » Thu May 10, 2018 7:50 pm

Hi,

I am trying to configure the C1+ USB OTG Ethernet Gadget to behave in a similar way to the Beaglebone Black. Basically if you plug it into a PC (Linux or Windows) it will automatically issue the host PC interface with an IP address and it would be able to connect to a web server on the C1+.

However I am unable to get even a simple connection established between the C1+ and a linux host PC, following the same instructions as in the Feb 2014 Odroid magazine article concerning the OTG Gadget. (https://magazine.odroid.com/wp-content/uploads/ODROID-Magazine-201402.pdf#page=16)

C1+ upon loading g_ether module:
Code: Select all
$ modprobe g_ether
$ dmesg
...
[  518.357441] g_ether gadget: using random host ethernet address
[  518.358127] usb0: MAC ee:20:fd:7e:38:ce
[  518.358139] usb0: HOST MAC ce:45:33:03:64:b8
[  518.358226] g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
[  518.358242] g_ether gadget: g_ether ready
[  518.491876] USB RESET
[  518.618911] USB RESET
[  518.757373] g_ether gadget: high-speed config #1: CDC Ethernet (ECM)


Host PC after connecting USB cable:
Code: Select all
$ dmesg
...
[920299.663128] cdc_ether 3-3:1.0 usb0: register 'cdc_ether' at usb-0000:00:14.0-3, CDC Ethernet Device, ce:45:33:03:64:b8
[920299.669082] cdc_ether 3-3:1.0 enp0s20u3: renamed from usb0


Setting IP address on C1+:
Code: Select all
$ ip addr add 192.168.100.1/24 dev usb0
$ ip link set dev usb0 up
$ ip addr
...
usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether ee:20:fd:7e:38:ce brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.1/24 scope global usb0
       valid_lft forever preferred_lft forever
    inet6 fe80::ec20:fdff:fe7e:38ce/64 scope link
       valid_lft forever preferred_lft forever
$ ip route
192.168.100.0/24 dev usb0  proto kernel  scope link  src 192.168.100.1


Setting IP Address on Host PC:
Code: Select all
$ ip addr add 192.168.100.2/24 dev enp0s20u3
$ ip link set dev enp0s20u3 up             
$ ip addr
...
enp0s20u3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether ce:45:33:03:64:b8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.2/24 scope global enp0s20u3
       valid_lft forever preferred_lft forever
    inet6 fe80::2686:a9e:889b:3632/64 scope link
       valid_lft forever preferred_lft forever
$ ip route
...
192.168.100.0/24 dev enp0s20u3 proto kernel scope link src 192.168.100.2


Trying to ping in either direction results in "Destination Host Unreachable", however the number of "RX Packets" on the interface increments with each ping. Doing the same exact steps with an ethernet cable between the C1+ and the host PC works as expected, can ping and SSH from both directions.

Does anyone have any advice on how to get the Ethernet over USB connection set up properly?
crick
 
Posts: 8
Joined: Thu Jul 06, 2017 11:55 pm
languages_spoken: english
ODROIDs: C0, C1+, XU4

Re: C1+ USB OTG Ethernet Gadget

Unread postby odroid » Fri May 11, 2018 3:48 am

The MAC address seems to be wrong. Refer this thread.
viewtopic.php?f=111&t=29323
User avatar
odroid
Site Admin
 
Posts: 28703
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

Re: C1+ USB OTG Ethernet Gadget

Unread postby crick » Fri May 11, 2018 7:08 pm

Thanks for your response @odroid.

It's my understanding that the gadget creates two MAC addresses for both ends of the connection when it is loaded. The HOST MAC is assigned to the interface on the Host PC which is what happens for me. Strangely in the Odroid Magazine article, the interface on the Host PC is different to the one created by the gadget.

Thanks for pointing out that thread. I've done the following steps to get the diagnostic info @mad_ady asked for in that thread:

C1+ Setup (loaded g_ether with fixed host and device MAC addresses):
Code: Select all
$ modprobe g_ether host_addr=00:11:22:33:44:55 dev_addr=00:55:44:33:22:11
$ dmesg
...
[  303.559766] usb0: MAC 00:55:44:33:22:11
[  303.559848] usb0: HOST MAC 00:11:22:33:44:55
[  303.562882] g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
[  303.569421] g_ether gadget: g_ether ready
$ ifconfig usb0 192.168.100.1 netmask 255.255.255.0 up
$ ifconfig usb0
usb0      Link encap:Ethernet  HWaddr 00:55:44:33:22:11 
          inet addr:192.168.100.1  Bcast:192.168.100.255  Mask:255.255.255.0
          inet6 addr: fe80::255:44ff:fe33:2211/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1214 (1.1 KiB)  TX bytes:328 (328.0 B)


Host PC:
Code: Select all
$ dmesg
...
[1003251.833148] cdc_ether 3-4:1.0 eth0: register 'cdc_ether' at usb-0000:00:14.0-4, CDC Ethernet Device, 00:11:22:33:44:55
[1003251.839890] cdc_ether 3-4:1.0 enp0s20u4: renamed from eth0
$ ifconfig enp0s20u4 192.168.100.2 netmask 255.255.255.0 up
$ ifconfig enp0s20u4
enp0s20u4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.100.2  netmask 255.255.255.0  broadcast 192.168.100.255
        inet6 fe80::5790:5116:375c:54dd  prefixlen 64  scopeid 0x20<link>
        ether 00:11:22:33:44:55  txqueuelen 1000  (Ethernet)
        RX packets 6  bytes 384 (384.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 14  bytes 2751 (2.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


C1+ tcpdump while pinging from Host PC:
Code: Select all
HOST:
$ ping -c 5 192.168.100.1
PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
From 192.168.100.2 icmp_seq=1 Destination Host Unreachable
From 192.168.100.2 icmp_seq=2 Destination Host Unreachable
From 192.168.100.2 icmp_seq=3 Destination Host Unreachable
From 192.168.100.2 icmp_seq=4 Destination Host Unreachable
From 192.168.100.2 icmp_seq=5 Destination Host Unreachable

C1+:
tcpdump -n -i usb0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on usb0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:58:30.872680 ARP, Request who-has 0.0.0.0 (03:00:65:74:68:30) tell 192.168.9.0, length 28
09:58:31.879960 ARP, Request who-has 255.255.255.255 (ff:ff:ff:ff:ff:ff) tell 192.168.255.255, length 28
09:58:32.893302 ARP, Request who-has 0.0.0.0 (03:00:75:73:62:30) tell 192.168.9.0, length 28
09:58:33.907047 ARP, Request who-has 255.255.255.255 (ff:ff:ff:ff:ff:ff) tell 192.168.255.255, length 28
09:58:34.920007 ARP, Request who-has 255.255.255.255 (ff:ff:ff:ff:ff:ff) tell 192.168.255.255, length 28
09:58:35.933324 ARP, Request who-has 255.2.0.0 (44:ff:fe:33:22:11) tell 192.168.2.85, length 28


Host tcpdump while pinging from C1+:
Code: Select all
C1+:
$ ping -c 5 192.168.100.2
PING 192.168.100.2 (192.168.100.2) 56(84) bytes of data.
From 192.168.100.1 icmp_seq=1 Destination Host Unreachable
From 192.168.100.1 icmp_seq=2 Destination Host Unreachable
From 192.168.100.1 icmp_seq=3 Destination Host Unreachable
From 192.168.100.1 icmp_seq=4 Destination Host Unreachable
From 192.168.100.1 icmp_seq=5 Destination Host Unreachable

--- 192.168.100.2 ping statistics ---
5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4006ms

HOST:
$ tcpdump -n -i enp0s20u4
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp0s20u4, link-type EN10MB (Ethernet), capture size 262144 bytes
10:50:42.219078 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:11:22:33:44:55, length 363
10:50:49.190801 ARP, Request who-has 192.168.100.2 tell 192.168.100.1, length 28
10:50:49.190853 ARP, Reply 192.168.100.2 is-at 00:11:22:33:44:55, length 28
10:50:50.186780 ARP, Request who-has 192.168.100.2 tell 192.168.100.1, length 28
10:50:50.186808 ARP, Reply 192.168.100.2 is-at 00:11:22:33:44:55, length 28
10:50:51.186751 ARP, Request who-has 192.168.100.2 tell 192.168.100.1, length 28
10:50:51.186782 ARP, Reply 192.168.100.2 is-at 00:11:22:33:44:55, length 28
10:50:52.195897 ARP, Request who-has 192.168.100.2 tell 192.168.100.1, length 28
10:50:52.195927 ARP, Reply 192.168.100.2 is-at 00:11:22:33:44:55, length 28
10:50:53.186776 ARP, Request who-has 192.168.100.2 tell 192.168.100.1, length 28
10:50:53.186808 ARP, Reply 192.168.100.2 is-at 00:11:22:33:44:55, length 28
10:50:54.186729 ARP, Request who-has 192.168.100.2 tell 192.168.100.1, length 28
10:50:54.186777 ARP, Reply 192.168.100.2 is-at 00:11:22:33:44:55, length 28


To me the ARP requests from the C1+ pinging the host look correct but in the other direction they make no sense with non-existant hosts like 192.168.9.0 and 192.168.2.85 making requests.

I do not know very much about networking. Do you know what this signifies?
crick
 
Posts: 8
Joined: Thu Jul 06, 2017 11:55 pm
languages_spoken: english
ODROIDs: C0, C1+, XU4

Re: C1+ USB OTG Ethernet Gadget

Unread postby crick » Mon May 14, 2018 10:35 pm

Could someone else with a C1+ please try the following steps to see if they are getting the same behavior?

On the C1+ (Micro USB end of OTG cable plugged in):
Code: Select all
$ modprobe g_ether
$ ifconfig usb0 192.168.100.1 netmask 255.255.255.0 up


On the host (with USB Type A end of OTG cable plugged in):
Code: Select all
// check the host picked up the interface and get the name
$ dmesg
...
[1003251.833148] cdc_ether 3-4:1.0 eth0: register 'cdc_ether' at usb-0000:00:14.0-4, CDC Ethernet Device, 00:11:22:33:44:55
[1003251.839890] cdc_ether 3-4:1.0 enp0s20u4: renamed from eth0
$ ifconfig <interface name> 192.168.100.2 netmask 255.255.255.0 up
$ ping 192.168.100.1
crick
 
Posts: 8
Joined: Thu Jul 06, 2017 11:55 pm
languages_spoken: english
ODROIDs: C0, C1+, XU4

Re: C1+ USB OTG Ethernet Gadget

Unread postby mad_ady » Tue May 15, 2018 12:42 am

I'll try to test it next week, when i'm reunited with my C1. If anyone can test sooner, then great!
User avatar
mad_ady
 
Posts: 4585
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1

Re: C1+ USB OTG Ethernet Gadget

Unread postby mad_ady » Mon May 28, 2018 5:19 pm

Sorry, I hadn't had time to test until now. I reproduced your setup and tests:
c1:
Code: Select all
root@c1-dev:~# modprobe g_ether
root@c1-dev:~# ifconfig usb0 192.168.100.1 netmask 255.255.255.0 up
dmesg
...
[239484.538328] g_ether gadget: using random self ethernet address
[239484.538346] g_ether gadget: using random host ethernet address
[239484.539767] usb0: MAC 3e:82:15:c8:e6:ab
[239484.539779] usb0: HOST MAC 32:c8:32:50:91:78
[239484.539844] g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
[239484.539860] g_ether gadget: g_ether ready
[239500.321263] IPv6: ADDRCONF(NETDEV_UP): usb0: link is not ready



PC (ubuntu 18.04, kernel 4.15.0-20-generic:
Code: Select all
dmesg:
[2393914.590754] usb 3-1.4: New USB device found, idVendor=0525, idProduct=a4a2
[2393914.590755] usb 3-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[2393914.590757] usb 3-1.4: Product: RNDIS/Ethernet Gadget
[2393914.590758] usb 3-1.4: Manufacturer: Linux 3.10.107-190 with dwc_otg_pcd
[2393914.627994] cdc_ether 3-1.4:1.0 usb0: register 'cdc_ether' at usb-0000:00:14.0-1.4, CDC Ethernet Device, 32:c8:32:50:91:78
[2393914.628415] usbcore: registered new interface driver cdc_ether
[2393914.633190] usbcore: registered new interface driver cdc_subset
[2393914.729351] IPv6: ADDRCONF(NETDEV_UP): usb0: link is not ready
adrianp@frost:~$ sudo ifconfig usb0 192.168.100.2 netmask 255.255.255.0 up
adrianp@frost:~$ ping 192.168.100.1
PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
From 192.168.100.2 icmp_seq=1 Destination Host Unreachable
From 192.168.100.2 icmp_seq=2 Destination Host Unreachable
From 192.168.100.2 icmp_seq=3 Destination Host Unreachable
adrianp@frost:~$ ip route get 192.168.100.1
192.168.100.1 dev usb0 src 192.168.100.2 uid 1001
    cache
adrianp@frost:~$ arp -an | grep 192.168.100.1
? (192.168.100.1) at <incomplete> on usb0


Packet captures of ARP requests looks fine on the PC:
Code: Select all
11:03:29.906796 ARP, Request who-has 192.168.100.1 tell 192.168.100.2, length 28
11:03:30.931076 ARP, Request who-has 192.168.100.1 tell 192.168.100.2, length 28
11:03:31.954785 ARP, Request who-has 192.168.100.1 tell 192.168.100.2, length 28
11:03:32.978825 ARP, Request who-has 192.168.100.1 tell 192.168.100.2, length 28
11:03:34.002962 ARP, Request who-has 192.168.100.1 tell 192.168.100.2, length 28
11:03:35.026800 ARP, Request who-has 192.168.100.1 tell 192.168.100.2, length 28
11:03:36.050823 ARP, Request who-has 192.168.100.1 tell 192.168.100.2, length 28
11:03:37.075118 ARP, Request who-has 192.168.100.1 tell 192.168.100.2, length 28
11:03:38.098821 ARP, Request who-has 192.168.100.1 tell 192.168.100.2, length 28
11:03:39.122796 ARP, Request who-has 192.168.100.1 tell 192.168.100.2, length 28
^C


But packets arrive garbled at the remote end:
Code: Select all
11:03:15.249830 IP 192.168.100.2.7003 > 53.108.13.10.13112:  rx type 27 (1472)
11:03:15.249949 IP 192.168.100.2 > 53.108.13.10: ip-proto-17
11:03:15.250078 IP 192.168.100.2 > 53.108.13.10: ip-proto-17
11:03:15.250135 IP 192.168.100.2 > 101.100.101.115: ip-proto-17
11:03:15.250206 IP 192.168.100.2.27508 > 101.100.101.115.28528: UDP, bad length 12139 > 182
11:03:15.563959 IP 192.168.100.2.27508 > 101.100.101.115.28528: UDP, bad length 12139 > 167
11:03:15.951133 IP 192.168.100.2.27508 > 101.100.101.115.28528: UDP, bad length 12139 > 400
11:03:16.564433 IP 192.168.100.2.23368 > 50.51.114.27.7003:  rx type 101 (167)
11:03:17.153162 IP 192.168.100.2.7003 > 53.108.13.10.13112:  rx type 27 (217)
11:03:17.392075 IP 192.168.100.2.7003 > 53.108.13.10.13112:  rx type 27 (1472)
11:03:17.392191 IP 192.168.100.2 > 53.108.13.10: ip-proto-17
11:03:17.392291 IP 192.168.100.2 > 53.108.13.10: ip-proto-17
11:03:17.392338 IP 192.168.100.2 > 50.58.48.51: ip-proto-17
11:03:17.392410 IP 192.168.100.2.11825 > 51.58.49.52.14133: UDP, bad length 12841 > 467
11:03:17.563137 IP 192.168.100.2.7003 > 53.108.13.10.13112:  rx type 27 (40)
11:03:17.563679 IP 192.168.100.2.7003 > 53.108.13.10.13112:  rx type 27 (40)
11:03:17.565093 IP 192.168.100.2.23368 > 50.51.114.27.7003:  rx type 58 (167)
11:03:18.026014 IP 192.168.100.2.7003 > 53.108.13.10.13112:  rx type 0 (400)
11:03:18.564107 IP 192.168.100.2.23368 > 50.51.114.27.7003:  rx type 101 (40)
11:03:18.564705 IP 192.168.100.2.7003 > 53.108.13.10.13112:  rx type 27 (40)
11:03:20.565038 IP 192.168.100.2.7003 > 53.108.13.10.13112:  rx type 27 (40)
11:03:20.565126 IP 192.168.100.2.7003 > 53.108.13.10.13112:  rx type 27 (40)
11:03:21.154470 IP 192.168.100.2.7003 > 53.108.13.10.13112:  rx type 27 (217)
11:03:27.859408 ARP, Request who-has 52.54.55.32 (30:33:2e:38:33:38) tell 192.168.50.58, length 28
11:03:28.881806 ARP, Request who-has 59.53.59.50 (0d:0a:1b:5b:33:38) tell 192.168.53.108, length 28
11:03:29.159190 IP 192.168.100.2.7003 > 53.108.13.10.13112:  rx type 27 (217)
11:03:29.906321 ARP, Request who-has 59.53.59.50 (0d:0a:1b:5b:33:38) tell 192.168.53.108, length 28
11:03:30.931124 ARP, Request who-has 50.50.100.49 (72:1b:5b:48:1b:5b) tell 192.168.50.51, length 28
11:03:31.955335 ARP, Request who-has 59.53.59.50 (0d:0a:1b:5b:33:38) tell 192.168.53.108, length 28
11:03:32.979896 ARP, Request who-has 50.51.100.49 (72:1b:5b:48:1b:5b) tell 192.168.50.51, length 28
11:03:34.004553 ARP, Request who-has 59.53.59.50 (0d:0a:1b:5b:33:38) tell 192.168.53.108, length 28
11:03:35.028876 ARP, Request who-has 59.53.59.50 (0d:0a:1b:5b:33:38) tell 192.168.53.108, length 28
11:03:36.053027 ARP, Request who-has 59.53.59.50 (0d:0a:1b:5b:33:38) tell 192.168.53.108, length 28
11:03:37.077322 ARP, Request who-has 59.53.59.50 (0d:0a:1b:5b:33:38) tell 192.168.53.108, length 28
11:03:38.101021 ARP, Request who-has 52.54.55.32 (30:33:2e:38:33:38) tell 192.168.50.58, length 28
11:03:39.124987 ARP, Request who-has 59.53.59.50 (0d:0a:1b:5b:33:38) tell 192.168.53.108, length 28



The C1 dmesg occasionaly outputs:
Code: Select all
[239777.128678] UDP: short packet: From 192.168.100.2:5353 438/225 to 224.0.0.251:5353


If I set the MAC manually on the PC side, I can ping, but the incoming packets get malformed and there is no reply:
PC:
Code: Select all
adrianp@frost:~$ sudo arp -s 192.168.100.1 3e:82:15:c8:e6:ab
adrianp@frost:~$ arp -an | grep 192.168.100.1
? (192.168.100.1) at 3e:82:15:c8:e6:ab [ether] PERM on usb0
adrianp@frost:~$ ip route get 192.168.100.1
192.168.100.1 dev usb0 src 192.168.100.2 uid 1001
    cache
adrianp@frost:~$ ping 192.168.100.1
PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
^C
--- 192.168.100.1 ping statistics ---
53 packets transmitted, 0 received, 100% packet loss, time 53227ms



C1:
Code: Select all
11:11:58.598806 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:11:59.602568 IP 192.168.100.2 > 53.108.27.91: ICMP type-#54, length 64
11:12:00.626634 IP 192.168.100.2 > 53.108.27.91: ICMP type-#54, length 64
11:12:01.650563 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:02.674573 IP 192.168.100.2 > 101.100.101.115: ICMP type-#107, length 64
11:12:03.698612 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:04.722553 IP 192.168.100.2 > 53.108.27.91: ICMP type-#54, length 64
11:12:05.746550 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:06.770564 IP 192.168.100.2 > 53.108.27.91: ICMP type-#54, length 64
11:12:07.794592 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:08.818550 IP 192.168.100.2 > 101.100.101.115: ICMP type-#107, length 64
11:12:09.842601 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:10.866587 IP 192.168.100.2 > 101.100.101.115: ICMP type-#107, length 64
11:12:11.890542 IP 192.168.100.2 > 101.100.101.115: ICMP type-#107, length 64
11:12:12.914603 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:13.938547 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:14.962561 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:15.986563 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:17.010562 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:18.034547 IP 192.168.100.2 > 101.100.101.115: ICMP type-#107, length 64
11:12:19.058553 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:20.082485 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:21.106522 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:22.130660 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:23.154539 IP 192.168.100.2 > 101.100.101.115: ICMP type-#107, length 64
11:12:24.182494 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:25.202539 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:26.226438 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:27.250518 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:28.274540 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:29.298490 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:30.322516 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:31.346499 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:32.370457 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:33.394450 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:34.418492 IP 192.168.100.2 > 101.100.101.115: ICMP type-#107, length 64
11:12:35.442478 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:36.466402 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:37.490415 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:38.514403 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:39.538483 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:40.562454 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:41.586494 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:42.610415 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:43.634457 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:44.658455 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:45.682384 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:46.706460 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:47.730361 IP 192.168.100.2 > 101.100.101.115: ICMP type-#107, length 64
11:12:48.754394 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:49.778452 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:50.802422 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64
11:12:51.826415 IP 192.168.100.2 > 53.108.13.10: ICMP type-#27, length 64


If I try the ping from the other side (C1->PC), I get the ARP request correctly, but the reply is not understood:
PC:
Code: Select all
11:14:42.255259 ARP, Request who-has 192.168.100.2 tell 192.168.100.1, length 28
11:14:42.255273 ARP, Reply 192.168.100.2 is-at 32:c8:32:50:91:78, length 28
11:14:43.254049 ARP, Request who-has 192.168.100.2 tell 192.168.100.1, length 28
11:14:43.254081 ARP, Reply 192.168.100.2 is-at 32:c8:32:50:91:78, length 28
11:14:44.254031 ARP, Request who-has 192.168.100.2 tell 192.168.100.1, length 28


C1:
Code: Select all
11:16:17.199727 ARP, Request who-has 192.168.100.2 tell 192.168.100.1, length 28
11:16:17.199905 ARP, Reply 192.168.53.108 is-at 32:c8:32:50:91:78, length 28
11:16:18.193021 ARP, Request who-has 192.168.100.2 tell 192.168.100.1, length 28
11:16:18.193180 ARP, Reply 192.168.53.108 is-at 32:c8:32:50:91:78, length 28
11:16:19.193019 ARP, Request who-has 192.168.100.2 tell 192.168.100.1, length 28
11:16:19.193162 ARP, Reply 192.168.53.108 is-at 32:c8:32:50:91:78, length 28
11:16:20.202121 ARP, Request who-has 192.168.100.2 tell 192.168.100.1, length 28
11:16:20.202350 ARP, Reply 192.168.101.100 is-at 32:c8:32:50:91:78, length 28
11:16:21.193019 ARP, Request who-has 192.168.100.2 tell 192.168.100.1, length 28
11:16:21.193196 ARP, Reply 192.168.53.108 is-at 32:c8:32:50:91:78, length 28


So, I'd say there's something messing up bytes within the packet on the PC -> C1 side (C1 download stream). It's not networking's fault. It's either the driver (unlikely), the USB stack (likely), or a timing factor/governor (I did my tests on performance).
Maybe other users know better what is going on...
User avatar
mad_ady
 
Posts: 4585
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1

Re: C1+ USB OTG Ethernet Gadget

Unread postby crick » Tue May 29, 2018 2:56 am

Thanks for such thorough testing @mad_ady. Really appreciated!

I'm kind of glad it's not just me getting this issue...

When you say USB stack are you refering to the hardware or the USB drivers?
crick
 
Posts: 8
Joined: Thu Jul 06, 2017 11:55 pm
languages_spoken: english
ODROIDs: C0, C1+, XU4

Re: C1+ USB OTG Ethernet Gadget

Unread postby mad_ady » Tue May 29, 2018 4:00 am

USB drivers. Amlogic's implementation is a bit problematic on the C1, less so on the C2, but even C2 has issues with USB
User avatar
mad_ady
 
Posts: 4585
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1

Re: C1+ USB OTG Ethernet Gadget

Unread postby rooted » Tue May 29, 2018 4:17 am

I don't think OTG is really maintained all that well either, not enough people use it.
User avatar
rooted
 
Posts: 5579
Joined: Fri Dec 19, 2014 9:12 am
Location: Gulf of Mexico, US
languages_spoken: english
ODROIDs: C1, C1+, C2
XU3 Lite, XU4
N1
VU7+
HiFi Shield 2
Smart Power (original)

Re: C1+ USB OTG Ethernet Gadget

Unread postby mad_ady » Tue May 29, 2018 1:09 pm

Hmm. That's an interesting thought. I will try it the other way around. C1 as master and C2 as otg slave. Though I expect it will work in this case.
User avatar
mad_ady
 
Posts: 4585
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1


Return to Issues

Who is online

Users browsing this forum: No registered users and 0 guests