EC25-V connection issue with Verizon

Technical Subjects
1

I have a few EC25-V modules, installed in various openwrt-devices, which do not receive an IP from Verizon, using ppp. Sometimes it succeeds, but only after a few hours of redialing.
The firmware is EC25VFAR02A14M4G

I see

AT+CSQ
+CSQ: 14,99

+COPS: 0,0,“Verizon Wireless”,7

+QNWINFO: “FDD LTE”,“311480”,“LTE BAND 4”,2050
Any suggestions, what to do/check ?

Some debug output from pppd:
Mon Nov 1 02:03:13 2021 daemon.notice netifd: Interface ‘wwan’ is setting up now
Mon Nov 1 02:03:15 2021 daemon.notice pppd[32166]: pppd 2.4.9 started by root, uid 0
Mon Nov 1 02:03:16 2021 daemon.debug pppd[32166]: Script USE_APN=vzwinternet DIALNUMBER=99**1# /usr/sbin/chat -t5 -E -f /etc/chatscripts/3g.chat finished (pid 32222), status = 0x0
Mon Nov 1 02:03:16 2021 daemon.info pppd[32166]: Serial connection established.
Mon Nov 1 02:03:16 2021 daemon.debug pppd[32166]: using channel 4178
Mon Nov 1 02:03:16 2021 kern.info kernel: [26069.560189] 3g-wwan: renamed from ppp0
Mon Nov 1 02:03:16 2021 daemon.info pppd[32166]: Renamed interface ppp0 to 3g-wwan
Mon Nov 1 02:03:16 2021 daemon.info pppd[32166]: Using interface 3g-wwan
Mon Nov 1 02:03:16 2021 daemon.notice pppd[32166]: Connect: 3g-wwan <–> /dev/ttyUSB3
Mon Nov 1 02:03:17 2021 daemon.debug pppd[32166]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x65d04e9b>]
Mon Nov 1 02:03:17 2021 daemon.debug pppd[32166]: rcvd [LCP ConfReq id=0xf3 <asyncmap 0x0> <magic 0x194cf8ff> ]
Mon Nov 1 02:03:17 2021 daemon.debug pppd[32166]: No auth is possible
Mon Nov 1 02:03:17 2021 daemon.debug pppd[32166]: sent [LCP ConfRej id=0xf3 ]
Mon Nov 1 02:03:17 2021 daemon.debug pppd[32166]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x65d04e9b>]
Mon Nov 1 02:03:17 2021 daemon.debug pppd[32166]: rcvd [LCP ConfReq id=0xf4 <asyncmap 0x0> <magic 0x194cf8ff>]
Mon Nov 1 02:03:17 2021 daemon.debug pppd[32166]: sent [LCP ConfAck id=0xf4 <asyncmap 0x0> <magic 0x194cf8ff>]
Mon Nov 1 02:03:17 2021 daemon.debug pppd[32166]: sent [LCP EchoReq id=0x0 magic=0x65d04e9b]
Mon Nov 1 02:03:18 2021 daemon.debug pppd[32166]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Mon Nov 1 02:03:18 2021 daemon.debug pppd[32166]: sent [IPV6CP ConfReq id=0x1 ]
Mon Nov 1 02:03:18 2021 daemon.debug pppd[32166]: rcvd [LCP DiscReq id=0xf5 magic=0x194cf8ff]
Mon Nov 1 02:03:18 2021 daemon.debug pppd[32166]: rcvd [LCP EchoRep id=0x0 magic=0x194cf8ff 65 d0 4e 9b]
Mon Nov 1 02:03:18 2021 daemon.notice pppd[32166]: Modem hangup
Mon Nov 1 02:03:18 2021 daemon.notice pppd[32166]: Connection terminated.

