Our carrier board is designed based on the Xaiver NX development board, with the core board using 3688-0001. The software operating system is based on Jetson_Linux_R35.3.1/arch64.tbz2, with adjustments made to MB1’s cfg and dtb, and support for Veye’s imx462 and external SD CARD.
After setting the IP address of eth0 (192.168.2.10) using ifconfig. Then use ping to test the network, it can ping, but after a few attempts, eth0’s IP address is lost and switched to another network. At this point, using the ifconfig command, it is found that eth0’s IP address has been lost. Reconfigure the IP address using ifconfig eth0 192.168.2.10, ping again successfully, but communication fails after several attempts.
We have made a total of 8 sets of devices and tested other devices, and the phenomenon is consistent, all of which have failed after pinging several times.
Attached are the log files from our testing. We are unsure if it is a software configuration issue or a hardware problem.
ping failed.txt (5.5 KB)
Will you please give some advices on it,Thanks.
Could you try to use other IP address here as 192.168.55.1 will conflict with the interface generated by usb device interface.
Try another IP address instead of 192.168.2.10, and it still has the same problem.
try 10.0.0.1 on rel-35.6 first.
Try on R35.6, and the same problem.
But config eth0 address with UI or with command nmcli, it work well and ping ok.
Maybe you could check syslog and see what happened to the interface.
After an error, check the output for that interface with ifconfig (or in some cases “ip -s addr”). Be very careful to include the RX and TX statistics which might show some issue.
You might also want to watch your router’s log while doing this. Most routers have a web interface, some even have ssh interface. If you can see what the router thinks, it might be a good clue even if the problem is at the carrier board (it is the router which sees and replies to DHCP requests).
Perhaps also try to reserve a specific IP address on the router, and tell the router to not issue a DHCP reply to your MAC address (and make sure your MAC address does not change). Then statically configure the address on the Jetson to that address. This would take DHCP out of the equation.
Attach the log from termial, it include start,ifconfig ,ping and ping failed.Please check out for us ,thanks!
nvidia-ifconfig.log (179.9 KB)
Our carried board with P
3688-0001 connect directly to PC .There is no router,and PC has a static ip address.
What cable are you connecting on your Jetson during this test?
This seems abnormal.
64 bytes from 192.168.2.16: icmp_seq=7 ttl=64 time=0.851 ms^M^M
64 bytes from 192.168.2.16: icmp_seq=8 ttl=64 time=0.767 ms^M^M
64 bytes from 192.168.2.16: icmp_seq=9 ttl=64 time=1.18 ms^M^M
64 bytes from 192.168.2.16: icmp_seq=10 ttl=64 time=0.804 ms^M^M
64 bytes from 192.168.2.16: icmp_seq=11 ttl=64 time=0.828 ms^M^M
64 bytes from 192.168.2.16: icmp_seq=12 ttl=64 time=1.25 ms^M^M
64 bytes from 192.168.2.16: icmp_seq=13 ttl=64 time=0.862 ms^M^M
64 bytes from 192.168.2.16: icmp_seq=14 ttl=64 time=1.07 ms^M^M
64 bytes from 192.168.2.16: icmp_seq=15 ttl=64 time=0.842 ms^M^M
64 bytes from 192.168.2.16: icmp_seq=16 ttl=64 time=1.49 ms^M^M
64 bytes from 192.168.2.16: icmp_seq=17 ttl=64 time=1.11 ms^M^M
64 bytes from 192.168.2.16: icmp_seq=18 ttl=64 time=1.05 ms^M^M
64 bytes from 192.168.2.16: icmp_seq=19 ttl=64 time=1.16 ms^M^M
From 192.168.55.1 icmp_seq=20 Destination Host Unreachable^M^M
From 192.168.55.1 icmp_seq=21 Destination Host Unreachable^M^M
From 192.168.55.1 icmp_seq=22 Destination Host Unreachable^M^M
From 192.168.55.1 icmp_seq=23 Destination Host Unreachable^M^M
From 192.168.55.1 icmp_seq=24 Destination Host Unreachable^M^M
From 192.168.55.1 icmp_seq=25 Destination Host Unreachable^M^M
From 192.168.55.1 icmp_seq=26 Destination Host Unreachable^M^M
From 192.168.55.1 icmp_seq=27 Destination Host Unreachable^M^M
192.168.55.1 is always the usb device port interface IP with that micro usb port on Jetson devkit.
Sep 8 09:58:30 nvidia avahi-daemon[365]: Registering new address record for 192.168.55.1 on l4tbr0.IPv4.^M^M
There is no usb cable to usb port,and only lan cable to ethernet port.
Could you share your ifconfig -a as linuxdev suggseted? I open your log file but didn’t see that result at all.
Attach the log with ifconfig -a.
nvidia-ifconfig.log (197.5 KB)
I still see the l4tbr0 interface is up even you told us there is no usb connection.
l4tbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500^M^M
inet 192.168.55.1 netmask 255.255.255.0 broadcast 192.168.55.255^M^M
inet6 fe80::1 prefixlen 128 scopeid 0x20<link>^M^M
ether f6:2f:44:ed:8b:0d txqueuelen 1000 (Ethernet)^M^M
RX packets 0 bytes 0 (0.0 B)^M^M
RX errors 0 dropped 0 overruns 0 frame 0^M^M
TX packets 0 bytes 0 (0.0 B)^M^M
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0^M^M
Try to disable l4t-usb-device-mode service and check your ifconfig again.
Also, I notice something from the rest of logs
- 5.10.104 is a kernel version that in some early jetpack release. Not the latest one
- You mentioned this is NV devkit but it seems you changed the device tree, what is the purpose of changing device tree here?
It’s a customer carried board based on devkit, and changing device tree to be enable external SD card and imx462.
How to disable l4t-usb-device-mode service?
sudo service nv-l4t-usb-device-mode stop
and check if that l4tbr0 interface is gone.
The nvidia-ifconfig.log seems to just be a session log. I don’t see the output from the ifconfig itself. You do not need sudo for ifconfig, but I suspect that if you were redirecting a session from a regular user, and then used ifconfig, there is some possibility that the root user content in the sudo was not echoed to the log. Also, it might be useful to show all interfaces since there can be conflicts between interfaces.
I’ll double down on what @WayneWWW saw: The 192.168.55.1 was not there. If this ping took place on the Jetson itself, then there would be no reason for this to fail unless the service itself is not running since this is the Jetson’s own local network. If this is from a host PC, then the host should be able to self-ping at 192.168.55.100 when the fully booted Jetson has the correct USB cable connected to the host PC. If the host and Jetson are connected via USB, then the host could ping the Jetson at 192.168.55.1, and the Jetson could ping the host at 192.168.55.100.
I have checked the different of syslog between using ifconfig and using nmcli to set the ip address. The syslog of nmcli command as follow:
Sep 8 10:02:59 nvidia NetworkManager[418]: [1662631379.5874] device (eth0): state change: ip-check → secondaries (reason ‘none’, sys-iface-state: ‘managed’)
Sep 8 10:02:59 nvidia NetworkManager[418]: [1662631379.5883] device (eth0): state change: secondaries → activated (reason ‘none’, sys-iface-state: ‘managed’)
Sep 8 10:02:59 nvidia NetworkManager[418]: [1662631379.5897] manager: NetworkManager state is now CONNECTED_LOCAL
Sep 8 10:02:59 nvidia NetworkManager[418]: [1662631379.5952] device (eth0): Activation: successful, device activated.
It has a log as “device (eth0): Activation: successful, device activated.” But this log not found in the syslog of command ifconfig .
What is the test result after you disable the nv-l4t-usb-device-mode ? Is l4tbr0 interface removed ?
What is the full output of the ifconfig? There should be both a TX and RX section listing things like errors, overruns, collisions, so on.