RNDIS USB tethering stuck on 169.x IP

Message

62626368616e · Post by **62626368616e** » Wed Oct 21, 2020 4:08 pm

Hi,
I'm trying to set up USB tethering between my Rockpro64 dev board (gentoo, systemd) and my Gentoo PC (openrc) I have successfully been able to connect the board to my laptop, enumerating it as an RNDIS device. It seems like connectivity is working locally, between my laptop and the device, as I am still able to maintain SSH and start sftp.
I have tried running dhcpcd and I also have an appropriate entry in /etc/conf.d/net for the device.

Here's what my dmesg looks like on the PC:

Code: Select all

[23744.826354] usb 1-1: new high-speed USB device number 8 using xhci_hcd
[23744.959321] usb 1-1: New USB device found, idVendor=1058, idProduct=0827, bcdDevice= 5.09
[23744.959327] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[23744.959331] usb 1-1: Product: RNDIS
[23744.959334] usb 1-1: Manufacturer: Pine
[23744.971023] rndis_host 1-1:1.0 usb0: register 'rndis_host' at usb-0000:00:14.0-1, RNDIS device, e6:c3:74:d1:fd:cf
[23745.551540] rndis_host 1-1:1.0 enp0s20f0u1: renamed from usb0

And on the board, when I created the appropriate entry in configfs:

Code: Select all

[ 5340.742874] udc fe800000.usb: registering UDC driver [rockpro64]
[ 5340.742985] configfs-gadget gadget: adding 'rndis'/00000000916f8169 to config 'c'/00000000e6aefc62
[ 5340.745285] usb0: HOST MAC 82:be:ff:d5:83:2b
[ 5340.746602] usb0: MAC 7e:ed:70:c5:27:e5
[ 5340.747307] rndis_set_param_medium: 0 0
[ 5340.747320] configfs-gadget gadget: RNDIS: super speed IN/ep1in OUT/ep1out NOTIFY/ep2in
[ 5340.960218] usb0: eth_open
[ 5341.198787] configfs-gadget gadget: resume
[ 5341.200826] configfs-gadget gadget: resume
[ 5341.203941] configfs-gadget gadget: resume
[ 5341.204354] configfs-gadget gadget: high-speed config #1: c
[ 5341.204385] configfs-gadget gadget: reset rndis control 0
[ 5341.204397] configfs-gadget gadget: init rndis ctrl 0
[ 5341.204429] configfs-gadget gadget: init rndis
[ 5341.204441] configfs-gadget gadget: RNDIS RX/TX early activation ... 
[ 5341.204845] usb0: qlen 10
[ 5341.204859] configfs-gadget gadget: rndis_open
[ 5341.204872] rndis_set_param_medium: 0 4259840
[ 5341.204897] usb0: eth_start
[ 5341.205175] rndis_set_param_dev:
[ 5341.205498] IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready
[ 5341.207636] configfs-gadget gadget: non-core control req21.00 v0000 i0000 l24
[ 5341.207671] configfs-gadget gadget: rndis req21.00 v0000 i0000 l24
[ 5341.207887] rndis_msg_parser: RNDIS_MSG_INIT
[ 5341.208210] configfs-gadget gadget: non-core control reqa1.01 v0000 i0000 l1025
[ 5341.208266] configfs-gadget gadget: rndis reqa1.01 v0000 i0000 l1025
[ 5341.208681] configfs-gadget gadget: non-core control req21.00 v0000 i0000 l28
[ 5341.208718] configfs-gadget gadget: rndis req21.00 v0000 i0000 l28
[ 5341.208912] gen_ndis_query_resp: RNDIS_OID_GEN_PHYSICAL_MEDIUM
[ 5341.209138] configfs-gadget gadget: non-core control reqa1.01 v0000 i0000 l1025
[ 5341.209193] configfs-gadget gadget: rndis reqa1.01 v0000 i0000 l1025
[ 5341.209471] configfs-gadget gadget: non-core control req21.00 v0000 i0000 l12
[ 5341.209495] configfs-gadget gadget: rndis req21.00 v0000 i0000 l12
[ 5341.209629] rndis_msg_parser: RNDIS_MSG_HALT
[ 5341.210084] configfs-gadget gadget: non-core control req21.00 v0000 i0000 l24
[ 5341.210116] configfs-gadget gadget: rndis req21.00 v0000 i0000 l24
[ 5341.210227] rndis_msg_parser: RNDIS_MSG_INIT
[ 5341.210455] configfs-gadget gadget: non-core control reqa1.01 v0000 i0000 l1025
[ 5341.210494] configfs-gadget gadget: rndis reqa1.01 v0000 i0000 l1025
[ 5341.210789] configfs-gadget gadget: non-core control req21.00 v0000 i0000 l28
[ 5341.210815] configfs-gadget gadget: rndis req21.00 v0000 i0000 l28
[ 5341.210935] gen_ndis_query_resp: RNDIS_OID_GEN_PHYSICAL_MEDIUM
[ 5341.211112] configfs-gadget gadget: non-core control reqa1.01 v0000 i0000 l1025
[ 5341.211151] configfs-gadget gadget: rndis reqa1.01 v0000 i0000 l1025
[ 5341.211346] configfs-gadget gadget: non-core control req21.00 v0000 i0000 l76
[ 5341.211364] configfs-gadget gadget: rndis req21.00 v0000 i0000 l76
[ 5341.211476] gen_ndis_query_resp: RNDIS_OID_802_3_PERMANENT_ADDRESS
[ 5341.211651] configfs-gadget gadget: non-core control reqa1.01 v0000 i0000 l1025
[ 5341.211707] configfs-gadget gadget: rndis reqa1.01 v0000 i0000 l1025
[ 5341.211956] configfs-gadget gadget: non-core control req21.00 v0000 i0000 l32
[ 5341.211974] configfs-gadget gadget: rndis req21.00 v0000 i0000 l32
[ 5341.212103] gen_ndis_set_resp: RNDIS_OID_GEN_CURRENT_PACKET_FILTER 0000002d
[ 5341.212273] configfs-gadget gadget: non-core control reqa1.01 v0000 i0000 l1025
[ 5341.212321] configfs-gadget gadget: rndis reqa1.01 v0000 i0000 l1025

