Hardware: GL-E750; latest GL-Inet firmware flashed via U-Boot.
Original modem: EC25-AF FA (apparently for North America)
Replacement modem: Different EC-25 (works in Europe)
Carrier: APN: "internet", Auth: NONE
Issue: PPP connection establishes but fails at IPCP negotiation
Background
I replaced the original EC25-AF FA modem in my GL-E750 with a different EC-25 variant, which works in Europe I have used that modem for years in Kiwi Wifi router running OpenWRT. The SIM card I am trying now works perfectly in phones.
SIM doesn't require a PIN.
When using Web UI, in case of choosing QMI, /dev/cdc-wdm0, APN, the UI shows ping message which states "Connecting..." forever.
In case of using '3G', and choosing any port: /dev/ttyUSB{0, 1, 3} or /dev/cdc-wdm0, same result. Tried disabling band and roaming in UI.
It is interesting that modem responds to AT commands vie /dev/ttyUSB2, while UI doesn't show that port.
So at some point I decided to dig in that direction, and started editing /etc/config/network by hand, explicitly mentioning ttyUSB2 as modem.
This way was hard and long but I guess I was able to pass some challenges.
Configuration
Edited part in /etc/config/network:
config interface 'modem_1_1_2'
option service 'LTE/UMTS/GPRS'
option apn 'internet'
option proto '3g'
option node '1-1.2:1.3'
option auth 'NONE'
option metric '40'
option band_enable '0'
option disabled '0'
option device '/dev/ttyUSB2'
option roaming '0'
option ipv6 '0'
option dialnumber '*99#'
Current Status
After extensive troubleshooting:
What Works Now:
- Modem is detected and responds to AT commands
- PPP connection establishes successfully (
Serial connection established) - Chat script completes with correct APN and dial number (*99#)
- Interface
3g-modem_1_1_2is created with traffic flowing (TX/RX packets)
What Doesn't Work:
- IPCP negotiation consistently times out (
IPCP: timeout sending Config-Requests) - Connection terminated after ~30-40 seconds
- No IP address assigned to interface
Modifications Made:
-
Fixed GL.iNet AT command incompatibilities - Disabled problematic functions in
/lib/functions/modem.sh:modem_AT_set_roaming()modem_AT_set_band()modem_AT_lock_cell_tower()
These were sending Quectel-specific commands (
AT+QNWPREFCFG,AT+QNWCFG, etc.) that the replacement modem doesn't support. -
PPP echo parameter adjustments - Added to
/lib/netifd/proto/3g.sh:lcp-echo-interval 0 lcp-echo-failure 0This eliminated the "No response to 5 echo-requests" errors.
-
Protocol attempts: Tried both QMI (
/dev/cdc-wdm0) and 3G (/dev/ttyUSB2). 3G gets much further in the connection process.
Current Configuration
network.modem_1_1_2.service='LTE/UMTS/GPRS'
network.modem_1_1_2.apn='internet'
network.modem_1_1_2.proto='3g'
network.modem_1_1_2.device='/dev/ttyUSB2'
network.modem_1_1_2.auth='NONE'
network.modem_1_1_2.dialnumber='*99#'
network.modem_1_1_2.ipv6='0'
Questions
-
Modem variant compatibility: Are there known differences between EC-25 variants that could affect IPCP negotiation with specific carriers?
-
IPCP timeout resolution: The carrier (Armenian Ucom) appears to not respond to standard IPCP Config-Requests. Are there alternative PPP parameters or initialization sequences that might work?
-
GL.iNet specific: Does the GL-E750 firmware have carrier-specific profiles or timeouts that might need adjustment for Armenian networks?
The fact that this exact configuration worked with the other modem suggests either:
- Hardware-level differences between EC-25 variants
- Carrier network changes since the original setup
- Missing initialization that was specific to the original modem
Any insights on EC-25 variant differences or alternative approaches for stubborn IPCP negotiation would be appreciated.
Logs
PPP establishes successfully but fails at IP assignment:
pppd[X]: Serial connection established.
pppd[X]: Connect: 3g-modem_1_1_2 <--> /dev/ttyUSB2
[30 seconds later]
pppd[X]: IPCP: timeout sending Config-Requests
netifd: Interface 'modem_1_1_2' is now down
P. S. other time, several days ago, before several reflashes, I was able to make the modem connect, no idea how. Perhaps I was sending it some AT commands, and though it didn't help, but after reboot it somehow helped.
However I stumbled upon another problem: my carrier would route to Cloudflare, but would not route to Google and most of the world. It would also route to my own server with real static IP hosted in my house.
But that state is long gone. I didn't troubleshoot as hard as this time, and I used QMI, not 3g. Now I am not able to use QMI and connect.