JetPack 4.3 on Jetson Nano Prod Module: l4tbr0 not work

Autonomous Machines Jetson & Embedded Systems Jetson Nano
1

Hello,

Does anybody has experience on l4tbr0 problem would shed a light what might be the root cause or how to resolve it ?

After flashing Jetpack 4.3 on Jetson Nano Prod Module and let it boot up, sometimes l4tbr0 is missing, sometimes l4tbr0 shows up but it has only Tx packets without any Rx packets. Host machine sometimes can see Nvidia from lsusb, sometimes not but in anyway host machine cannot ping Jetson Nano.

This happened on multiple boards at different areas. One board does not work in my office, it works fine in other office.

When l4tbr0 shows up but not fully work, the nv-l4t-usb-device-mode.service is loaded successfully and active (exited), status=0/SUCCESS. Restart this service does not resolve the issue.

On host machine, lsusb can find Nvidia device.

on host machine:

$ ping -c 2 192.168.55.1
PING 192.168.55.1 (192.168.55.1) 56(84) bytes of data.

— 192.168.55.1 ping statistics —
2 packets transmitted, 0 received, 100% packet loss, time 1000ms

on Jetson Nano

guest@localhost:~$ ifconfig l4tbr0
l4tbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.55.1 netmask 255.255.255.0 broadcast 192.168.55.255
inet6 fe80::1 prefixlen 128 scopeid 0x20
inet6 fe80::428:5eff:fe03:65e5 prefixlen 64 scopeid 0x20
ether 06:28:5e:03:65:e5 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 291 bytes 14200 (14.2 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

guest@localhost:~$ sudo ethtool -i l4tbr0
driver: bridge
version: 2.3
firmware-version: N/A
expansion-rom-version:
bus-info: N/A
supports-statistics: no
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

guest@localhost:~$ sudo systemctl restart nv-l4t-usb-device-mode.service
[ 587.932216] using random self ethernet address
[ 587.932218] using random host ethernet address
[ 588.232692] using random self ethernet address
[ 588.237192] using random host ethernet address

guest@localhost:~$ sudo systemctl status nv-l4t-usb-device-mode.service
nv-l4t-usb-device-mode.service - Configure USB flashing port for device mode
Loaded: loaded (/opt/nvidia/l4t-usb-device-mode/nv-l4t-usb-device-mode.servic
Active: active (exited) since Mon 2018-01-29 00:09:14 CST; 7s ago
Process: 1811 ExecStopPost=/opt/nvidia/l4t-usb-device-mode/nv-l4t-usb-device-m
Process: 2334 ExecStart=/opt/nvidia/l4t-usb-device-mode/nv-l4t-usb-device-mode
Main PID: 2334 (code=exited, status=0/SUCCESS)

Jan 29 00:09:13 localhost.localdomain systemd[1]: Starting Configure USB flashin
Jan 29 00:09:14 localhost.localdomain nv-l4t-usb-device-mode-start.sh[2334]: /
Jan 29 00:09:14 localhost.localdomain systemd[1]: Started Configure USB flashing

Regards

  • Steven
2

The bridge is using the network “gadget” software, which in turn goes over the micro-B USB. Are you using the micro-B USB cable which comes with the dev kit (I’m not actually sure what comes with the B01 revision)? If not, then the vast majority of micro-B USB cables are just “charger” cables with very low signal quality and the majority will fail at some point when working with data.

3

Thanks for the reply, you have a good point. Is there any suggested brand/model of cable that has best signal quality ?

5

I only use the cables provided by NVIDIA in dev kits. I couldn’t tell you of a particular brand which is good. When someone does find the cable is the issue they will often report buying three to four brands before they get one which works. Anyone know of a known good micro-B USB cable?

6

Besides the cable, is there any known SW reason for l4tbr0 not work ? What are most popular solutions if any ?
Thanks a lot here for any help.

7

l4tbr0 tends to work correctly. What tends to fail is NetworkManager setup, and this indirectly sets l4tbr0 in many cases. In terms of when this is used with the USB network device “gadget”, then this tends to be an issue of the USB cable or the other end trying to use the bridge incorrectly. Just to emphasize, an overwhelming percentage of cheap charger cables fail when running at USB2 speeds, and this is the speed of that port with the gadget network device.

When NetworkManager fails it tends to be due to confusion about what connection should remain up, which connection takes priority, and what to do when something changes temporarily.

Look closely at this:

…that bridge is operating normally, and without error. If the USB side fails, then essentially it will just not be connected, much like what you see here. If the actual ethernet on the bridge has something wrong, then you would probably see errors/dropped/overruns/carrier/collisions.

The loss from the host PC is because you have no route, and not because of network errors. Does your host PC’s “ifconfig” show it has seen the device? Does the host side get assigned address 192.168.55.100? If not, then it is the host PC which is failing, not the Jetson.

Of course the twist on that story is that the host PC could be failing if the cable is a charger cable instead of a good cable capable of working with USB2 speeds. Still, I would expect that if you monitor “dmesg --follow” as you insert a USB cable (even a bad one), then you would at least see some log message (perhaps then followed by a disconnect).

8

Hi linuxdev:
I have a problem in host pc, I don’t get address192.168.55.10 in host pc, and ifconfig in host pc don’t see the device.and ssh name@192.168.55.1 connect failed,demsg --follow as attachement
dmesg --follow demsg.log (1.5 KB)
ifconfig:ifconfig.log (1.2 KB)
sudo lshw -class network:lshw.log (2.0 KB)

9

It should be “192.168.55.100”, but I am guessing that is just a typo and you’d know if there were no “192.168.55.xxx” address host side. Thus the problem is at the host end.

On dmesg I see the Jetson is visible, and the several “gadget” devices are visible (for example, rndis_host is ethernet, usb-storage is a virtual hard drive partition, cdc_acm is a serial UART which is actual instead of virtual…scsi is regarding the virtual hard drive interface of usb-storage).

The Jetson has done its job, and announced its presence to the host; the host’s USB has seen and announced the virtual devices. Now it is up to the host PC to use those devices, and it seems that perhaps the ethernet has been ignored and configuration did not continue beyond announcing the device presence.

It would be common for a security setting to not just automatically use random network devices, but often the Ubuntu default is to use those devices. An extremely important line in your dmesg log is this:

[32376.858401] cdc_ncm 1-1:1.5: MAC-Address: 22:f0:a3:8a:02:66

The MAC address “22:f0:a3:8a:02:66” can be used to tell your host PC it is ok to use that device. I would recommend (on the host) to use “nm-connection-editor” (if you don’t have this, then “sudo apt-get install network-manager-gnome”). The “gear” icon at the bottom (after selecting a name for a device) allows configuring. Individual devices are identified by the above mentioned MAC address (interfaces can be automatically renamed, but MAC addresses are constant). I forget the actual update, but basically you’ll want this to be set to “automatically connect”, “all users may connect to this”, and automatic setup under “Ethernet” (not VPN since this is not a VPN). Under IPv4 make sure “Method” is “Automatic (DHCP)”. See if you can then see “192.168.55.100” on the host side’s “ifconfig”, and also if you can now “ping 192.168.55.1”.

Just to illustrate this from the lshw output, the MAC is shown as “serial” there:

  *-network:1 DISABLED
       description: Ethernet interface
       physical id: 2
       logical name: enp0s20f0u1i5
       serial: 22:f0:a3:8a:02:66
       capabilities: ethernet physical
       configuration: broadcast=yes driver=cdc_ncm driverversion=22-Aug-2005 firmware=CDC NCM link=no multicast=yes

…which shows the USB ethernet is functioning 100% correctly using the cdc_ncm driver, but the host decided to disable it.

10

Hi linuxdev;
follow your tip used “nm-connection-editor” to add two Ethernets ,but still can not ping192.168.55.1 and ifconfig still don’t have 192.168.55.1001 2 3 4

1 Like
11

For the ethernet you set to use DHCP automatically, does the MAC address match what you see at the moment of plugging in the Jetson (I assume you will be monitoring “dmesg --follow” to see MAC address)?

Once you have added this MAC’s setup, in the “General” tab, is this set to “Automatically connect…”, and does it also have checked “All users may connect…”? Also, once this is done, make sure to save, and then unplug and replug the fully booted Jetson via the micro-B USB…I’m hoping to at least see some message in “demsg --follow” which indicates progress, or else indicates some new issue.

12

HI linuxdev;
I checked the “General tab” is have “Automatically connect…” and “All user may connet…” ,unplug and replug the Jetson via the micro-B USB, the message from “dmesg --follow” as below,and it still can not see 192.168.55.100 by ifconfig:
dmesg_follow.log (3.7 KB)

13

There is definitely a connect for the MAC address 22:f0:a3:8a:02:66. I see the host PC doing some udev renaming though, and this seems associated with two devices, and I am not positive what the meaning of that would be:

[178464.083457] rndis_host 1-1:1.0 enp0s20f0u1: renamed from usb0
[178464.253216] cdc_ncm 1-1:1.5 enp0s20f0u1i5: renamed from usb1

Then I see unregister of the same devices:

[178712.665404] rndis_host 1-1:1.0 enp0s20f0u1: unregister 'rndis_host' usb-0000:00:14.0-1, RNDIS device
[178712.787277] cdc_ncm 1-1:1.5 enp0s20f0u1i5: unregister 'cdc_ncm' usb-0000:00:14.0-1, CDC NCM

I see a different MAC address listed here, and since it is usb0, I am scratching my head a bit wondering:

[178716.199381] rndis_host 1-1:1.0 usb0: register 'rndis_host' at usb-0000:00:14.0-1, RNDIS device, de:87:40:f4:91:7f

Then once more some MAC address content related to the USB connect:

[178716.225278] cdc_ncm 1-1:1.5: MAC-Address: 22:f0:a3:8a:02:66
[178716.225480] cdc_ncm 1-1:1.5 usb1: register 'cdc_ncm' at usb-0000:00:14.0-1, CDC NCM, 22:f0:a3:8a:02:66
[178716.233747] rndis_host 1-1:1.0 enp0s20f0u1: renamed from usb0
[178716.263955] cdc_ncm 1-1:1.5 enp0s20f0u1i5: renamed from usb1

This all seems a bit odd. The host has what it needs, but is going through a lot of steps. Some questions, but see if you can make sure the interfaces are enabled for all in nm-connection-editor prior to checking these questions:
What do you see on the host from “ifconfig enp0s20f0u1”?
What do you see on the host from “ifconfig enp0s20f0u1i5”?
What do you see on the host from “route”?

14

Hi,linuxdev:
“route” "ifconfig enp0s20f0u1 “ ifconfig enp0s20f0u1i5 ” show as below:
leetop@lv:~/work/R32.4.2/nx/Linux_for_Tegra$ ifconfig enp0s20f0u1i5
enp0s20f0u1i5: flags=4098<BROADCAST,MULTICAST> mtu 1500
ether ce:b2:57:12:ca:8e 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

leetop@lv:~/work/R32.4.2/nx/Linux_for_Tegra$ ifconfig enp0s20f0u1
enp0s20f0u1: flags=4098<BROADCAST,MULTICAST> mtu 1500
ether 52:a1:9a:c4:52:85 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

leetop@lv:~/work/R32.4.2/nx/Linux_for_Tegra$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default _gateway 0.0.0.0 UG 0 0 0 enp4s0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 enp4s0

15

Both enp0s20f0u1i5 and enp0s20f0u1 look correct for an interface which is not receiving packets from a router. Basically, there is no IP address assigned, and there is no indication of traffic. A normal plug to a router or switch would show a few bytes of traffic for various query content even if the interface is not used or further set up. Are these physically connected to a router or switch? If so, what is the physical connection topology?

Notice that your route indicates enp4s0 is actually a 192.168.x.x/16 subnet, and what I would normally expect here is a /24 subnet. This is not an error, but it does make me think some sort of setup cusenp0s20f0u1i5 and enp0s20f0u1tomization took place for that interface. However, at the moment, since enp0s20f0u1i5 and enp0s20f0u1 do not have an address, this becomes irrelevant.

Can you give more details on the physical wiring of the USB network devices?