External Ethernet Adapter

Hi,
can someone recommend an external Ethernet Adapter with 2.5.GigE ? If have tried some from different manufacturers, but no success.

PCIe or USB3

Regards

No suggestion for now, may other developers help to share experiences.

I also have no recommendation in particular, but if it is shown as working with desktop Linux, then it should work in the Jetson if the driver is added. Binary third party drivers would need an arm64/aarch64 version compiled for this kernel, so it probably wouldn’t work, but anything with a driver supported by the standard Linux kernel should work after building the driver (probably as a module which is just a file copy to install). Of the devices you have tried, did they have the driver installed? Or was no driver available?

Yes i think there is a driver available:
https://realtek-download.com/realtek-usb-fe-gbe-2-5g-rtl8156-rtl8153-rtl8152b-gaming-ethernet-family-controller/

Realtek is perhaps one of the best supported network devices in both Windows and Linux. It is quite common, and most of these are available in the Linux kernel if configured to be built. On that URL, note that it describes compatibility via the “chipset”, and not via a particular model. The chipsets listed are:

RTL8156, RTL8153, RTL8152B

I don’t even have to look those up to know the kernel has these as an option, and at least part of those would be there by default and not even need extra config. On the Jetson, what do you see from this?

zcat /proc/config.gz | grep -i 'rtl815'

Each CONFIG_ which is “=y” is present and directly integrated into the kernel. Each CONFIG_ which is “=m” is present in the form of a dynamically loadable module. Others are not present, but could be (typically you’d configure the kernel as an exact match of the existing kernel, then alter it by selecting the needed driver in the form of a module, compile this, and copy the file to the correct place on the Jetson). Not all drivers or features can be a module, but I know that all of the Realtek drivers are available as a module (in fact most drivers are unless they are invasive); installing an integrated feature is more involved.

So I need the RTL8156 but its not in the list:

zcat /proc/config.gz | grep -i ‘rtl815’
CONFIG_USB_RTL8150=m
CONFIG_USB_RTL8152=y
#CONFIG_USB_RTL8152_SHIELD is not set

Some driver “families” work with more than one chipset if they are similar enough. What is the exact model of device? I noticed that the Linux driver was a source code format for the r8152, so there is a strong chance the “CONFIG_USB_RTL8152=y” is all that is needed. In addition to this there is also a udev rule, and all this does would be limited “metadata” changes, and for example perhaps this is responsible for telling the USB subsystem that this device of a “similar” chipset just uses the standard 8152 driver (which would be pretty easy to adjust for if the udev rule is all that is needed).

The udev file in that downloaded is “50-usb-realtek-net.rules”. It would simply be copied to “/etc/udev/rules.d/” and reboot.

This is the device: ALLNET ALL174XGA: Netzwerkkarte, USB 3.0, 2.5 Gigabit Ethernet, 1x RJ45 bei reichelt elektronik

Although the RTL8156x seems different, it also looks like the RTL8152 should work (going by what the download has).

There are some optional content notes with that download, but it looks like those only apply if you need the device during boot (for example, network booting), but not if you only want to use the device once booted. The exception is the previously mentioned file “50-usb-realtek-net.rules”. In the downloadable Linux driver from the URL in your previous post unpack this in an empty directory, and copy file “50-usb-realtek-net.rules” to “/etc/udev/rules.d”, and reboot.

Once you’ve added the udev rule file, and if you monitor “dmesg --follow”, what do you see when you plug in the USB?

It seem to be recognised by the kernel:

[  165.359303] usb 2-1.3: new SuperSpeed USB device number 3 using tegra-xusb
[  165.383842] usb 2-1.3: New USB device found, idVendor=0bda, idProduct=8156
[  165.383913] usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[  165.383966] usb 2-1.3: Product: USB 10/100/1G/2.5G LAN
[  165.384007] usb 2-1.3: Manufacturer: Realtek
[  165.384049] usb 2-1.3: SerialNumber: 001000001
[  165.416244] cdc_ncm 2-1.3:2.0: MAC-Address: 00:0f:c9:1b:f3:4d
[  165.416311] cdc_ncm 2-1.3:2.0: setting rx_max = 16384
[  165.416721] cdc_ncm 2-1.3:2.0: setting tx_max = 16384
[  165.421241] cdc_ncm 2-1.3:2.0 usb1: register 'cdc_ncm' at usb-70090000.xusb-1.3, CDC NCM, 00:0f:c9:1b:f3:4d
[  165.496537] IPv6: ADDRCONF(NETDEV_UP): usb1: link is not ready
[  165.496776] IPv6: ADDRCONF(NETDEV_UP): usb1: link is not ready

