From mboxrd@z Thu Jan 1 00:00:00 1970 From: ummeegge To: development@lists.ipfire.org Subject: Re: Kernel patch - ERROR KCFG= FAIL Date: Tue, 19 Feb 2019 18:21:30 +0100 Message-ID: <3bf5ea6ec97d824ceab819d69b7f81e86a06c13f.camel@ipfire.org> In-Reply-To: <679D975C-8023-4625-9ECA-7AEFF44A6302@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3887236798235137314==" List-Id: --===============3887236798235137314== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, On Di, 2019-02-19 at 16:20 +0000, Michael Tremer wrote: > Hi, >=20 > > 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. > >=20 > > Haven=C2=B4t found something which can lead me in the right direction. > > Have > > uploaded the build log --> > >=20 https://people.ipfire.org/~ummeegge/logs/kernel_log_KCFG-ERROR-nDPI-netfilter > > may you can find something there=E2=80=A6 >=20 > There is a massive error message here: >=20 > 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 >=20 > If you manually set NF_CT_EXT_NUM then, it cannot be larger than 9. No, haven=C2=B4t set any values there, but great to know a little more what=C2=B4s causing the problem. Have informed the author, let=C2=B4s see what=C2=B4s happend. >=20 > If you didn=E2=80=99t set this, then this patch is probably incompatible wi= th > 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. >=20 > > > What is this patch for? > >=20 > > I think it implements some tracking possiblities via > > conntrack/netfilter, the kernel config needed to be also modified. > > In > > here -->=20 > >=20 https://github.com/vel21ripn/nDPI/blob/netfilter-2.2/ndpi-netfilter/INSTALL#L= 22 > > 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. >=20 > Well, nDPI (by stop) is what have in the kernel as ipp2p. A module > that detects P2P protocol traffic. >=20 > However, I deeply regret to add ipp2p as well as the layer 7 filter > to IPFire. Those will never ever go into IPFire 3. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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=E2=80=99t 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=3D50&t=3D22320=20 where i took a small step in but possibly there is some more=20 initiative, let=C2=B4s 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. >=20 > Best, > -Michael Best, Erik >=20 > >=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 > >=20 > >=20 https://github.com/vel21ripn/nDPI/blob/netfilter-2.2/ndpi-netfilter/kernel-pa= tch/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 > > > >=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 >=20 --===============3887236798235137314==--