Ping not replying for LTE modem


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.

  • qcserial
  • qmi_wwan
    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
    blacklist qcserial
    blacklist qmi_wwan
    “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
#sudo reboot

In wireshark, am able to see ICMP reply from 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
14:53:10.193672 IP > ICMP echo request, id 2062, seq 14, length 64
14:53:10.321686 IP > ICMP echo reply, id 2062, seq 14, length 64
14:53:11.194101 IP > ICMP echo request, id 2062, seq 15, length 64
14:53:11.376100 IP > ICMP echo reply, id 2062, seq 15, length 64
14:53:12.194039 IP > ICMP echo request, id 2062, seq 16, length 64

route command:
default UG 100 0 0 eth0 * U 100 0 0 eth0
link-local * U 1000 0 0 usb0 * U 100 0 0 usb0 * 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.

Hi Linuxdev,

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.