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. If this could be useful to you I will be happy to share my code. 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
