Re: [RFC PATCH 1/1] ublox: create only 1 gprs context

[Denis Kenzior <denkenz@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3845 bytes --]

Hi Jonas,

> OK, thanks for digging that out despite the cobwebs!

No worries.  Sorry I forgot to reply to this earlier.

> 
> So, this is where I end up then:
> 
> i)  MMS (and other) contexts are just IP endpoints, but they are all 
> identified by a "type"

Right now yes.  In theory you could have a DNS, routing, etc for these 
contexts as well.  In fact, once we introduce IMS contexts, this has to 
be done anyway.

> ii)  connman handles "Internet" contexts and ignores everything else...

Correct.

> iii) other applications (like mmsd) handle contexts of other types
> iv)  mmsd, unlike connman, expects the network interface associated with 
> the context to be fully configured... IP address, route, etc.

Correct, at least at the moment

> 
> ofono is designed to expect a network interface for each context.  For 
> this reason, it's pretty heavy-handed in its setup of the interface:  it 
> assumes the interface isn't shared by other contexts and isn't careful 
> about maintaining settings coming from other contexts.

This is also what 3GPP intended, at least back in the multiplexing / 
27.010 days.  Now things become a bit more complex as you can tell. 
Intel modems do actually expose multiple pseudo-ethernet devices for this.

> 
> So the real impedance mismatch here for the case where a modem puts 
> multiple contexts behind a single network interface is the way ofono is 
> implemented.

Correct.

> 
> ofono could be re-implemented here to add multiple IP addresses to a 
> single interface and to set routing accordingly (for MMS contexts only, 
> apparently... it looks like ofono does nothing currently for other 
> context types).

This gets tricky, but I assume that for 'bridged' mode we would need to 
do this yes.

With router mode things become a bit simpler.  Likely the only thing 
needed on these is to just automagically setup routing for MMS/SIP 
proxies.  The only difference from what we have today would be that we 
need to remove the corresponding routes when the MMS context goes down 
(today oFono assumes that the entire interface is brought down) So it 
wouldn't be that hard to implement actually.  And since ConnMan ignores 
non-Internet contexts, things would probably just work.

Someone needs to test that theory though.  I don't have any ublox devices.

> 
> Another alternative is to have the gprs-context driver for affected 
> devices create "virtual network devices" (is this still a thing?) with 
> static IP addresses for all contexts.  For the u-blox "router mode" 
> case, though, I can't figure out who runs the DHCP client... (and the 
> TOBY L4 is router-mode-only, so requiring bridge-mode is not an option).

We have been contemplating for a long time that DHCP needs to move out 
of ConnMan and into the individual daemons, e.g. BlueZ, iwd, oFono.  I 
already started moving bits of DHCP into ell, but higher priority tasks 
came up.

There was an earlier thread where weird device behaviors were described 
(by Giacinto, I think?).  E.g. a device would not succeed in context 
activation until DHCP was run against the interface.  So supporting such 
devices with DHCP in ConnMan is a bit problematic and we have a fighting 
chance with DHCP in oFono.

> 
> Either way, this is a reasonably big undertaking.  I don't think I want 
> to take this on without a concrete use-case presenting itself, first! :)
> 

Device Provisioning, Firmware update, MMS, IMS :)

> So given that, the right thing to do here is probably to just drop 
> multiple context support from the u-blox driver until ofono is modified 
> (someday) to handle multiple contexts behind a single network interface. 
>   I will send a patch.

For now I think that is the right approach.

Regards,
-Denis