From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Kernel patch - ERROR KCFG= FAIL Date: Tue, 19 Feb 2019 16:20:32 +0000 Message-ID: <679D975C-8023-4625-9ECA-7AEFF44A6302@ipfire.org> In-Reply-To: <636c6297bd98358f1a21751f35371662d0f38d94.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7346896989527056759==" List-Id: --===============7346896989527056759== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, > On 19 Feb 2019, at 15:07, ummeegge wrote: >=20 > Hi Michael, > great that you looked over it. >=20 > On Di, 2019-02-19 at 11:25 +0000, Michael Tremer wrote: >> Hi, >>=20 >> The error message is probably quite a bit before the end of the log. > Haven=C2=B4t 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-netfilt= er > may you can find something there=E2=80=A6 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_a= ssert' _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^~~~~~~~~~~~~~~~~~~ ./include/linux/build_bug.h:47:37: note: in expansion of macro 'compiletime_a= ssert' #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_M= SG' 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=E2=80=99t 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 -->=20 > 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 >=20 > wanted to give it some tests, i thought it might be a nice addition to the = already=20 > available layer 7 patch. Well, nDPI (by stop) is what have in the kernel as ipp2p. A module that detec= ts 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 illus= tration for this. Basically all out-of-tree patches that we have ever added t= o 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 o= ther 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 ev= ery 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 patc= hes 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 kee= p 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 kern= el 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 in= terested to see where it goes, but I assume it won=E2=80=99t be very far. Doe= s it work with nftables? Best, -Michael >=20 >=20 >>=20 >> -Michael >>=20 >>> On 19 Feb 2019, at 11:22, ummeegge wrote: >>>=20 >>> Hi all, >>> am trying currently to patch the kernel for nDPI-netfilter and am >>> getting an error which i can=C2=B4t solve. The patch is from here --> >>>=20 > 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=20 >>>=20 >>> 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 >>>=20 >>> ERROR: Building linux >>> KCFG=3D =20 >>>=20 >>> [ FAIL ] >>> Check /var/dev-ipfire_20190118_1813/ipfire- >>> 2.x/log/_build.ipfire.log for errors if applicable >>>=20 >>>=20 >>> so may there is a simple solution for the "KCFG=3D ERROR". Since i do >>> not >>> really have much experience in kernel development i decided to ask >>> the >>> list for potential help... >>>=20 >>> Might be great if someone do have a hint for me ? >>>=20 >>> Best, >>>=20 >>> Erik >>>=20 >>=20 >>=20 >=20 --===============7346896989527056759==--