Hi Michael, On Di, 2019-02-19 at 16:20 +0000, Michael Tremer wrote: > Hi, > > > On 19 Feb 2019, at 15:07, ummeegge 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 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 > > > > > > > > > > > >