Hi Michael,
On Di, 2019-02-19 at 16:20 +0000, Michael Tremer wrote:
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.
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#...
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@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