Hi Daniel / Patrick -
Thanks for the feedback with respect to the kernel features ConnMan
expects to be available. It's certainly useful information to know
given the fact that we can't all use the latest kernel releases.
Certainly allowing ConnMan to fail "gracefully" when a needed kernel
feature is not present is much preferred.
With that said, I have a couple of questions related to the Session
implementation and design goals. Based on the documentation I've read
and the presentation Daniel gave in 2011 at Vancouver my questions
follow:
1) It appears their is an assumption that the client "application"
belongs to a unique process, group, or Secure Linux context.
2) The client application must explicitly do two things:
a) Bind to a specific device (SO_BINDTODEVICE). I am not clear why
that is necessary?
b) Mark the socket (and thus packets sent over that socket) with a
special "magic" number that is associated with the "mark" field in the
session configuration and used in the iptables configuration which
tracks statistics associated with that socket. It's not clear how this
"magic" number is shared between the application and ConnMan. Can you
clarify?
There are few things that concern me with (a) and (b) above. As stated
in the presentation, there is no "free l lunch".
1) It appears that the client application must have "root" access in
order to set both the "SO_BINDTODEVICE" and "SO_MARK" socket options
(at least this is the case on my system). I suspect in all cases this
may not be advisable from a security/sandboxing standpoint. Was this
foreseen or am I missing something?
2) There appears to be an implicit assumption that the client
application has the ability to set atypical socket options (as above).
Certainly this is generally plausible for a C/C++ program but I wonder
if you've considered applications written in other languages (e.g.
scripting languages like Python, Lua, or Javascript) that may/may not
have direct access to those socket options. In particular, with HTML5
"apps" being all the rage today, how would you expect HTML5 "apps"
running in the context of a browser to set these options? These types
of applications may either run in their own process (the
Android/Chrome model) or perhaps still be part of a single WebKit
process and share the JavaScript VM with other "apps".
3) With respect to (2), I certainly see a future where some
applications will be implemented in HTML5. How would you see ConnMan
supporting applications in that environment. I am somewhat concerned
because your usual HTML5 developer's access to lower level sockets may
be hidden by either class libraries (e.g. Node.js) or browser
abstractions that don't give them the lower level access to the
features ConnMan seems to require for the "session feature.
I'm interested if you could elaborate on plans you may have for
supporting the scenarios I've described above. It's likely that I'm
merely ignorant of your overall design strategy and there is a clearer
path forward.
Thanks for any feedback you can offer . . .
Glenn
On Tue, Oct 29, 2013 at 4:52 AM, Daniel Wagner <[email protected]> wrote:
> Hi Glenn,
>
>
> On 10/29/2013 02:38 AM, Glenn Schmottlach wrote:
>>
>> I've been investigating the ConnMan "Session" API and implementation.
>> It would appear that it relies heavily on a couple of key netfilter
>> features that are only available in newer Linux Kernels (e.g. Kernel
>> 3.3+).
>
>
> The Session API comes with a set of features. The main goal is to
> support the per application routing and statistics use case.
> With the D-Bus API we also support other per application
> use case such as notify applications when there a bearer
> in the AllowedBearers is online.
>
> We implemented the D-Bus parts first and now we added the
> missing pieces for the per application routing and statistics
> use cases. That is why you see new dependencies.
>
>
>> In particular per-session accounting is maintained using
>> netfilter's nfacct feature. Unfortunately, I'm on an i.MX6 platform
>> and the latest "stable" Linux kernel offered by Freescale is Linux
>> 3.0.35 where the nfacct feature is not available.
>
>
> Ooch, that is even not the last stable kernel of the 3.0 series.
>
>
>> The question I have
>> is how forgiving is ConnMan for running on these earlier kernels and
>> whether I can expect to use any of the ConnMan session features with
>> this kernel.
>
>
> Yes, we tried to make sure that the new dependencies are not
> hard dependencies.
>
>
>> Perhaps the better question is whether these missing
>> features will make using ConnMan unstable/unsuitable for this
>> platform.
>
>
> No it should not impact the stability etc. If it does it is
> a bug which needs to be fixed.
>
>
>> Early experimentation seems to indicate the core features do
>> in fact work.
>
>
> Nice, that was we tried to achieved.
>
>
>> I hope the unsuitability is only related to session
>> support and that I can expect to utilize the other features of the
>> service without problem. Is this indeed the situation?
>
>
> If you don't use the Session API at all you should have any
> problem.
>
>
>> On a side note, I'm curious to know whether the core ConnMan
>> developers are sensitive to the fact that the newer kernel features
>> are not routinely available for all SoCs and BSPs that are commonly
>> available from the silicon vendors? Is there a minimum kernel version
>> that is expected in order to use ConnMan?
>
>
> Yep, we are aware of this fact. We have listed all known
> dependencies in the README instead of asking for min version
> of kernel. I really hope that the silicon vendors start to
> catch up with mainline really soon. The current situation
> is bad for everyone for obvious reasons.
>
>
>> Thanks for any insights that can be offered . . .
>
>
> If you have bug reports etc please do not hesitate to report.
>
> cheers,
> daniel
_______________________________________________
connman mailing list
[email protected]
https://lists.connman.net/mailman/listinfo/connman
