USB TETHERING ISSUE

[arthurkhatch]

We have been using an Motorola G6 phone for internet access on an Odroid C2 with ubuntu 16.04 LTS and it all works fine. However on newer images the usb tethering does not work.
When we set up the internet connection the Odroid time adjusts but cannot we cannot ping or access the internet from the odroid.
We have noticed that internet access works if we turn USB Debugging ON on the phone which we did not have to do in the past at all.

Any clues on what is the issue and how to fix. This happens on all new images of 16.04 and 18.04 for the C2.

[mad_ady]

What do you get in odroid's dmesg when you plug in the phone?
What do the following commands show when tethered(both with adb debugging on/off)?

Code: Select all

ip link show
ip addr show
ip route show
cat /etc/resolv.conf
ping -c 4 8.8.8.8
uname -a
cat /etc/lsb-release

[arthurkhatch]

Here you go !

Outputs when USB DEBUGING OFF on Tethered Phone:

ip link show:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
link/ether 00:1e:06:37:25:6b brd ff:ff:ff:ff:ff:ff
4: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 1000
link/ether da:75:c6:3d:df:f7 brd ff:ff:ff:ff:ff:ff

ip addr show:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether 00:1e:06:37:25:6b brd ff:ff:ff:ff:ff:ff
4: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
link/ether da:75:c6:3d:df:f7 brd ff:ff:ff:ff:ff:ff
inet 192.168.42.100/24 brd 192.168.42.255 scope global noprefixroute usb0
valid_lft forever preferred_lft forever
inet6 fe80::d875:c6ff:fe3d:dff7/64 scope link noprefixroute
valid_lft forever preferred_lft forever

ip addr show:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether 00:1e:06:37:25:6b brd ff:ff:ff:ff:ff:ff
4: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
link/ether da:75:c6:3d:df:f7 brd ff:ff:ff:ff:ff:ff
inet 192.168.42.100/24 brd 192.168.42.255 scope global noprefixroute usb0
valid_lft forever preferred_lft forever
inet6 fe80::d875:c6ff:fe3d:dff7/64 scope link noprefixroute
valid_lft forever preferred_lft forever
odroid@odroid:~$ ip route show
default via 192.168.42.129 dev usb0 proto static metric 100
169.254.0.0/16 dev usb0 scope link metric 1000
192.168.42.0/24 dev usb0 proto kernel scope link src 192.168.42.100 metric 100

cat /etc/resolv.conf:

# Generated by NetworkManager
nameserver 127.0.0.53

ping -c 4 8.8.8.8:

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 192.168.42.100 icmp_seq=1 Destination Host Unreachable
From 192.168.42.100 icmp_seq=2 Destination Host Unreachable
From 192.168.42.100 icmp_seq=3 Destination Host Unreachable
From 192.168.42.100 icmp_seq=4 Destination Host Unreachable

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3007ms
pipe 3

uname -a:

Linux odroid 3.16.72-46 #1 SMP PREEMPT Tue Aug 13 18:09:58 -03 2019 aarch64 aarch64 aarch64 GNU/Linux

cat /etc/lsb-release:

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.3 LTS"


Outputs when USB DEBUGING ON on Tethered Phone:

ip link show:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
link/ether 00:1e:06:37:25:6b brd ff:ff:ff:ff:ff:ff
5: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 1000
link/ether aa:b0:e5:8f:d7:fb brd ff:ff:ff:ff:ff:ff

ip addr show:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether 00:1e:06:37:25:6b brd ff:ff:ff:ff:ff:ff
5: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
link/ether aa:b0:e5:8f:d7:fb brd ff:ff:ff:ff:ff:ff
inet 192.168.42.100/24 brd 192.168.42.255 scope global noprefixroute usb0
valid_lft forever preferred_lft forever
inet6 2607:fb90c2315d737ba0/64 scope global dynamic noprefixroute
valid_lft 3571sec preferred_lft 3571sec
inet6 fe80::a8b0:e5ff:fe8f:d7fb/64 scope link noprefixroute
valid_lft forever preferred_lft forever

ip route show:

default via 192.168.42.129 dev usb0 proto static metric 100
169.254.0.0/16 dev usb0 scope link metric 1000
192.168.42.0/24 dev usb0 proto kernel scope link src 192.168.42.100 metric 100

cat /etc/resolv.conf:

# Generated by NetworkManager
nameserver 127.0.0.53

ping -c 4 8.8.8.8:

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=200 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=40.5 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=35.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=117 time=38.2 ms

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 35.469/78.751/200.683/70.421 ms

uname -a:

Linux odroid 3.16.72-46 #1 SMP PREEMPT Tue Aug 13 18:09:58 -03 2019 aarch64 aarch64 aarch64 GNU/Linux

cat /etc/lsb-release:

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.3 LTS"

[mad_ady]

Hmm, the difference I see is that with debugging on you also get a public ipv6. IPv4 looks the same, yet in the first case the odroid complains that 8.8.8.8 is unreachable, though it has a valid route. In that case could you also ping the gateway? 192.168.42.128?

[arthurkhatch]

Here is the pings:

USB DEBUGGING ON:

ping -c 4 192.168.42.129:

PING 192.168.42.129 (192.168.42.129) 56(84) bytes of data.
64 bytes from 192.168.42.129: icmp_seq=1 ttl=64 time=2.07 ms
64 bytes from 192.168.42.129: icmp_seq=2 ttl=64 time=3.08 ms
64 bytes from 192.168.42.129: icmp_seq=3 ttl=64 time=2.12 ms
64 bytes from 192.168.42.129: icmp_seq=4 ttl=64 time=2.08 ms

--- 192.168.42.129 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 2.075/2.342/3.081/0.427 ms


USB DEBUGGING OFF:

ping -c 4 192.168.42.129:

ping -c 4 192.168.42.129
PING 192.168.42.129 (192.168.42.129) 56(84) bytes of data.
From 192.168.42.100 icmp_seq=1 Destination Host Unreachable
From 192.168.42.100 icmp_seq=2 Destination Host Unreachable
From 192.168.42.100 icmp_seq=3 Destination Host Unreachable
From 192.168.42.100 icmp_seq=4 Destination Host Unreachable

--- 192.168.42.129 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3001ms
pipe 2

[mad_ady]

It would say destination host unreachable if the tethered phone didn't reply to arp requests. You could check by running a tcpdump -n -i usb0 while doing the ping. You should see arp "who has" messages without replies.
Why it doesn't reply? I don't know, but the tethered phone is responsible for it...

[arthurkhatch]

USB DEBUGGING ON:

