Comment 1 Andre Klapper 2010-03-09 19:13:42 UTC

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.

Comment 3 Andre Klapper 2010-03-10 20:59:40 UTC

frals: Thanks for clarifying!

Comment 4 Markus Silvan 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 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.

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?

Comment 8 Andre Klapper 2010-04-26 23:53:06 UTC

I wonder if http://foolab.org/node/7888 is helpful here?

Comment 9 Markus Silvan 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.

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]
fixdirs.c

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. ***

Comment 18 Markus Silvan 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.

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).