From: Denis Kenzior <denkenz@gmail.com>
To: ofono@ofono.org
Subject: Re: [RFC PATCH 1/1] ublox: create only 1 gprs context
Date: Fri, 15 Mar 2019 11:28:35 -0500 [thread overview]
Message-ID: <e3343eef-12ff-4f9f-10dd-5ec0a3392e21@gmail.com> (raw)
In-Reply-To: <d391b873-ef59-c91f-369f-ed3b4b395789@norrbonn.se>
[-- Attachment #1: Type: text/plain, Size: 4548 bytes --]
Hi Jonas,
>> From what I recall, ublox does claim to support multiple PDP contexts
>> active at the same time. However, I don't know how this works in
>> practice as you need a unique network interface for each one. As it
>> stands today, given the udevng detection logic, this plugin is wrong.
>
> Right, so the way this works is that the modem looks like either a
> "bridge" or a "router". If configured as a "bridge", the outbound
> packet's source address is used to determine which context to use; if
> configured as a "router", the outbound packet's destination _network_ is
> used to determine which context to use and a default route is set via
> the _first activated context_ for packets that don't match the network
> of any active context. That's a mouthful...!!!
Ugh. Both of these are really not ideal. I'd really rather have the
host manage all these details than having the modem do it. Oh well.
I take it that in bridged mode we should be setting multiple IP
addresses to the network interface?
>
> The short of it is that this probably works in practice.
>
That depends. I suspect that it might not 'just work' for certain
classes of applications running on the host / application processor side.
> Is it ok for the connection manager interface to see multiple active
> contexts with the same Interface and the IP settings set to method
> "dhcp". Will it run a DHCP client on each interface or is it expected
> to be smart enough to recognize the common interface??? What would the
> point be since the only thing that differs the contexts is the APN and
> the connection manager shouldn't care about that particular detail...???
> This all applies to "router" mode only, really.
uBlox is just being too smart here. The whole bridged vs router stuff
was never intended by 27.007. They made this all up themselves.
Neither oFono nor ConnMan were designed to handle such a setup.
The main issue will be for contexts used for MMS / OMA DM. My memory
from the Meego / Tizen days is fuzzy, but from what I recall we designed
oFono with the assumption that we will always get an IP address and a
separate interface for the MMS context.
There's also the proxy. MMS contexts frequently have a proxy associated
with them. Again, we assumed that if a proxy is set, then it is also in
a form of an IP address. The proxy is then added as a route on the
interface by oFono (see pri_setproxy for details). And in practical
terms there is no domain name resolution for these contexts. Everything
just goes to the proxy.
This was how e.g. mmsd was designed to work. See
https://git.kernel.org/pub/scm/network/ofono/mmsd.git. That project has
not been touched in some time though, but there are others that act very
similar.
>
> In "bridge" mode, the above is probably moot since each context would
> announce different IP settings and the connection manager would be
> expected to apply those settings to the common interface. No idea if
> this works in practice.
Right. Do note that oFono is responsible for setting the IP on the
interface. So in bridged mode, this would need to be fixed. Also, I
don't know whether connman supports multi-IP interfaces in the first place.
Another issue is that ConnMan ignores all contexts that are not of type
Internet. So for example, nobody (or at least neither oFono, nor
ConnMan) would set the domain name servers for MMS contexts.
>
> Do you know how these multiple, active contexts are used in practice? In
> particular with regard to ofono?
>
They are used, yes. MMS, OMA DM/device provisioning, etc.
>>
>>>
>>> If I were to follow the model of other plugins, the below patch would
>>> seem appropriate...
>>>
>>> A bit of insight here would be appreciated.
>>
>> There are drivers for USB based modems that do this properly. See
>> xmm7xxx for example. Multiple PDP context support was added to that
>> recently.
>>
>> Modems that used multiplexing had support for multiple PDP contexts
>> for quite some time. E.g. plugins/ifx, etc.
>>
>> Anyway, patch looks fine to me. Let me know if you want me to apply
>> it or you want to take a stab at fixing the detection logic.
>
> From this, it sounds like the multiple gprs-context atoms are probably
> correct. I'll take a look at the xmm7xxx driver and see how it handles
> things.
>
So this is still debatable :)
Regards,
-Denis
next prev parent reply other threads:[~2019-03-15 16:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-14 22:37 [RFC PATCH 1/1] ublox: create only 1 gprs context Jonas Bonn
2019-03-15 1:27 ` Denis Kenzior
2019-03-15 7:42 ` Jonas Bonn
2019-03-15 16:28 ` Denis Kenzior [this message]
2019-03-16 6:41 ` Jonas Bonn
2019-03-19 15:26 ` Denis Kenzior
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e3343eef-12ff-4f9f-10dd-5ec0a3392e21@gmail.com \
--to=denkenz@gmail.com \
--cc=ofono@ofono.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox