Re: Kernel patch - ERROR KCFG= FAIL

[ummeegge <ummeegge@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 7962 bytes --]

Hi Michael,

On Di, 2019-02-19 at 16:20 +0000, Michael Tremer wrote:
> Hi,
> 
> > On 19 Feb 2019, at 15:07, ummeegge <ummeegge(a)ipfire.org> wrote:
> > 
> > Hi Michael,
> > great that you looked over it.
> > 
> > On Di, 2019-02-19 at 11:25 +0000, Michael Tremer wrote:
> > > Hi,
> > > 
> > > The error message is probably quite a bit before the end of the
> > > log.
> > 
> > Haven´t found something which can lead me in the right direction.
> > Have
> > uploaded the build log -->
> > 
https://people.ipfire.org/~ummeegge/logs/kernel_log_KCFG-ERROR-nDPI-netfilter
> > may you can find something there…
> 
> There is a massive error message here:
> 
> In file included from ./include/linux/init.h:5:0,
>                  from ./include/linux/netfilter.h:5,
>                  from net/netfilter/nf_conntrack_core.c:18:
> In function 'total_extension_size',
>     inlined from 'nf_conntrack_init_start' at
> net/netfilter/nf_conntrack_core.c:2011:2:
> ./include/linux/compiler.h:328:38: error: call to
> '__compiletime_assert_1977' declared with attribute error:
> BUILD_BUG_ON failed: NF_CT_EXT_NUM > 9
>   _compiletime_assert(condition, msg, __compiletime_assert_,
> __LINE__)
>                                       ^
> ./include/linux/compiler.h:308:4: note: in definition of macro
> '__compiletime_assert'
>     prefix ## suffix();    \
>     ^~~~~~
> ./include/linux/compiler.h:328:2: note: in expansion of macro
> '_compiletime_assert'
>   _compiletime_assert(condition, msg, __compiletime_assert_,
> __LINE__)
>   ^~~~~~~~~~~~~~~~~~~
> ./include/linux/build_bug.h:47:37: note: in expansion of macro
> 'compiletime_assert'
>  #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
>                                      ^~~~~~~~~~~~~~~~~~
> ./include/linux/build_bug.h:71:2: note: in expansion of macro
> 'BUILD_BUG_ON_MSG'
>   BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
>   ^~~~~~~~~~~~~~~~
> net/netfilter/nf_conntrack_core.c:1977:2: note: in expansion of macro
> 'BUILD_BUG_ON'
>   BUILD_BUG_ON(NF_CT_EXT_NUM > 9);
>   ^~~~~~~~~~~~
> make[3]: *** [scripts/Makefile.build:326:
> net/netfilter/nf_conntrack_core.o] Error 1
> make[2]: *** [scripts/Makefile.build:585: net/netfilter] Error 2
> 
> If you manually set NF_CT_EXT_NUM then, it cannot be larger than 9.
No, haven´t set any values there, but great to know a little more
what´s causing the problem.
Have informed the author, let´s see what´s happend.

> 
> If you didn’t set this, then this patch is probably incompatible with
> our kernel 4.14 release.
Yes, i think so. There are some other forks out there, have tested
only one more which stops working much earlier.

> 
> > > What is this patch for?
> > 
> > I think it implements some tracking possiblities via
> > conntrack/netfilter, the kernel config needed to be also modified.
> > In
> > here --> 
> > 
https://github.com/vel21ripn/nDPI/blob/netfilter-2.2/ndpi-netfilter/INSTALL#L22
> > you can find some further infos.
> > If all went well, it should be possible to regulate traffic via
> > IPTables
> > module on application-layer basis e.g. :
> >    iptables -A INPUT -m ndpi --youtube -j DROP  # Block youtube
> >    iptables -A INPUT -m ndpi --facebook -j DROP # Block facebook
> >    iptables -A INPUT -m ndpi --skype -j DROP # Block skype
> > 
> > wanted to give it some tests, i thought it might be a nice addition
> > to the already 
> > available layer 7 patch.
> 
> Well, nDPI (by stop) is what have in the kernel as ipp2p. A module
> that detects P2P protocol traffic.
> 
> However, I deeply regret to add ipp2p as well as the layer 7 filter
> to IPFire. Those will never ever go into IPFire 3.
> 
> There is a little bit of a story to it. I guess Reiser 4 is also a
> good illustration for this. Basically all out-of-tree patches that we
> have ever added to the distribution have caused us trouble. Reiser 4
> has been abandoned and we could not update our kernel for a while.
> Layer 7 is terribly unstable. All other distributions that used it
> removed it (OpenWRT) because there were loads of memory leaks in it.
> Nobody seemed to care much about it. Then we have the IMQ patch;
> nobody really cares about that one either, but it is small and every
> time there is a new kernel, somebody random will update it.
This is indeed not accaptable even i can not understand why there is so
less interest in the OpenSource communities in those topics in general.

