Bug 9476 (int-160207)

Summary: Only 1 APN connection is shown in 'Connect automatically' setting
Product: [Maemo Official Platform] Telephony Reporter: Venomrush <tri>
Component: GeneralAssignee: unassigned <nobody>
Status: RESOLVED WONTFIX QA Contact: telephony-general-bugs
Severity: normal    
Priority: Unspecified CC: andre_klapper, ext-markus.p.silvan, frals, jussi24, luke, peltsip, pierre-bugzilla, redex
Version: 5.0/(3.2010.02-8)   
Target Milestone: ---   
Hardware: N900   
OS: Maemo   
Bug Depends on:    
Bug Blocks: 9500    
Attachments: fixdirs.c

Description Venomrush (reporter) 2010-03-09 05:11:14 UTC
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'
Comment 1 Andre Klapper maemo.org 2010-03-09 19:13:42 UTC
Nick, just to be sure here, can you confirm that this is not a fAPN issue? TIA!
Comment 2 Nick Leppänen Larsson 2010-03-10 01:26:37 UTC
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.
Comment 3 Andre Klapper maemo.org 2010-03-10 20:59:40 UTC
frals: Thanks for clarifying!
Comment 4 Markus Silvan nokia 2010-03-23 09:48:42 UTC
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.
Comment 5 Andre Klapper maemo.org 2010-04-16 16:12:28 UTC
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.
Comment 6 ossipena 2010-04-16 16:31:59 UTC
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.
Comment 7 Nick Leppänen Larsson 2010-04-16 16:51:46 UTC
(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?
Comment 8 Andre Klapper maemo.org 2010-04-26 23:53:06 UTC
I wonder if http://foolab.org/node/7888 is helpful here?
Comment 9 Markus Silvan nokia 2010-04-27 14:22:48 UTC
> 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.
Comment 10 Pierre Ossman 2010-04-30 17:04:20 UTC
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.
Comment 11 Pierre Ossman 2010-05-01 20:34:14 UTC
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.
Comment 12 Pierre Ossman 2010-05-01 20:35:10 UTC
Created an attachment (id=2675) [details]
fixdirs.c

Source for LD_PRELOAD hack.
Comment 13 Pierre Ossman 2010-05-01 20:49:32 UTC
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?
Comment 14 Pierre Ossman 2010-05-01 21:02:18 UTC
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.
Comment 15 Pierre Ossman 2010-05-04 08:24:14 UTC
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?
Comment 16 redex 2010-07-01 23:53:54 UTC
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.
Comment 17 Nick Leppänen Larsson 2010-08-11 18:20:04 UTC
*** Bug 11115 has been marked as a duplicate of this bug. ***
Comment 18 Markus Silvan nokia 2010-10-27 11:04:27 UTC
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.
Comment 19 Pierre Ossman 2010-10-27 14:15:03 UTC
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).