maemo.org Bugzilla – Full Text Bug Listing
|Only 1 APN connection is shown in 'Connect automatically' setting
|[Maemo Official Platform] Telephony
|andre_klapper, ext-markus.p.silvan, frals, jussi24, luke, peltsip, pierre-bugzilla, redex
|Bug Depends on:
SOFTWARE VERSION: (Control Panel > General > About product) 3.2010.02-8 STEPS TO REPRODUCE THE PROBLEM: 1. Navigate to: Menu -> Settings -> Internet Connections -> Connections 2. Tap on 'Connect automatically' EXPECTED OUTCOME: You are able to see all APN connections created ACTUAL OUTCOME: Only 1 APN connection is shown, and I expect this is the newly/newest added APN (added using fAPN in Extras) REPRODUCIBILITY: (always/sometimes/once) Always OTHER COMMENTS: I have added a new APN via fAPN (in Extras) I can only see this APN under 'Connect automatically'
Nick, just to be sure here, can you confirm that this is not a fAPN issue? TIA!
The GPRS IAP listed there seems to be selected by some arbitrary definition (ie not always latest added, might be by keyname in gconf?). This bug shouldn't be caused by fAPN as any GPRS IAP added manually with gconf would exhibit the same behavior. AFAIK fAPN adds the IAP the "right way" and by looking up the gconfkeys for the IAPs I can't see any difference between one added by ICD (or whatever daemon does that when a SIM is inserted) and one added with fAPN.
frals: Thanks for clarifying!
There can be multiple IAPs defined in gconf (for example after using multiple SIM cards), but only one access point matching the current SIM/network is shown. Not a Connectivity, but a GPRS issue.
According to Nokia this is a WONTFIX for Maemo5: "It is complex issue it would extensive modifications. Whole GPRS daemon APN handling is based on assumption that it should provide access point that can be used for Internet access and for that you only need one. And it does exactly that. And is definitely closed source. fAPN is already a hack to this effect. I do wonder why community would need something else. They can tweak with fAPN as musch as they need." Constructive comments welcome.
If this bug is wontfix, fMMS isn't a real option for mms support in N900 because it requires on most cases different APN than default internet. One can only see the sender of MMS if another APN isn't added.
(In reply to comment #5) > fAPN is already a hack to this effect. I do wonder why community would need > something else. They can tweak with fAPN as musch as they need." > fAPN only allows adding of more GPRS IAPs currently. However, if the logic behind how the GPRS APN is chosen is released, the community could develop a workaround so users can select which IAP to default to for GPRS (by tweaking the data inserted to gconf, I assume). I.e. in what order does it traverse the gconf-tree to find a suitable match for sim imsi? Does it return the first result or last from the tree traversal?
I wonder if http://foolab.org/node/7888 is helpful here?
> Does it return the first result or last from the tree traversal?
It uses gconf_client_all_dirs() to get a list of access point and iterates it
from the beginning to find a matching IAP for the SIM card.
Could Nokia please reconsider this decision. I've been looking at the gconf code and the order of entries from gconf_client_all_dirs() is for all intents and purposes random and not stable from time to time. There is no way of fixing this outside the Nokia code (except hacking gconf to return something more predictable). It is not needed to fix support for multiple APNs, but at least put a g_slist_sort() after the gconf_client_all_dirs() call so that the ordering is predictable and stable. Any program that adds extra entries could then do a "z_" prefix to avoid problems.
I've tested the above by adding a LD_PRELOAD fix to icd2 that sorts this list. Unfortunately it seems like comment 9 is not giving the full picture as it is not picking the first entry in the list.
Created an attachment (id=2675) [details]
Source for LD_PRELOAD hack.
Sorting things in the reverse order makes things work more sanely. It did pick the wrong instance at one point though. Hopefully just a fluke. I guess the algorithm is that icd goes through every entry, storing a candidate for the connection and overwriting it as it goes through. So in practice, the last entry will be selected. Correct?
Apparently not a fluke. The connection chosen is not consistent and varies from time to time. So there is some logic inside icd2 that's fudging things.
I've done some tracing and discovered that there is at least two algorithms at work here. On a fresh start of icd2, it will scan over all entries checking "type". Next it does a second scan, looking at "sim_imsi" and "name". The last suitable entry will be used for the connection. On reconnect, things look different. icd2 will again scan all entries and check "type", but it will not recheck "sim_imsi" and "name". It also doesn't pick the last entry, at least not consistently. Markus, could you have another look at the code and give us more info on how the code behaves so that we can figure out a way around it?
What about to add a simple boolean "use for autoconnect" value to the default APN connection and handle this in the closed Nokia module? Then we can have more than one APN and don't break our internet connection. This should be very simlpe to implement for Nokia.
*** Bug 11115 has been marked as a duplicate of this bug. ***
Is the list returned by gconf_client_all_dirs() ordered in any way? If not, and the first encountered matching entry is grabbed from that list, then the IAP selection will be inconsistent if there are more than one matching entries. In this case some sort of workaround is needed.
No, my analysis of gconf is that the ordering is very much random. It's probably consistently the same as long as the gconf data doesn't change. But any change in the data can result in complete reordering of the output result. Any sorting would therefore have to be done in the Nokia software (which probably isn't terribly difficult though).