search

morrownr / rtl8852bu

Linux Driver for USB WiFi Adapters that are based on the RTL8832BU and RTL8852BU Chipsets - v1.19.3 - 20230505
Other
105 stars 21 forks source link

(Info) Progress Log #2

Open morrownr opened 1 year ago

morrownr commented 1 year ago

Progress Log:

List of things that appear to be broken or unfinished:

ToDo:

Help is welcome.

Note: There are a massive amount of additions and changes from the WiFi 5 class Realtek out-of-kernel drivers.

Summary: Managed mode appears to be solid. Monitor mode and AP mode have had minimal testing so the status is mostly unknown, Monitor mode may not work as desired in all situations but that is true of almost all Realtek out-of-kernel drivers. I think this is a driver that can be released to the public but the driver appears to still be in development by Realtek and is fragile right now.

Performance report Test using managed mode and 5 GHz DFS channel:

$ iperf3 -c 192.168.1.1
Connecting to host 192.168.1.1, port 5201
[  5] local 192.168.1.184 port 45936 connected to 192.168.1.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  66.2 MBytes   556 Mbits/sec    0   1.89 MBytes       
[  5]   1.00-2.00   sec  67.5 MBytes   566 Mbits/sec    0   1.89 MBytes       
[  5]   2.00-3.00   sec  68.8 MBytes   577 Mbits/sec    0   1.89 MBytes       
[  5]   3.00-4.00   sec  70.0 MBytes   587 Mbits/sec    0   1.89 MBytes       
[  5]   4.00-5.00   sec  68.8 MBytes   577 Mbits/sec    0   1.89 MBytes       
[  5]   5.00-6.00   sec  70.0 MBytes   587 Mbits/sec    0   1.89 MBytes       
[  5]   6.00-7.00   sec  68.8 MBytes   577 Mbits/sec    0   1.89 MBytes       
[  5]   7.00-8.00   sec  70.0 MBytes   587 Mbits/sec    0   1.89 MBytes       
[  5]   8.00-9.00   sec  70.0 MBytes   587 Mbits/sec    0   1.89 MBytes       
[  5]   9.00-10.00  sec  68.8 MBytes   577 Mbits/sec    0   1.89 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   689 MBytes   578 Mbits/sec    0             sender
[  5]   0.00-10.01  sec   686 MBytes   575 Mbits/sec                  receiver

iperf Done.

Performance Test on a RasPi4B running RasPiOS: (the lower speed is likely due to my RasPi4B running headless)

RasPi4B:~ $ iperf3 -c 192.168.1.1
Connecting to host 192.168.1.1, port 5201
[  5] local 192.168.1.184 port 59510 connected to 192.168.1.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.05   sec  48.4 MBytes   386 Mbits/sec    0   1.07 MBytes       
[  5]   1.05-2.02   sec  51.2 MBytes   445 Mbits/sec    0   1.23 MBytes       
[  5]   2.02-3.00   sec  53.8 MBytes   458 Mbits/sec    0   1.30 MBytes       
[  5]   3.00-4.00   sec  52.5 MBytes   439 Mbits/sec    0   1.50 MBytes       
[  5]   4.00-5.01   sec  55.0 MBytes   456 Mbits/sec    0   1.50 MBytes       
[  5]   5.01-6.01   sec  53.8 MBytes   453 Mbits/sec    0   1.58 MBytes       
[  5]   6.01-7.02   sec  55.0 MBytes   458 Mbits/sec    0   1.58 MBytes       
[  5]   7.02-8.02   sec  55.0 MBytes   459 Mbits/sec    0   1.58 MBytes       
[  5]   8.02-9.00   sec  53.8 MBytes   459 Mbits/sec    0   1.58 MBytes       
[  5]   9.00-10.02  sec  55.0 MBytes   455 Mbits/sec    0   1.58 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.02  sec   533 MBytes   447 Mbits/sec    0             sender
[  5]   0.00-10.02  sec   533 MBytes   446 Mbits/sec                  receiver

iperf Done.

Packet Injection Test

$ sudo aireplay-ng --test wlx893a35b802a5
[sudo] password for xzxzxz: 
14:54:20  Trying broadcast probe requests...
14:54:22  No Answer...
14:54:22  Found 11 APs

14:54:22  Trying directed probe requests...
14:54:22  CC:BE:59:C0:16:E2 - channel: 11 - 'Lolli369#'
14:54:22  Ping (min/avg/max): 10.349ms/15.036ms/21.051ms Power: -74.17
14:54:22  30/30: 100%

14:54:22  Injection is working!

14:54:22  6C:CD:D6:E2:EC:F7 - channel: 10 - 'NETGEAR61'
14:54:28   0/30:   0%

14:54:28  10:33:BF:60:FA:32 - channel: 11 - ''
14:54:29  Ping (min/avg/max): 1.726ms/6.949ms/35.982ms Power: -39.00
14:54:29  30/30: 100%

14:54:29  10:33:BF:60:FA:36 - channel: 11 - ''
14:54:29  Ping (min/avg/max): 1.698ms/6.039ms/24.658ms Power: -39.03
14:54:29  30/30: 100%

14:54:29  10:33:BF:60:FA:34 - channel: 11 - ''
14:54:29  Ping (min/avg/max): 1.880ms/5.366ms/24.434ms Power: -39.90
14:54:29  30/30: 100%

