I have Sierra USB modem connected to TX1 devkit with R24.2.1. As recommendation from vendor i have installed Gobinet and Gobiserial drivers which created ttyUSBx and qcqmi0 nodes. Also GobiAPI(QMI) provided from Vendor able to talk with modem. Once i enabled the data session and try using ping, am not getting any reply messages. Same when I install drivers and APIs in my local ubuntu PC it works fine.
Following are the host setup requirement:
The Linux distribution may have in built drivers and applications that can interfere with SDK process’s
execution. The below Qualcomm drivers, if present, need to be black listed.
Please black list them as below (example is for Ubuntu). Add the 2 entries to the
“/etc/modprobe.d/blacklist-modem.conf” file and restart the host
“Modem Manager” is another application that can interfere with the SDK’s operation. Please remove it
and restart the host. Below example is for an Ubuntu PC:
#sudo apt-get remove modemmanager
#sudo killall -9 modemmanager
In wireshark, am able to see ICMP reply from 126.96.36.199 but somehow it is discarding in TX1. Also i have checked the packets via tcpdump, and packets am seeing as below when i give ping 188.8.131.52:
14:53:10.193672 IP 10.81.83.241 > 184.108.40.206: ICMP echo request, id 2062, seq 14, length 64
14:53:10.321686 IP 220.127.116.11 > 10.81.83.241: ICMP echo reply, id 2062, seq 14, length 64
14:53:11.194101 IP 10.81.83.241 > 18.104.22.168: ICMP echo request, id 2062, seq 15, length 64
14:53:11.376100 IP 22.214.171.124 > 10.81.83.241: ICMP echo reply, id 2062, seq 15, length 64
14:53:12.194039 IP 10.81.83.241 > 126.96.36.199: ICMP echo request, id 2062, seq 16, length 64
default 10.81.83.242 0.0.0.0 UG 100 0 0 eth0
10.81.83.240 * 255.255.255.252 U 100 0 0 eth0
link-local * 255.255.0.0 U 1000 0 0 usb0
192.168.2.0 * 255.255.255.0 U 100 0 0 usb0
192.168.100.0 * 255.255.252.0 U 0 0 0 wlan0
NOTE: Attached file is the wireshark pcap file need to rename as capture.pcap for viewing in wireshark.
Any suggestion on this would help me to resolve this issue.
Thanks in Advance.
capture.txt (63 KB)
One minor possibility is related to the protocol used in ping, ICMP. Ping requires this protocol to be allowed and passed through. Each node on the route can have its own settings as to whether to respond to ICMP. If you use traceroute instead, then you check the ping at each hop along the route instead of just one hop…under traceroute you’re likely to get at least one reply at one hop if this is the case. Sometimes routers themselves (when supplied by an ISP) do not reply at all hops.
Packet is discarding because destination mac and device mac are not matching. In usbnet.c file, usbnet_skb_return function giving mac address as below. Always seeing last byte getting corrupted and also with same value 8.
[ 628.826306] dest addr: fe dev addr: fe
[ 628.826308] dest addr: 3b dev addr: 3b
[ 628.826311] dest addr: 87 dev addr: 87
[ 628.826313] dest addr: f8 dev addr: f8
[ 628.826316] dest addr: 61 dev addr: 61
[ 628.826318] dest addr: 8 dev addr: 3e
[ 99.315173] dest addr: ce dev addr: ce
[ 99.315176] dest addr: 1c dev addr: 1c
[ 99.315178] dest addr: ce dev addr: ce
[ 99.315181] dest addr: ec dev addr: ec
[ 99.315183] dest addr: 52 dev addr: 52
[ 99.315186] dest addr: 8 dev addr: 1a
[ 55.394366] dest addr: 56 dev addr: 56
[ 55.394369] dest addr: 9e dev addr: 9e
[ 55.394371] dest addr: ad dev addr: ad
[ 55.394374] dest addr: b6 dev addr: b6
[ 55.394376] dest addr: 1e dev addr: 1e
[ 55.394378] dest addr: 8 dev addr: f0
[ 87.109488] dest addr: b6 dev addr: b6
[ 87.109491] dest addr: 74 dev addr: 74
[ 87.109494] dest addr: c4 dev addr: c4
[ 87.109496] dest addr: d7 dev addr: d7
[ 87.109499] dest addr: 7e dev addr: 7e
[ 87.109501] dest addr: 8 dev addr: 3d
That looks like a genuine bug, but I’m not sure who would handle the bug fix in this case.
This is an older kernel, so there is a strong possibility an upstream kernel already has this fixed if it isn’t specific to L4T. I don’t know from that if the usbnet_skb_return function was in error, or if values passed to the function are in error; in the former case you’d need to search for a fix to backport, but in the latter case it may actually be something specific to the L4T or arm64 code (or it could again be fixed in a more recent kernel and once again not specific to L4T). If you are running something like KGDBOC you might try to get a call stack and trace back at which point that byte is being corrupted.