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

[lampotakl]

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

[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.

[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.