but it is not usable in the system

From the point of view of the kernel driver this seems to be doing what it should be. IPv6 is complaining, and it might be other IPv6 issues causing the device to fail, but is it possible WiFi is being configured and the system is purposely not bringing up the wired ethernet on this device? What do you see from the full output of “ifconfig” and also “iwconfig”, plus also “route” now that this device is connected with the udev rule?

So the “50-usb-realtek-net.rules ” is copied to “/etc/udev/rules.d ”.
Outputs:

ifconfig

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000
        inet 192.168.20.1  netmask 255.255.255.0  broadcast 192.168.20.255
        inet6 fe80::6acb:5151:a7b8:8708  prefixlen 64  scopeid 0x20<link>
        ether 48:b0:2d:3d:51:be  txqueuelen 1000  (Ethernet)
        RX packets 172  bytes 16251 (16.2 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 207  bytes 30842 (30.8 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 151  base 0x5000  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 503  bytes 35336 (35.3 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 503  bytes 35336 (35.3 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

rndis0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 66:3f:b7:17:ac:f9  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

usb0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 66:3f:b7:17:ac:fb  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

iwconfig

rndis0    no wireless extensions.

eth0      no wireless extensions.

l4tbr0    no wireless extensions.

lo        no wireless extensions.

dummy0    no wireless extensions.

usb0      no wireless extensions.

route

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    20100  0        0 eth0
link-local      0.0.0.0         255.255.0.0     U     1000   0        0 eth0
192.168.20.0    0.0.0.0         255.255.255.0   U     100    0        0 eth0
_gateway        0.0.0.0         255.255.255.255 UH    20100  0        0 eth0

The integrated wired ethernet is working according to that, but USB0 never even attempted a DHCP request. I see zero bytes in or out, and no address assigned. Can you use “sudo nm-connection-editor” and see if that device shows up? You might need to click the “+” icon in the lower left to “add” an interface, and then see if the USB one is available to be added.

The device ist shown in "nm-conncetion-editor" but if i set somthing e.g. the ip adress nothing happens in ifconfig. there are n o changes visible.

Can you try to set it to use only automatic DHCP under IPv4 and disable IPv6 using nm-connection-editor? Then reboot. After a short time look at “ifconfig” again and see if the USB adapter shows at least some TX bytes and RX bytes.

I have tried but nothing happens. The ethernet USB-adapter is still not working:

usb0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 66:3f:b7:17:ac:fb  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I have made the same tests on a Jetson Xavier NX same results :-(

There could be a software issue, but the ability to see the device in lsusb, combined with the ability of ifconfig to query the device, tends to verify the driver is loaded. There might also be firmware, but I doubt it would have got this far if the firmware is missing (not all have separate firmware, but the ones which do tend to change the API the driver expects, and a wrong API tends to cause driver load to fail).

With no packets showing up I begin to wonder if it is the cable and/or switch it plugs into. I’d like to see how it differs with different cables or different ports. I’m starting to think it might be a wiring issue. Maybe even damage to connector or socket if not the cable itself. Try different cables, examine the socket and plug, and look for TX and RX bytes both showing up after a reboot.

@linuxdev
we tried different cables, usb-ports and switches the problem is still the same. Maybe we have to buy another external usb or pcie ethernet card

Because the device shows up without error in both lsusb and ifconfig that the device and drivers are loaded and working correctly, and that there must be some other configuration or software issue other than driver and other than hardware.

I see no bytes at all on TX or RX, and this says that the device never even attempted to send out a DHCP request. I still suspect IPv6 protocol as part of the problem since I’ve had so much issue with IPv6 in the past and IPv6 requires additional drivers and support beyond IPv4.

Try each of these, and check if there are any TX bytes or RX bytes after the command (stop with the IPv4 version if bytes show up, don’t go to the IPv6 version unless IPv4 fails):

# IPv4:
sudo dhclient -4 usb0
ifconfig
# IPv6:
sudo dhclient -6 usb0
ifconfig

It seems likely the problem is related to that adapter (software), and probably is unrelated to being a Jetson, but it is frustrating that I also think the adapter is basically ready to operate if I could figure out why it isn’t accepting settings and isn’t even attempting DHCP. It is like some other software related to activating and using a working adapter just isn’t there.

@linuxdev i have tried

 IPv4:
sudo dhclient -4 usb0
ifconfig
# IPv6:
sudo dhclient -6 usb0
ifconfig

but no success.
We still have zero TX / RX bytes