GL-E750 beta 4.0 0804beta2: empty APN is not persisted by UI, but works if manually added to /etc/config/glmodem

Device:
GL-E750

Firmware:
Version 4.0
Firmware Type 0804beta2
Update Time 2026-03-27 03:17:30 UTC

Summary:
I am using a Free SIM from a pocket WiFi device.
For this SIM, the cellular connection only works when the APN is left empty.
In the GL.iNet web UI, I can temporarily clear the APN and the connection works.
However, after some hours, or after the system re-applies modem/network settings, an APN name is restored automatically and the connection becomes unstable or stops working correctly.

What I found:

  1. The modem itself accepts an empty APN on the main PDP context.
  2. `AT+CGDCONT?` shows:
    +CGDCONT: 1,"IPV4V6",""
    +CGDCONT: 2,"IPV4V6","ims"
    +CGDCONT: 3,"IPV4V6","sos"

This suggests the modem-side working configuration is really an empty APN for context 1.

Problem in GL.iNet layer:
In `/etc/config/glmodem`, when APN is cleared from the UI, no `option apn` is stored for the SIM section.
Using:
`uci set glmodem.@sim[0].apn=''`
followed by:
`uci commit glmodem`
does not persist the option either.

Workaround:
If I manually edit `/etc/config/glmodem` and add:
`option apn ''`
inside the active SIM section, the setting survives reboot and the 4G connection comes back correctly after reboot.

Example active config:
config sim '8933150224012917678F'
option proto 'qmi'
option device '/dev/cdc-wdm0'
option node '1-1.2:1.4'
option ip_type 'IPV4V6'
option auth 'NONE'
option apn ''
option roaming '1'
option band_enable '0'

Observed behavior:

  • Empty APN works at modem level
  • Empty APN is not properly persisted by the UI/UCI flow
  • Manual insertion of `option apn ''` in `/etc/config/glmodem` works

Expected behavior:
If the APN field is intentionally left empty in the UI, GL.iNet firmware should persist this as an explicit empty APN for the SIM profile, instead of treating it like no saved APN / auto-detection.

This looks like a GL.iNet configuration persistence bug, not a modem or carrier issue, because the modem accepts the empty APN and the connection works when option apn '' is explicitly present in /etc/config/glmodem.

Hello,
The command AT+CGDCONT? queries the APN configured on the GUI. If you haven't manually changed the APN config, it is normal for AT+CGDCONT? to return empty. The device will connect to the network via auto setup mode in this case.

AT+CGCONTRDP can be used to check the actual APN used by the router. It is recommended that you manually enter the obtained APN config into the router to see if it can successfully connect to the network.

Hello Cathy,

Thank you for the clarification.

I checked with AT+CGCONTRDP and it indeed showed that the actual APN used by the router was mifi.

I then manually configured mifi in the GL.iNet UI, and the connection works correctly. The configuration is now properly stored in /etc/config/glmodem as:

config sim '8933150224012917678F'
option proto 'qmi'
option device '/dev/cdc-wdm0'
option node '1-1.2:1.4'
option apn 'mifi'
option ip_type 'IPV4V6'
option auth 'NONE'
option roaming '1'
option band_enable '0'

So this solves the issue for me.

My confusion came from the fact that:

  1. leaving the APN field empty allowed the router to connect,
  2. AT+CGDCONT? showed an empty APN on the main context,
  3. an empty APN could also be manually injected into /etc/config/glmodem and still worked.

Because of that, it looked like an empty APN was the required configuration, while in reality the router was using auto setup mode and the effective APN was mifi.

So the issue is not a connectivity bug anymore, but I still think the current behavior is a bit misleading for troubleshooting.
It would be helpful if, when auto setup mode is used, the UI made it clearer that:

  • the APN is being auto-detected
  • and possibly what APN was actually selected

That would make diagnosis much easier.

Thanks again.

Glad to know it works. And thanks for your suggestion. We will verify it and consider your suggestion.