Hi, On 11 May 2015 at 15:37, Mylene JOSSERAND <mylene.josser...@openwide.fr> wrote:
> 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 ? > Yes sorry, in my case connman/ofono terminates the current PPP session and then creates a new one with a new dhcp assigned IP. > > > > > 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. > Let me know if this would still be useful for you. > > 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 > _______________________________________________ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