> 
> So that means that when ever we rebase our kernel (which is a lot of
> work by itself), another chunk of work is being put on top of this to
> make those patches work. There is a reason for all of them why they
> are not in the mainline kernel. Usually the code is just bad, untidy
> and unmaintainable.
This makes sense. This project where the source comes from is four
years old and it was looking up-to-date (actual version of nDPI from
ntop) so i was not too shy to go for a try.

> 
> In IPFire 3 we have a rule for no out-of-tree patches. I hope that we
> can keep it that way, because I do not see any other way.
Good decision.

> 
> What we would need here is patches that are maintained for a) the
> latest kernel release and b) for all LTS kernels as long as we are
> using them. The only project that has had this was grsecurity and
> that worked well for the time it lasted for.
In this specific project a 4.15 kernel patch is available but it seems
that there are not much testings for the various versions out there.

> 
> So, please toy around with (probably the ntop version of) nDPI. I
> would be interested to see where it goes, but I assume it won’t be
> very far. Does it work with nftables?
Yes, will invest a little more time if i get response from the
developer. This idea comes original from IPFire forum -->
https://forum.ipfire.org/viewtopic.php?f=50&t=22320 
where i took a small step in but possibly there is some more 
initiative, let´s see.
I think it does not work with nftables.

Thanks Michael for looking into this, will give you here a feedback if
some news are worth to mention.

> 
> Best,
> -Michael

Best,

Erik

> 
> > 
> > 
> > > 
> > > -Michael
> > > 
> > > > On 19 Feb 2019, at 11:22, ummeegge <ummeegge(a)ipfire.org> wrote:
> > > > 
> > > > Hi all,
> > > > am trying currently to patch the kernel for nDPI-netfilter and
> > > > am
> > > > getting an error which i can´t solve. The patch is from here --
> > > > >
> > > > 
> > 
> > 
https://github.com/vel21ripn/nDPI/blob/netfilter-2.2/ndpi-netfilter/kernel-patch/v4.14.0.diff
> > > > and it does apply but the kernel quits after sometime with 
> > > > 
> > > > CC [M]  drivers/net/wireless/ti/wlcore/sdio.o
> > > > LD [M]  drivers/net/wireless/ti/wlcore/wlcore_sdio.o
> > > > LD [M]  drivers/net/wireless/ti/wlcore/wlcore.o
> > > > AR      drivers/net/wireless/ti/built-in.o
> > > > AR      drivers/net/wireless/built-in.o
> > > > AR      drivers/net/built-in.o
> > > > AR      drivers/built-in.o
> > > > make[1]: Leaving directory '/usr/src/linux-4.14.97'
> > > > make: *** [linux:149: /usr/src/log/linux-4.14.97-ipfire] Error
> > > > 
> > > > ERROR: Building linux
> > > > KCFG=                                                          
> > > >     
> > > > 
> > > >                         [ FAIL ]
> > > >   Check /var/dev-ipfire_20190118_1813/ipfire-
> > > > 2.x/log/_build.ipfire.log for errors if applicable
> > > > 
> > > > 
> > > > so may there is a simple solution for the "KCFG= ERROR". Since
> > > > i do
> > > > not
> > > > really have much experience in kernel development i decided to
> > > > ask
> > > > the
> > > > list for potential help...
> > > > 
> > > > Might be great if someone do have a hint for me ?
> > > > 
> > > > Best,
> > > > 
> > > > Erik
> > > > 
> > > 
> > > 
> 
>