The difference between kernels 4.1 and 4.2 was commit d10101a60372 (rtlwifi: rtl8821ae: Fix problem with regulatory information). Previous to that point, the driver used a channel plan for the world that included all three 5 GHz bands. The patch changed the driver to use the information in the EEPROM to set the band.

If possible, I would like you to clone the git repo at http://github.com/lwfinger/rtlwifi_new.git. Once you have that running, there will be an easier means of getting diagnostic logging.

By the way, my RTL8821AE chip has the FCC channel plan in its EEPROM, and it works correctly with the low and high 5G bands enabled; however, not all vendors program the EEPROM correctly.

Too bad that the DWA 582 seems to be the only device with the RTL8812AE chip. I have no hardware that supports that kind of PCI Express adapter. I can only use mini-PCIe cards.

This bug is likely the same as reported at https://bugzilla.redhat.com/show_bug.cgi?id=1279653.

I installed the 4.4 kernel using Manjaro's kernel tool and then I installed the rtlwifi_new-dkms package in the Arch User Repo (https://aur.archlinux.org/packages/rtlwifi_new-dkms/). It basically git clones your master branch, builds the driver, and blacklists the modules bundled with the kernel. I rebooted and now I'm running the rtlwifi_new driver but the issue remains. I can only see 2.4 GHz APs. Here is some output you may find useful: http://pastebin.com/raw/9Eb8teCj

That output was useful. At least the very last line was. For country code 11, routine _rtl_regdomain_select() was selecting only 2.4 GHz channels. I just pushed a change that will also select 5G channels as well.

I have no idea how long it takes Arch to complete their process, but the source change is there now.

The script does a git clone every time the package is updated, so the changes should be instant. I've updated the package and 5 GHz is working now. :)

Created attachment 200611 [details]
Patch to add 5G channels to the channel plan

The problem with the D-Link DWA-582 is that the country code is improperly encoded in the EEPROM. This problem leads to the driver selecting a channel plan that only includes 2.4 GHz channels. This patch changes that tp allow both 2.4 and 5 GHz bands.

I think this bug can be closed. The patch will be submitted to the wireless tree.

Created attachment 201981 [details]
Test patch to log channelplan

If possible, please add the following patch to the kernel code and tell me the value of the channelplan read from efuse.

The Realtek engineer is worried that the previous fix will fail with 2.4G-only devices. I think we are OK, but I would like the above info just in case.

The wifi card is in my HTPC which is running an old Intel dual-core with only 2 GB of RAM and has a 16 GB SSD so compiling took much longer than expected. Not an issue though since I decided to compile it on my powerful machine and then just transfer the kernel over wifi.

[owner@TV-PC ~]$ dmesg | grep channel
[    4.006910] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    4.659604] rtlwifi: **** channelplan 52

Thanks for the effort. I have sent that channelplan info to the engineer at Realtek.

That channelplan is for US/Canada. I am surprised that it was not in the regulatory info.

The new channelplan has been added to the master branch of the git repo at http://github.com/lwfinger/rtlwifi_new.git. Please pull, make and install it. That should work without turning on 5G channels in devices that only have 2.4G radios, which worries the Realtek engineer. My tests show that mac80211 and cfg80211 handle that case correctly, but I do want to keep him happy.

Thanks.

I can confirm that 5 GHz is still working with the DWA-582 on the latest commit (53d85a2661a413972720e8cc206c666b703d2842)

Thanks for testing. The other patch has already been sent upstream for 4.5, but I will be reverting it and supplying this patch for mainline.

>Too bad that the DWA 582 seems to be the only device with the RTL8812AE chip.
>I have no hardware that supports that kind of PCI Express adapter. I can only
>use mini-PCIe cards.

As a side-note, I found this neat website: https://wikidevi.com/wiki/Realtek#ac

It lists all the Realtek chips: https://i.imgur.com/AuLGxEA.png

And if you click on the "7 devices" link in the top right corner under the "Adapters" column, it lists a bunch of devices that use that chip: https://i.imgur.com/4O31tnH.png

So from the chart, it seems the SparkLAN WPET-232ACN is a mini-PCIe card that uses the RTL8812AE chip. Not that you need to purchase a RTL8812AE though since I'm happy to provide any debugging information required as long for as I own this card (which is pretty much forever).

This bug has a code fix already in mainline. Pleas close it. I do not have privilege.

Hmm, I decided to try out Linux 4.5-rc4 and 5 GHz still seems to be not working. It can scan the channels but it can't connect. I tried the rtlwifi driver immediately after and it worked. There seems to be a difference between rtlwifi and the in-kernel driver that stops it from working. I'm going to build the kernel from scratch just to make sure.

The weird thing is that IIRC, the in-kernel driver was working when I tested it in comment #7.

Of course there is a difference between rtlwifi_new and the kernel. I can immediately submit changes to the former. Fixes for the latter take a long route getting to mainline.

If you are getting a WARNING in dmesg, that is a second fix that just hit mainline since last Sunday.

It looks like it worked when I compiled the latest commit manually. Either it was fixed between rc4 and the latest commit or the pre-compiled kernel by the Manjaro devs is incorrectly configured. Either way, I don't think it's related to this bug report so I've put in the 'resolved' state again.