It seems like everything is OK, but I am getting a 169.x IP and unable to connect on my PC:

Code: Select all

enp0s20f0u1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 169.254.54.41  netmask 255.255.0.0  broadcast 169.254.255.255
        inet6 fe80::af63:56b1:15ef:ad47  prefixlen 64  scopeid 0x20<link>
        ether e6:c3:74:d1:fd:cf  txqueuelen 1000  (Ethernet)
        RX packets 94  bytes 23808 (23.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 300  bytes 72433 (70.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

------------

sleepy@seraph ~ $ ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
From 169.254.54.41 icmp_seq=1 Destination Host Unreachable
From 169.254.54.41 icmp_seq=2 Destination Host Unreachable
From 169.254.54.41 icmp_seq=3 Destination Host Unreachable
^C
--- 1.1.1.1 ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4090ms
pipe 4
sleepy@seraph ~ $ ping google.com
ping: google.com: Temporary failure in name resolution

In case it would be helpful, here are my kernel configs-
Board: https://dpaste.com/DJRQCDQ7B
PC: https://dpaste.com/BWP2KLC59

Is there something extra that I need to do to get this working-- like dnsmasq or something of the sort?

Post by **NeddySeagoon** » Wed Oct 21, 2020 4:59 pm

62626368616e,

How are you setting up the Ethernet over USB link at both ends?

There are two ways, PPP, in which case your Rockpro64 uses the PC as a gateway to the wider network.
That OK for a single device

The second way is to make your PC a router for connected devices. That's a lot of work for one device. There is a wiki guide.
Going with PPP, you need a script like this on your PC and ppp support in your kernel both ends ...

Code: Select all

#!/bin/bash
#
# ipaqnet       Control script for iPAQ USBNet connection
#
# Author: Michel Stempin
# Creation: 11/08/2002

# additional comments and minor tweaks
# Roy Bamford 6 Dec 2003

PC_ADDR=192.168.100.201
IPAQ_ADDR=192.168.100.202
IPAQ_NET=192.168.100.0/24

# WARNING:usb0 is hard coded in some places
UPLINK_IF=usb0

start() {
    # load the usb networking module
    /sbin/modprobe usbnet
    
    # bring up the PC end of the link with IP addr PC_ADDR
    # exit if it fails for some reason
    /sbin/ifconfig usb0 inet $PC_ADDR up
    if [ $? -ne 0 ]; then
        echo "Could not set up usb0"
        echo "Is the iPaq connected and switched on?"
        exit 1
    fi
 
    # set up proxy_arp for our usb interface 
    echo "1" >/proc/sys/net/ipv4/conf/usb0/proxy_arp
    UPLINK=`/sbin/ifconfig $UPLINK_IF >/dev/null 2>&1`
    # exit if it fails for some reason
    if [ $? -ne 0 ]; then
        echo "Could not set up proxy_arp for usb0"
        exit 1
    fi
 
    # set up proxy_arp for eth0, so this better be our
    # internet connection
    echo "1" >/proc/sys/net/ipv4/conf/eth0/proxy_arp

    # turn on IP forwarding
    echo "1" >/proc/sys/net/ipv4/ip_forward

    # delete the unwanted route via usb0
    # its wrong anyway
    /sbin/route del -net $IPAQ_NET dev usb0

    # add the route we really want
    /sbin/route add $IPAQ_ADDR dev usb0
}

stop() {
    /sbin/ifconfig usb0 down
    # rmmod -r usbnet
}
case "$1" in
    start|add)
        start
        ;;
    stop|remove)
        stop
        ;;
    *)
        echo $"Usage: $0 {start|stop|add|remove}"
        exit 1
esac

You will need to fiddle with the IP addresses and interface names.
Do make sure the IP addresses you choose are not used. They must be in the same subnet as your PC to Router link.
Horrible things happen if you allocate the same IP to two devices at the same time.

