Android tethering won't work on my TX1

I’ve trying to get TX1 access to internet via Android smartphone USB tethering. But the TX1 seems not recognizing my android as networking device even I connect the phone and TX1 with USB and configure “USB tethering” on the android. I’m using nVidia’s development kid carrier board and L4T 2.3.1 firmware.

This is the response when I just connect USB (but the android is still not switched to USB tethering mode). The android is successfully recognized as mass storage, and its content is accessible from TX1.

$ dmesg
[  150.374770] usb 1-3.2: new high-speed USB device number 7 using tegra-xhci
[  150.409020] usb 1-3.2: New USB device found, idVendor=04dd, idProduct=994e
[  150.409043] usb 1-3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  150.409056] usb 1-3.2: Product: SH01H
[  150.409068] usb 1-3.2: Manufacturer: SHARP Corporation
[  150.409078] usb 1-3.2: SerialNumber: 353363060646200

$ lsusb
Bus 001 Device 007: ID 04dd:994e Sharp Corp.

$ ifconfig
enx00044b65e43b Link encap:Ethernet  HWaddr 00:04:4b:65:e4:3b  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

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:65536  Metric:1
          RX packets:366 errors:0 dropped:0 overruns:0 frame:0
          TX packets:366 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:27858 (27.8 KB)  TX bytes:27858 (27.8 KB)

wlan0     Link encap:Ethernet  HWaddr 00:04:4b:65:e4:39  
          inet addr:192.168.11.32  Bcast:192.168.11.255  Mask:255.255.255.0
          inet6 addr: fe80::204:4bff:fe65:e439/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:343 errors:0 dropped:0 overruns:0 frame:0
          TX packets:464 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:27817 (27.8 KB)  TX bytes:175384 (175.3 KB)

And this is the response when I switch the android to USB tethering mode. TX1 still recognize the android but not as a networking device.

$dmesg
[  514.668582] usb 1-3.2: USB disconnect, device number 7
[  515.054385] usb 1-3.2: new high-speed USB device number 8 using tegra-xhci
[  515.077068] usb 1-3.2: New USB device found, idVendor=04dd, idProduct=9951
[  515.077077] usb 1-3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  515.077083] usb 1-3.2: Product: SH01H
[  515.077088] usb 1-3.2: Manufacturer: SHARP Corporation
[  515.077093] usb 1-3.2: SerialNumber: 353363060646200

$ lsusb
Bus 001 Device 008: ID 04dd:9951 Sharp Corp. 

$ ifconfig
enx00044b65e43b Link encap:Ethernet  HWaddr 00:04:4b:65:e4:3b  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

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:65536  Metric:1
          RX packets:366 errors:0 dropped:0 overruns:0 frame:0
          TX packets:366 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:27858 (27.8 KB)  TX bytes:27858 (27.8 KB)

wlan0     Link encap:Ethernet  HWaddr 00:04:4b:65:e4:39  
          inet addr:192.168.11.32  Bcast:192.168.11.255  Mask:255.255.255.0
          inet6 addr: fe80::204:4bff:fe65:e439/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:621 errors:0 dropped:0 overruns:0 frame:0
          TX packets:740 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:44527 (44.5 KB)  TX bytes:332512 (332.5 KB)

I’ve tried the same thing using my pc running genuine Ubuntu 14.04 and 16.04, then both easily recognize the android as networking device and automatically connected to the internet. So it seems that I have to do something with TX1 to get this work. Has anyone tried or experienced same things?

I’ve never used Android tethering, I’m not familiar with it. However, the USB information tends to say that you need a driver on the JTX1 specific to the Android device. It seems that the device is not a general class, but instead requires a custom driver. While connected in tether mode, and from the JTX1, you could verify this via:

lsusb -vvv -d '04dd:9951'

Thanks, linuxdev.

Below were the response to " lsusb -vvv -d ‘04dd:9951’ ".

If it’s a problem of missing drivers, since the original Ubuntu could recognize the phone as tethering device, isn’t there a way to migrate relative drivers from the original Ubuntu to L4T Ubuntu? (I may have to rebuild from source because the original Ubuntu is amd64 compiled but the L4T one is arm64 compiled.)

ubuntu@tegra-ubuntu:~$ lsusb -vvv -d '04dd:9951'

Bus 001 Device 014: ID 04dd:9951 Sharp Corp. 
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x04dd Sharp Corp.
  idProduct          0x9951 
  bcdDevice            3.10
  iManufacturer           1 
  iProduct                2 
  iSerial                 3 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           98
    bNumInterfaces          3
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Association:
      bLength                 8
      bDescriptorType        11
      bFirstInterface         0
      bInterfaceCount         2
      bFunctionClass        224 Wireless
      bFunctionSubClass       1 Radio Frequency
      bFunctionProtocol       3 RNDIS
      iFunction               7 
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass       224 Wireless
      bInterfaceSubClass      1 Radio Frequency
      bInterfaceProtocol      3 RNDIS
      iInterface              5 
      ** UNRECOGNIZED:  05 24 00 10 01
      ** UNRECOGNIZED:  05 24 01 00 01
      ** UNRECOGNIZED:  04 24 02 00
      ** UNRECOGNIZED:  05 24 06 00 01
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 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              6 
      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
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass     66 
      bInterfaceProtocol      1 
      iInterface              8 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        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     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0

