Hi Patrik and Glenn,
On 04/01/2014 08:14 AM, Patrik Flykt wrote:
> On Mon, 2014-03-31 at 10:01 -0400, Glenn Schmottlach wrote:
>> 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".
I hope we get away with the 'easy way' here. I don't know if it is
exponentially more complicated to test for online per Session. I guess
someone has to try to cook up a patch.
> 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.
I think an online test should be configurable per Session (also the same
goes for VPN service) because not all networks give you an internet link
IF you are depending on the 'online' state information. If you are happy
with 'connected' nothing has to be changed.
> 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.
To be honest ConnMan's aim was to be extra clever here and not relying
on the user being smart. The question if the 80% solution we have
currently is good enough.
> 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".
Another point to mention here is that 'online' tells you that the clock
have been synced, which 'ready' doesn't.
>> 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.
I have not idea how hard it would be to implement this. I have some
hopes that it is not so hard as Patrik thinks :)
> We'd need to tweak the
> online check to use the particluar routing table,
Aren't we using FDs everywhere and bind the request to the device and
therefore the routing table is not used at all?
> and also twist
> pacrunner to use it - but only for this Session's context.
PACrunner is another thing. I have no clue what would needed to get this
working, e.g. does the API between ConnMan and PACrunner allow this?
> Way too complicated to achieve in practise.
Without seeing a patch this is a bit too early conclusion, don't you
think? :D
cheers,
daniel
_______________________________________________
connman mailing list
[email protected]
https://lists.connman.net/mailman/listinfo/connman
