VLANs not working w/ L4T 36.4

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin NX
1

Expected:

  • Able to create a VLAN and ping a device in that subnet

Actual:

  • Ping doesn’t work to VLAN subnet. Only outbound packets seem to increase.

I have a device connected directly to the Orin with IP 192.168.2.3

Replicate:

  • sudo ip link set dev eth1 up
  • sudo ip addr add dev eth1 192.168.2.10/24
  • ping 192.168.2.3
    < ping successful >

Okay, lets create a VLAN and try the same ping

  • remove IP from physical interface:
    sudo ip link del dev eth1 192.168.2.10

  • Add VLAN and same address, try ping
    sudo ip link add dev eth1.2 link eth1 type vlan id 2
    sudo ip link set dev eth1.2 up
    sudo ip addr add dev eth1.2 192.168.2.10/24
    ping 192.168.2.3
    < Ping unsuccessful >

Is this a known issue with L4T 36.4? VLANs don’t seem to be working at all.

I am using the sample root filesystem without building the kernel from source, flashed using initrd

3

Is your usecase fine when using rel-35?

4

I haven’t tried 35, but just flashed 36.3 and same issue is present. It appears to be a duplicate of this. Wondering why it hasn’t been pushed upstream

5

You can see packets leaving the VLAN interface, but no packets are received. This issue appears to be present in both 36.4 and 36.3.

I don’t see where in the 36.4 kernel to apply the patch you mentioned, it looks like the driver has been moved.

aero@aero:~$ sudo ip link add dev enP8p1s0.2 link enP8p1s0 type vlan id 2
aero@aero:~$ sudo ip link set dev enP8p1s0.2 up
aero@aero:~$ sudo ip addr add dev enP8p1s0.2 10.223.204.2/16
aero@aero:~$ ping 10.223.204.142
PING 10.223.204.142 (10.223.204.142) 56(84) bytes of data.
From 10.223.204.2 icmp_seq=1 Destination Host Unreachable
From 10.223.204.2 icmp_seq=2 Destination Host Unreachable
From 10.223.204.2 icmp_seq=3 Destination Host Unreachable
^C
— 10.223.204.142 ping statistics —
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3059ms
pipe 4
aero@aero:~$ ifconfig
enP8p1s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
RX packets 127 bytes 36942 (36.9 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 121 bytes 17056 (17.0 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 22 base 0x3000

enP8p1s0.2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.223.204.2 netmask 255.255.0.0 broadcast 0.0.0.00x20
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 32 bytes 4056 (4.0 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

6

Hi,

The patch you are talking about are already present in rel-36.3 and rel-36.4 codeline… They are in nvidia-oot repo.

kernel/nvidia-oot/drivers/net/ethernet/nvidia/nvethernet/ether_linux.c

Maybe you could take a look first. If they are there and you still reproduce this issue, please share the whole setup and steps to reproduce your issue.

7

Interesting, maybe the issue lies with the Seeed 3rd party carrier board that I am using. All other ethernet functionality seems to work though, so I would find it odd that the carrier is the root cause.

8

I just realize that this is a “Orin NX” issue.

Orin NX is not using nvethernet driver at all but PCIe based solution with Realtek PCIe NIC driver. Therefore, I think this could be an issue that is not from our driver.

1 Like
9

That makes sense, it’s showing that driver r8168 is managing eth0, so not an NVIDIA Driver. I tried to see if using r8169 would fix the VLAN issue by enabling it in the kernel defconfig, but didn’t change the behavior. Do you have any ideas of potential avenues to get this working? It seems that the Realtek PCIe Ethernet controller should support VLANs.

11

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.