Hi Frederik,
On 05/11/2015 02:57 PM, Frederik Lotter wrote: > Hi Mylene, > > I only see this thread now, and I see you have already started implementing > a solution. > > I had to solve the same problem. > > What I have done in the end is not to change Connman, but used the fact > that a modem "disable / enable" sequence in connman translated to a context > query in ofono. In Ofono I disabled context saving and implemented a DBUS > modem context provider plugin. The way my application manages this is to > trigger a disable/enable sequence in Connman, while it also implements the > DBUS context provider, which my application manages. The application can > set the next context and then trigger the update in connman. This works > well for my application where I have to dynamically change GSM APN settings > as the hardware moves between networks. I think I see what you are talking about.With this solution, could I have 2 APNs connected (in data mode) at the same time with different IP addresses ? Or, when the modem will be disabled in connman, it will loose his IP address ? > > If this could be useful to you I will be happy to share my code. Thank you, it would be great ! It could help me a lot to see what you have done so far and try to adapt it to my problem. Best regards, Mylène > > Kind Regards, > Frederik > > On 11 May 2015 at 14:36, Tomasz Bursztyka <tomasz.burszt...@linux.intel.com> > wrote: > >> Hi Mylene, >> >> That would need to be fixed yes. >>>> My best bet would be to revert the logic when it comes to context and >>>> network: >>>> >>>> instead of modem->context = ... >>>> you could have: context->modem = modem >>>> and modem->contexts would be a list of those context (a simple GSList). >>>> >>> Yes, this is what I have done so far. I did not create a GSList but a >>> HashTable to have the context_path, but it is pretty the same logic. >>> >> Unless you get dozens of contexts, go for a GSList. GHashTable does not >> have tiny memory footprint. >> (well, the current code is not perfect either. With an hashtable storing >> context path/data pairs is also overkill. >> I guess we would need to cleanup this also one day) >> >> Then you would create the network with the context as data. >>>> For the network, try to get a name made of the modem's name, and >>>> something that identifies the context (is there such thing? I don't know) >>>> >>> In fact, the network is created with the context path as identifier. So I >>> have the information but since it is the identifier, should I create a list >>> of networks ? do you think it could work ? If I implement a list of >>> network, the "add_network" and "connman_network_create" would be called >>> twice (for the two contexts). I think you have more distance than me about >>> the code : do you think it could work like this ? >>> >> Actually I missed this last time. But you seem to be on the right track. >> Since you are moving towards a network per context, remove the network >> pointer and put it network_context structure. >> You will thus get in a modem: a list of context as you did, each context >> will point to its proper network structure. >> So indeed you will call add_network and connman_network_create as many >> times as context your modem provides. >> >> You will have to change many functions which works on modem basis instead >> of context. >> (like set_connected, or netreg_update_strength where you would need to >> loop on each context from the modem, etc...) >> Basically, whatever exists around modem->network, you will have to adapt >> the code to the new logic. >> >> I have never touched that plugin myself, so I might miss some stuff there. >> >> >> Tomasz >> >> _______________________________________________ >> connman mailing list >> connman@connman.net >> https://lists.connman.net/mailman/listinfo/connman >> > _______________________________________________ > connman mailing list > connman@connman.net > https://lists.connman.net/mailman/listinfo/connman -- Mylène JOSSERAND Développeuse Linux Embarqué OPEN WIDE Ingénierie - Toulouse 36, rue Jacques Babinet 31100 TOULOUSE http://ingenierie.openwide.fr http://www.linuxembedded.fr _______________________________________________ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
