# WP77XX goes into state where no LTE data is recv until some data is sent **URL:** \ **Category:** Legato Application Framework\ **Created:** [February 4, 2025, 10:03pm UTC](https://forum.legato.io/t/wp77xx-goes-into-state-where-no-lte-data-is-recv-until-some-data-is-sent/6891 "2025-02-04T22:03:47Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![upsampled](https://avatars.discourse-cdn.com/v4/letter/u/bc8723/32.png) [@upsampled](https://forum.legato.io/u/upsampled)\ **Post date:** [February 4, 2025, 10:03pm UTC](https://forum.legato.io/t/wp77xx-goes-into-state-where-no-lte-data-is-recv-until-some-data-is-sent/6891/1 "2025-02-04T22:03:47Z")
# Summary Periodically the WP77XX will go into a state where it will not receive LTE data until data is sent via LTE. # No Rx State When in state, device shows connected ```auto root@p240wp77xx:~# cm data info Index: 1 APN: cdi01.com.attz PDP Type: IPV4 Connected: yes Interface: rmnet_data0 Family[IPv4]: inet IP[IPv4]: 10.64.32.78 Gateway[IPv4]: 10.64.32.77 Dns1[IPv4]: 167.206.112.138 Dns2[IPv4]: 167.206.7.4 root@p240wp77xx:~# ip route show default via 10.64.32.77 dev rmnet_data0 10.64.32.76/30 dev rmnet_data0 proto kernel scope link src 10.64.32.78 192.168.0.0/23 dev eth0 proto kernel scope link src 192.168.1.208 192.168.2.0/24 dev ecm0 proto kernel scope link src 192.168.2.2 192.168.225.0/24 dev bridge0 proto kernel scope link src 192.168.225.1 linkdown root@p240wp77xx:~# tcpdump -vv -i rmnet_data0 tcpdump: listening on rmnet_data0, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes ``` but pings sent from host are not answered ```auto liam@godr-boonton:~$ ping 10.64.32.78 PING 10.64.32.78 (10.64.32.78) 56(84) bytes of data. ``` ## Device can get out of state Device can get out of state by pinging the host ip ```auto root@p240wp77xx:~# ping 10.10.10.95 PING 10.10.10.95 (10.10.10.95): 56 data bytes 64 bytes from 10.10.10.95: seq=0 ttl=61 time=832.916 ms 64 bytes from 10.10.10.95: seq=1 ttl=61 time=237.843 ms 64 bytes from 10.10.10.95: seq=2 ttl=61 time=189.543 ms ``` **ANY outbound traffic seems to fix the issue** ```auto root@p240wp77xx:~# ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes ^C --- 8.8.8.8 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss root@p240wp77xx:~# ``` After this the host can initiate the ping as well ```auto liam@godr-boonton:~$ ping 10.64.32.78 PING 10.64.32.78 (10.64.32.78) 56(84) bytes of data. 64 bytes from 10.64.32.78: icmp_seq=1 ttl=60 time=13040 ms 64 bytes from 10.64.32.78: icmp_seq=2 ttl=60 time=12049 ms 64 bytes from 10.64.32.78: icmp_seq=3 ttl=60 time=11043 ms 64 bytes from 10.64.32.78: icmp_seq=4 ttl=60 time=10039 ms 64 bytes from 10.64.32.78: icmp_seq=5 ttl=60 time=9034 ms 64 bytes from 10.64.32.78: icmp_seq=6 ttl=60 time=8018 ms 64 bytes from 10.64.32.78: icmp_seq=7 ttl=60 time=7004 ms 64 bytes from 10.64.32.78: icmp_seq=8 ttl=60 time=5980 ms 64 bytes from 10.64.32.78: icmp_seq=9 ttl=60 time=4964 ms 64 bytes from 10.64.32.78: icmp_seq=10 ttl=60 time=3950 ms 64 bytes from 10.64.32.78: icmp_seq=11 ttl=60 time=2934 ms 64 bytes from 10.64.32.78: icmp_seq=12 ttl=60 time=1920 ms 64 bytes from 10.64.32.78: icmp_seq=13 ttl=60 time=896 ms 64 bytes from 10.64.32.78: icmp_seq=14 ttl=60 time=243 ms ``` ## Not an iptables issue turning iptables off does not fix the issue. ```auto root@p240wp77xx:~# root@p240wp77xx:~# iptables -F root@p240wp77xx:~# iptables -X root@p240wp77xx:~# iptables -P INPUT ACCEPT root@p240wp77xx:~# iptables -P OUTPUT ACCEPT root@p240wp77xx:~# iptables -P FORWARD ACCEPT root@p240wp77xx:~# iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT ``` Device still does not recv data. ## Repeatable with just cm data connect even when the primary app is not running and only cm data is used to connect, the device falls into this state ```auto root@p240wp77xx:~# cm data connect Setting up profile 1 Connecting ... ok Checking if device 'rmnet_data0' is up ... ok Routing inet ... ok Updating /etc/resolv.conf ... ok Updating /etc/resolv.conf ... ok ``` still goes into this state ---
**Author:** ![jyijyi](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.legato.io/jyijyi/32/822_2.png) [@jyijyi](https://forum.legato.io/u/jyijyi)\ **Post date:** [February 5, 2025, 1:40am UTC](https://forum.legato.io/t/wp77xx-goes-into-state-where-no-lte-data-is-recv-until-some-data-is-sent/6891/2 "2025-02-05T01:40:30Z")
Seems same issue as this one: > **[WP77xx Modem only reachable after sending data (LTE)](https://forum.sierrawireless.com/t/wp77xx-modem-only-reachable-after-sending-data-lte/21464)** > > Hi, I have a problem with the WP77xx modules concerning the data connection. Situation: I have aWP7702 module, from which I can connect to a LTE-M network via a private APN. I’ve verified that it is connected to the private APN and that there... does it help to disable edrx feature by AT+CEDRXS=0? > **[WP7702 TCP no answer after 2s](https://forum.sierrawireless.com/t/wp7702-tcp-no-answer-after-2s/29768/8)** > > Also you can have a look here: I wonder if this is related to RRC\_IDLE, also you can bring it back to RRC CONNECTED by just doing a simple TCP transfer such as keep-alive packet. In addition, you can try if there is improvement by disabling... ---
**Author:** ![upsampled](https://avatars.discourse-cdn.com/v4/letter/u/bc8723/32.png) [@upsampled](https://forum.legato.io/u/upsampled)\ **Post date:** [February 5, 2025, 11:23am UTC](https://forum.legato.io/t/wp77xx-goes-into-state-where-no-lte-data-is-recv-until-some-data-is-sent/6891/3 "2025-02-05T11:23:01Z")
Seems to have worked. I ended up using the [Legato API](https://docs.legato.io/20_08/c_lpt.html) for this instead of the AT command with the same positive result