Compilation error: wiphy->regulatory_flags |= REGULATORY_IGNORE_STALE_KICKOFF

[Jesus-M]

Since yesterday I am getting this error when compiling the module:

/var/lib/dkms/rtl88x2bu/5.13.1/build/os_dep/linux/wifi_regd.c: In function ‘rtw_regd_init’:
/var/lib/dkms/rtl88x2bu/5.13.1/build/os_dep/linux/wifi_regd.c:409:36: error: ‘REGULATORY_IGNORE_STALE_KICKOFF’ undeclared (first usein this function)
409 |         wiphy->regulatory_flags |= REGULATORY_IGNORE_STALE_KICKOFF;
|                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/var/lib/dkms/rtl88x2bu/5.13.1/build/os_dep/linux/wifi_regd.c:409:36: note: each undeclared identifier is reported only once for each function it appears in
make[2]: *** [scripts/Makefile.build:250: /var/lib/dkms/rtl88x2bu/5.13.1/build/os_dep/linux/wifi_regd.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [Makefile:2012: /var/lib/dkms/rtl88x2bu/5.13.1/build] Error 2
make: *** [Makefile:2523: modules] Error 2

Today there was an update on the os_dep/linux/wifi_regd.c file:

-#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3, 19, 0)) && (LINUX_VERSION_CODE < KERNEL_VERSION(6, 5, 0))
+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3, 19, 0)) && (LINUX_VERSION_CODE < KERNEL_VERSION(6, 4, 4))

Still same error today.

I can compile the module just deleting the lines 408-410, but not sure of side effects from removing these lines

My environment:

Slackware 15.0 x86_64 (post 15.0 -current)
Linux liet.triana 6.1.39 #1 SMP PREEMPT_DYNAMIC Wed Jul 19 14:01:23 CDT 2023 x86_64 Intel(R) Core(TM) i5-4670 CPU @ 3.40GHz GenuineIntel GNU/Linux
dkms-3.0.11
GNU Make 4.4.1
gcc version 13.1.0 (GCC)

Until now, it worked flawlessly with any and every version I tried.

[morrownr]

Hi @Jesus-M

Interesting. I have an idea what might have happened. Can I get you to test the following:

#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3, 19, 0)) && (LINUX_VERSION_CODE < KERNEL_VERSION(6, 1, 39))

Change line 408 to use your kernel version and compile.

What I am testing is whether the backport from kernel 6.5 was accidentally taken all the way back into kernel 6.1.? (which is a LTS kernel).

[Jesus-M]

That worked!

So, did someone mess it up with the last 6.1.x kernel?

[morrownr]

Ok, so that worked. This is not my happy face. We know that the kernel 6.5 backport goes back to 6.1.39.

This was a really bad idea by whoever approved this. This backport can't go into kernel 6.2 because it is depreciated. But Ubuntu 23.04 and all the little Buntu's use kernel 6.2. Ubuntu could pull the backport in but do they know to do so? There are other distros that can create the same havoc. It is okay to take a backport back to the latest LTS if it is something like a new VID/PID but with something like this, it just should not be done.

@5kft and I are looking at this. I suspect we won't have a good solution and next week the each repo will fill with bugs reports.

So, did someone mess it up with the last 6.1.x kernel?

Yes.

[morrownr]

FYI: we are going to go with the fix you used. I fear it is not a clean fix but it is as clean as we can do. We'll see what happens.

[Jesus-M]

ok, I made a couple of tests on my own (and I broke my PC and needed few hours to recover it XD )

• the problem is so far indeed only with kernel 6.1.39, I rolled back to 6.1.38 and works fine in the original version.
• the kernel 6.1.39 has more problems, as it keeps one of the cores at 100% all the time.

So I would say it is not worth it to fix your driver, just it is better to stay away from 6.1.39.

Anyway, the important thing is that either avoiding the bad kernel or using your update, it works.

Thanks a lot!

[exzombie]

Is there a chance that the changes introduced in 6.1.39 will be reverted in a later release?

[morrownr]

Is there a chance that the changes introduced in 6.1.39 will be reverted in a later release?

It is possible.

[Jesus-M]

For the time being, kernel 6.1.40 is out and they problems persists (including the 100% use of one of the cores), so I am sticking with 6.1.38 for now.

[ElisabettaCarrara]

Just an heads up, I updated the package (Linux Manjaro 22.1 on the kernel 6.4.6-1, my machine is an HP250 laptop) and apparently it built correctly except at the end I had a bunch of "==> ERROR: Missing boot kernel headers for module rtl88x2bu/5.13.1.r189.12cfcd8." warnings.
I see the previous comments were about missing headers, should I rebuild the package manually applying the fix above or go to a previous kernel? Do you need more info on the issue to understand what is going on? I used yay to upgrade it if this is relevant, because I have an issue with pamac-GUI not working properly in KDE Plasma (know issue with no fix for now) so konsole is the way to go. Thanks for the advice

[vizrbo]

I would like to add to this thread. I am on a Debian 12 Laptop with KDE X11.
My USB is "TP-Link WN725N v3" which uses the "r8188eu" driver which I realise is not what this repository is about.

However I would like to report a few observations:

1. I used "https://github.com/ivanovborislav/rtl8188eu" to dkms install the "rtl8188eu" driver instead of using the "r8188eu" driver (the performance difference is quite obvious)

2. All was well while I was on Kernel 6.1.38-4. Then I received an update from Debian for Kernel 6.1.52-1.

3. The dkms building failed with the exact same error mentioned here. The module would not build whatsoever. No matter of googling could solve the "REGULATORY_IGNORE_STALE_KICKOFF;" error. Removed the "rtl8188eu" driver completely restoring the defaults (r8188eu)

4. Booted back into Kernel 6.1.38-4 and tried dkms installing again. Installs and works as intended!

I'm a newbie when it comes to Linux distributions; been going back-and-forth with Linux Mint and Windows since 2021, before deciding to finally settle with Debian 12 this year. As such my technical know-how is very limited when it comes to these matters. But nonetheless, please let me know if I can contribute in any manner!

[morrownr]

Hi @vizrbo

Realtek out-of-kernel drivers are a total pain in the ass. They seem to be designed for professional programers working on embedded projects. For us desktop users, I have created a Main Menu here at this site:

https://github.com/morrownr/USB-WiFi

Scroll down to view the menu. Menu items 1 and 2 should be a good starting point. Menu item one gives some information about USB WiFi on Linux and then menu item 2 gives a list of adapters that are plug and play. There are certainly more adapters that are plug and play than what is in the list but the list only shows adapters where we have good information or I have tested.

I think your pick of Debian 12 should work well and if you have questions about WiFi adapters, just post in Issues for the repo I ave you to the link to above.

Cheers

[5kft]

@vizrbo If you're just looking to address the compilation issue with the newer kernel, in your local git clone of https://github.com/ivanovborislav/rtl8188eu/blob/main/os_dep/linux/wifi_regd.c, you can change line 408 from

#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3, 19, 0))

to

#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3, 19, 0)) && (LINUX_VERSION_CODE < KERNEL_VERSION(6, 1, 39))

Then try the dkms install again on the newer kernel?

[morrownr]

@5kft

Did I leave this out in this driver?

[5kft]

Did I leave this out in this driver?

No, I read this as they're using a different driver (for the 8188eu).

[morrownr]

@5kft

Ouch. You read it right. My bad.

@vizrbo

please let me know if I can contribute in any manner!

Go to the Main Menu, have a look around, see what is of interest to you and let me know. I can always use help.

[vizrbo]

Thanks a lot @morrownr and @5kft !

@morrownr I've got to admit. A great deal of work and care has gone behind the exhaustive guide you have prepared for the community. I looked up the adapters and the chipsets they were based on. Although the Mediatek chipset caught my attention its sad that there are no local brands that make adapters based on Mediatek chipsets where I reside. A lot of the Mediatek brands you mentioned are either unavailable in my region or priced ridiculously (~ $130) obviously because of the shipping charges. TP-Link is widely available in my region though and going through your doc, I've found the TP-Link Archer T3U Nano pretty interesting which uses a recommended chipset RTL8812bu.

As a small gesture I have starred your repository and would be re-visiting to put up issues concerning new/existing info.

@5kft It's just as you said. In my case editing the "/usr/src/rtl8188eu-5.13.3/os_dep/linux/wifi_regd.c" with your correction and upgrading to the available Kernel 6.1.52-1 started the dkms autobuild service. The dkms installation was successful!

sudo modinfo 8188eu | grep version

version:        v5.13.3-17-gb1925f81a.20210615
srcversion:     93D49C0AE7ED7D5986193B2
vermagic:       6.1.0-12-amd64 SMP preempt mod_unload modversions 
parm:           rtw_chip_version:int

uname -v
#1 SMP PREEMPT_DYNAMIC Debian 6.1.52-1 (2023-09-07)

[mod-at-nwa]

SOLVED

The file regulatory.h contains all the definitions for these flags.
File location: /usr/src/linux-headers-6.2.0-20/include/net/regulatory.h

enum ieee80211_regulatory_flags {
REGULATORY_CUSTOM_REG = BIT(0),
REGULATORY_STRICT_REG = BIT(1),
REGULATORY_DISABLE_BEACON_HINTS = BIT(2),
REGULATORY_COUNTRY_IE_FOLLOW_POWER = BIT(3),
REGULATORY_COUNTRY_IE_IGNORE = BIT(4),
REGULATORY_ENABLE_RELAX_NO_IR = BIT(5),
REGULATORY_IGNORE_STALE_KICKOFF = BIT(6),
REGULATORY_WIPHY_SELF_MANAGED = BIT(7),
};

I looked in my current directory's definitions for regulatory.h and found this:
File location: /usr/src/linux-headers-6.2.0-39/include/net/regulatory.h

enum ieee80211_regulatory_flags {
REGULATORY_CUSTOM_REG = BIT(0),
REGULATORY_STRICT_REG = BIT(1),
REGULATORY_DISABLE_BEACON_HINTS = BIT(2),
REGULATORY_COUNTRY_IE_FOLLOW_POWER = BIT(3),
REGULATORY_COUNTRY_IE_IGNORE = BIT(4),
REGULATORY_ENABLE_RELAX_NO_IR = BIT(5),
/* reuse bit 6 next time */
REGULATORY_WIPHY_SELF_MANAGED = BIT(7),
};

I'm going to edit my linux-headers-6.2.0-39 regulatory.h definition file. I'm going to add the line REGULATORY_IGNORE_STALE_KICKOFF = BIT(6), to my definition file.

If you never hear from me again, this was a success.
Edits: I am a gitnub, and struggling to make this pretty.
Edit2: IT WORKS.