Patrik, based on your kernel config explanation it would seem tethering of USB Ethernet devices will not be possible if Session's/accounting is enabled, is this an expected feature limitation?
The reason for my question is that CONFIG_IP_NF_TARGET_MASQUERADE requires CONFIG_NETFILTER_ADVANCED to be disabled. While CONFIG_NETFILTER_XT_CONNMARK requires the CONFIG_NETFILTER_ADVANCED option to be enabled. (Unless this is specific to my older version of the kernel as well) 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<https://lists.connman.net/mailman/listinfo/connman> > _______________________________________________ connman mailing list [email protected] https://lists.connman.net/mailman/listinfo/connman
