Skip to content

Adding atc-apn-database for automatic APN detection. - #14

Open
SuperKali wants to merge 3 commits into
mrhaav:mainfrom
SuperKali:main
Open

Adding atc-apn-database for automatic APN detection.#14
SuperKali wants to merge 3 commits into
mrhaav:mainfrom
SuperKali:main

Conversation

@SuperKali

@SuperKali SuperKali commented May 20, 2025

Copy link
Copy Markdown
  • Bump atc-fib-fm350_gl and added support to APN autodetection
  • Bump luci-proto-atc and added support to APN autodetection

Mention #12

- Bump atc-fib-fm350_gl and added support to APN autodetection
- Bump luci-proto-atc and added support to APN autodetection
Comment thread atc-apn-database/Makefile
Comment thread atc-apn-database/Makefile
@raenye

raenye commented May 20, 2025

Copy link
Copy Markdown

Would changing active SIM (via AT+DUALSIM=1) cause the script to re-evaluate the APN?

@SuperKali

Copy link
Copy Markdown
Author

Would changing active SIM (via AT+DUALSIM=1) cause the script to re-evaluate the APN?

In practice it should, then knowing the fibocom you may have to restart it but I’m not sure.

At each reconnection, the check is performed again.

@mrhaav

mrhaav commented May 23, 2025

Copy link
Copy Markdown
Owner

Hi

Some thoughts:

Since this is an add on I would like to keep the changes in atc.sh to a minimum.

I don´t understand the need for detect_and_set_apn(). Can you, please, elaborate?
If auto_apn is chosen, then just set all apn parameters from the databas.

In current implementation you first run
# Auto profile discovery
and then
# Configure PDPcontext, initial profile and profile 1
isn´t one enough?

Why do we need check the apn setting after a network initiated disconnection?
The modem will use the current settings. Have you seen any scenario where the apn settings had been changed?

Do you have an example of the database file?
Could the pdp-type (IPversion) be included?
Is it required to include the name of the provider to get the correct APN settings?
Why create a json file if you don´t read it with a json parser?

BTW, a lots of ISPs allow you to use an empty APN and then the ISP will use the default APN and set it to you.

@SuperKali

Copy link
Copy Markdown
Author

Hi,

Thanks for taking the time to review this! You made some really good points and I want to make sure I understand exactly what you have in mind before I start changing things.

About the database format - the Android source is XML, and I initially tried converting it to JSON thinking I could use jsonfilter to parse it properly. But I ran into some issues getting jsonfilter to work correctly with the nested structure, so I ended up using grep/sed instead. You're absolutely right though - if I'm not using a proper JSON parser, the format is overkill. Would a simple format like 222_01:ibox.tim.it work better? Or maybe something else you have in mind?

For the code organization, I'm not sure what fits best with the project style. Should I just add a small function in atc.sh that reads the database, or would you prefer keeping it completely separate? I could make it really minimal if that's better.

You mentioned that many ISPs work with empty APNs - that's a good point I hadn't considered. Should we maybe try empty first and only look up the database if that fails? Or the other way around?

Also, when auto_apn is enabled, should it completely override what the user configured, or only fill in the blanks if they didn't set an APN?

Honestly, I'm flexible on all of this - I just want to contribute something useful that fits well with how you maintain the project. If you could give me a rough idea of how you'd approach it, I'll follow that direction.

What do you think?

@raenye

raenye commented May 23, 2025

Copy link
Copy Markdown

Finally I got to trying the new package today.
At first it didn't work, and the relevant log message was "No APN found in database for MCC:SIM MNC:IMSI".
Examining the script some more, I think the problem is the following line in atc.sh:

 [ "$atc_debug" -ge 1 ] && echo "SIM IMSI: $imsi, MCC: $mcc, MNC: $mnc, MNC length: $mnc_length"

which overrides the return value of get_mcc_mnc.
When I comment out option atc_debug '2' in /etc/config/network/ it works fine.