sudo 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
16:36:46.072318 IP 192.168.42.100 > 192.168.42.129: ICMP echo request, id 4434, seq 6, length 64
16:36:46.074893 IP 192.168.42.129 > 192.168.42.100: ICMP echo reply, id 4434, seq 6, length 64
16:36:46.078830 ARP, Request who-has 192.168.42.100 tell 192.168.42.129, length 28
16:36:46.078852 ARP, Reply 192.168.42.100 is-at ee:b5:65:fc:46:d4, length 28
16:36:47.015133 IP6 2607:fb90:586:d03231cc:56ea:c5dd.44405 > 2607:f8b0:4007:80e::200a.443: Flags [.], ack 989748429, win 269, options [nop,nop,TS val 615920 ecr 2316196687], length 0
16:36:47.051735 IP6 2607:f8b0:4007:80e::200a.443 > 2607:fb90:586:d03231cc:56ea:c5dd.44405: Flags [.], ack 1, win 266, options [nop,nop,TS val 2316241786 ecr 602400], length 0
16:36:47.074125 IP 192.168.42.100 > 192.168.42.129: ICMP echo request, id 4434, seq 7, length 64
16:36:47.075446 IP 192.168.42.129 > 192.168.42.100: ICMP echo reply, id 4434, seq 7, length 64
16:36:48.075185 IP 192.168.42.100 > 192.168.42.129: ICMP echo request, id 4434, seq 8, length 64
16:36:48.077311 IP 192.168.42.129 > 192.168.42.100: ICMP echo reply, id 4434, seq 8, length 64
16:36:49.076504 IP 192.168.42.100 > 192.168.42.129: ICMP echo request, id 4434, seq 9, length 64
16:36:49.079398 IP 192.168.42.129 > 192.168.42.100: ICMP echo reply, id 4434, seq 9, length 64
16:36:49.185130 IP6 2607:fb90:586:d03231cc:56ea:c5dd.59146 > 2607:f8b0:4009:810::200e.443: Flags [.], ack 3800949931, win 329, options [nop,nop,TS val 616137 ecr 783337325], length 0
16:36:49.498517 IP6 2607:f8b0:4009:810::200e.443 > 2607:fb90:586:d03231cc:56ea:c5dd.59146: Flags [.], ack 1, win 265, options [nop,nop,TS val 783382515 ecr 602589], length 0
16:36:50.077585 IP 192.168.42.100 > 192.168.42.129: ICMP echo request, id 4434, seq 10, length 64
16:36:50.080063 IP 192.168.42.129 > 192.168.42.100: ICMP echo reply, id 4434, seq 10, length 64
16:36:51.079219 IP 192.168.42.100 > 192.168.42.129: ICMP echo request, id 4434, seq 11, length 64
16:36:51.080705 IP 192.168.42.129 > 192.168.42.100: ICMP echo reply, id 4434, seq 11, length 64
16:36:51.905129 IP6 2607:fb90:586:d03231cc:56ea:c5dd.43563 > 2607:f8b0:4009:812::200e.443: Flags [.], ack 849060970, win 252, options [nop,nop,TS val 616409 ecr 2593924108], length 0
16:36:52.014277 IP6 2607:f8b0:4009:812::200e.443 > 2607:fb90:586:d03231cc:56ea:c5dd.43563: Flags [.], ack 1, win 289, options [nop,nop,TS val 2593969218 ecr 602868], length 0
16:36:52.025129 IP6 fe80::ecb5:65ff:fefc:46d4 > fe80::9c38:faff:feb6:4541: ICMP6, neighbor solicitation, who has fe80::9c38:faff:feb6:4541, length 32
16:36:52.027337 IP6 fe80::9c38:faff:feb6:4541 > fe80::ecb5:65ff:fefc:46d4: ICMP6, neighbor advertisement, tgt is fe80::9c38:faff:feb6:4541, length 24
16:36:52.051776 IP6 fe80::9c38:faff:feb6:4541 > 2607:fb90:586:d03231cc:56ea:c5dd: ICMP6, neighbor solicitation, who has 2607:fb90:586:d03231cc:56ea:c5dd, length 32
16:36:52.051867 IP6 2607:fb90:586:d03231cc:56ea:c5dd > fe80::9c38:faff:feb6:4541: ICMP6, neighbor advertisement, tgt is 2607:fb90:586:d03231cc:56ea:c5dd, length 24
16:36:52.080882 IP 192.168.42.100 > 192.168.42.129: ICMP echo request, id 4434, seq 12, length 64
16:36:52.082073 IP 192.168.42.129 > 192.168.42.100: ICMP echo reply, id 4434, seq 12, length 64
16:36:53.082363 IP 192.168.42.100 > 192.168.42.129: ICMP echo request, id 4434, seq 13, length 64
16:36:53.085134 IP 192.168.42.129 > 192.168.42.100: ICMP echo reply, id 4434, seq 13, length 64
16:36:54.084338 IP 192.168.42.100 > 192.168.42.129: ICMP echo request, id 4434, seq 14, length 64
16:36:54.087046 IP 192.168.42.129 > 192.168.42.100: ICMP echo reply, id 4434, seq 14, length 64
16:36:55.086242 IP 192.168.42.100 > 192.168.42.129: ICMP echo request, id 4434, seq 15, length 64
16:36:55.087861 IP 192.168.42.129 > 192.168.42.100: ICMP echo reply, id 4434, seq 15, length 64
16:36:55.815141 IP6 2607:fb90:586:d03231cc:56ea:c5dd.50730 > 2607:f8b0:4007:80c::2004.443: Flags [.], ack 3707980806, win 329, options [nop,nop,TS val 616800 ecr 1652735862], length 0
16:36:55.936485 IP6 2607:f8b0:4007:80c::2004.443 > 2607:fb90:586:d03231cc:56ea:c5dd.50730: Flags [.], ack 1, win 265, options [nop,nop,TS val 1652780995 ecr 598753], length 0
16:36:56.088063 IP 192.168.42.100 > 192.168.42.129: ICMP echo request, id 4434, seq 16, length 64
16:36:56.090235 IP 192.168.42.129 > 192.168.42.100: ICMP echo reply, id 4434, seq 16, length 64
16:36:56.135141 IP6 2607:fb90:586:d03231cc:56ea:c5dd.50729 > 2607:f8b0:4007:80c::2004.443: Flags [.], ack 923460749, win 921, options [nop,nop,TS val 616832 ecr 1384100308], length 0
16:36:56.135209 IP6 2607:fb90:586:d03231cc:56ea:c5dd.54949 > 2607:f8b0:4007:800::200a.443: Flags [.], ack 2613303496, win 348, options [nop,nop,TS val 616832 ecr 1970427703], length 0
16:36:56.183130 IP6 2607:f8b0:4007:80c::2004.443 > 2607:fb90:586:d03231cc:56ea:c5dd.50729: Flags [.], ack 1, win 266, options [nop,nop,TS val 1384145419 ecr 598788], length 0
16:36:56.189498 IP6 2607:f8b0:4007:800::200a.443 > 2607:fb90:586:d03231cc:56ea:c5dd.54949: Flags [.], ack 1, win 265, options [nop,nop,TS val 1970472814 ecr 598795], length 0
16:36:56.295126 IP6 2607:fb90:586:d03231cc:56ea:c5dd.38038 > 2607:f8b0:4007:80d::2003.443: Flags [.], ack 2002866284, win 1065, options [nop,nop,TS val 616848 ecr 808583362], length 0
16:36:56.332492 IP6 2607:f8b0:4007:80d::2003.443 > 2607:fb90:586:d03231cc:56ea:c5dd.38038: Flags [.], ack 1, win 269, options [nop,nop,TS val 808628493 ecr 598813], length 0
16:36:56.455129 IP6 2607:fb90:586:d03231cc:56ea:c5dd.59593 > 2607:f8b0:4007:803::2003.443: Flags [.], ack 218946344, win 575, options [nop,nop,TS val 616864 ecr 3297488710], length 0
16:36:56.490794 IP6 2607:f8b0:4007:803::2003.443 > 2607:fb90:586:d03231cc:56ea:c5dd.59593: Flags [.], ack 1, win 265, options [nop,nop,TS val 3297533819 ecr 598830], length 0
^C
44 packets captured
44 packets received by filter
0 packets dropped by kernel

