Hi, On 05/11/2015 04:37 PM, Frederik Lotter wrote: > Hi, > > On 11 May 2015 at 15:37, Mylene JOSSERAND <[email protected]> > 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.
ok, this is what I though. > > >>> 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. I do not think it will help me. Anyway, thanks for your proposition. > > >> Best regards, >> >> Mylène >> >>> Kind Regards, >>> Frederik >>> >>> On 11 May 2015 at 14:36, Tomasz Bursztyka < >> [email protected]> >>> 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 >>>> [email protected] >>>> https://lists.connman.net/mailman/listinfo/connman >>>> >>>> _______________________________________________ connman mailing list [email protected] https://lists.connman.net/mailman/listinfo/connman
