GL-X750 (v1) Quectel EC25-AF: IPv6/4

Weird behavior: Somewhat continued from the earlier thread, but not directly related (where the modem was accidentally issued the command AT+QCFG="usbauto",1 which turned the Quectel board into a headless, inaccessible RNDIS adapter).

Now, we are back to where the board is accessible. I can access /dev/ttyUSB2 and send it AT commands. I continue to have the FTDI USB-to-TTY 3.3v adapter hardwired into the Quectel board, just in case it decides to nuke itself again (shut off access to /dev/ttyUSBx).

I have tried: The 4.0x firmware from GLiNet. The latest release of Openwrt 23.5.04. The latest ROOter firmware (a fork of Openwrt that focuses more on Modem options, on routers that have 4G/5G connectivity).

Every time, I have chosen to not keep settings, so it should be like 'new', or 'blank slate' or 'default configuration'.

The symptom I have been having, is the connectivity became flaky. That is what started me on this path. See previous thread.

Now, the consistent issue, is oftentimes, after a flash of the GL-X750, the modem connection comes up as IPv4 only. Sometimes it comes up as IPv6 only. But it won't do both. And there doesn't seem to be consistency. I would like to know if there is some ATxxx command that will reset the Quectel board to 'default'. But according to Quectel support, on their forum, the method to reset the device completely, is not something made available outside of their company. Except for mild changes to the AT settings, such as settling on AT+QCFG="usbnet",2 (MBIM) as my preferred method of communication, I cannot consistently get a new flash to the GL-X750 to work in both IPv4 and IPv6 mode, even though the provider supports both.

AT+CGPIAF=1,1,1,0
OK
AT+CGCONTRDP
+CGCONTRDP: 1,5,vzwinternet,100.99.21.72,2600:1016:B156:E975:0000:0034:00B4:3501, FE80:0000:0000:0000:0000:0034:00B4:3540,198.224.150.135 2001:4888:003B:FF00:03C2:000D:0000:0000,198.224.151.135 2001:4888:0032:FF00:03C1:000D:0000:0000

OK

That shows that the modem is being issued an IPv4 address, and an IPv6 address. But, on the ROOter firmware it's on now, (similar to the GLiNet or Openwrt), it displays:

IPv4 Upstream

Protocol: MBIM Cellular
Address: 100.99.21.72/32
Gateway: 0.0.0.0
DNS 1: 198.224.150.135
DNS 2: 198.224.151.135
Connected: 0h 18m 18s

Ethernet Adapter: "wwan0"
MAC address: C2:5F:57:B1:C8:41

And no IPv6 information. Even though previously, within the last 24 hrs, on my first attempted flash of the ROOter firmware, it was showing only IPv6 information, and only 'pings' to ipv6 sites were working.

Pings to ipv4 sites work, but not ipv6. This is from inside a terminal (ssh) connection at the GL-X750 router.

There's some kind of communication disconnect, between the Quectel modem and the GL-X750, where the GL-X750 is not properly pulling the IPv4 and IPv6 information from the Quectel.

Any questions now?

1 Like

Thank you for following-up.

The only cause i can find, of very similar or the same behavior, is through using another piece of equipment. The LBR20, with it's EG18-NA - when it's LED activity light is set to flash according to receive/send activity of wwan0, it causes the same issue.

There is some hardware signalling/interaction between the LED activity and the modem, that generates some noise, that causes disconnect. It does not do that on the default 'heartbeat', which is a regular pulse.

I discovered the cause of the issue, only after pulling the SIM out of the EC25-AF, and using it in the LBR20. To go back to testing it in the GL-X750, I would need an active sim on the same provider, ideally, so the conditions are as identical as possible. I do not have an extra active SIM on that provider, currently, to test with. Or the time.

You see the light on the 750 sometimes not working?

I don't think you understand what I said: The GL-X750 when programmed to flash the 4G LTE activity LED on receive/transmit of the wwan0 interface, may have the same hardware issue that I could positively identify on the LBR20.

I no longer at this time, have a spare active SIM to test the theory on the GL-X750. It had very similar / same symptoms, though.

I still don't understand what phenomenon you're talking about
I still can't replicate that disconnect you're talking about
sorry