14:54:29  CC:BE:59:3C:40:DA - channel: 11 - 'Lacys place'
14:54:30  Ping (min/avg/max): 11.869ms/21.771ms/141.221ms Power: -73.23
14:54:30  30/30: 100%
morrownr commented 1 year ago

I think I had to manually enable USB3 mode even for the 8852bu adapters, it wasn't done automatically...

The older drivers such as the 8812bu and 8812au definitely default to USB2 but can be changed to USB3 with a module parameter. Maybe I am mixing the 8852bu up with the Mediatek chipsets that autdetect USB mode. I sure thought the 8852bu could autodetect.

Thank you once more for the new kernels support! :)

I hope to have all needed kernel support done by the end of the weekend at the latest. It could have gone very fast but there have been a pile of changes in the code since the December version we last worked on. And some of those changes are causing me to have to dig in and sort things out.

The documents you created are good.

If you find any issues, go ahead create an issue here with details.

Nick

morrownr commented 1 year ago

Alkis,

I have updated the Progress Log. I'm testing with kernel 6.4.

We need testers so I am going tp go ahead and post messages asking for testers/helpers. It may be a challenge as I'm not sure how many Linux users have adapters with this chipset.

alkisg commented 1 year ago

Next week I'm going to give it a big testing myself, and if it seems better than the previous version, I'll push it to our apt repository, so we'll have a lot of testers...! :)

morrownr commented 1 year ago

So far, I am seeing rock solid managed mode operation. No drops at all. I am testing on my main dev box for the most part right now and I am seeing solid 580 Mbps with 5 Ghz AC 80 MHz channel width on DFS, I also have a PCIe card based on the mt7922 chipset and an adapter using the mt7921au chipset. Both of those devices are showing 620 Mbps in the same testing conditions. All 3 are rock solid. This is a lot more fun when things work.

Nick

morrownr commented 1 year ago

Alkis,

At this point, I think I have done everything you need in order for you to start testing. Please let me know if you find something you need.

Keep in mind that the architecture auto-detection is not installed yet so anything other than x86 will require you to make adjustments. I can go ahead and throw that in if it helps as there are ARM distros everywhere these days. My plan is to work on adding and testing the additional files and features that I use in the other repos while you test.

FWIW: I did a test on Ubuntu 20.04 with kernel 5.15. My router used for this test was set to Mixed WPA2/WPA3 5 GHz. The client failed during logon attempt. Ubuntu detected WPA3 but negotiation failed. I then set Ubuntu to use WPA2 and everything was fine. This does not happen on Ubuntu 22.04 and later. No problem with USB3 or the more modern distros. The problem is in the older underlying support in the older distros. This problem will show up on many distros that are more than about 2 years old. The problem is not with this driver.

FYI: It appears power saving is not functional yet. I noticed this in the release notes. I have not seen any problems resuming from suspend so that is working so this may be a non-issue.

I was thinking that we may have to go public with this repo once we think it is really as that may be the only way to get a reasonable amount of testing. What do you think?

Nick

morrownr commented 1 year ago

Hate to hear you are not feeling good. Get better soon.

I will port remarks next week as I find them.

Sounds good.

As my work and testing has continued, I am forming an opinion of this latest driver. This driver is very fragile. I have been testing with various Makefile options changed from default and with various module parameter settings. I am seeing a lot of breakage with compilation and function. This tells me that the testing is not well done. I've also been looking around in the source. There are a lot of ToDo's posted in the comments and some code that makes me wonder what they are thinking. If this was my project, I would call it an Alpha.

It is not clear to me why Realtek is continuing with this out-of-kernel driver format they are using. Support for the PCIe version of this chipset is already in the kernel. Basically all that would need to be done is add usb support similar to how it was done with the 88x2bu driver. The amount of wasted time that is taking place here is vast.

The driver is stable in managed mode. I haven't seen any drops. It might be a good idea for you to tell me before you download so that I can check to make sure the repo has the correct settings. I am still working on a lot of things as the little details are bogging me down. I have not tested with ARM yet and it is not clear to me how that will need to be handled as this new driver has invalidated the technique I developed for the WiFi 5 drivers. I also have not tested AP or monitor modes.

Nick

morrownr commented 1 year ago

Alkis,

Here is some news that is not very good. I tested on a RasPi4B using RasPiOS 64 bit. It failed. It appears there is some auto-detection of ARCH going on but the auto-detection is showing ARCH=aarch64 but we need ARCH=arm64. You and I realize they are the same thing but nobody has told gcc yet.

I am going through the code to determine a solution. I already have an idea or two but have not put if all together yet and may not for a while. Right now, the driver is limited to x86, x86_64 and amd64. The manual method of editing the Makefile has been convoluted badly in this new WiFi 6 driver so I don't even have a manual solution for you at this point. In fact, I still don't have the driver compiling on my RasPi. So many big changes have taken place that this is truly a challenge. We are on our own as there is no prior art to help us along. There seems to be little interest in the Linux community for working on these Realtek WiFi 6 drivers.

I still do not get why Realtek is putting a massive amount of work into these outdated out-of-kernel drivers when all they need to do is add USB support to rtw89. This is truly insane.

Nick

