Hi,
On Mon, 2014-03-31 at 10:01 -0400, Glenn Schmottlach wrote:
> > The global routing table used by everybody else will have its default
> > route updated (or not) according to "normal" rules, i.e. the new service
> > if the new service can go online and the existing service was in state
> > ready, else the existing service is kept.
>
> Is it true that the "global" routing table's default route is updated
> to reflect the service that is currently in the "online" state? If for
> some reason a newly connected service *cannot* reach
> ipv{4,6}.connman.net is the default global route still updated (e.g.
> is it updated before or after the "online" state change)?
When a service gets to the ready state, i.e. IP address configured, the
default route is updated to this new service if PreferredTechnologies
indicates the new service is more preferred than the existing one. The
next check is made if the new service can enter online state. If no
other service is in online state, the new service will get the default
route. Again PreferredTechnologies plays in, if the new service is more
preferred than the old online one, the new service gets the default
route and online state.
> For the case of 'auser' and 'buser' you mentioned that they each have
> their own routing tables and default routes. Does this imply that
> individually, they each could achieve the "online" state
> simultaneously or is the "online" state only applicable to the global
> state (and thus global routing table)? Perhaps some clarification of
> the terminology might be helpful here.
First of all, remember to enable multiple routing tables in the kernel,
it's documented in the README file.
Online state follows the default routing table. Theoretically Sessions
could individually reach online state but they won't. It's exponentially
more complicated to get the online check done via auser and buser
Session's routing tables, especially since the online check is done by
ConnMan itself with the proxy part handled by pacrunner. Both these
daemons are not subject to the same UID/GID/SELinux routing table lookup
as the Session user. So no, to keep our sanity online check is done only
"the easy way".
Our perhaps last corner case in this area would need pacrunner to have
multiple proxy contexts - patches for this are welcome as usual. This
time around one will get the detailed problem description by asking on
the ml...
> > If a http connect to ipv{4,6}.connman.net succeeds, the connection is
> > considered online. pacrunnner,
>
> It seems that the "online" state is really only a ConnMan concept in
> the sense that it really has no bearing on whether data can be routed
> over a given service/interface.
Being able to look up ipv{4,6}.connman.net via DNS, having IP
addressing, routing and a http connection, the connectivity validation
part is about as good as it gets. In additon it can also mean that
pacrunner is set up with correct proxies, i.e. ConnMan's proxy
configuration was properly done. It's sythetic in a sense, but gives
quite a lot more promises than just the ready state.
That said, in 95% of the cases when the proxies are not set up in detail
or there is some other minor glitch between the device and connman.net,
the service stays in ready state but is nevertheless a fully functional
Internet connection for all practical purposes. In some cases ready is a
very local home network with no route out or otherwise limited
connectivity. It is left to the user to actually know what he's
connecting to and not to panic when both cases go to the ready state. In
ready there is IP addressing and very likely also routing, but the
end-to-end connectivity check to connman.net is not giving the last bits
of the connectivity check. So ready state is definitely weaker IP
connectivity than ready, but usually only a matter between "good" and
"excellent".
> What it seems to imply is that as long
> as a service reaches the 'ready' state it's available to route and
> pass data from a session. Is this the correct understanding?
In 90% of the cases the answer is yes. When ready is reached, IP
addressing works. There most likely is a default route somewhere, but
not mandatory. As the users really ought to know what they connect to,
it should not be a problem.
> > Only one service at a time can be online.
> >
>
> Again, what does being "online" really mean internally to ConnMan?
> Does this only mean one of the configured services was able to reach
> out to ipv{4,6}.connman.net (e.g. the one that was specifically
> "connected" to)?
As above.
> If that's true, then is seems if we have a situation
> where 'auser' session and 'buser' session, each configuring different
> services (e.g. WiFi and cellular), might be able to connect and go
> "online" at the same time. They have separate routing tables and thus
> different default routes so it might appear there would be no
> conflicts?
As above, to get the individual sessions to online state independently
means a lot of work without giving too much back. We'd need to tweak the
online check to use the particluar routing table, and also twist
pacrunner to use it - but only for this Session's context. Way too
complicated to achieve in practise.
> Are there two different concepts being discussed here: a
> service "online" state and a separate session "online" state?
It's a 1:1 mapping, the session using a service in online state gets its
session to online state as well, otherwise the session stays in
connected state, i.e. uses services in state ready.
There for sure are a few corner cases still in Session, just ask on the
ml and we'll figure out if it's the intended behavior or a bug.
Cheers,
Patrik
_______________________________________________
connman mailing list
[email protected]
https://lists.connman.net/mailman/listinfo/connman
