Kernel patch - ERROR KCFG= FAIL

Kernel patch - ERROR KCFG= FAIL

[ummeegge]

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

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

Re: Kernel patch - ERROR KCFG= FAIL

[Michael Tremer]

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

Hi,

The error message is probably quite a bit before the end of the log.

What is this patch for?

-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
> 

Re: Kernel patch - ERROR KCFG= FAIL

[ummeegge]

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

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...

> 
> 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.


> 
> -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
> > 
> 
> 

Re: Kernel patch - ERROR KCFG= FAIL

[Michael Tremer]

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

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.

If you didn’t set this, then this patch is probably incompatible with our kernel 4.14 release.

>> 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.

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.

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.

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.

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?

Best,
-Michael

> 
> 
>> 
>> -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
>>> 
>> 
>> 
> 

Re: Kernel patch - ERROR KCFG= FAIL

[ummeegge]

[-- 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
> > > > 
> > > 
> > > 
> 
> 

Re: Kernel patch - ERROR KCFG= FAIL

[ummeegge]

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

Hi,
just a fast feedback from here.

On Di, 2019-02-19 at 16:20 +0000, Michael Tremer wrote:
> 
> 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?
got some answers from the developer and it was pointed out to use the
4.15er kernel patch which did worked while building but loading the
module was not possible:

[127389.287576] xt_ndpi: disagrees about version of symbol module_layout

which is a little sad since it seems like the only one actual
development in this topic. Also the OpenDPI people have had their last
activities 6 years ago -->
https://github.com/ewildgoose/ndpi-netfilter
.

A current working solution is here -->
https://github.com/betolj/ndpi-netfilter
findable which seems to be a kind of the original one. There is also no
kernel/kernel_config patch needed but the code (but also the nDPI which
is from ntop) seems to be pretty outdated (needed to patch main.c to
bring it to life).

Some tests has been made and it do not work with 100 but with 90% but
the last (fundamental) activities are there also 2 years ago and it
looks like nobody maintains it currently.

A little documentation for a deeper look into, if wanted, can be found
in here -->
https://forum.ipfire.org/viewtopic.php?f=50&t=22320#p122679

Best and thanks again for your help.

Erik