62626368616e · Post by **62626368616e** » Wed Oct 21, 2020 5:31 pm

NeddySeagoon wrote:62626368616e,

How are you setting up the Ethernet over USB link at both ends?

The link is from my PC to the Rockpro64, via the USB-C port on the board.
I should note as well that I need to use RNDIS specifically (as opposed to better alternatives like CDC NCM) as I'm trying to test out some patches that deal with RNDIS code.

NeddySeagoon wrote: There are two ways, PPP, in which case your Rockpro64 uses the PC as a gateway to the wider network.
That OK for a single device

The second way is to make your PC a router for connected devices. That's a lot of work for one device. There is a wiki guide.
Going with PPP, you need a script like this on your PC and ppp support in your kernel both ends ...

I am trying to bridge the board's connection to the laptop, so would I do the opposite in this case-- use the board as a gateway to the wider network?
Also, I am not sure if this is something you can tell me, but I was wondering this (just out of complete curiosity as I'm trying to learn)-- in the case of Android USB tethering, which also uses RNDIS, it normally "just works" without really needing to do any messing around. I guess there are some extra patches or userspace daemons that take care of any associated networking tweaking needed to get things working?

Thanks for the info!

Post by **NeddySeagoon** » Wed Oct 21, 2020 6:39 pm

62626368616e,

Explain the wider problem you are trying to solve. I'm concerned we have an [XY Problem in the making here.
That link is unkind but its a good explanation.

You cannot bridge a ppp link because ppp0 will not exist until its started, then both ends get an IP address.
Once you have configured the interface, you may not donate it to a bridge.

On Android, the Android device runs as a router.

So to baby steps. Make the link work from your PC to Rockpro64 and nowhere else.
The rest of the world can come along later.

Manage both ends of the link by hand. Say allocate 10.0.0.1/24 to one end and 10.0.0.2/24 to the other end.
That should get you 10.0.0.0/24 in the routing table both ends for free.
You should be able to run ssh, ping and so on over the link.

I'm not sure that donating the Rockpro64 interfaces to a bridge is part of the solution to your problem.
If it is, creating the bridge is the step after all the interfaces work on their own.

In this context 'work' means ping the next hop out of each interface separately.

62626368616e · Post by **62626368616e** » Wed Oct 21, 2020 6:45 pm

NeddySeagoon wrote:62626368616e,

Explain the wider problem you are trying to solve. I'm concerned we have an [XY Problem in the making here.
That link is unkind but its a good explanation.

You cannot bridge a ppp link because ppp0 will not exist until its started, then both ends get an IP address.
Once you have configured the interface, you may not donate it to a bridge.

On Android, the Android device runs as a router.

So to baby steps. Make the link work from your PC to Rockpro64 and nowhere else.
The rest of the world can come along later.

Manage both ends of the link by hand. Say allocate 10.0.0.1/24 to one end and 10.0.0.2/24 to the other end.
That should get you 10.0.0.0/24 in the routing table both ends for free.
You should be able to run ssh, ping and so on over the link.

I'm not sure that donating the Rockpro64 interfaces to a bridge is part of the solution to your problem.
If it is, creating the bridge is the step after all the interfaces work on their own.

In this context 'work' means ping the next hop out of each interface separately.

Ah, I'm sorry! It made sense in my head, but "bridge" might not have been the correct term. I just want to connect the board to my laptop via USB-C and tether the connection from the board to the laptop.
I think that I will try to get the board set up as a router, I think this could be useful for me in the future.

Edit: Do you have the link to the wiki for router setup by any chance? I see a "home router" page but I just want to make sure it's the correct entry before I get into it.

Post by **NeddySeagoon** » Wed Oct 21, 2020 7:14 pm

62626368616e,

That's it.

A network 'bridge' is where you donate interfaces to a software construct called a bridge.
The bridge then behaves as a single interface which gets configured as any other interface.
Any packets sent on received by the bridge are available an all the interfaces.

Its like the software version of a network hub.

62626368616e · Post by **62626368616e** » Thu Oct 22, 2020 3:39 am

NeddySeagoon wrote:62626368616e,

That's it.

A network 'bridge' is where you donate interfaces to a software construct called a bridge.
The bridge then behaves as a single interface which gets configured as any other interface.
Any packets sent on received by the bridge are available an all the interfaces.

Its like the software version of a network hub.

I will take care to use the correct terminology next time

Thanks a lot for your help and all the helpful info

Post by **NeddySeagoon** » Thu Oct 22, 2020 9:36 am

62626368616e,

No problem with the terminology. I suspected we may have a communications issue, which is why I asked aboud the wider problem.

Your 169 ... IP address may well work for a link to your PC. Its not routable, so its confined to the network segment that it appears on.
To test, on your PC, try ifconfig <ifname> <link-local-ip>
Where <link-local-ip> is choosen from 169.254.0.0/16 but not the same as the IP at the other end.
This manually allocates an IPv4 address to your usb interface.

If you have IPv6 each end, then you will have auto allocated IPv6 link local addresses too. They will be in the range fe80::/10
They will work too. ping -6 fe80.... its a lot more typing.