Maybe it is better to go back to the way it was done in the earlier commit (9aadc6c):

[ "$atc_debug" -ge 1 ] && logger -t atc "SIM IMSI: $imsi, MCC: $mcc, MNC: $mnc, MNC length: $mnc_length"

the Android source is XML

Two typical entries:

  <apn carrier="Lycamobile"
      carrier_id = "2152"
      mcc="234"
      mnc="26"
      apn="data.lycamobile.co.uk"
      authtype="1"
      user="lmuk"
      password="plus"
      mvno_type="spn"
      mvno_match_data="Lycamobile"
      type="default,ia,supl"
  />

  <apn carrier="docomo"
      mcc="440"
      mnc="10"
      apn="spmode.ne.jp"
      type="default,ia,supl"
      authtype="0"
      protocol="IPV4V6"
  />

As you can see, protocol/roaming_protocol are not always specified.

Would a simple format like 222_01:ibox.tim.it work better? Or maybe something else you have in mind?

The problem I see is that it wouldn't work for entries with positive authtype.

Why do we need check the apn setting after a network initiated disconnection?

Let's say the USIM is changed (by switching to the other sim via AT+GTDUALSIM=x, by physically removing the SIM card and inserting another, or by activating a different e-SIM profile). Ideally the modem would just pick up the new APN without forcing the user to edit /etc/config/network.

BTW, a lots of ISPs allow you to use an empty APN and then the ISP will use the default APN and set it to you.

Definitely not all of them.

Should we maybe try empty first and only look up the database if that fails? Or the other way around?

If the database entry works too, and you already have the code to query it, why not?

@mrhaav

mrhaav commented May 26, 2025

Copy link
Copy Markdown
Owner

You can parse the database with jsonfilter.

Some entities are not correct. Which type are you copying, default?
If protocol is available then I think it´s good to add that to the database. If it´s not available then we will use IPv4.

Two incorrect profiles:

root@OpenWrt:/etc/atc# jsonfilter -i apn_database.json -e '@["240_02"]'
{ "apn": "services", "carrier": "3 Ut" }

Should be this profile:

  <apn carrier="3"
      carrier_id = "1691"
      mcc="240"
      mnc="02"
      apn="data.tre.se"
      mmsc="http://mms.tre.se"
      mmsproxy="mmsproxy.tre.se"
      mmsport="8799"
      type="default,ia,supl,mms"
      protocol="IPV4V6"
      roaming_protocol="IPV4V6"
      network_type_bitmask="1|2|3|4|5|6|7|8|9|10|12|13|14|15|17|20"
  />

and

root@OpenWrt:/etc/atc# jsonfilter -i apn_database.json -e '@["240_07"]'
{ "apn": "internet.tele2.no", "auth": "1", "carrier": "Tele2 Internet", "password": "wap", "username": "wap" }

Should be this profile:

  <apn carrier="Tele2 Internet"
      carrier_id = "1696"
      mcc="240"
      mnc="07"
      apn="internet.tele2.se"
      type="default,ia,supl,mms"
      mmsc="http://mmsc.tele2.se"
      mmsproxy="mmsproxy.tele2.se"
      mmsport="8080"
      protocol="IPV4V6"
      roaming_protocol="IPV4V6"
  />

@raenye

raenye commented May 27, 2025

Copy link
Copy Markdown

incorrect profiles

Do you mean that for this MCC-MNC combination the original XML contains multiple entries (e.g., due to MVNOs), and the wrong one was selected to be included in the JSON file?

@mrhaav

mrhaav commented May 27, 2025

Copy link
Copy Markdown
Owner

Regarding "240_02", there are no MVNOs. I don´t understand why carrier="3 Ut" was chosen. In my view, type="default,...." should be used.
For "240_07" we have MVNOs.
First choice should be the apn without MVNO settings. That´s the "main" apn for that PLMN.
If we shall include MVNOs we need to add mvno_type and mvno_match_data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants