IMQ@NAT kernel modul issue

[Lantis]

No they won’t interfere.
You should be able to just modify in place rather than move to the boot directory.

Please let me know after a longer test period.

[RomanHK]

So I modified the file /etc/bodules.d/46-ipt-imq, output:

Code: Select all

ip6_tables: (C) 2000-2006 Netfilter Core Team
IMQv4: Hooking IMQ after mangle on INPUT, pf=2, hooknum=1, priority=-149
IMQv6: Hooking IMQ after mangle on INPUT, pf=10, hooknum=1, priority=-149
IMQv4: Hooking IMQ after mangle on FORWARD, pf=2, hooknum=2, priority=-149
IMQv6: Hooking IMQ after mangle on FORWARD, pf=10, hooknum=2, priority=-149
IMQ driver loaded successfully. (numdevs = 1, numqueues = 1, imq_dev_accurate_stats = 1)
Netfilter messages via NETLINK v0.30.

And the error occurred after the second restart - the parameters do not solve the problem .

[tester]

The init/netinit doesn’t appear to make a difference.

Did you check nf_queue.c differences as well? Maybe I'm doing something wrong, but 1 of 5 of your changes gives error when I apply a patch.

[Lantis]

The patch applies fine for me. Remember that there are other patches that touch all of the files, so they need to all be applied (in order) to avoid conflicts or rejected patches.

[Lantis]

@roman
you can try the images here for a potential fix:
https://lantisproject.com/gargoyle_mvebu/

It doesn't load at boot, but loads when needed.

[RomanHK]

I'll be testing for a long time.

I turned on (just test) QoS and there are some errors in the log (the first one):

Code: Select all

daemon.err rmmod: module is not loaded
kern.info kernel: [  321.049545] 	IMQv4: Hooking IMQ after mangle on INPUT, pf=2, hooknum=1, priority=-149
kern.info kernel: [  321.057456] 	IMQv6: Hooking IMQ after mangle on INPUT, pf=10, hooknum=1, priority=-149
kern.info kernel: [  321.065456] 	IMQv4: Hooking IMQ after mangle on FORWARD, pf=2, hooknum=2, priority=-149
kern.info kernel: [  321.073507] 	IMQv6: Hooking IMQ after mangle on FORWARD, pf=10, hooknum=2, priority=-149
kern.info kernel: [  321.081676] IMQ driver loaded successfully. (numdevs = 1, numqueues = 1, imq_dev_accurate_stats = 1)
daemon.err insmod: module is already loaded - cls_fw
daemon.err insmod: module is already loaded - cls_flow
daemon.err insmod: module is already loaded - sch_hfsc
daemon.err insmod: module is already loaded - sch_sfq

[Lantis]

Those are all harmless, and cause no problems.

[tester]

The patch applies fine for me. Remember that there are other patches that touch all of the files, so they need to all be applied (in order) to avoid conflicts or rejected patches.

Can't find 'nf_queue.c' in other patches. Can you upload nf_queue.c after all applied patches to pastebin (or here)?

By default numdevs=2 in IMQ, but when you init it you always use numdevs=1, is this ok?

If I understand right in the new patch for imq.c you don't print 'Error hooking IMQ' on errors anymore, maybe it's better to bring it back? Can nf_register_net_hooks() return errors?

Can (in theory) enabled IPv6 in the IMQ be connected with errors on nat mod loading and/or imq hooking?

[Lantis]

https://pastebin.com/XUauy5S3
nf_queue.c after all patches applied. Kernel 4.14.xxx.

There are also 7 (at least) other patches which touch nf_queue.c:
https://git.openwrt.org/?p=openwrt%2Fop ... nf_queue.c

We only need 1 device, so this is fine.

There is still an error message: https://github.com/ericpaulbishop/gargo ... atch#L1350
The individual hook errors are only useful in debugging. The individual hook method was also causing some of the errors leading to the crash on unload so i've removed them for now. With a bit more careful thought they could probably be put back in, but this is fine for now.
Yes it can return errors: https://elixir.bootlin.com/linux/v4.14. ... ore.c#L375

IPv6 has been enabled for some time with no problems. I only made it obvious in the last patch so that i could do some debugging.
I guess in theory it could be involved, but it only affects some and not all systems.

[tester]

Thanks for information.

There is still an error message: https://github.com/ericpaulbishop/gargo ... atch#L1350
The individual hook errors are only useful in debugging. The individual hook method was also causing some of the errors leading to the crash on unload so i've removed them for now. With a bit more careful thought they could probably be put back in, but this is fine for now.
Yes it can return errors: https://elixir.bootlin.com/linux/v4.14. ... ore.c#L375

That error must be useless in our case, see here: 'Error hooking IMQ' but 'IMQ driver loaded successfully'. We suspect problems with hooking, so need ability to catch it. Maybe just do like this: if nf_register_net_hooks() return error then print in log 'Error #X when registering hooks'? It will be enough for brief debugging now, imo.