search

morrownr / 88x2bu

Linux Driver for USB WiFi Adapters that are based on the RTL8812BU and RTL8822BU Chipsets
435 stars 73 forks source link

(solved-finally) Driver options #53

Closed GeneDot3 closed 2 years ago

GeneDot3 commented 3 years ago

Could you please give advice on how to interrogate, and potentially modify, the various driver options found when you issue the "ls /sys/module/88x2bu/parameters" command?

Thanks in advance.

morrownr commented 3 years ago

Certainly.

Open a terminal Change to the driver directory - $ cd ~/src/88x2bu Run - $ sudo ./edit-options.sh

That script puts you in the nano editor that is editing the file 88x2bu.conf

That file documents and sets defaults for the parameters (options) that I thought would be useful for most users that would be looking for drivers here. Realtek does a terrible job of documenting the parameters. Massive amounts of research, code reading and testing is what I used to document the parameters that I documented.

A lot of the undocumented parameters are just that, undocumented. Simple things can take an incredible amount of work when working on these Realtek drivers. I'm trying to help one of the other users here get to the bottom of why WPA3 doesn't work. WPA3 works wonderfully with my mt7612u based adapters. It does WPA3 and WPA3 Transitional in managed, master and monitor modes flawlessly. But then the mt7612u driver is in-kernel and is well maintained and is Linux Wireless standards compliant.

I maintain these Realtek drivers as pay back to the community. Hopefully it helps new users that are bringing existing adapters. That does not make me a fan of Realtek. I am not. I do not recommend that Linux users spend new money on Realtek based adapters. When Realtek gets their USB WiFi drivers in the kernel, where they belong, we can readdress my opinion of Realtek.

GeneDot3 commented 3 years ago

thanks for the info, I thought there might be a listing of all the parameters and their defaults, I guess not then. Very good work, Sir. Kudos for the intense work it must have been. Best regards,Gene

On Wednesday, March 17, 2021, 4:53:35 PM EDT, morrownr ***@***.***> wrote:

Certainly.

Open a terminal Change to the driver directory - $ cd ~/src/88x2bu Run - $ sudo ./edit-options.sh

That script puts you in the nano editor that is editing the file 88x2bu.conf

That file documents and sets defaults for the parameters (options) that I thought would be useful for most users that would be looking for drivers here. Realtek does a terrible job of documenting the parameters. Massive amounts of research, code reading and testing is what I used to document the parameters that I documented.

A lot of the undocumented parameters are just that, undocumented. Simple things can take an incredible amount of work when working on these Realtek drivers. I'm trying to help one of the other users here get to the bottom of why WPA3 doesn't work. WPA3 works wonderfully with my mt7612u based adapters. It does WPA3 and WPA3 Transitional in managed, master and monitor modes flawlessly. But then the mt7612u driver is in-kernel and is well maintained and is Linux Wireless standards compliant.

I maintain these Realtek drivers as pay back to the community. Hopefully it helps new users that are bringing existing adapters. That does not make me a fan of Realtek. I am not. I do not recommend that Linux users spend new money on Realtek based adapters. When Realtek gets their USB WiFi drivers in the kernel, where they belong, we can readdress my opinion of Realtek.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

morrownr commented 3 years ago

Gene, I do have information on a few more parameters but it is for parameters that should not be high interest items and the info is not organized. If anyone asked a question that can be solved with one of the undocumented parameters that I am familiar with then I will provide the best answer I can. If you run onto good documentation on a parameter that you think should be documented, please write it up and submit it so we can make the information available. Do keep in mind that most folks that show up here are just looking to get their adapter going in managed mode and they want the installation to be simple and painless. If we make the docs longer and more complicated, that is more information than maybe is necessary and it hurts the installation experience. It is a judgement call.

GeneDot3 commented 3 years ago

Thanks for letting me know, I will keep that in mind also. I do have a question regarding the log parameter, I tried and keep getting the question " did I enter an number > 0 ", it doesn't seem to work for me. Best regards,Gene

On Thursday, March 18, 2021, 1:44:24 PM EDT, morrownr ***@***.***> wrote:

