Hi,
I do a test with two same Orin board. The two Orin is connected by 10G netcard(The device tree address is 0x6810000). When I insert the net cable,
one orin print netcard link up information at once, but another one print the same information after 200+s.
Do you know the reason?
I can’t answer, but here is something to do to get started…
Monitor “dmesg --follow” prior to plugging in any network cables. Now plug in the cables, one at a time, and post any logs which are added due to the plugin, stating which behavior goes with which log lines.
Also, prior to plugging in any cables, show the output of:
ip -s addr show
(the old command was “netstat”, use that instead if it works)ip route
(the old command was “route”, use that instead if it works)
Then, repeat the addr and route commands after each cable has been plugged in for at least a few seconds. Note in the forum thread what each log shows, and which cable was added to get the output.
Hi,
I follow your instruction to capture the log.
The 10g_later_linkup.log (77.0 KB) is the output of “dmesg --follow ”
The 10g_ip_cmd.log (16.0 KB) is the output of the ip command.
By the way, the eth1 is the 10G netcard.
Thanks.
It is important to know that not the entire dmesg --follow is needed. That’s a large log. I’m quite interested in what log lines are appended only after plugin. Is it correct that these lines are from plugin:
[ 521.494972] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 521.498047] nvethernet 6810000.ethernet eth1: Link is Up - 10Gbps/Full - flow control off
According to that the NIC is operating normally, but I only see it registering for IPv6. If your router is assigning IPv6, then that is fine, but it is rather suspicious that IPv4 is not even mentioned. IPv4 tends to be less problematic than IPv6. Does your router have the ability to force IPv4 address assignment?
Plugin does not seem to produce any errors in terms of errors/dropped/overrun/collisions. There is a lack of address assignment, but no conflicting configurations.
Do you know what your router’s IP address is? Does that router have access to the outside world? I ask because I see a default route assigned to eth2, but I’d expect it to be the router’s address unless the router isn’t talking to the outside world. The address I see for default is 172.23.100.1.
No traffic is seen on eth0 or eth1. I assume this is expected, and that those interfaces do not have a network cable attached. Or perhaps they are statically assigned and have no reason for a DHCP query.
It is correct that these lines are from plugin:
[ 521.494972] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 521.498047] nvethernet 6810000.ethernet eth1: Link is Up - 10Gbps/Full - flow control off
And there is no route, two Orin board linked directly with 10G netcard.
Although there is no error in the plugin, but the link up information is later printed 200+s after the cable is inserted.
After the link up information is printed, I assigned the ipv4 address of the eth1 with command ifconfig, and the two board can ping with 10G netcard.
Aha! If directly connected, then there would be no address assignment unless it is set up as a static assignment.
The default of any of the network interfaces for a NIC is to send out a DHCP query, and wait for a response to assign the address. You have no router, so no matter how long it waits, there will be no response. Only a timeout.
Have you configured a static IP address? I think perhaps missing configuration is related to the long period of time, although this could still be a problem. Either:
- Use a router.
- Assign a static IP address, netmask, and default route through that interface.
Hi,
I assigned the address of eth1 with a static IP address.The result is the same as before.The following is the the output of command ip a. You can see the ip of eth1 is 172.16.1.101 and the state of eth1 is down.
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 1e:cb:45:15:8d:6e brd ff:ff:ff:ff:ff:ff
3: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1466 qdisc mq state DOWN group default qlen 1000
link/ether 48:b0:2d:91:60:06 brd ff:ff:ff:ff:ff:ff
4: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1466 qdisc mq state DOWN group default qlen 1000
link/ether 48:b0:2d:91:60:06 brd ff:ff:ff:ff:ff:ff
inet 172.16.1.101/16 brd 172.16.255.255 scope global eth1
valid_lft forever preferred_lft forever
5: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UNKNOWN group default qlen 1000
link/ether 48:b0:2d:94:c4:f1 brd ff:ff:ff:ff:ff:ff
altname enP1p1s0
inet 172.23.100.101/24 brd 172.23.100.255 scope global eth2
valid_lft forever preferred_lft forever
inet6 fd74:452d:57d0:3d00:4ab0:2dff:fe94:c4f1/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 6913sec preferred_lft 3313sec
inet6 fe80::a064:6dff:fe96:3ae8/64 scope link
valid_lft forever preferred_lft forever
6: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:3c:e9:f1:c6 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
I thought what you were looking at is for eth2. If there is a static address to eth1, then normally this would be “up”.
A lot of differences occur depending on whether an interface is “managed” or “unmanaged”. I am quite curious though, can you install “nm-connection-editor” (“sudo apt-get install network-manager-gnome” if you don’t already have it), and configure both the address (static) and “up” state there? Also, if you are ok with IPv4 (all I see currently is IPv6), can you at least for testing limit this to IPv4 (there is a separate checkbox and setup for IPv4 and IPv6 in nm-connection-editor)? I’m trying to limit this to the most simple case.
Incidentally, your address assigned is IPv4, but the part I see which from an earlier log is stating that the IPv6 link of eth1 is ready. IPv6 tends to be more problematic.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.