Hi,
On Mon, 2013-10-28 at 22:38 -0400, Glenn Schmottlach wrote:
> 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+). 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. 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.
Currently the code expects nfacct to be available for
init_firewall_session() to succeed. This seems to be slightly too strict
in order to use sessions, especially if sessions are used only as a
notification mechanism.
I think nfacct should be an optional feature. I don't have a time
estimate when that will be happening, though. Meanwhile, nfacct is easy
to circumvent in that init function.
> Perhaps the better question is whether these missing
> features will make using ConnMan unstable/unsuitable for this
> platform. Early experimentation seems to indicate the core features do
> in fact work. 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?
The nfacct requirement is only related to sessions. Session routing
support uses CONFIG_IP_MULTIPLE_TABLES and CONFIG_NETFILTER_XT*CONNMARK
mentioned in the README file. CONFIG_BRIDGE and
CONFIG_IP_NF_TARGET_MASQUERADE are used only for tethering with
CONFIG_USB_GADGET and CONFIG_USB_ETH for a USB network connection. So
we're pretty modular here.
> 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?
If there are new features in ConnMan where the solution is to use a new
and shiny kernel feature, the new feature is going to be used. We are on
the insensitive side when older kernels are used; drivers should be
pushing upstream for the SoC, BSP or platform to make any sense mid and
long term. Thus there is not too much mercy in reserve when older
kernels are concerned.
But all of this is open source, anyone can send a sensible patch with a
sensible description; we'll for sure look at every patch sent to the
mailing list.
Cheers,
Patrik
_______________________________________________
connman mailing list
[email protected]
https://lists.connman.net/mailman/listinfo/connman