Gene, I do have information on a few more parameters but it is for parameters that should not be high interest items and the info is not organized. If anyone asked a question that can be solved with one of the undocumented parameters that I am familiar with then I will provide the best answer I can. If you run onto good documentation on a parameter that you think should be documented, please write it up and submit it so we can make the information available. Do keep in mind that most folks that show up here are just looking to get their adapter going in managed mode and they want the installation to be simple and painless. If we make the docs longer and more complicated, that is more information than maybe is necessary and it hurts the installation experience. It is a judgement call.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

morrownr commented 3 years ago

Gene, it sounds like you are running the 'save-log.sh' script. That script is designed to extract only the lines that apply to this driver from the main dmesg log file. If there are no lines related to this driver in the dmesg log file, then you get the message you are seeing. That indicates that you have left the driver log file parameter (option) at its default of zero. Zero turns logging off. Logging is for troubleshooting so there is no need for us to waste cpu time when we are not troubleshooting.

You need to set a non-zero number on the rtw_drv_log_level parameter in the 88x2bu.conf file.

Run $ sudo ./edit-options.sh from the driver directory and modify the line that starts with options

Change the zero after rtw_drv_log_level= to 4 and then, ctrl-x, y, enter to save the file. Reboot and try save-log.sh again.

GeneDot3 commented 3 years ago

I guess I did not explain well. I tried 4 and 6 in the options setting 'sudo ./edit-options.sh', rebooted and tried saving using the 'save-log.sh' script.  I tried several times just as a test and got no log because somehow it did not recognize the number I entered. |

On Thursday, March 18, 2021, 4:03:51 PM EDT, morrownr ***@***.***> wrote:

Gene, it sounds like you are running the 'save-log.sh' script. That script is designed to extract only the lines that apply to this driver from the main dmesg log file. If there are no lines related to this driver in the dmesg log file, then you get the message you are seeing. That indicates that you have left the driver log file parameter (option) at its default of zero. Zero turns logging off. Logging is for troubleshooting so there is no need for us to waste cpu time when we are not troubleshooting.

You need to set a non-zero number on the rtw_drv_log_level parameter in the 88x2bu.conf file.

Run $ sudo ./edit-options.sh from the driver directory and modify the line that starts with options

Change the zero after rtw_drv_log_level= to 4 and then, ctrl-x, y, enter to save the file. Reboot and try save-log.sh again.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

morrownr commented 3 years ago

Well, we need to figure out what is going on. Can you run edit-options.sh then copy and paste the options line here?

The default is as follows:

options 88x2bu rtw_drv_log_level=0 rtw_led_ctrl=1 rtw_vht_enable=1 rtw_power_mgnt=1 rtw_switch_usb_mode=0

The line modified to enable log level 4 would look like this:

options 88x2bu rtw_drv_log_level=4 rtw_led_ctrl=1 rtw_vht_enable=1 rtw_power_mgnt=1 rtw_switch_usb_mode=0

GeneDot3 commented 3 years ago

This is what I have:options 88x2bu rtw_drv_log_level=4 rtw_led_ctrl=1 rtw_vht_enable=1 rtw_power_mgnt=0 rtw_switch_usb_mode=1 I had to make the 'rtw_switch_usb_mode=1" because when I displayed the usbports using 'lsusb -t' the speeds were incorrect. Best Regards,Gene

On Friday, March 19, 2021, 8:28:16 AM EDT, morrownr ***@***.***> wrote:

Well, we need to figure out what is going on. Can you run edit-options.sh then copy and paste the options line here?

The default is as follows:

options 88x2bu rtw_drv_log_level=0 rtw_led_ctrl=1 rtw_vht_enable=1 rtw_power_mgnt=1 rtw_switch_usb_mode=0

The line modified to enable log level 4 would look like this:

options 88x2bu rtw_drv_log_level=4 rtw_led_ctrl=1 rtw_vht_enable=1 rtw_power_mgnt=1 rtw_switch_usb_mode=0

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

GeneDot3 commented 3 years ago

Also. while I was looking at the list of parameters I noticed 2 things: there is no 'rtw_drv_log_level' listed and there is one named 'rtw_advnace_ota' that looks like it may be a typo for 'rtw_advance_ota'.  

On Friday, March 19, 2021, 8:28:16 AM EDT, morrownr ***@***.***> wrote:

Well, we need to figure out what is going on. Can you run edit-options.sh then copy and paste the options line here?

The default is as follows:

options 88x2bu rtw_drv_log_level=0 rtw_led_ctrl=1 rtw_vht_enable=1 rtw_power_mgnt=1 rtw_switch_usb_mode=0

The line modified to enable log level 4 would look like this:

options 88x2bu rtw_drv_log_level=4 rtw_led_ctrl=1 rtw_vht_enable=1 rtw_power_mgnt=1 rtw_switch_usb_mode=0

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

GeneDot3 commented 3 years ago

I found what may be the culprit, there is a '!' in front of the '="0" ' this typically makes it a 'not equal' equation.'if [[ "$RESULT" != "0" ]]; then         echo "An error occurred while running: ${SCRIPT_NAME}"         echo "Did you set a log level > 0 ?"         exit 1' I removed the '!' and it said it ran, but there was no output.  :-( Gene

On Friday, March 19, 2021, 8:28:16 AM EDT, morrownr ***@***.***> wrote:

Well, we need to figure out what is going on. Can you run edit-options.sh then copy and paste the options line here?

The default is as follows:

options 88x2bu rtw_drv_log_level=0 rtw_led_ctrl=1 rtw_vht_enable=1 rtw_power_mgnt=1 rtw_switch_usb_mode=0

The line modified to enable log level 4 would look like this:

options 88x2bu rtw_drv_log_level=4 rtw_led_ctrl=1 rtw_vht_enable=1 rtw_power_mgnt=1 rtw_switch_usb_mode=0

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

GeneDot3 commented 3 years ago

I must apologize for all these individual emails, I had 2 teeth extracted yesterday and perhaps not thinking clearly enough to get all the info intoone email. I found this line in 'journalctl' - Mar 19 10:31:59 GEMAPiFRX kernel: 88x2bu: unknown parameter 'rtw_drv_log_level' ignored

Best Regards,Gene

On Friday, March 19, 2021, 8:28:16 AM EDT, morrownr ***@***.***> wrote:

Well, we need to figure out what is going on. Can you run edit-options.sh then copy and paste the options line here?

The default is as follows:

options 88x2bu rtw_drv_log_level=0 rtw_led_ctrl=1 rtw_vht_enable=1 rtw_power_mgnt=1 rtw_switch_usb_mode=0

The line modified to enable log level 4 would look like this:

options 88x2bu rtw_drv_log_level=4 rtw_led_ctrl=1 rtw_vht_enable=1 rtw_power_mgnt=1 rtw_switch_usb_mode=0

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

morrownr commented 3 years ago

Quote: "Also. while I was looking at the list of parameters I noticed 2 things: there is no 'rtw_drv_log_level' listed and there is one named 'rtw_advnace_ota' that looks like it may be a typo for 'rtw_advance_ota'. "

Where are you seeing this?

Quote: "there is a '!' in front of the '="0""

It needs to be there for the logic to work.

Are you get output if you run the sollowing?

$ sudo dmesg

GeneDot3 commented 3 years ago 
On Friday, March 19, 2021, 11:14:25 AM EDT, morrownr ***@***.***> wrote:

Quote: "Also. while I was looking at the list of parameters I noticed 2 things: there is no 'rtw_drv_log_level' listed and there is one named 'rtw_advnace_ota' that looks like it may be a typo for 'rtw_advance_ota'. " Where are you seeing this? ***** in the listing I get when I issue the 'ls /sys/module/88x2bu/parameters' cmd

Quote: "there is a '!' in front of the '="0"" It needs to be there for the logic to work. ***** When I remove the line it seemed to pass on to exit1, I have since removed the parameter because in 'journalctl' there was a line indicating there was no such parameter

Are you get output if you run the sollowing?

$ sudo dmesg ***** Yes, I get info from this command, there are no lines beginning with 'rtw', however I see one line that mentions 88x2bu:[    5.354220] 88x2bu: loading out-of-tree module taints kernel.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

morrownr commented 3 years ago

@GeneDot3

I'm going to be busy for the next few days but will take another look at this when able.

GeneDot3 commented 3 years ago

not a problem

On Saturday, March 20, 2021, 2:32:23 PM EDT, morrownr ***@***.***> wrote:

@GeneDot3

I'm going to be busy for the next few days but will take another look at this when able.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

morrownr commented 3 years ago

Gene,

I hope your mouth is better at this point. Now, where are you with the issue?

GeneDot3 commented 3 years ago

Much better, thanks. Ok, I have removed the option for "logs" because a line was showing up in "journalctl" referencing it as an invalid option. I have not tried any of the options listed in the full  listing that results from the "ls/sys/module/88x2bu/parameters" cmd. I would really like to be able to get a display of the current settings in the chip, but unable to without log function, I think?

I guess I found out the hard way that changing this setting from 0 to 1:# USB mode options: ( rtw_switch_usb_mode )

0 = No switch (default)

1 = Switch from usb 2.0 to usb 3.0

2 = Switch from usb 3.0 to usb 2.0

affects both usb busses. This may be the fault of the mod 4 Raspberry Pi.

I tried this because my antenna is connecting at usb 2.0 speeds not 3.0, when I force 3.0 (change the parameter to 1) my usb kybd suffers badly. With the parameter set to 0 (default), when I plug a usb 3.0 memory stick into the same bus as the antenna it connects at 3.0 speed, the antenna connects at 2.0 speed. Right now I am running with default and all seems ok with the exception of the usb connection speed. Not sure at this point what else I can tell you, just that if you need more test work I will do what I can tohelp see if these things can be corrected. Best regards,Gene.

On Thursday, March 25, 2021, 4:23:51 PM EDT, morrownr ***@***.***> wrote:

Gene,

I hope your mouth is better at this point. Now, where are you with the issue?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

morrownr commented 3 years ago

Gene,

I have a Raspberry Pi 4b and a Raspberry Pi 3b. If I can get you to tell me exactly what hardware and software you are using, I can probably duplicate your setup and we can get to the bottom of this.

Nick

GeneDot3 commented 3 years ago 
On Friday, March 26, 2021, 6:02:08 PM EDT, morrownr ***@***.***> wrote:

Gene,

I have a Raspberry Pi 4b and a Raspberry Pi 3b. If I can get you to tell me exactly what hardware and software you are using, I can probably duplicate your setup and we can get to the bottom of this.

Hope this helps.Gene.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

morrownr commented 3 years ago

Gene,

I have read and pondered this thread a couple of times now. While I cannot say that I see a smoking gun, I will just throw some things out here for you to look at.

"Official Raspberry Pi 2A power supply (120vac)"

That has me concerned. The RasPi4b calls for a 3A power supply, not 2A. This new Pi4b is more power hungry than previous versions. The 4B USB subsystem will supply up to 1.2A to USB adapters but I don't think there is anywhere near 1.2A left over to use if your power supply is only providing 2A. The WiFi adapter, if based on a 8812bu chipset, can pull at least .5A by itself. A lack of enough power to your USB subsystem could explain some of this funny business.

"Used as a Network bridge"

My Pi4b's primary job is as a bridged access point (5g and 2g). It also runs BOINC 24/7 doing medical research and various other things but there is still plenty of CPU power to support high throughput access point operation. I'm going to tell you something you probably don't want to hear but I don't use an adapter based on a 8812bu chipset as an AP (access point). I have tried and tried to get stable performance with this driver and a 8812bu based adapter and I just can't do it with 11ac and USB 3. Of the 5 Realtek drivers that I support here, only 2 of them can max perform in a stable manner when working in AP mode... 8812au and 8821au (with a 8811au chipset).

The adapter that I use with my RasPi4b is a Alfa AWUS036ACM. It is based on a mt7612u chipset. It is more expensive than most adapters with a rtl8812bu chipset but it is such a pleasure to use. The driver for it is in-kernel so you don't have to fuss with compiling a driver. It auto-detects USB 3 and switches automatically. The driver supports WPA3 and WPA3 transitional so you can set your WPA3 devices to WPA3 instead of WPA2. mt7612u adapters also use less power. I have measured it to use between 180 to 360 mA with the 360 when it is maxed out. This makes it a wonderful match with a RasPi4b given that we are dealing with a USB subsystem that has limited power capability. I have a repo for info on the my7612u...

https://github.com/morrownr/7612u

I use the setup outlined in this file...

Bridged_Wireless_Access_Point-2.md

Back to the issue at hand...

It might be a good idea to just run...

$ sudo ./remove-driver.sh

and then delete the driver folder and reboot and then start the installation process again clean.

Once the driver is installed, don't change any of the driver parameters (options). How about we see how far we get with the access point setup and only touch the driver options when necessary to get faster speeds so that we can see where things go wrong. Also, please check into the power supply issue. 2A is really not good enough for a 4b.

Oh, and could you tell me what software you are using for bridged access point mode?

Let me know.

Nick

GeneDot3 commented 3 years ago

Hi Nick,I understand what you are saying. I have to tell you that my brain failed me and I thought I was using a 2A pwr supply but it is indeed 3A. I checked the boxes and both my Pis use the 3A (very sorry for trusting my brain, my apologies). I do know the power of the mod 4 as my son and I have been using these since very early on, I still have my first mod 1 running as a garage door opener and camera in the garage.

Not knowing much about these antennae, I am unaware of how the usb function and the radio function are implemented. The Log Mode error I see in journalctl baffles me as well. The antenna itself is working fine aside from the usb connection and the fact that I cannot get to the log mode are not stoppers for me.

Perhaps I will get an antenna with the chipset you recommend at some point, I just have to see the signal strength this one provides when we go camping. I plan to use it in a motorhome for more than a Network Bridge this coming season. Looking into streaming with Kodi and Pandora with it as well. I appreciate the driver you have and the support you have given me, Thanks! I have tried several times to remove and reinstall, I even built a new image from the ground up, none of which helped. What I will do is make an image with just the driver and see what happens. I will let you know how the plain vanilla build works out and we'll go from there.

Best Regards,Gene

On Monday, March 29, 2021, 3:54:13 AM EDT, morrownr @.***> wrote:

Gene,

I have read and pondered this thread a couple of times now. While I cannot say that I see a smoking gun, I will just throw some things out here for you to look at.

"Official Raspberry Pi 2A power supply (120vac)"

That has me concerned. The RasPi4b calls for a 3A power supply, not 2A. This new Pi4b is more power hungry than previous versions. The 4B USB subsystem will supply up to 1.2A to USB adapters but I don't think there is anywhere near 1.2A left over to use if your power supply is only providing 2A. The WiFi adapter, if based on a 8812bu chipset, can pull at least .5A by itself. A lack of enough power to your USB subsystem could explain some of this funny business.

"Used as a Network bridge"

My Pi4b's primary job is as a bridged access point (5g and 2g). It also runs BOINC 24/7 doing medical research and various other things but there is still plenty of CPU power to support high throughput access point operation. I'm going to tell you something you probably don't want to hear but I don't use an adapter based on a 8812bu chipset as an AP (access point). I have tried and tried to get stable performance with this driver and a 8812bu based adapter and I just can't do it with 11ac and USB 3. Of the 5 Realtek drivers that I support here, only 2 of them can max perform in a stable manner when working in AP mode... 8812au and 8821au (with a 8811au chipset).

The adapter that I use with my RasPi4b is a Alfa AWUS036ACM. It is based on a mt8712u chipset. It is more expensive that most adapters with a rtl8812bu chipset but it is such a pleasure to use. The driver for it is in-kernel so you don't have to fuss with compiling a driver. It auto-detects USB 3 and switches automatically. The driver supports WPA3 and WPA3 transitional so you can set your WPA3 devices to WPA3 instead of WPA2. mt7612u adapters also use less power. I have measured it to use between 180 to 360 mA with the 360 when it is maxed out. This makes it a wonderful match with a RasPi4b given that we are dealing with a USB subsystem that has limited power capability. I have a repo for info on the my7612u...

https://github.com/morrownr/7612u

I use the setup outlined in this file...

Bridged_Wireless_Access_Point-2.md

Back to the issue at hand...

It might be a good idea to just run...

$ sudo ./remove-driver.sh

and then delete the driver folder and reboot and then start the installation process again clean.

Once the driver is installed, don't change any of the driver parameters (options). How about we see how far we get with the access point setup and only touch the driver options when necessary to get faster speeds so that we can see where things go wrong. Also, please check into the power supply issue. 2A is really not good enough for a 4b.

Let me know.

Nick

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

GeneDot3 commented 3 years ago

Hey Nick. Here is a baseline lsusb -t result, this is a plain vanilla build with the usb antenna plugged in, prior to installing the driver:~ $ lsusb -t /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M     | Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M         | Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=, 480M         | Port 4: Dev 4, If 1, Class=Human Interface Device, Driver=usbhid, 12M         | Port 4: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M

After installing the driver and reboot, antenna plugged in:~ $ lsusb -t /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M     | Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M         | Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=rtl88x2bu, 480M         | Port 4: Dev 4, If 1, Class=Human Interface Device, Driver=usbhid, 12M         | Port 4: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M

From the journalctl:Mar 29 10:27:01 GEMAPi4FR kernel: 88x2bu: unknown parameter 'rtw_drv_log_level' ignored Speeds without VPN:~ $ speedtest-cli Retrieving speedtest.net configuration... Testing from Verizon Fios (71.251.28.44)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by Interserver, inc (Secaucus, NJ) [69.70 km]: 12.942 ms Testing download speed................................................................................ Download: 108.65 Mbit/s Testing upload speed...................................................................................................... Upload: 116.52 Mbit/s

Speed with VPN is about halved. Best Regards,Gene

On Monday, March 29, 2021, 3:54:13 AM EDT, morrownr ***@***.***> wrote:

Gene,

I have read and pondered this thread a couple of times now. While I cannot say that I see a smoking gun, I will just throw some things out here for you to look at.

"Official Raspberry Pi 2A power supply (120vac)"

That has me concerned. The RasPi4b calls for a 3A power supply, not 2A. This new Pi4b is more power hungry than previous versions. The 4B USB subsystem will supply up to 1.2A to USB adapters but I don't think there is anywhere near 1.2A left over to use if your power supply is only providing 2A. The WiFi adapter, if based on a 8812bu chipset, can pull at least .5A by itself. A lack of enough power to your USB subsystem could explain some of this funny business.

"Used as a Network bridge"

My Pi4b's primary job is as a bridged access point (5g and 2g). It also runs BOINC 24/7 doing medical research and various other things but there is still plenty of CPU power to support high throughput access point operation. I'm going to tell you something you probably don't want to hear but I don't use an adapter based on a 8812bu chipset as an AP (access point). I have tried and tried to get stable performance with this driver and a 8812bu based adapter and I just can't do it with 11ac and USB 3. Of the 5 Realtek drivers that I support here, only 2 of them can max perform in a stable manner when working in AP mode... 8812au and 8821au (with a 8811au chipset).

The adapter that I use with my RasPi4b is a Alfa AWUS036ACM. It is based on a mt8712u chipset. It is more expensive that most adapters with a rtl8812bu chipset but it is such a pleasure to use. The driver for it is in-kernel so you don't have to fuss with compiling a driver. It auto-detects USB 3 and switches automatically. The driver supports WPA3 and WPA3 transitional so you can set your WPA3 devices to WPA3 instead of WPA2. mt7612u adapters also use less power. I have measured it to use between 180 to 360 mA with the 360 when it is maxed out. This makes it a wonderful match with a RasPi4b given that we are dealing with a USB subsystem that has limited power capability. I have a repo for info on the my7612u...

https://github.com/morrownr/7612u

I use the setup outlined in this file...

Bridged_Wireless_Access_Point-2.md

Back to the issue at hand...

It might be a good idea to just run...

$ sudo ./remove-driver.sh

and then delete the driver folder and reboot and then start the installation process again clean.

Once the driver is installed, don't change any of the driver parameters (options). How about we see how far we get with the access point setup and only touch the driver options when necessary to get faster speeds so that we can see where things go wrong. Also, please check into the power supply issue. 2A is really not good enough for a 4b.

Let me know.

Nick

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

morrownr commented 3 years ago

Gene,

I am not seeing problems in journalctl on my 4B. Here are the first 7 lines of my 88x2bu.conf file:

# /etc/modprobe.d/88x2bu.conf
#
# Purpose: Allow easy access to specific driver options.
#
# Edit the following line to change options
#
options 88x2bu rtw_drv_log_level=2 rtw_led_ctrl=0 rtw_vht_enable=2 rtw_power_mgnt=1 rtw_switch_usb_mode=1

What I think we need to do is make sure you are editing the correct 88x2bu.conf file. Do not edit the one in the driver directory. Edit this one:

$ sudo mousepad /etc/modprobe.d/88x2bu.conf

Note that I changed from using nano as the editor and I specified the exact location of the file. You should be able to copy my "options" line above and paste it over yours, at least for testing.

On another subject: Are you using hostpad?

GeneDot3 commented 3 years ago 
On Monday, March 29, 2021, 1:20:33 PM EDT, morrownr ***@***.***> wrote:

Gene,

I am not seeing problems in journalctl on my 4B. Here are the first 7 lines of my 88x2bu.conf file:

/etc/modprobe.d/88x2bu.conf

Purpose: Allow easy access to specific driver options.

Edit the following line to change options

options 88x2bu rtw_drv_log_level=2 rtw_led_ctrl=0 rtw_vht_enable=2 rtw_power_mgnt=1 rtw_switch_usb_mode=1 I had used the command "sudo ./edit-options.sh" to edit the options.  I have not touched them after installing the driver this time, they are defaults as downloaded: options 88x2bu rtw_drv_log_level=0 rtw_led_ctrl=1 rtw_vht_enable=1 rtw_power_mgnt=1 rtw_switch_usb_mode=0

What I think we need to do is make sure you are editing the correct 88x2bu.conf file. Do not edit the one in the driver directory. Edit this one: $ sudo mousepad /etc/modprobe.d/88x2bu.conf Note that I changed from using nano as the editor and I specified the exact location of the file. You should be able to copy my "options" line above and paste it over yours, at least for testing. I did exactly as you instructed, I rebooted and the response from my mini keyboard is very poor, I almost have to be on top of the Pi for it to function. I have been here before.Results of the lsusb -t show correct  device connection but the interference must be severe:~ $ lsusb -t /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M     | Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=rtl88x2bu, 5000M /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M     | Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M         | Port 4: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M         | Port 4: Dev 4, If 1, Class=Human Interface Device, Driver=usbhid, 12M I tried moving the antenna and keyboard adapters to various usb ports but nothing helped the keyboard response, and the antenna did about the same.

No improvement in download/upload speed (fyi, all these are done while connected to a 5G WiFi source):~ $ speedtest-cli Retrieving speedtest.net configuration... Testing from DediPath (45.132.227.179)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by NEPA Fiber (Wilkes-Barre, PA) [161.07 km]: 21.011 ms Testing download speed................................................................................ Download: 56.11 Mbit/s Testing upload speed...................................................................................................... Upload: 33.85 Mbit/s

Still seeing "Mar 29 15:52:50 GEMAPi4FR kernel: 88x2bu: unknown parameter 'rtw_drv_log_level' ignored" in journalctl

On another subject: Are you using hostpad?Not using hostapd as it was not in the implementation I followed. Is that a problem? Let me know if you want to continue on this as it must be cutting into other things you want/need to do.I can manage with the antenna connecting as a 2.0 device and I was interested in viewing the logs, but in the long run I am happy with the ease of installing your driverand if I can get decent range from it at the campgrounds I will be fine with that. Let me know if you want to continue or just keep this in mind and send me an email if you do happen to think of something. Best Regards,Gene.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

morrownr commented 3 years ago

"Not using hostapd as it was not in the implementation I followed. Is that a problem?"

That is not a problem. I'm just trying get a handle on what you are doing. I use and am familiar with hostapd so I might be limited help with a different setup until I have a chance to figure it out. However, the more important issue seems to be that you have some kind of interference going on. I run my RasPi4b headless via VNC. Do you have the ability to run headless or with corded keyboard and mouse? It sure sounds like interference right in that area where the USB ports are.

GeneDot3 commented 3 years ago 
On Monday, March 29, 2021, 6:39:58 PM EDT, morrownr ***@***.***> wrote:

"Not using hostapd as it was not in the implementation I followed. Is that a problem?"  I use dhcpcd and dnsmasq, I will have to look into hostapd, I just got used to configuring the dhcpcd, dnsmasq and iptables enough to be dangerous.

That is not a problem. I'm just trying get a handle on what you are doing. I use and am familiar with hostapd so I might be limited help with a different setup until I have a chance to figure it out. However, the more important issue seems to be that you have some kind of interference going on. I run my RasPi4b headless via VNC. Do you have the ability to run headless or with corded keyboard and mouse? It sure sounds like interference right in that area where the USB ports are. I'm afraid I do not have the ability to run with a corded keyboard/mouse. The times I need the keyboard/mouse is when I have Kodi running, other than that the Pi just runs 24/7 connected to the wireless router. I don't think Kodi likes headless. Nick, thanks for helping out here. I appreciate it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

morrownr commented 3 years ago

For what it is worth: Unless you really like messing with iptables and dnsmasq, hostapd makes things a little easier. I can point you toward a tutorial if you like.

Kodi may not work well headless. But nothing works that well with interference. If you are using two little usb devices, one for the keyboard and one for the mouse, they may be interfering with each other.

GeneDot3 commented 3 years ago

I would like a tutorial for hostapd, send it along, I'll give it a try. Easier doesn't sound bad, iptables is hard!One adapter, it's a mini keyboard/trackpad thing, backlit and all.

On Tuesday, March 30, 2021, 4:00:22 PM EDT, morrownr ***@***.***> wrote:

For what it is worth: Unless you really like messing with iptables and dnsmasq, hostapd makes things a little easier. I can point you toward a tutorial if you like.

Kodi may not work well headless. But nothing works that well with interference. If you are using two little usb devices, one for the keyboard and one for the mouse, they may be interfering with each other.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

morrownr commented 3 years ago

Gene,

Sorry about being slow with the tutorial but I have a few too many irons in the fire right now.

First, I have to say that you were right about there being a problem with the log. I had some time this afternoon to investigate. I found a problem that I simply had overlooked. Please run $ sudo ./remove-driver.sh and then delete the driver directory and then start over. Tell me if things work better once you set a log level and reboot.

I keep a tutorial here:

https://github.com/morrownr/8812au/blob/5.9.3.2/Bridged_Wireless_Access_Point.md

I only keep the tutorial in the repo for the 8812au and 8811au drivers because the other drivers are problematic in AP mode. It is for a Raspberry Pi. I can't remember, is that what you have?

Nick

GeneDot3 commented 3 years ago

Hi Nick,Don't worry about response time, I know too well about having too many irons in the fire! I am in the midst of moving things into the motorhome, I did however reload the driver last night because my image was not seeing WLAN1, so corrected that. As soon as I get to things inside againI will replace the parameter for logging, I had gotten in the habit of taking it out due to the line in journalctl.

I'll check out the tutorial also, it's always good to learn. I'll let you know what happens, thanks. Best Regards,Gene.

On Monday, April 5, 2021, 12:12:07 AM EDT, morrownr ***@***.***> wrote:

Gene,

Sorry about being slow with the tutorial but I have a few too many irons in the fire right now.

First, I have to say that you were right about there being a problem with the log. I had some time this afternoon to investigate. I found a problem that I simply had overlooked. Please run $ sudo ./remove-driver.sh and then delete the driver directory and then start over. Tell me if things work better once you set a log level and reboot.

I keep a tutorial here:

https://github.com/morrownr/8812au/blob/5.9.3.2/Bridged_Wireless_Access_Point.md

I only keep the tutorial in the repo for the 8812au and 8811au drivers because the other drivers are problematic in AP mode. It is for a Raspberry Pi. I can't remember, is that what you have?

Nick

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.