morrownr commented 1 year ago

Alkis,

I think I have auto-detect ARCH working and it is installing on all supported platforms, including RasPi. What a pain in the ass. It needs a LOT of testing.

I have other things that I think are ready but are not in the repo yet so send me a message before you download.

Hope you are feeling better.

Nick

morrownr commented 1 year ago

Hi Alkis,

Glad to hear that you are feeling better. Take care of yourself.

I just checked again and it appears I pushed everything I was working on last night. The only things that I am aware of right now that I need to work on are the files like README.md, FAQ.md and 8852bu.conf and it is all documentation related things. An example would be the hostapd adapter specific configuation lines which I have not had time to determine and test so far.

I did a test last night on my old x86 single core 32 bit system running kernel 4.19. No problems noted. It took 17 minutes to compile. The driver auto-detecting ARCH and all supported platforms have been tested and are working. I seem to have an idea of the changes Realtek is making in this regard but it is not clear at all why they are doing what they are doing.

I added one user to the repo yesterday so expect him to show up soon. One of the problems with attracting testers is that there is no existing driver already available so we will just have to work our way through it.

I consider managed mode to be very stable currently. Some I did with the edit-options.sh script is I added the capabilty that if it is started, it it does not detect that the 8852bu.conf file is installed, it will copy the version in the driver directory and then start editing it. I'm not sure if that is something you want but it is there.

Nick

alkisg commented 1 year ago

I built the driver on Ubuntu 22.04 with an OEM 6.1 kernel. It did show an UBSAN out of bounds error but other than that it appeared to work fine.

The logs in dmesg were a bit too much for my taste so I tried to compile with CONFIG_RTW_DEBUG=n, but that failed. I pushed a patch to fix that part.

I also compiled it on Raspberry Pi OS 32bit with an 6.1.21-v7+ armv7l kernel, it loaded OK. Tomorrow I'll do more tests!

morrownr commented 1 year ago

built the driver on Ubuntu 22.04 with an OEM 6.1 kernel. It did show an UBSAN out of bounds error but other than that it appeared to work fine.

I added that to the Progress Log ToDo section as: - fix UBSAN out of bounds error

I'll work that.

I tried to compile with CONFIG_RTW_DEBUG=n, but that failed.

Yes, I am aware of that. I have encountered that and some other situations when changing Makefile settings. Very annoying. I add it to ToDo as: - ask Realtek to fix CONFIG_RTW_DEBUG=n (compile fails with that setting)

Is that something you could write up and get to Realtek?

My opinion is that the default setting should be CONFIG_RTW_DEBUG=n as it can be turned on by devs.

I also compiled it on Raspberry Pi OS 32bit with an 6.1.21-v7+ armv7l kernel, it loaded OK. Tomorrow I'll do more tests!

Sounds good. I also need to work on part 2 of the support for kernel 6.5 as I just found something else when I turned on another setting in Makefile. Will work that tomorrow.

Added another tester today. He will have good access to WiFi 6 capable wifi routers.

Until tomorrow.

Nick

alkisg commented 1 year ago

A few years ago I've been having a lot of feedback from users like "oh look at this very alarming warning from dmesg, should I be worried about it?".

Since then I've been defaulting to CONFIG_RTW_DEBUG=n for the 8812au, 88x2bu, 8821cu and 8852bu drivers. I don't know if I missed any important clues, but I had fewer emails from worried users! :smile:

Here's the function I'm using to modify the Makefiles and disable the options in the .conf files, before shipping the drivers:

cmd_dh_install() {
    local rchip rversion

    rchip=$1
    rversion=$2
    re test -n "$rchip"
    re test -n "$rversion"
    re cd "$(dirname "$0")"
    re find . -type d -exec chmod 755 {} \;
    re find . -type f -not -name driverctl -exec chmod 644 {} \;
    re sed "s/$CHIP/$rchip/" -i driverctl
    re sed "s/$VERSION/$rversion/" -i driverctl
    re sed 's/^options/# &/' -i "$rchip.conf"
    test -f hal/phydm/phydm_debug.h &&
        re sed 's/\bprintk/_RTW_DBG/' -i hal/phydm/phydm_debug.h
    re sed 's/.*-Werror$/EXTRA_CFLAGS += -Wno-error/' -i Makefile
    re sed 's|^EXTRA_CFLAGS += -Wimplicit-fallthrough=3$|#&|' -i Makefile
    re sed 's|^\(CONFIG_RTW_DEBUG =\).*|\1 n|' -i Makefile
    re sed 's|^\(CONFIG_WIFI_MONITOR =\).*|\1 y|' -i Makefile
    re sed 's|^\(CONFIG_RTW_LOG_LEVEL =\).*|\1 0|' -i Makefile
    re sed 's|uname -m[^)]*|uname -m \| sed -e s/i.86/i386/ -e s/armv.l/arm/ -e s/aarch64/arm64/|' -i Makefile
    re cd -
}

Btw, to enable ARM builds, apart from that last sed command above, I'm also using the following make command (you call it make.sh, I call it driverctl make). This means that if ARCH is unset in the Makefile, then it's correctly set from the environment:

