Mudule built by DKMS is not working and has much smaller size

[lampotakl]

I'm trying to create dkms.conf for kernel module, but I have a problem with it. When module is compiled using DKMS then there are no errors during build and resulting object files are good but the resulting kernel module file (.ko) has very small size (16kB instead of 500kB) and the module is not working so it seems that there is some problem with linker maybe? But there are no errors or related messages to it.
Originally the module is compiled with ./autogen.sh && ./configure && make so I've added PRE_BUILD= script with ./autogen.sh && ./configure and MAKE="make" in dkms.conf.
Building with DKMS like this ends up with not working resulting kernel module file.
I've tried for a test to add ./autogen.sh && ./configure && make in PRE_BUILD= script and then check the resulting kernel module file at the end of this script and it turned out that it was built correctly.
So there is some problem with how DMKS is building it with MAKE="make".
Can someone advise me what can I do to make DKMS build the kernel module correctly? Or do I have some errors in dkms.conf?

Here is the error when I try to use the module built using DKMS:

$ sudo iptables -t mangle -I INPUT -j WGOBFS --key "test" --unobfs
Warning: Extension WGOBFS revision 0 not supported, missing kernel module?
iptables v1.8.9 (nf_tables):  RULE_INSERT failed (No such file or directory): rule in chain INPUT

Here is the module in question with DKMS support in the current state:
https://github.com/lampotakl/xt_wgobfs/tree/dkms

[evelikov]

At a glance, the first thing I would recommend is removing the autotools/autoconf setup and using a simple Makefile or two. Autoconf/autotools are useful for very old and non-linux platforms, where the project seems to cover the complete opposite - modern linux.

By default, autotools generate a lot of unnecessary (for your use-case) files and data, while also mucking around with pre-processor/compiler/linker flags et al.

Another two pieces that pop-up while browsing through:

• all the dkms pre/post scripts should not be needed, same goes for the MAKE and CLEAN tokens in dkms.conf
• the version in dkms.conf and dkms/openwrt/package/Makefile should be updated during release/tag time - using sed to screen-scrape the data off the .C file is far from elegant

With ^^ addresses, I would be happy to have another look.

[lampotakl]

As I understand it, this module was intended to be included in xtables-addons by original module autor @infinet:
https://github.com/infinet/xtables-addons
https://www.netfilter.org/projects/xtables-addons/index.html
Autoconf/autotools is used here with expectation of addition of this module in the main kernel/iptables packages at some point in the future and iptables is using autoconf/autotools to build modules.

Is it a good idea to keep separate simple Makefile to use with DKMS until this module is included in main package and separately maintain autoconf/autotools setup for this inclusion?
Overall thank you for your remarks, I'll try to remake this build setup into a simple Makefile, though I'll have to delve into how it even works first.

[evelikov]

To be honest I don't particularly follow the whole xtables/xtables-addons situation.

From a quick test - this seems to be a user error/incorrect dkms conversion. Let me open a MR in the right place, thanks for the link.

/close

[lampotakl]

I've tried to use the simple Makefile that you provided as an example here:
infinet/xt_wgobfs#29
And it builds correct kernel module file if I just build it with make using this Makefile:

$ ls -la xt_WGOBFS.ko
-rw-r--r-- 1 user user 524048 Oct 22 10:01 xt_WGOBFS.ko

But using DKMS it'll built kernel module file that is not working and has small size:

-rw-r--r-- 1 root root  13237 Oct 22 09:36 xt_WGOBFS.ko

So is it a problem somewhere in DKMS?

UPD:
Ok, it seems that this issue is caused by strip here:
https://github.com/dell/dkms/blob/master/dkms.in#L1115
DKMS builds correct module with this option in dkms.conf:

STRIP[0]="no"

[evelikov]

Good find - didn't expect stripping to affect this.

Bear in mind that we use "strip --strip-debug" which as the name suggests should remove only the debug symbols. If that leads to a broken module then that sounds like a non-dkms bug. Either the strip tool itself is being overzealous or the module itself does not have it's data not stored/annotated correctly.

Distributions will typically do the same - either strip directly or via the kernel INSTALL_MOD_STRIP=1 toggle. So I strongly suggest tracking it down and reporting a bug.

In the meanwhile having a STRIP[0]="no" workaround should be fine.

[lampotakl]

Yes, this is not a DKMS bug, I'll use STRIP option for now and I'll try to track this issue to understand why it's happening.