When I using TX2(192.168.1.10) connect to Ubuntu Host computer(192.168.1.100), and ping each other works fine.
Bug TX2(192.168.1.10) connnect to an IP Camera(IP: 192.168.1.160), ping failed, and get some error messages like this:
nvidia@tegra-ubuntu:~$ dmesg
[...]
[ 11.388165] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 11.685245] tegradc 15210000.nvdisplay: unblank
[ 11.874493] IPv6: ADDRCONF(NETDEV_UP): docker0: link is not ready
[ 13.361605] eqos 2490000.ether_qos eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[ 13.370783] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 13.396169] eqos 2490000.ether_qos: changing MTU from 1500 to 9000
[ 13.402503] bcm54xx_low_power_mode(): put phy in iddq-lp mode
[ 13.981223] fuse init (API version 7.23)
[ 17.036280] eqos 2490000.ether_qos eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[ 17.176002] IPVS: Creating netns size=1424 id=2
[ 17.292168] tegradc 15210000.nvdisplay: blank - powerdown
[ 17.355825] PD DISP2 index4 DOWN
[ 17.355918] PD DISP1 index3 DOWN
[ 17.355992] PD DISP0 index2 DOWN
[ 17.379588] tegradc 15210000.nvdisplay: blank - powerdown
[ 17.385061] tegradc 15210000.nvdisplay: unblank
[ 17.385075] PD DISP0 index2 UP
[ 17.387072] PD DISP1 index3 UP
[ 17.387160] PD DISP2 index4 UP
[ 17.393748] Parent Clock set for DC plld2
[ 17.396730] tegradc 15210000.nvdisplay: hdmi: pclk:74250K, set prod-setting:prod_c_75M
[ 18.439566] tegradc 15210000.nvdisplay: unblank
[ 18.821821] IPVS: Creating netns size=1424 id=3
[ 92.069256] eqos 2490000.ether_qos eth0: Link is Down
[ 100.317073] eqos 2490000.ether_qos eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[ 102.937851]
prx_desc[00 ffffff800c7f1040 004 RECEIVED FROM DEVICE] = 0x0:0x13:0x0:0x3509805f
[ 103.937872]
prx_desc[00 ffffff800c7f1050 005 RECEIVED FROM DEVICE] = 0x0:0x93:0x0:0x3501805e
[ 104.940028]
prx_desc[00 ffffff800c7f1060 006 RECEIVED FROM DEVICE] = 0x0:0x93:0x0:0x3509805e
[ 105.937903]
prx_desc[00 ffffff800c7f1070 007 RECEIVED FROM DEVICE] = 0x0:0x93:0x0:0x3501805f
[ 106.937919]
prx_desc[00 ffffff800c7f1080 008 RECEIVED FROM DEVICE] = 0x0:0x13:0x0:0x3509805f
[ 107.940090]
prx_desc[00 ffffff800c7f1090 009 RECEIVED FROM DEVICE] = 0x0:0x93:0x0:0x3501805e
[ 108.937957]
prx_desc[00 ffffff800c7f10a0 010 RECEIVED FROM DEVICE] = 0x0:0x13:0x0:0x3509805f
[ 109.938021]
prx_desc[00 ffffff800c7f10b0 011 RECEIVED FROM DEVICE] = 0x0:0x93:0x0:0x3501805f
[ 110.940208]
prx_desc[00 ffffff800c7f10c0 012 RECEIVED FROM DEVICE] = 0x0:0x93:0x0:0x3509805e
[ 148.758260]
prx_desc[00 ffffff800c7f10d0 013 RECEIVED FROM DEVICE] = 0x0:0x93:0x0:0x3501805f
[ 148.939204]
prx_desc[00 ffffff800c7f10e0 014 RECEIVED FROM DEVICE] = 0x0:0x13:0x0:0x3509805f
[ 149.940824]
prx_desc[00 ffffff800c7f10f0 015 RECEIVED FROM DEVICE] = 0x0:0x93:0x0:0x3501805f
So I can’t play the IP Camera, can someone give any advise about this?
add some message:
When plugout and plugin the cable, IP Camera can be pinged once, and then shows “destination host unreachable” in terminal.
Check dmesg, there is some “prx_desc” errors .
nvidia@tegra-ubuntu:~$ ping 192.168.1.160
PING 192.168.1.160 (192.168.1.160) 56(84) bytes of data.
From 192.168.1.10 icmp_seq=1 Destination Host Unreachable
From 192.168.1.10 icmp_seq=2 Destination Host Unreachable
From 192.168.1.10 icmp_seq=3 Destination Host Unreachable
From 192.168.1.10 icmp_seq=4 Destination Host Unreachable
From 192.168.1.10 icmp_seq=5 Destination Host Unreachable
From 192.168.1.10 icmp_seq=6 Destination Host Unreachable
From 192.168.1.10 icmp_seq=7 Destination Host Unreachable
From 192.168.1.10 icmp_seq=8 Destination Host Unreachable
From 192.168.1.10 icmp_seq=9 Destination Host Unreachable
From 192.168.1.10 icmp_seq=10 Destination Host Unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
64 bytes from 192.168.1.160: icmp_seq=64 ttl=64 time=1000 ms
64 bytes from 192.168.1.160: icmp_seq=65 ttl=64 time=1.01 ms
64 bytes from 192.168.1.160: icmp_seq=102 ttl=64 time=2990 ms
64 bytes from 192.168.1.160: icmp_seq=104 ttl=64 time=984 ms
From 192.168.1.10 icmp_seq=11 Destination Host Unreachable
From 192.168.1.10 icmp_seq=14 Destination Host Unreachable
From 192.168.1.10 icmp_seq=15 Destination Host Unreachable
From 192.168.1.10 icmp_seq=17 Destination Host Unreachable
From 192.168.1.10 icmp_seq=18 Destination Host Unreachable
From 192.168.1.10 icmp_seq=19 Destination Host Unreachable
From 192.168.1.10 icmp_seq=20 Destination Host Unreachable
From 192.168.1.10 icmp_seq=21 Destination Host Unreachable
From 192.168.1.10 icmp_seq=23 Destination Host Unreachable
From 192.168.1.10 icmp_seq=24 Destination Host Unreachable
From 192.168.1.10 icmp_seq=26 Destination Host Unreachable
From 192.168.1.10 icmp_seq=27 Destination Host Unreachable
From 192.168.1.10 icmp_seq=28 Destination Host Unreachable
From 192.168.1.10 icmp_seq=29 Destination Host Unreachable
From 192.168.1.10 icmp_seq=32 Destination Host Unreachable
From 192.168.1.10 icmp_seq=33 Destination Host Unreachable
From 192.168.1.10 icmp_seq=35 Destination Host Unreachable
Apparently the Jetson is receiving corrupt or malformed packets. There are a number of reasons this might occur…it could be the device sending bad data, it could be a cable is bad, it could be the PHY at the receiving end is bad. Perhaps there is some setting which is incompatible and auto-negotiation isn’t honored. My suggestion: Try with a known good gigabit switch in the middle. Maybe it is a simple case of auto-detect not knowing it needs to be cross-over mode (which leads to the question…is it a cross-over cable? does the camera have auto-detect of need for cross-over?). A switch would remove any requirement for cross-over detection. A switch would also change which hardware talks directly to the Jetson (presumably the switch would provide a known good signal).
The arp makes me wonder, due to this excerpt:
at <incomplete>
…the “” should be a MAC address. Without a MAC the physical layer will not work correctly. This might be explained by the network errors from ifconfig. If certain parts of the received packets are corrupt, then the MAC would be missing or garbage.
The output of the “route” command suggests this is correctly configured and not part of the issue.
You are right, in this case, TX2 can’t get the MAC address for IP Camera, so they can’t build the physical layer connection, thus, ping and connection is failed.
I do some more connection tests here:
The IP Camera can ping my host Ubuntu computer(using 4Pins or 8Pins RJ45 Cable)
TX2 can ping my host Ubuntu computer(using 4Pins or 8Pins RJ45 Cable)
TX2 can not ping the IP Camera (using 4Pins or 8Pins RJ45 Cable)
add a switch between IP Camera and TX2, then TX2 can ping IP Camera
The IP Camera only has RJ45 4 data pins(using 1,2,3,6 Pin for data transfer, where most RJ45 Cable has 8pins for connectioin), I swiched PIN 1,2 and 3,6, unfortunately TX2 can’t connect the IP Camera too, maybe the data pins different cause the problems ?
If this is truly a known good crossover cable, then it should work when direct connect fails due to not being able to auto-negotiate as crossover. This wouldn’t surprise me that crossover is required, but I am surprised if a real crossover cable fails.
Having a switch in between fixes both signal issues and crossover issues. Are you trying a known good crossover cable? It is highly likely the camera and TX2 combination is not automatically correcting for this, which would simply be a feature not available rather than something failing. I don’t know if your pin switching is correct or not since it could also affect signal quality depending on how it is performed.
I can confirm the crossover cable is right.
Due to my project schedule, I changed another IP Camera, connect with TX2 fine, once I finish the project I will come back to check the difference of network connection between the two IP Cameras. Then I will put the solution here.