cmd_make() {
    local memavail nproc

    memavail=$(LANG=C free | awk '/Mem:/ { print $2 }')
    memavail=${memavail:-400000}
    nproc=$(($(nproc) - 1))
    test "$nproc" -ge 1 || nproc=1
    if [ "$memavail" -lt 400000 ] && [ "$nproc" -gt 1 ]; then
        # In low-RAM systems, use a single process to avoid OOM
        echo "Free RAM=$memavail Kb, limiting compilation processes from $nproc to 1"
        nproc=1
    fi
    # arch and kernelver are set by dkms, when it's used
    arch=${arch:-$(uname -m)}
    case "$arch" in
    i?86) arch=i386 ;;
    armv?l) arch=arm ;;
    aarch64) arch=arm64 ;;
    esac
    export ARCH="$arch"
    kernelver=${kernelver:-$(uname -r)}
    # Logs at e.g. /var/lib/dkms/rtl88???u/1.15.11/5.15.76-v8+/aarch64/log/make.log
    make all "ARCH=$ARCH" "-j$nproc" "KVER=$kernelver" "KSRC=/lib/modules/$kernelver/build"
}

Feel free to take whatever you like from that code, if it suits you.

morrownr commented 1 year ago

Since then I've been defaulting to CONFIG_RTW_DEBUG=n for the 8812au, 88x2bu, 8821cu and 8852bu drivers. I don't know if I missed any important clues, but I had fewer emails from worried users!

I'm going to take hard look at this again and make a desicion. My experience is that the logging is designed primarily for the needs of the Realtek devs and is only rarely useful to me in determining the problem.

Speaking of unneeded stuff... that is broken when you try to turn it off:

CONFIG_MP_INCLUDED = y

I'm working on AP mode right now but if you want to take a look at the above and see if it is an easy fix, go for it.

UBSAN out of bounds error

I was looking to see about a fix for this but can't find it. Where did you see?

Thanks for the code. Good stuff. Let me compare it and see how many good ideas I can borrow.

Speaking of good ideas... I need a good idea. You ever have something that you know you need to do but just can't get around to it? What I need is a little code added to install-driver.sh. The problem is that I do not have complete code for doing removals. The current code will remove manual installations and dkms installations if the driver version is the same as the driver you are installing but I need to the code to remove multiple previous dkms installations that have any driver version. You are welcome to take a look. This is the simgle biggest problem left in the installation script. Exaaple:

S dkms status

rtl8852bu/1.19.3, 6.2.0-24-generic, x86_64: installed rtl8852bu/1.19.3, 6.2.0-25-generic, x86_64: installed rtl8852bu/1.15.1, 6.2.0-24-generic, x86_64: installed rtl8852bu/1.15.1, 6.2.0-25-generic, x86_64: installed

In the above, the first two installations will be removed but the last 2 will not. If you find time to check out the code and see an idea, great.

alkisg commented 1 year ago

Nick you can use the following code to parse the output of dkms and remove all the module versions:

dkms status | sort -k1,1 -u | while IFS=" ," read -r modver ker arch installed; do
  mod=${modver%/*}
  ver=${modver#*/}
  arch=${arch%:}
  case "$mod" in *88x2bu)
    echo dkms remove -m "$mod" -v "$ver" --all
  esac
done

After testing, remove the echo in front of the dkms remove command.

Re: UBSAN, I'll post the exact error message and how to reproduce it later on.

alkisg commented 1 year ago

@morrownr would it make sense to rename this repository to 8852bu-20230505, to match the others?

morrownr commented 1 year ago

@alkisg

This is a question I have been thinking about for a long time. I'm leaning toward renaming to the existing naming scheme. What do you think?

It should be easy to change right before going public. Once the repo is public, it starts becoming a pain in the ass as places link to it.

The part 2 of kernel 6.5 support that came in today was me discovering something else when tdls support was turned on. I am continuing to dig.

Thanks for the code snippet above. Let me melt it into the script and test.

morrownr commented 1 year ago

I just added WiFi 6 testing on managed mode to the Progress Log. I tested both bands in AX. Nice.

At this point, the driver, other than a few known issues that are minor, seems to be solid so I am mostly going to be working on the documentation and scripts going forward.

Any problem with looking at a release (go public) date of August 01? Given that this is a new driver, I can't see holding off on releasing due to additional testing. If it was an existing driver with many users, we could pick up more help but I don't think that is going to happen.

Ah, we do need to decide which of the repo names to use:

8852bu-20230505

or

rtl8852bu

I have been using module name - driver release date (8852bu-20230505) for some time and it has worked well.

@morrownr

alkisg commented 1 year ago

Re: naming, I would go for a single repository with separate branches for each Realtek release.