It looks like at least parts of the system are indeed a non-standard class requiring a device-specific driver. If there is a driver on another architecture (meaning desktop x86_64 or other ARM types) it could possibly be ported, but you’d need the source code. The question is whether your regular Ubuntu desktop system uses a driver which is open source or not.

You could dig into your working system’s installed packages and find out what drivers are used (this device has more than one function, so more than one driver might apply); then see if they are all available as open source.

I’ve looked into the kernel compile settings and noticed that some of related modules may be not compiled as for the original L4T kernel. (e.g. “Host for RNDIS and ActiveSync devices”)

For kernel compilation, I’m now referring to “2. compile on the HOST linux pc.” on https://devtalk.nvidia.com/default/topic/929186/jetson-tx1-kernel-compilation/. Is this still the most recommended way for TX1 and kernel R24.2.1?

Cross compile is still the way to go since it requires two compilers (ARMV8-a 64-bit and ARMv8 32-bit). Here’s another note on cross compile setup:
https://devtalk.nvidia.com/default/topic/936880/jetson-tx1/jetson-tx1-24-1-release-need-help-with-complier-directions-can-not-complie/post/4885136/#4885136

There was a note about a missing quote on a string…I think that is fixed in R24.2.1.

Hi sf624,

Can you please confirm that whether USB tethering work for your TX1 system, as I have same kind of requirment. If its worked for you please share the driver details and steps you followed to enable USB tethering between Android device and TX1.

Also how you setup you ubuntu 14.04/16 to make this work, as I am not able to get USB tethering in my ubuntu system also though enabled the Host for RNDIS option in kernel .config and recompiled the kernel.

Thanks in advance.

I have a problem with RNDIS driver installation while recompiling my linux kernel 3.10.96.
It will be of great help if someone could suggest me the steps to follow while recompiling the kernel for the installation of RNDIS driver in Nvidia jetson Tx1. Thank you in advance :)

Instructions differ depending on which L4T version. R28.1 is recommended, but since you are using 3.10.96 kernel, I will assume this is R24.2.1 instead.

The partial answer (I’ll wait to answer further after I know which L4T version and a description of where or how things fail for you) is that most failures start with the kernel not using an exact match for the running system kernel’s config. You cannot edit an option and get a working kernel…unless you already configured first for a working config.

You get a copy of the running system’s config via copy of file “/proc/config.gz” somewhere, and then “gunzip config.gz”. This can be saved as a reference, and then copied to name “.config”. When you go into a config editor (such as “make menuconfig” or “make nconfig”), if this file is in place before starting, then edits should succeed.

Also, since I do not use RNDIS, which kernel feature are you changing to use this? I see this on the default R24.2.1 config:

# CONFIG_USB_NET_RNDIS_HOST is not set
# CONFIG_USB_NET_RNDIS_WLAN is not set
CONFIG_USB_ETH_RNDIS=y

If a kernel build works, but things still fail, it probably means modules were not loaded because CONFIG_LOCALVERSION does not match your system. If your “uname -r” gives “3.10.96-tegra”, then CONFIG_LOCALVERSION needs to be “-tegra”.

The kernel searches for modules in “/lib/modules/$(uname -r)/”. If the existing kernel gets modules of the wrong version, this may cause the module to be rejected. If the kernel itself is replaced with this being incorrect, then no modules will be found and there will be a 100% module failure even if the module is otherwise valid. If you add a module instead of an integrated kernel feature, then only a module needs to be added and the kernel image itself can be left alone.

I also have a problem trying to connect NVIDIA Jetson Nano with Android USB Theathering, at first I was able to access the internet and suddenly my computer died. I do not understand what actually happened, do you have a solution to my problem? Thank you

This particular forum is for the TX1, and may or may not apply to the Nano. The Nano requires an add-on WiFi, whereas we know what the hardware is on the TX1 due to this being integrated hardware. Both do share a lot of the software in common since they are both Ubuntu. In the case of non-integrated hardware this is probably more of an Ubuntu question, with an exception…

Now if this is a USB WiFi dongle, then something like USB power savings modes could kick in and cause problems and thus this could end up being a question of Nano-specific power savings modes. I’ll recommend to post this to the Nano forum:
https://devtalk.nvidia.com/default/board/371/jetson-nano/
…and then give specific hardware listings, e.g., USB versus some sort of PCIe, so on, and to give the release running on the Nano. Any software you added for working with that WiFi would also be useful to know about.

In that new thread for the Nano forum, also provide the following information when the Nano works with WiFi and when the Nano fails with WiFi (you may need to “sudo apt-get install wireless-tools”):

iwconfig
ifconfig
route