Hi,
On 19 Feb 2019, at 15:07, ummeegge ummeegge@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-netfilte... 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#... 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@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-p...
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