With this scheme, "issues" and "discussions" would be the same for all branches. It should be possible to have commits like Fix UBSAN warning (#123), and that commit could be cherry-picked by many branches and still point to the correct issue.

morrownr commented 1 year ago

I would go for a single repository with separate branches for each Realtek release.

Agree.

The repository name would be rtl8852bu

Agree.

The branch name would be main

I don't like this. If there is going to be one branch, main is fine but if we go to a single repo, multiple branch setup then no branch should be called main. All branches should be named after their version number or date or both. My opinion of course. Remember that we can use "default" to set the default branch. I think "default" works better for what I think we are trying to accomplish here but my ears are open. You may have a different take on things.

Users would git pull normally

Agree.

When a new release is out, main would get renamed to 20230505, and main would then be the new release

Will it work better to use date, version or both? It would be best if Realtek just used release date as version but this is not what they do. Right now I have the lone branch we are working on named 1.19.3 which is the version number. If trying to be consist:

$ dkms status
rtl8852bu/1.19.3, 6.2.0-25-generic, x86_64: installed

dkms is using the driver name and version number. In looking around, that may be the most consistent naming we can use.

With this scheme, "issues" and "discussions" would be the same for all branches.

I'm not sure that this is a plus or minus. Let's say we add a new branch loaded with a new release. How do we keep users from reading old crap that no longer applies... without fully deleting the issue. Old information in the hands of users is one of the problematic issues with Linux, as is consistency, but that is another problem for another day. I'm not sure if maintaining more than one version is something that helps but maybe we could just delete the old branch if it is a problem.

The one thing I know for sure is that there currently is no prefect solution. How about we both think on this for a few days and revisit it?

@morrownr

morrownr commented 1 year ago

Alkis,

dkms status | sort -k1,1 -u | while IFS=" ," read -r modver ker arch installed; do
  mod=${modver%/*}
  ver=${modver#*/}
  arch=${arch%:}
  case "$mod" in *88x2bu)
    echo dkms remove -m "$mod" -v "$ver" --all
  esac
done

I ran into problems as soon as I tested something beyond the very modern x86 world.

The output of dkms status has varied over the last several years and dkms remove --all was making the code harder that it needs to be. Here is where I am at. I'm going to test with an old 32 bit distro with kernel 4.19 tomorrow. I'd appreciate you looking this over.

    dkms status | while IFS=" ,:/" read -r modname modver kerver xarch xstatus; do
        case "$modname" in *${MODULE_NAME})
            dkms remove -m "$modname" -v "$modver" -k "$kerver"
        esac
    done

We really don't need xarch and xstatus but I'm beat for tonight.

Thanks for getting me started.

alkisg commented 1 year ago

The output of dkms status has varied over the last several years

Nick do paste different dkms outputs if you need help with them; I've been testing on other arches but not on very old dkms versions.

dkms status | while IFS=" ,:/" read -r modname modver kerver xarch xstatus; do

It's fine to have a _dummy or _rest variable at the end to read the "rest of the line", e.g. read -r modname modver kerver _dummy. And with a dash in front of the variable name, shellcheck doesn't complain if you don't use the variable at all.

morrownr commented 1 year ago

I feel like a _dummy. ha ha

That is good. Getting this capability in solid shape would finish fixing one of the single biggest problems that I have seen which is installations blowing up because of already installed drivers, same version and earlier versions. It is not as bad as it used to be but this is the right thing to do. Do you have code in your installer that cleans previous installations out?

Another issue: we are setting IFS and I suspect that we shoulf immediately after use set it back to default as the consequences could be bad. What is your suggestion for setting IFS back to default?

I've been testing on other arches...

Are you seeing anything other than already known very minor issues? I'm not and I have 3 adapters running on 3 different systems. I am going to continue working on the docs and scripts unless something comes up.

I'm starting to see adapters based on the rtl8852cu chipset coming onto the market.

Nick

alkisg commented 1 year ago 
$ LANG=C date
Mon Jul 17 21:04:24 EEST 2023

$ echo "$LANG"
el_GR.UTF_8
(i.e. it's not C even if we set it to C above)

There's a feature in shell where if you run VAR=VALUE COMMAND, then VAR is set or modified for the duration of COMMAND, but that change doesn't persist for subsequent commands. This means that in while IFS=whatever read -r ..., the change in IFS only affects the read command, and there's no need to reset it to what it was before.

Re: installer, yes our "uninstallation command" is sudo apt purge rtl88x2bu-dkms, and this cleans up everything.

Re: other arches, I haven't noticed anything different. The main issue with the older version of the driver was "it disconnects after a while", but I haven't seen it yet with the current version of the driver. Fingers crossed...!

morrownr commented 1 year ago

Alkis,

What is your suggestion for setting IFS back to default?

I was doing some work and realized the above question was not asking what I really wanted to know. I know about the while IFS= thing. Let me post the current status of the routine:

# check for and remove all dkms installations with DRV_NAME
if command -v dkms >/dev/null 2>&1; then
    dkms status | while IFS=" ,/" read -r modname modver kerver _dummy; do
        if [ "$modname" = "$DRV_NAME" ]; then
            echo "->" "$modname"   "$modver"   "$kerver"
        fi
        case "$modname" in *${MODULE_NAME})
            dkms remove -m "$modname" -v "$modver" -k "$kerver"
        esac
    done
    if [ -f /etc/modprobe.d/${OPTIONS_FILE} ]; then
        rm -f /etc/modprobe.d/${OPTIONS_FILE}
    fi
    if [ -f /usr/src/${DRV_NAME}-${DRV_VERSION} ]; then
        rm -rf /usr/src/${DRV_NAME}-${DRV_VERSION}
    fi
fi

The current While IFS= ; do ; done should stay local to while. The issue is that we have the following line that is still using the local IFS:

dkms remove -m "$modname" -v "$modver" -k "$kerver"

I would like to use IFS=" ,-/" in place of the existing IFS as a old version of dkms used to use - instead of / but if I do that, it breaks the above dkms remove statement. dkms has some inconsistencies and I may need to do a side trip to snoop around in the dkms source. What I was thinking was if I could temporarily use a different (the default) IFS only for the dkms remove... statement above, it would solve the issue.

Hopefully this explanation is better. My head hurts. This making sure things are fully compatible going back in time is a pain. I limit support to nothing older than kernel 4.19 in the docs currently, but even that is a challenge.

If someone wants support with anything earlier than kernel 4.19, they need to get their checkbook out.

alkisg commented 1 year ago

The current While IFS= ; do ; done should stay local to while.

No. IFS only applies to the read command. It doesn't apply to the while command block. I.e. the dkms remove command is using the default IFS, not the modified IFS.

See the example below, which proves that inside the while, hexdump sees the default IFS, which is "space tab enter".

date | while IFS=" ,-/" read -r var; do echo "$IFS" | hexdump -C; done
00000000  20 09 0a 0a                                       | ...|
morrownr commented 1 year ago

Thanks. A lot of good info there.

Same here. I have beat up managed mode and am not seeing any drops or problems at all. My testing of the other modes has been limited but have not seen problems there either. Since you use different scripts and docs, I'd say anytime you decide to push an update, it would work. I'd like to hold onto a schedule of August 01 as the day to make the repo public so as to give me some time to get my docs and scripts in reasonable shape. I'm not going to have everything perfect as that will take some time.

One thing I will predict is there will be complaints about weak signals just based on how some of the wifi routers are setup these days and it will get worse with the rtl8852cu chipset as 6 GHz is thrown in there.

Nick

morrownr commented 1 year ago

Alkis,

UBSAN: shift-out-of-bounds in /var/lib/dkms/rtl8852bu/1.19.3/build/phl/hal_g6/phy/bb/halbb_interface.c:212:44 shift exponent 32 is too large for 32-bit type 'unsigned int'

Does that look familiar?

alkisg commented 1 year ago

Nick yeh, that's quite possibly the issue I've seen, thanks a bunch! I'm still waiting for feedback from the users that had "connection drops", to tell me if the newer driver is more stable...

alkisg commented 1 year ago

How do we keep users from reading old crap that no longer applies... without fully deleting the issue.

Closed issues are only used as references. E.g. if a git commit points to issue #123, users can go read the discussion that led to the code. Or if a user asks for help, someone that knows the solution may point them to issue #234. Issues are NOT documentation. They are not at all guaranteed to contain current information. E.g. if someone goes to read issue #123 from the Linux kernel from 1992, it's almost certain that the information there won't apply anymore.

Documentation must always be up to date. Issues do not have that restriction.

The best we can do is to handle issues in the manner they're designed for. If they users use them wrong, then it's up to them to change their behaviour; fortunately most users already know that information in old issues may not apply anymore.

morrownr commented 1 year ago

that's quite possibly the issue I've seen, thanks a bunch!

I finally saw it the log. It must appear sporadically. Anyway, after some research, I think it is fixed but since it does not show up consistently, it would be good if you can keep an eye on it.

Also, I merged support for kernel 6.4 today and it is not normal. A backport from kernel 6.5 went into kernel 6.4.4 requiring a change.

The best we can do is to handle issues in the manner they're designed for.

Okay. We can always simply delete issues that have information that causes problems so I'm good with the driver name being the repo name and using it as a single, permanent repo.

alkisg commented 1 year ago

Heya Nick, yesterday I packaged and released snapshots of 8812au, 88x2bu, 8821cu and 8852bu. These will be used only in new installations (the next repository). If users report they're stable, in a couple of weeks I'll migrate them to the stable repository and thousands of users will get and test them. I'll post any findings to the corresponding repositories. Thanks again!

morrownr commented 1 year ago

Alkis,

I don't remember if I gave you the details of a recent problem that has caused me a lot of work. You need to know because it could show up in unexpected ways.

A change that originally went into kernel 6.5 was backported. Originally if was backported to kernel 4.4. I handled both situations for all 6 drivers. Then the bug reports started flowing and eventually I figured out that it had been backported all the way to kernel 6.1.38, Here is where things get messy. Kernel 6.2 is no longer supported so no backport but some distros use 6.2 so will they grab and merge the backport into their 6.2? Things seem to have calmed down so maybe things are good. If you look in the patches that say something about kernel 6.5, you can track down what I did.

alkisg commented 1 year ago

What's the symptom, "compilation failure" or "the module will compile/load but it won't work properly"?

morrownr commented 1 year ago

Compilation failure See:

https://github.com/morrownr/88x2bu-20210702/issues/165

alkisg commented 1 year ago

I tested all drivers yesterday in a lot of distributions and I haven't seen that, so ...great work! :)

morrownr commented 1 year ago

That is good news. I'm not declaring victory but the best option right now is likely just to be aware of it. It is very easy to spot so if you see it, get the distro name, distro version and kernel version so I can see how it fits into the puzzle.

Something I have failed to do and I think I owe this to you so that you better understand who you are working with:

I learned programming with FORTRAN on an IBM Mainframe while in college. I was an Economics major but a few classes in ComSci was required and I enjoyed it. This, of course, predates things like mice, keyboards and even monitors which makes it clear that I am not a young person. My history of operating systems on small computers goes like this: CP/M, PC-DOS, DR-DOS, OS/2 and Linux. There were also a couple of proprietary operating systems in the mix. I have programmed with many languages: FORTRAN, BASIC, Pascal, Rexx, Assembly, various scripting lanaguages and C (yuk). I do not like C but I have a couple of good reference books that I use. I have some experience with device drivers on older platforms but this is my first work on Linux device drivers. My previous experience with device drivers was not something for public use. We had hardware that provided 100% of the needed information and it was fun. Working in a situation where inadequate information and trial and error is the norm is not as fun. Anyway, my primary career was in aviation and after retiring from that, I taught at the college level for 10 years and then retired for real.

Hopefully that gives you an idea of who you are dealing with. I am no expert on Linux wifi programming but my long background in programming gives me the ability to figure a lot of things out given enough time to do so. If you see something and there is a better solution, please tell me. I often come up with a solution that works but it is not optimal so over time, I would toward more efficient solutions.

Cheers

morrownr commented 1 year ago

FYI: I found another UBSAN issue and think it has been solved. You can look at the fix for more info.

Also, I have been slowly working on the low hanging fruit as far as the logging goes. The log is much cleaner now but far from what we would like. I have not merged the changes yet but intend to do so this weekend.

There are places where the code needs to be worked on but for now, unless I see an operational error, I'm not touching it.

Here is an observation:

Both iperf3 outputs below are from the same computer with the adapters being collocated and connecting to the same AP:

Driver: rtl8852bu

$ iperf3 -c 192.168.1.1 Connecting to host 192.168.1.1, port 5201 [ 5] local 192.168.1.110 port 51300 connected to 192.168.1.1 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 13.0 MBytes 109 Mbits/sec 0 512 KBytes
[ 5] 1.00-2.00 sec 40.8 MBytes 342 Mbits/sec 0 1.85 MBytes
[ 5] 2.00-3.00 sec 68.8 MBytes 577 Mbits/sec 0 1.85 MBytes
[ 5] 3.00-4.00 sec 70.0 MBytes 587 Mbits/sec 0 1.85 MBytes
[ 5] 4.00-5.00 sec 68.8 MBytes 577 Mbits/sec 0 1.85 MBytes
[ 5] 5.00-6.00 sec 68.8 MBytes 577 Mbits/sec 0 1.85 MBytes
[ 5] 6.00-7.00 sec 70.0 MBytes 587 Mbits/sec 0 1.85 MBytes
[ 5] 7.00-8.00 sec 68.8 MBytes 577 Mbits/sec 0 1.85 MBytes
[ 5] 8.00-9.00 sec 67.5 MBytes 566 Mbits/sec 0 1.85 MBytes
[ 5] 9.00-10.00 sec 70.0 MBytes 587 Mbits/sec 0 1.85 MBytes

[ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 606 MBytes 509 Mbits/sec 0 sender [ 5] 0.00-10.01 sec 604 MBytes 507 Mbits/sec receiver

Driver: mt7921

$ iperf3 -c 192.168.1.1 Connecting to host 192.168.1.1, port 5201 [ 5] local 192.168.1.127 port 59762 connected to 192.168.1.1 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 68.6 MBytes 576 Mbits/sec 0 1.91 MBytes
[ 5] 1.00-2.00 sec 75.0 MBytes 629 Mbits/sec 0 1.91 MBytes
[ 5] 2.00-3.00 sec 73.8 MBytes 619 Mbits/sec 0 1.91 MBytes
[ 5] 3.00-4.00 sec 73.8 MBytes 619 Mbits/sec 0 1.91 MBytes
[ 5] 4.00-5.00 sec 75.0 MBytes 629 Mbits/sec 0 1.91 MBytes
[ 5] 5.00-6.00 sec 72.5 MBytes 608 Mbits/sec 0 1.91 MBytes
[ 5] 6.00-7.00 sec 75.0 MBytes 629 Mbits/sec 0 1.91 MBytes
[ 5] 7.00-8.00 sec 75.0 MBytes 629 Mbits/sec 0 1.91 MBytes
[ 5] 8.00-9.00 sec 73.8 MBytes 619 Mbits/sec 0 1.91 MBytes
[ 5] 9.00-10.00 sec 73.8 MBytes 619 Mbits/sec 0 1.91 MBytes

[ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 736 MBytes 618 Mbits/sec 0 sender [ 5] 0.00-10.00 sec 733 MBytes 615 Mbits/sec receiver

My thoughts: The adapter using the rtl8852bu has a slightly better signal level (51 vs 53) which is due to the amp/antennas in use but are very close which takes that out as a cause. Note that the mt7921 driver jumps up to full speed quicker and is faster overall. Here is all there is in the log for the mt7921 driver:

$ sudo dmesg | grep mt79 [sudo] password for morrow: [ 10.241512] mt7921e 0000:03:00.0: enabling device (0100 -> 0102) [ 10.249380] mt7921e 0000:03:00.0: ASIC revision: 79220010 [ 10.342645] mt7921e 0000:03:00.0: HW/SW Version: 0x8a108a10, Build Time: 20230627143702a [ 10.360311] mt7921e 0000:03:00.0: WM Firmware Version: ____000000, Build Time: 20230627143946 [ 11.887353] mt7921e 0000:03:00.0 wlp3s0: renamed from wlan0

I have been doing comparisons of the two drivers the entire time I have been working on the rtl8852bu driver. The mt7921 driver is currently much better than the rtl8852bu.

alkisg commented 1 year ago

Heya Nick. Thank you for all the information! I'm a bit time-pressed this month (but in a good way that involves sea vacations :)), so some quick answers. You may find some info about my background here. While regarding the opening of this repository to the public, the only thing that I can think of, is that maybe we could delete the personal information. But I don't mind much if it stays online either!

morrownr commented 1 year ago

Enjoy your time at sea. I will go ahead and scan this issue to see if anything personal should be deleted.

Concerning the issue about market share we discussed. Here is a filtered list from the OpenWRT database of supported devices:

https://openwrt.org/toh/views/toh_available_16128_ax-wifi

The list is filtered to only show WiFi 6 devices. The companies with the most market share are Mediatek, Qualcomm and Broadcom but you don't see Broadcom on this list because Broadcom is persona non grata due to its terrible Linux support. My main router uses Qualcomm chips.

Back to the topic at hand. I merged one big patch yesterday that included a lot of things that I had been testing. I guess we will see what happens after the driver is public.

Have fun. Wish I was there,

Nick

alkisg commented 1 year ago

Some good news:

A user was complaning "connection drops after a few minutes" with the older version of this driver. With this new version, he reported that the problem is fixed!

morrownr commented 1 year ago

That is good news. The old version had a problem. This one seems solid in managed mode.

I opened the repo so between your users and the repo, it is time to figure out what is not working.

morrownr commented 1 year ago

@alkisg

Usage report:

In 8 days we have had 37 clones and 2 bug reports. Both bug reports were from the same user and ended up being very minor. One edit to install-driver.sh and one edit to remove-driver.sh. Both bugs were closed by the user as fixed.

This is a very light amount of clones but we expected that, It is interesting that we have exactly zero bug reports on driver code. There is a list of cosmetic things that don't work. The list is in msg 1 of this thread.

The single biggest annoyance to me is the terrible logging in this driver. I've trying to shut as much as I can down but there is still ugliness in the system log and it is stuff that seems to have little effect on the operation of the driver. I wish that was cleaned up because it will worry some users.

So, we can wait for bug reports.

Cheers

p7x404 commented 1 year ago

Sorry if it's not the best place to do it, but wanted to provide you with some feedback.

First of all : thanks a lot for this driver !

I have an AX4L from Brostrend and had a strange behaviour with the provided drivers : download/upload rate were good, but the performance wasn't so good overall :

morrownr commented 1 year ago

@p7x404

Sorry if it's not the best place to do it, but wanted to provide you with some feedback.

You are welcome to post here or create your own issue. Feedback is VERY welcome. Alkis and I are the only ones that have worked on and tested this driver. Please keep coming back as you have more to add.

instability (the connection would suddenly be dropped)

Been there, done that. We have actually been trying to get this driver available for some time. This release is based on fresh source. The version you had may have been based on the older 1.15.x code which I found to be unstable just like you. I don't release drivers unless it is something I would use.

Since this release has had very limited testing, please report even the most minor problem... misspelled words, bad installation instructions and anything that is not clear in the docs.

Thanks again for the feedback.

@morrownr

alkisg commented 1 year ago

@p7x404 Brostrend is actually using the same 8812au, 88x2bu, 8821cu and 8852bu drivers as the ones found in Nick's repositories, and contributing as much as possible. It's an excellent showcase of open source cooperation! :)

Thank you too for your feedback!

p7x404 commented 1 year ago

@alkisg Okayyyy, looks like I was just too impatient ! Thanks for your reply that can be deleted 🙂

p7x404 commented 1 year ago

@morrownr

Alkis and I are the only ones that have worked on and tested this driver. Please keep coming back as you have more to add.

I'll sure do. If I can be of any help in testing, don't hesitate to ask.

morrownr commented 1 year ago

@p7x404

If I can be of any help in testing, don't hesitate to ask.

Alright. This is me asking.

When you install, is it clear what you have to do to turn USB3 mode on?

You can check the usb mode with:

$ lsusb -t

Also, I need you to test updating the driver. Go to the driver directory in a terminal:

$ git pull $ sudo sh install-driver.sh

...and let me know if everything works and is understandable.

Thanks

morrownr commented 1 year ago

@alkisg

I merged a fairly good size patch today. I was testing with gcc 13 and kernel 6.5. There were a couple of warnings that I shut down with the intent of going back later to fix. I haven't seen any operational issues so no emergency. I did some work in the Makefile... fixed a couple of things that could be problems going forward. Sometimes things don't look as good when you go over things again. There was also editing in the docs and yesterday I merged a patch with code fixes.

This is all I have for now. I'm mostly going to go into wait and see mode with this driver until we see bug reports. Once some time has pasted, I'll look at merged the docs and script changes into rtl8821cu so as to see if there are any problems before merging the changes into the rest of the drivers. We actually made some pretty good progress with install-driver.sh.

@morrownr

alkisg commented 1 year ago

Thank you Nick. We've been using this driver in production for more than 2 weeks now, we didn't get any negative feedback, it's definitely better than the previous version!