Problem using an APN with 4G not available

Paul Bartell p.bartell at
Sat Nov 7 22:18:04 UTC 2020


I’ve encountered a similar problem with a Quectel EC25 (and Telit LE910C4-NF) modem where a custom apn was only allowed to connect on LTE as the default EPS bearer. Without changing the default eps bearer apn setting to match the custom apn, the modem fails to register on the network and falls back to 3G.

You might try modifying the APN setting of the default EPS bearer with qmicli wds-modify-profile (usually the first profile) and checking if you can connect to LTE that way.

You might also try using a blank apn setting in profile #1 if your modem has a carrier profile with a default bearer apn set. Setting this value to an empty string will cause the modem to use the network provided apn setting.

Hope this helps,

> On Nov 7, 2020, at 1:21 PM, Giovanni Parodi <giovanniparodi79 at> wrote:
> Thank you, you are right, I verified today.
> There are 2 different reply from APN: “unsubscribed option” when I use a SIM that doesn’t support LTE option (didn’t pay for it) or “unknown-apn” when the sim could connect to lte, but the APN doesn’t support it. I should support it downgrading connectivity to umts|gsm and everything works fine.
> Stupid error from my side, I was sure there should be an automatic downgrading to LTE as it happens when you have a not powerful enough signal, but this a different issue, and it should be managed by the SW developer. Thank you for your great help
> Il giorno sab 7 nov 2020 alle 17:59 Aleksander Morgado <aleksander at> ha scritto:
> Hey,
> > Good morning, I'm a user of libqmi and qmicli tool and I need some help.
> > I'm using a SIM of an Italian provider (TIM), configured on a standard private APN (the SIM and APN are of a customer of my company, he pays for a custom APN to the TIM company).
> >
> > When using the standard public APN (, with a modem that supports LTE connectivity (Quectel EC25), I can go online and get a connection to the network.
> > If I configure the custom private APN (that uses the same network infrastructure), I'm able to connect to the (private) network and to go online, pinging the private customer server, only if a set the modem as 3G using the command line:
> >
> > qmicli -d /dev/cdc-wdm0 --nas-set-system-selection-preference="umts|gsm"
> >
> >
> > If I configure the SIM as:
> >
> > qmicli -d /dev/cdc-wdm0 --nas-set-system-selection-preference="lte|umts|gsm"
> >
> >
> > I receive the error:
> >
> > <<<<<<   type       = "Call End Reason" (0x10)
> > <<<<<<   length     = 2
> > <<<<<<   value      = F5:03
> > <<<<<<   translated = gsm-wcdma-unknown-apn
> > <<<<<< TLV:
> > <<<<<<   type       = "Verbose Call End Reason" (0x11)
> > <<<<<<   length     = 4
> > <<<<<<   value      = 06:00:1B:00
> > <<<<<<   translated = [ type = '3gpp' reason = '27' ]
> >
> >
> > Here is my problem: if I use the SIM in a smartphone, the smartphone fails connection in lte mode but after a few seconds (about 30) goes to UMTS mode and gets its address.
> > My problem is that, even if I select to support umts,LTE,GSM, when the modem tries connecting, it tells me unknown-apn, and does not switch to UMTS connectivity option.
> > If I use 3G mode, everything works fine.
> > So here is my question: how should I manage this kind of problem?
> > How can I force qmicli to manage switching at connection time different mode search of APN?
> If you know in advance that you're going to hit the situation, I
> assume you could run the qmicli commands to prefer (or even limit) 3G
> depending on the specific APN to use? Or, otherwise, just assume that
> if you ever get the "gsm-wcdma-unknown-apn" call end reason you should
> think of falling back manually to 3G and retrying.
> > I know this may be a simple issue for expert people, but I'm really confused.
> I am no expert on the inner LTE stack details, so I cannot comment
> much more I'm afraid. This could also be a lack of planning in the
> operator side, for what it's worth; i.e. why does the APN get reported
> as unknown when using the LTE infrastructure? Is that a known
> limitation of that APN?
> -- 
> Aleksander
> _______________________________________________
> libqmi-devel mailing list
> libqmi-devel at

More information about the libqmi-devel mailing list