However, much later, connection is established:
Mon Nov 1 02:52:06 2021 daemon.notice pppd[19994]: pppd 2.4.9 started by root, uid 0
Mon Nov 1 02:52:08 2021 daemon.debug pppd[19994]: Script USE_APN=vzwinternet DIALNUMBER=99**1# /usr/sbin/chat -t5 -E -f /etc/chatscripts/3g.chat finished (pid 20091), status = 0x0
Mon Nov 1 02:52:08 2021 daemon.info pppd[19994]: Serial connection established.
Mon Nov 1 02:52:08 2021 daemon.debug pppd[19994]: using channel 4651
Mon Nov 1 02:52:08 2021 kern.info kernel: [29001.081176] 3g-wwan: renamed from ppp0
Mon Nov 1 02:52:08 2021 daemon.info pppd[19994]: Renamed interface ppp0 to 3g-wwan
Mon Nov 1 02:52:08 2021 daemon.info pppd[19994]: Using interface 3g-wwan
Mon Nov 1 02:52:08 2021 daemon.notice pppd[19994]: Connect: 3g-wwan <–> /dev/ttyUSB3
Mon Nov 1 02:52:09 2021 daemon.debug pppd[19994]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x738c194a>]
Mon Nov 1 02:52:09 2021 daemon.debug pppd[19994]: rcvd [LCP ConfReq id=0x7e <asyncmap 0x0> <magic 0x1979b4b2> ]
Mon Nov 1 02:52:09 2021 daemon.debug pppd[19994]: No auth is possible
Mon Nov 1 02:52:09 2021 daemon.debug pppd[19994]: sent [LCP ConfRej id=0x7e ]
Mon Nov 1 02:52:09 2021 daemon.debug pppd[19994]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x738c194a>]
Mon Nov 1 02:52:09 2021 daemon.debug pppd[19994]: rcvd [LCP ConfReq id=0x7f <asyncmap 0x0> <magic 0x1979b4b2>]
Mon Nov 1 02:52:09 2021 daemon.debug pppd[19994]: sent [LCP ConfAck id=0x7f <asyncmap 0x0> <magic 0x1979b4b2>]
Mon Nov 1 02:52:09 2021 daemon.debug pppd[19994]: sent [LCP EchoReq id=0x0 magic=0x738c194a]
Mon Nov 1 02:52:09 2021 daemon.debug pppd[19994]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Mon Nov 1 02:52:09 2021 daemon.debug pppd[19994]: sent [IPV6CP ConfReq id=0x1 ]
Mon Nov 1 02:52:09 2021 daemon.debug pppd[19994]: rcvd [LCP DiscReq id=0x80 magic=0x1979b4b2]
Mon Nov 1 02:52:09 2021 daemon.debug pppd[19994]: rcvd [LCP EchoRep id=0x0 magic=0x1979b4b2 73 8c 19 4a]
Mon Nov 1 02:52:10 2021 daemon.debug pppd[19994]: rcvd [IPCP ConfReq id=0x0]
Mon Nov 1 02:52:10 2021 daemon.debug pppd[19994]: sent [IPCP ConfNak id=0x0 <addr 0.0.0.0>]
Mon Nov 1 02:52:10 2021 daemon.debug pppd[19994]: rcvd [IPCP ConfNak id=0x1 <addr 100.76.27.225> <ms-dns1 198.224.166.135> <ms-dns2 198.224.167.135>]
Mon Nov 1 02:52:10 2021 daemon.debug pppd[19994]: sent [IPCP ConfReq id=0x2 <addr 100.76.27.225> <ms-dns1 198.224.166.135> <ms-dns2 198.224.167.135>]
Mon Nov 1 02:52:10 2021 daemon.debug pppd[19994]: rcvd [IPCP ConfReq id=0x1]
Mon Nov 1 02:52:10 2021 daemon.debug pppd[19994]: sent [IPCP ConfAck id=0x1]
Mon Nov 1 02:52:10 2021 daemon.debug pppd[19994]: rcvd [IPCP ConfAck id=0x2 <addr 100.76.27.225> <ms-dns1 198.224.166.135> <ms-dns2 198.224.167.135>]
Mon Nov 1 02:52:10 2021 daemon.warn pppd[19994]: Could not determine remote IP address: defaulting to 10.64.64.64
Mon Nov 1 02:52:10 2021 daemon.notice pppd[19994]: local IP address 100.76.27.225
Mon Nov 1 02:52:10 2021 daemon.notice pppd[19994]: remote IP address 10.64.64.64
Mon Nov 1 02:52:10 2021 daemon.notice pppd[19994]: primary DNS address 198.224.166.135
Mon Nov 1 02:52:10 2021 daemon.notice pppd[19994]: secondary DNS address 198.224.167.135
Mon Nov 1 02:52:10 2021 daemon.debug pppd[19994]: Script /lib/netifd/ppp-up started (pid 20123)
Mon Nov 1 02:52:10 2021 daemon.notice netifd: Network device ‘3g-wwan’ link is up
Mon Nov 1 02:52:10 2021 daemon.notice netifd: Interface ‘wwan’ is now up

Usually, I would conclude, that there is bad radio connection. But I have other, identical devices, in the same location, which work without problems.

2

Hello there
Please check whether your antenna is connect well and make sure your network environment is good enough or you can retry in other place, The CSQ return 14 means the network environment is not well, thank you.

3

HI
Please burn the latest version and try again. A version will be emailed to you, thank you.

4

Unfortunately, I did not get anything. Problem still pending. Pls, send newest firmware, as promised.

5

Update: I have another set of devices, having EC25-V with firmware
EC25VFAR02A13M4G
These devices work with Verizon, using QMI.
So, I modified my non-working devices, having EC25-V with firmware
EC25VFAR02A14M4G
to use QMI, too, and now they still do not work, but give the following error on openwrt:
Wed Oct 26 07:13:41 2022 daemon.notice netifd: wwan (3348): Waiting for SIM initialization
Wed Oct 26 07:13:41 2022 daemon.notice netifd: wwan (3348): Failed to parse message data
Wed Oct 26 07:13:41 2022 daemon.notice netifd: wwan (3348): PIN verification is disabled
Wed Oct 26 07:13:42 2022 daemon.notice netifd: wwan (3348): Device does not support 802.3 mode. Informing driver of raw-ip only for wwan0 …
Wed Oct 26 07:13:42 2022 daemon.notice netifd: wwan (3348): Waiting for network registration
Wed Oct 26 07:13:54 2022 daemon.notice netifd: wwan (3348): Network registration failed, registration timeout reached

Any ideas ?

6

Still having not received the promised most recent firmware for our EC25-V, this is going to be a serious problem. Because Verizon will stop 3g (PPP) support end of this year, and only doing LTE, we are left in the dust with all devices (openwrt-routers), having EC25-V installed, to be “out of service”. Because on most of them QMI does not work. Pls, provide most recent firmware for the EC25-V ASAP.