Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#1363 - QMI does not use correct APN #6295

Open
openwrt-bot opened this issue Feb 14, 2018 · 7 comments
Open

FS#1363 - QMI does not use correct APN #6295

openwrt-bot opened this issue Feb 14, 2018 · 7 comments
Labels

Comments

@openwrt-bot
Copy link

@openwrt-bot openwrt-bot commented Feb 14, 2018

yurtesen:

I get 4G service from a provider which provide public IP if APN of "opengate" is used. I found out that qmi.sh does not set the card correctly. The --autoconnect setting seems to be the cause. (Also maybe related: https://forum.openwrt.org/viewtopic.php?pid=372211 )

I replaced in my qmi.sh "--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.

See:

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
-2020095904
root@OpenWrt:/# uqmi -s -d /dev/cdc-wdm0 --get-current-settings
{"pdp-type":"ipv4","ip-family":"ipv4","mtu":1500,"ipv4":{"ip":"100.69.24.116","dns1":"192.89.123.230","dns2":"192.89.123.231","gateway":"100.69.24.117","subnet":"255.255.255.248"},"ipv6":{},"domain-names":{}}
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
-2020095904
root@OpenWrt:/# uqmi -s -d /dev/cdc-wdm0 --get-current-settings
{"pdp-type":"ipv4","ip-family":"ipv4","mtu":1500,"ipv4":{"ip":"46.132.191.50","dns1":"192.89.123.230","dns2":"192.89.123.231","gateway":"46.132.191.49","subnet":"255.255.255.252"},"ipv6":{},"domain-names":{}}
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
-2020095904
root@OpenWrt:/# uqmi -s -d /dev/cdc-wdm0 --get-current-settings
{"pdp-type":"ipv4","ip-family":"ipv4","mtu":1500,"ipv4":{"ip":"194.251.18.231","dns1":"192.89.123.230","dns2":"192.89.123.231","gateway":"194.251.18.232","subnet":"255.255.255.240"},"ipv6":{},"domain-names":{}}

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Feb 15, 2018

xback:

Hi,

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

Koen

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Feb 16, 2018

xback:

Hi,

1 more question:

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

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

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

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.

Thanks,

Koen

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Mar 28, 2018

yurtesen:

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.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented May 5, 2018

dchard:

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:
    AT+CGDCONT?
  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.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented May 5, 2018

dchard:

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.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented May 17, 2018

dchard:

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.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Nov 16, 2018

yurtesen:

@dchard it may be that the issue is related to some other things also. See the bug report https://bugs.openwrt.org/index.php?do=details&task_id=1252

I need to use a different APN so I had to remove autoconnect from my qmi.sh 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant