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
Hi,
The error message is probably quite a bit before the end of the log.
What is this patch for?
-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
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...
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.
-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
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
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
Hi, just a fast feedback from here.
On Di, 2019-02-19 at 16:20 +0000, Michael Tremer wrote:
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?
got some answers from the developer and it was pointed out to use the 4.15er kernel patch which did worked while building but loading the module was not possible:
[127389.287576] xt_ndpi: disagrees about version of symbol module_layout
which is a little sad since it seems like the only one actual development in this topic. Also the OpenDPI people have had their last activities 6 years ago --> https://github.com/ewildgoose/ndpi-netfilter .
A current working solution is here --> https://github.com/betolj/ndpi-netfilter findable which seems to be a kind of the original one. There is also no kernel/kernel_config patch needed but the code (but also the nDPI which is from ntop) seems to be pretty outdated (needed to patch main.c to bring it to life).
Some tests has been made and it do not work with 100 but with 90% but the last (fundamental) activities are there also 2 years ago and it looks like nobody maintains it currently.
A little documentation for a deeper look into, if wanted, can be found in here --> https://forum.ipfire.org/viewtopic.php?f=50&t=22320#p122679
Best and thanks again for your help.
Erik
-
Michael Tremer -
ummeegge