This continues from https://forum.gl-inet.com/t/gl-x750-v1-quectel-ec25-af-ipv6-4/
but as the topic is locked from 180-day imposed expiration, I am opening a new thread:
The last thing I said was: 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.
To which you replied: @ywp I still don't understand what phenomenon you're talking about. I still can't replicate that disconnect you're talking about. sorry.
To replicate: Tell your LTE activity LED to flash on receive/transmit. Not heartbeat, but on NETWORK DEVICE ACTIVITY, use(check the) TRANSMIT and RECEIVE. The simultaneous activity of the LED with actual packet traffic, generates so much hardware noise, that the quectel cell connection crashes. It's not really an issue with your GLiNet hardware, but probably an issue inside the quectel modem, with being too vulnerable to electrical noise. If you set the LTE LED to simply turn-on, or regularly heartbeat on LINK ON, the issue does not occur. And since that is the default for the layered GLiNET interface on top of Openwrt, you probably don't see too many issues about what i was pointing you towards.
The other issue: I could open another topic, but this also deals with what seems like another stability flaw in the quectel chips, and I'm interested in any workaround you have:
If I use the plain QMI interface, not ModemManager or MBIM (I do not recall what kind of method your layered GLiNet interface picks, I am only recalling from using straight released 'plain' Openwrt, which also defaults to plain QMI);
The plain QMI protocol does not auto-detect, or consequently, set the MTU. MTU can however, be manually set, in the Advanced preferences, either through the Interfaces tab or Devices tab. MBIM does autodetect and set, as does ModemManager.
In any case, when the MTU is set (lower than 1500), which the connection is awesome, smooth and functions well, it only does that for 2 minutes. Then the quectel chip crashes. It crashes/locks up, so badly, that only a power-off reboot brings it back up. Serial communication over /dev/ttyUSB2 no longer works, either. I have had this problem on the GLiNet GL-X750, and another device not manufactured by you, with a different Quectel chip. And it is repeatable on both. I have not found a solution. So whatever solution you have on the GLiNet device, I would like to know! Thanks.