OpenWrt/LEDE Project

  • Status Unconfirmed
  • Percent Complete
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity Medium
  • Priority Very Low
  • Reported Version Trunk
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Evren Yurtesen - 14.02.2018

FS#1363 - QMI does not use correct APN

I get 4G service from a provider which provide public IP if APN of “opengate” is used. I found out that does not set the card correctly. The `–autoconnect` setting seems to be the cause. (Also maybe related: )

I replaced in my “–autoconnect” with “–set-autoconnect enabled” in lines where “–start-network” is used.

Seems to do the trick. However “–stop-network” requires “–autoconnect” to be present or I get errors.


root@OpenWrt:/# uqmi -s -d /dev/cdc-wdm0 --set-client-id wds,19  --stop-network 0xffffffff --autoconnect
root@OpenWrt:/# uqmi -s -d /dev/cdc-wdm0 --get-current-settings
"Out of call"
root@OpenWrt:/# uqmi -s -d /dev/cdc-wdm0 --set-client-id wds,19 --start-network --apn opengate --autoconnect
root@OpenWrt:/# uqmi -s -d /dev/cdc-wdm0 --get-current-settings
root@OpenWrt:/# uqmi -s -d /dev/cdc-wdm0 --set-client-id wds,19  --stop-network 0xffffffff --autoconnect
root@OpenWrt:/# uqmi -s -d /dev/cdc-wdm0 --get-current-settings
"Out of call"
root@OpenWrt:/# uqmi -s -d /dev/cdc-wdm0 --set-client-id wds,19 --start-network --apn opengate
root@OpenWrt:/# uqmi -s -d /dev/cdc-wdm0 --get-current-settings
root@OpenWrt:/# uqmi -s -d /dev/cdc-wdm0 --set-client-id wds,19  --stop-network 0xffffffff --autoconnect
root@OpenWrt:/# uqmi -s -d /dev/cdc-wdm0 --get-current-settings
"Out of call"
root@OpenWrt:/# uqmi -s -d /dev/cdc-wdm0 --set-client-id wds,19 --start-network --apn opengate --set-autoconnect enabled
root@OpenWrt:/# uqmi -s -d /dev/cdc-wdm0 --get-current-settings
Project Manager
Koen Vandeputte commented on 15.02.2018 11:14


I was able to simulate this behavior and will investigate it further.


Project Manager
Koen Vandeputte commented on 16.02.2018 09:19


1 more question:

uqmi -s -d /dev/cdc-wdm0 --set-client-id wds,19 --start-network --apn opengate --autoconnect
"ip":""  "gateway":""

uqmi -s -d /dev/cdc-wdm0 --set-client-id wds,19 --start-network --apn opengate
"ip":""   "gateway":""

uqmi -s -d /dev/cdc-wdm0 --set-client-id wds,19 --start-network --apn opengate --set-autoconnect enabled
"ip":""   "gateway":""

I notice you get *3* different IP's and gateway's using the same APN.
Any idea why?

Could you test both APN's by just leaving "set-autoconnect" and "–autoconnect" out?

I've done some more testing here, and just leaving "–autoconnect" out seems to wield the same results.



Evren Yurtesen commented on 28.03.2018 00:17

Koen, the reason is that everytime I connect, I get different IP. So everytime I disconnect and try a different parameter set, I get new IP.

My provider give public IP address if APN `opengate` is used, give private IP address if `internet` (or perhaps any string) used.

So you quoted 3 lines.
1- I use `opengate` and `–autoconnect` and I still get private IP. (fail)
2- I use `opengate` but NO `–autoconnect` then I get public IP (pass)
3- I use `opengate` but NO `–autoconnect` instead `–set-autoconnect enabled` and I get public IP (pass)

The reason for 3 different IP addresses is that my provider give addresses from a pool and everytime I connect, I get different IP. My public IP service is not with static IP.

If I use `internet` (or perhaps any string) as APN, I get private IP, this is the default situation so I am not sure what it may prove to make tests with anything else than `opengate`. Because as long as I do not use `opengate` I get a private IP, so I won't see any changes whether the APN I set is used or not.

The only workaround I found was to leave `–autoconnect` out and later use `–set-autoconnect enabled` Perhaps it is a bug with uqmi.

dchard commented on 05.05.2018 13:53

I can confirm this behavior.

I have a Quectel EC25 modem and in QMI mode it is not applying the APN set in the luci-protocol-qmi app. No matter what APN I set on the webui, the modem sends the default APN it was programmed in the factory ("3gnet" in my case).

I also have a small LTE test network at my disposal, so I also checked the core network, where it is clear that the modem tries to activate the default EPS bearer with APN=3gnet, while I already set "internet", also tried with "static" and "" (empty string where the modem should not send a requested APN during the attach procedure).

Another way to confirm this without a core network:

1. Set whatever APN in the luci-protocol-qmi app.
2. Open minicom and query the PDN profiles with:
3. If the APN set on the luci-protocol-qmi is not matching the APN in the above query, the APN will be used is the one seen with AT+CGDCONT?

If I manually set the APN with AT+CGDCONT, then the QMI mode connection will use that APN instead of the one the user gives on the luci interface.

To elaborate why this problem is not so obvious and not affecting a lot of people:

During the default PDN activation - at least on LTE - the core network requests the subscribed profile from the HSS, and if the requested APN is not matching the "subscribed" APN, then the core network will in most cases activate the data connection with the default subscribed APn no matter what the modem requests, therefor the user will have internet.

The problem is visible when an operator allows multiple APNs like in the above example: public IP, NAT-ed, but even corporate can be part of this, so the user must specify the APN for these non-default cases.

I did not tried the above mentioned fix, I will on next monday.

None the less this is a serious issue that in QMI mode the APN setting is not applied.

I am using latest master for ar71xx for GL-MIFI and the kernel is 4.9.96.

I am more than happy to test any future fixes/patches to help fix this as soon as possible. In case needed, I can provide core network traces.

dchard commented on 05.05.2018 14:52

I tested the fix recommended by Evren on my home KPN NL connection and it is a partial success:

1. If I apply the recommended patch and I want to key in specific APN, that is now activated and the connection is set up, and it does not matter what AT+CGDCONT? shows.

2. However when I want to activate the default APN where the APN string is empty, that still does not work. I suspect in this case it is again the AT+CGDCONT value which gets activated (incorrectly), but I can only check this on monday.

dchard commented on 17.05.2018 11:35

Ok, I tested this patch in an outage situation, and I can confirm the modem is not connecting back to the network when this patch is apllied, so this is not a solution.

The trick is that the modem attaches, so if you ping the modem IP from external sources, you will get a reply, but on the router there is no internet and UQMI also repsonds with "Out of call". The annoying part is in this case the wwan interface is still up.

It fixes the APN issue (partially), but creates another (bigger) issue.

Evren Yurtesen commented on 16.11.2018 01:43

@dchard it may be that the issue is related to some other things also. See the bug report

I need to use a different APN so I had to remove autoconnect from my script I just run a script in background which checks connectivity and restarts modem if something is wrong. See the ticket I linked, I provided the script.


Available keyboard shortcuts


Task Details

Task Editing