USB DEBUGGING OFF:

sudo 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
16:40:48.305279 ARP, Request who-has 192.168.42.129 tell 192.168.42.100, length 28
16:40:49.305117 ARP, Request who-has 192.168.42.129 tell 192.168.42.100, length 28
16:40:50.305115 ARP, Request who-has 192.168.42.129 tell 192.168.42.100, length 28
16:40:51.305341 ARP, Request who-has 192.168.42.129 tell 192.168.42.100, length 28
16:40:52.305122 ARP, Request who-has 192.168.42.129 tell 192.168.42.100, length 28
16:40:53.305120 ARP, Request who-has 192.168.42.129 tell 192.168.42.100, length 28
16:40:54.305301 ARP, Request who-has 192.168.42.129 tell 192.168.42.100, length 28
16:40:55.305122 ARP, Request who-has 192.168.42.129 tell 192.168.42.100, length 28
16:40:56.305128 ARP, Request who-has 192.168.42.129 tell 192.168.42.100, length 28
16:40:57.305274 ARP, Request who-has 192.168.42.129 tell 192.168.42.100, length 28
16:40:58.305130 ARP, Request who-has 192.168.42.129 tell 192.168.42.100, length 28
16:40:59.305122 ARP, Request who-has 192.168.42.129 tell 192.168.42.100, length 28
16:41:00.305345 ARP, Request who-has 192.168.42.129 tell 192.168.42.100, length 28
16:41:01.305141 ARP, Request who-has 192.168.42.129 tell 192.168.42.100, length 28
16:41:02.305138 ARP, Request who-has 192.168.42.129 tell 192.168.42.100, length 28
16:41:03.305303 ARP, Request who-has 192.168.42.129 tell 192.168.42.100, length 28
^C
16 packets captured
16 packets received by filter
0 packets dropped by kernel

[mad_ady]

Yes, as I suspected, your phone (.129) doesn't answer to arp requests when debug mode is off. I don't know why.
Try to tether your phone to some other device and see if it's the same behaviour. I'd say the issue is somewhere inside the phone...

[arthurkhatch]

It's definitely NOT a phone problem since:

1) We have 30 phones and they all work on a C2 with 16.04 LTS Kernel 3.14 (for the past 2 years without issue)
2) They all work on a C2 with 20.04 LTS Kernel 3.16
3) None work on a C2 with 16.04 LTS or 18.04 LTS Kernel 3.16

It can't be the phone. It must be Kernel 3.16 on 16.04 LTS or 18.04 LTS !

[odroid]

It is very hard to know why 20.04 works while 16.04/18.04 Kernel 3.16 don't.

BTW, is there any specific reason you don't want to use the latest 20.04 LTS?

[arthurkhatch]

We are using 20.04 on C4 and works all great.
We would love to use on 20.04 on the C2 but we cannot get chromium to work on a fresh image ! Do you know about this issue ? It's too bad and we need chromium for our kiosk application. Chromium is never able to start !

[odroid]

I heard Canonical recently broke their Chromium package.
But we don't know how to workaround the problem.

BTW, can you share a output when you run chromium on the command line?

[arthurkhatch]

But chromium works when installed on 20.04 LTS image for C4. Why is that ?

It's says on C2 from the cli:
cannot apply seccomp profile: inavlid argument.

[mad_ady]

Try disabling apparmor.

[arthurkhatch]

It did not help. same issue.

[odroid]

Should we have some 'snap' loopback device nodes for Chromium like N2/C4?

Code: Select all

root@odroid:~# df -H
Filesystem      Size  Used Avail Use% Mounted on
udev            967M     0  967M   0% /dev
tmpfs           196M  1.5M  195M   1% /run
/dev/mmcblk0p2  7.5G  6.6G  800M  90% /
tmpfs           978M     0  978M   0% /dev/shm
tmpfs           5.3M  4.1k  5.3M   1% /run/lock
tmpfs           978M     0  978M   0% /sys/fs/cgroup
/dev/loop0      127M  127M     0 100% /snap/chromium/1449
/dev/loop1       52M   52M     0 100% /snap/core18/1949
/dev/loop2       52M   52M     0 100% /snap/core18/1990
/dev/loop3      153M  153M     0 100% /snap/gnome-3-28-1804/147
/dev/loop4       69M   69M     0 100% /snap/gtk-common-themes/1514
/dev/loop5       29M   29M     0 100% /snap/snapd/10709
/dev/loop6       66M   66M     0 100% /snap/gtk-common-themes/1506
/dev/loop7       29M   29M     0 100% /snap/snapd/11043
/dev/mmcblk0p1  134M   28M  107M  21% /media/boot
tmpfs           196M  8.2k  196M   1% /run/user/118
tmpfs           196M     0  196M   0% /run/user/0  

[arthurkhatch]

All these loopbacks exist when I run df on the C2 with 20.04 LTS image from hardkernel.

Chromium does not start and the error is (when run from cli):
"cannot apply seccomp profile: Invalid argument"