(solved) Problem creating 80211AC AP on RPI4 about 8814au HOT 37 CLOSED

Hi LittleFatHero,

Using hostapd to setup an access point now works. In fact, my testing shows that is works very well at maximum capable speeds to include 80211AC and 80 Mhz channels width.

Getting to this point was not simply a matter of working on this driver. Updates to hostapd, updates to Linux, testing to determine the best installation steps and configuration all played a part. I have put a text file called Bridged Wireless Access Point in the main directory of this repo. If outlines the steps to setup a bridged wireless access point using this driver, hostapd and a Raspberry Pi 4b. It should work on x86 hardware as well but I have not had time to test that.

If you decide to set up an AP with the instruction file, please keep notes so you can give me a report on how I can make the document better.

For future communication, can I get you to start a new issue? Most of this issue is now obsolete so I need to close it.

Regards

from 8814au.

Ok partial success?? I dont know know enough about 80211ac to determine whether this is true 80211ac setup. Here is what I did

Compiled and installed your 88x2bu driver with CONFIG_PLATFORM_ARM64_RPI flag using your install script

Here is my 88x2bu.conf
options 88x2bu rtw_switch_usb_mode=1 rtw_drv_log_level=6 rtw_led_ctrl=1 rtw_vht_enable=2 rtw_power_mgnt=0 rtw_ips_mode=1

here is my hostapd.conf

interface=wlan1
driver=nl80211
ssid=borg
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=toe54321
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

hw_mode=a
channel=36
wmm_enabled=1

country_code=US

require_ht=1
require_vht=1
ht_capab=[HT40-][HT40+][SHORT-GI-40][MAX-AMSDU-7935][DSSS_CCK-40]
vht_capab=[RX-LDPC][MAX-MPDU-11454][SHORT-GI-80][TX-STBC][SU-BEAMFORMEE]
vht_oper_chwidth=1
vht_oper_centr_freq_seg0_idx=42
#vht_oper_centr_freq_seg1_idx=157
ieee80211n=1
ieee80211ac=1

here is my output of iwconfig after the AP:
wlan1 IEEE 802.11bgn ESSID:"borg" Nickname:"WIFI@REALTEK"
Mode:Master Frequency:5.18 GHz Access Point: E8:4E:06:66:4B:7A
Bit Rate:867 Mb/s Sensitivity:0/0
Retry:off RTS thr:off Fragment thr:off
Power Management:off
Link Quality=0/100 Signal level=-100 dBm Noise level=0 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

judging from the "IEEE 80211bgn" it appears that this is not a true 80211AC AP but Im getting 867 Mb/s bit rate??

from 8814au.

I am not familiar with hostapd but will look at loading it on my RasPi 4B this afternoon so as to try to recreate the problem. Do you have a good link that would step me through the setup process for hostapd?

One issue that has come up regarding another driver here on this site is the need to add "rtw_vht_enable=2" to the module configuration file when operating in AP mode if you want full speed capability. The configuration file for this driver is called "8814au.conf". You can see how to edit the file in the README if you are not familiar. Maybe that could help.

from 8814au.

Okay, I had some time work this issue this afternoon. My report:

I used a RasPi 4B with a clean installation of RasPiOS 2020-12-02.

I followed the checklist at this site:

https://www.raspberrypi.org/documentation/configuration/wireless/access-point-bridged.md

I set channel 36 and now have two devices connected and getting solid internet from my 8814au adapter.

There are a couple of issues I need to check out:

• The channel width is only 20 MHz so I need to find out how to set 40 and 80.

• Getting VNC to work. My Pi has a cat 6 ethernet connection with 1gb service and I would to be able to access the Pi via VNC.

So, it seems to be working here. I guess we need to figure out what is the difference between your setup and mine.

from 8814au.

Hey

Yes I'm able to get 80211bgn ap working fine. But I'm not able to get 80211ac ap working. I added the flag to the driver config file and still doesnt work. I'm wondering if there are some regulatory restrictions baked into the driver?

from 8814au.

There are a lot of regulatory restrictions baked into this driver but it isn't clear to me that this is a problem with what you are trying to do. I had more time last night to learn more about hostapd. I am now seeing what you are seeing. No problems with bgn but ac is not happening. My next steps on this issue:

• I am going to test with other adapters and drivers to see if the issue is specific to the 8814au. I maintain 5 drivers here - github.com/morrownr - and I have the hardware to test all. This will take time as my little computer lab only has 2 dedicated test systems plus a few more that have other jobs but can be used.

• I am also going to see if this is specific to the RasPiOS so I will test on x86. I am a little sceptical of RasPiOS right now as the 64 bit test version is flat out broken as far as compiling these drivers is concerned and I am seeing some things I can't explain with the new 32 bit version. All is not well in the world of RasPioS right now.

from 8814au.

Hey sounds good. I've got hardware for 8812au and 8822bu and confirm same behavior. I'm also gonna test with ubuntu and see if I get similar results. Getting this working would be great step in getting more modern wifi capabilities for realtek chipsets.

from 8814au.

Status report:

I am making progress and appear to nearly be there. I am up to a 300 Mb/s connection on 5G, 40 MHz width.

Checklist:

Clean install of RasPiOS 2020-12-02 on a 4B. Updates that came in this morning stabilized things.

Followed this guide for a bridged setup:

https://www.raspberrypi.org/documentation/configuration/wireless/access-point-bridged.md

Am using the 8812au adapter and driver from this site but everything was consistent with what I was seeing with the 8814au driver so this may work there as well.

hostapd.conf

interface=wlan0
bridge=br0
hw_mode=a
channel=36
#ieee80211d=1
country_code=US
ieee80211n=1
ieee80211ac=1
wmm_enabled=1

ssid=RasPi-4B
auth_algs=1
wpa=2
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP
wpa_passphrase=myPassword

ht_capab=[HT40-][HT40+][SHORT-GI-20][SHORT-GI-40][MAX-AMSDU-7935][DSSS_CCK-40]
vht_capab=[HTC-VHT][MAX-MPDU-11454][SHORT-GI-80][TX-STBC-2BY1][SU-BEAMFORMEE]
#require_vht=1
vht_oper_chwidth=1
vht_oper_centr_freq_seg0_idx=42
#vht_oper_centr_freq_seg1_idx=159

Edit: [delete - do not do this] Makefile changes: (you need to sudo ./remove-driver.sh and make the below changes, reinstall and reboot) CONFIG_MP_VHT_HW_TX_MODE = Y (This after a LOT of research) [delete]

CONFIG_PLATFORM_I386_PC = n (this is a normal change for RasPi)
CONFIG_PLATFORM_ARM_RPI = y (this is a normal change for RasPi)

8812au.conf (addition) (see README) this needs to be done after the installation or the file won't be in place)
rtw_vht_enable=2

We are not to 80 yet but I think it will happen soon.

Nick

from 8814au.

BOOM! We are there! I had inadvertently left rtw_vht_enable=1 instead of rtw_vht_enable=2 and BOOM! 80 MHz width and 867 Mb/s.

In addition to the above, you need to change rtw_switch_usb_mode=0 to rtw_switch_usb_mode=1 in 8812au.conf or USB 2 speed will be the limfac.

This is with the 8812au driver but I will be testing the 8814au very soon and post the results.

So, the 8812au driver does support 80 MHz width. Smokin'

Nick

from 8814au.

Update: I am running into compilation problems on the RasPi with the other drivers. Right now it is only the 8812au that is working with the above checklist.

The problem stems from CONFIG_MP_VHT_HW_TX_MODE = Y (Makefile). It is a floating point thing and is likely specific to the RasPi. why this works with the 8812au driver and none of the rest is the big question right now.

I'd welcome anyone who has time to test this or other drivers on this site with hostapd on x86 using the setup shown above.

Nick

from 8814au.

After two solid days of testing with hostapd and the driver for the rtl8812au on the RasPi, I have come to the conclusion that that particular combination is VERY solid and supports a channel width of 80. iperf3 tests look really good. Here is my plan as of now. I am going to document the setup and post it to the 8812au driver ( github.com/morrownr ). Once that is going so that I can get feedback on it, I will start testing hostapd with other drivers on this site and will post updates in the repo for each driver. My next priority is the 8814au since that is where we started this adventure.

Update to above setup: Do NOT set CONFIG_MP_VHT_HW_TX_MODE = Y in the Makefile. I have it going without this setting.

from 8814au.

Nick,

Thanks for the hard work on this issue. Good to hear we can get 80211AC AP working on at least one RTL (8812au) chipset. I can confirm I have the same float issues compiling the 8814au and 88x2bu from your repos after enabling the CONFIG_MP_VHT_HW_TX_MODE. Im compiling on ubuntu so appears to be RPI specific issue. According to this repo, he did get VHT working on 8814au https://github.com/cilynx/rtl88x2bu. Im wondering how he did it...

Either way, Im compiling the 88x2bu driver without the flag using make and going to manually load the driver to see if iw list lists the necessary VHT capabilities. Will update tomorrow.

from 8814au.

Here is output of iw list

Wiphy phy1
max # scan SSIDs: 9
max scan IEs length: 2304 bytes
max # sched scan SSIDs: 0
max # match sets: 0
max # scan plans: 1
max scan plan interval: -1
max scan plan iterations: 0
Retry short limit: 7
Retry long limit: 4
Coverage class: 0 (up to 0m)
Supported Ciphers:
* WEP40 (00-0f-ac:1)
* WEP104 (00-0f-ac:5)
* TKIP (00-0f-ac:2)
* CCMP-128 (00-0f-ac:4)
* CMAC (00-0f-ac:6)
Available Antennas: TX 0 RX 0
Supported interface modes:
* IBSS
* managed
* AP
* monitor
* P2P-client
* P2P-GO
Band 1:
Capabilities: 0x1963
RX LDPC
HT20/HT40
Static SM Power Save
RX HT20 SGI
RX HT40 SGI
RX STBC 1-stream
Max AMSDU length: 7935 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 16 usec (0x07)
HT Max RX data rate: 300 Mbps
HT TX/RX MCS rate indexes supported: 0-15
Bitrates (non-HT):
* 1.0 Mbps
* 2.0 Mbps
* 5.5 Mbps
* 11.0 Mbps
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
Frequencies:
* 2412 MHz [1] (30.0 dBm)
* 2417 MHz [2] (30.0 dBm)
* 2422 MHz [3] (30.0 dBm)
* 2427 MHz [4] (30.0 dBm)
* 2432 MHz [5] (30.0 dBm)
* 2437 MHz [6] (30.0 dBm)
* 2442 MHz [7] (30.0 dBm)
* 2447 MHz [8] (30.0 dBm)
* 2452 MHz [9] (30.0 dBm)
* 2457 MHz [10] (30.0 dBm)
* 2462 MHz [11] (30.0 dBm)
* 2467 MHz [12] (30.0 dBm) (no IR)
* 2472 MHz [13] (30.0 dBm) (no IR)
* 2484 MHz [14] (30.0 dBm)
Band 2:
Capabilities: 0x1863
RX LDPC
HT20/HT40
Static SM Power Save
RX HT20 SGI
RX HT40 SGI
No RX STBC
Max AMSDU length: 7935 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 16 usec (0x07)
HT Max RX data rate: 300 Mbps
HT TX/RX MCS rate indexes supported: 0-15
VHT Capabilities (0x03d071b2):
Max MPDU length: 11454
Supported Channel Width: neither 160 nor 80+80
RX LDPC
short GI (80 MHz)
TX STBC
SU Beamformee
MU Beamformee
+HTC-VHT
VHT RX MCS set:
1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT RX highest supported: 867 Mbps
VHT TX MCS set:
1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT TX highest supported: 867 Mbps
Bitrates (non-HT):
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
Frequencies:
* 5180 MHz [36] (23.0 dBm)
* 5200 MHz [40] (23.0 dBm)
* 5220 MHz [44] (23.0 dBm)
* 5240 MHz [48] (23.0 dBm)
* 5260 MHz [52] (23.0 dBm) (radar detection)
* 5280 MHz [56] (23.0 dBm) (radar detection)
* 5300 MHz [60] (23.0 dBm) (radar detection)
* 5320 MHz [64] (23.0 dBm) (radar detection)
* 5500 MHz [100] (23.0 dBm) (radar detection)
* 5520 MHz [104] (23.0 dBm) (radar detection)
* 5540 MHz [108] (23.0 dBm) (radar detection)
* 5560 MHz [112] (23.0 dBm) (radar detection)
* 5580 MHz [116] (23.0 dBm) (radar detection)
* 5600 MHz [120] (23.0 dBm) (radar detection)
* 5620 MHz [124] (23.0 dBm) (radar detection)
* 5640 MHz [128] (23.0 dBm) (radar detection)
* 5660 MHz [132] (23.0 dBm) (radar detection)
* 5680 MHz [136] (23.0 dBm) (radar detection)
* 5700 MHz [140] (23.0 dBm) (radar detection)
* 5720 MHz [144] (23.0 dBm) (radar detection)
* 5745 MHz [149] (30.0 dBm)
* 5765 MHz [153] (30.0 dBm)
* 5785 MHz [157] (30.0 dBm)
* 5805 MHz [161] (30.0 dBm)
* 5825 MHz [165] (30.0 dBm)
* 5845 MHz [169] (30.0 dBm)
* 5865 MHz [173] (30.0 dBm)
* 5885 MHz [177] (30.0 dBm)
Supported commands:
* new_interface
* set_interface
* new_key
* start_ap
* new_station
* set_bss
* join_ibss
* set_pmksa
* del_pmksa
* flush_pmksa
* remain_on_channel
* frame
* set_channel
* connect
* disconnect
Supported TX frame types:
* IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
Supported RX frame types:
* IBSS: 0xd0
* managed: 0x40 0xb0 0xd0
* AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* P2P-client: 0x40 0xd0
* P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
WoWLAN support:
* wake up on anything (device continues operating normally)
software interface modes (can always be added):
* monitor
interface combinations are not supported
Device supports SAE with AUTHENTICATE command
Device supports scan flush.
Supported extended features:

from 8814au.

Cannonfodder,

I thought we had it but you are right. I was looking at the Wifi Analyzer app on my phone and it was showing a channel width of 80. iperf3 testing was limiting out at around 240 Mb/s where I should have been seeing 480-500 Mb/s if we were truly getting ac at 80 so I think we have solid n and that is it.

Anyway, so far I have enjoyed this but need to pull back a little because kernel 5.10 is likely to be released this weekend and I have a lot of work to do to getting these drivers ready for 5.10.

Back to the subject at hand: I did some research. I see that Ubuntu 20.10 is up to hostapd 2.9 (latest) and one of the latest patches that has flowed has to do with Realtek drivers. If you have time, you might want to install and update Ubuntu 20.10 and see if you can get real 11ac with the 8812au driver.

Nick

from 8814au.

@cannonfodder728

See README at github.com/morrownr/88x2bu

I have added a section called "Setting up a Bridged Wireless Access Point".

I think I found the problem. It was in the setup instructions we were following. The bottom line is that 802.11ac is very doable and works very well if setup properly. I tested yesterday with an adapter using a rtl8812bu chipset but it should work with the 8812au and 8814au chipsets as well. I was seeing great throughput all the way to and including 11ac.

Please test and let me know so that I can add the instructions to the other drivers.

Nick

from 8814au.

Hey I cant seem to get 80211AC AP setup with rtl88xbu driver on raspberry pi OS. I can get 80211bgn card at 867mbps.

I have the following card (chipset)
Bus 002 Device 002: ID 0bda:b812 Realtek Semiconductor Corp.

My 88x2bu.conf is below
options 88x2bu rtw_drv_log_level=6 rtw_led_ctrl=1 rtw_vht_enable=2 rtw_power_mgnt=1 rtw_switch_usb_mode=1

My hostapd.conf is same as yours absent bridge.

Output of lsusb confirms card is at USB 3.0
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

Iw list outputs the following features on 2.4 and 5Ghz spectrums

Capabilities: 0x1963
RX LDPC
HT20/HT40
Static SM Power Save
RX HT20 SGI
RX HT40 SGI
RX STBC 1-stream
Max AMSDU length: 7935 bytes
DSSS/CCK HT40

VHT Capabilities (0x03d071b2):
Max MPDU length: 11454
Supported Channel Width: neither 160 nor 80+80
RX LDPC
short GI (80 MHz)
TX STBC
SU Beamformee
MU Beamformee
+HTC-VHT

from 8814au.

@cannonfodder728

You are killing me! What platform are you using?

I may have to slow down on this issue for a few days as my main work box just lost its power supply and this is a bad time to expect shipping to happen in a timely manner. In the mean time, my RasPi 4B has become my main work box which means using it to test this issue is going to slow down.

We are going to get this solved. Cheers.

from 8814au.

Hey using raspberry pi os lite on rpi 4gb.

I managed to find a card with the 8812au chipset so I'm going to try that today.

from 8814au.

From looking at the source code of the various drivers maintained here, my opinion is that the driver for the 8812au is the most modern and issue free so there is something to be said for using that chipset. On the other hand, the driver for the 88x2bu is not far behind and gives faster throughput in my testing.

I need to know exactly how you are testing 11ac? I have been using iwconfig. It has told me 802.11AC.

As I have time, I am going to test on a box with a Ubuntu 20.10 partition. It uses kernel 5.8 and the latest hostapd. Raspberry Pi OS is still on kernel 5.4, which is fine, and is a couple of releases behind with hostapd.

Cheers.

from 8814au.

Hey Nick,

Thanks for updating the drivers. Sorry if my issues are getting to be a pain, but Im seeing same behavior with 8812au chipset card that I tried today.

One item to note in your 8812au repo, the driver config file has "88xbu" instead of "8812au." I had to make that change for the settings (usb mode, vht mode, power setting, etc) to take affect..

Yes, Im using iwconfig to determine protocol and seeing same 80211bgn at 867mbps. Im using same hostapd.conf as your repo absent bridge setup. Iperf is showing 100-200 mbps no matter which card I use (8822bu or 8812au). This is half of the nominal bit rate that Windows shows although Im a couple walls removed from the access point.

from 8814au.

Hey, I enjoy getting to the bottom of issues like this and I intent to continue as time permits. Thanks for the heads up the .conf file thing. I messed that up somehow. Keeping up with 5 separate drivers can be a challenge.

from 8814au.

@cannonfodder728

Success. The success is with an adapter using a 8812au chipset, the 8812au driver here and a Raspi4b running the Raspi OS (32 bit). Nothing fancy. No code slinging. Just the right configuration. I will get the blueprint up soon for 8812au and then I will see which other chipsets are good. Oh, and yes, it is fast. My internet is 1gb fiber optic.

Nick

from 8814au.

I placed a text file with the instructions in the 8812au repo. The title is: Bridged Wireless Access Point

I tested it multiple times over the last few days. It seems rock solid. I am now testing 8821au.

Let me know.

from 8814au.

@cannonfodder728

The 8821au driver with a 8811au adapter has tested good at 80211AC, channel width 80. I placed an instructional text file called Bridged Wireless Access Point in the repo with the driver.

That makes 2 drivers that have tested good, the 8812au and 8821au. I am going to test the 8814au next.

Nick

from 8814au.

Hey sorry for late reply.

Ive been able to compile the load the driver successfully on multiple OS on multiple SBCs (Ubuntu, Raspbian and Ubuntu for RK3328 SOC). Looks like I do indeed have a 80211AC AP at 5GHZ (Ive checked on multiple stations running multiple OS [Windowz and Ubuntu] and it seems like despite what iwconfig says, hostapd is truly advertising 80211AC AP on 5GHZ spectrum). I wonder why Im seeing not seeing 80211AC in output of iwconfig. In either case, I was able to setup a couple repeaters for my house using your driver with "make ARCH=arm" for the RK3328 chipset found in this SBC (https://www.amazon.com/Iconikal-Rockchip-Computer-Processor-1866MHz/dp/B0868WSTXH). Was able to get each repeater running for circa $25 including USB Wireless NIC.

Seeing that this driver has potential to support multiple SBC running multiple OS's aside from RPI, wondering if you can add "sudo apt-get update && sudo apt-get -y install dkms" to your install script as some of the OS dont have DKMS natively installed?

from 8814au.

FYI: I updated the document Bridged Wireless Access Point in the https://github.com/morrownr/8812au repo today. I tweaked the hostapd.conf settings a little and I added some test results. The driver for the 8812au really does a wonderful job with hostapd.

Which driver are you using regarding the message above?

I really don't understand why you are not seeing 80211AC. You are running iwconfig on the system that is connecting to the AP you are setting up, right?

Regarding the request to add the lines to the install script: Not all supported operating systems use apt for a package manager.

Hey, can I get you to start an issue in the repo for the driver you are talking about next time you write as we have been all over the place and folks in the future may think we are talking about setting up an AP with a 8814au.

from 8814au.

Hi morrownr，I have read your discussion above but I am still confused about whether the driver on this site supports setting up an AP with a 8814au?
And I noted that in the README file of 8814au driver, the "Note " that remind user that the driver may not work well with hostapd has disappear, does it mean that the 8814au driver has supported AP?

from 8814au.

Hi morrownr,
Thank you for answering my question!
Q: "For future communication, can I get you to start a new issue? "
Re: Sure, when I have time , I will test the AP mode according to the text file Bridged Wireless Access on linux mint 20.1 (amd64) and I will open a new issue to post my test report.

from 8814au.

Thank you.

Issue closed.

from 8814au.

@cannonfodder728 @LittleFatHero @qcoumes

I am reopening, at least for a while, this issue so as to report on my extensive testing:

My conclusion, as of this date, is that there are only two AC1200 class chipsets that reliably support 802.11AC and 80 MHz channel width on the RasPi4b. Both are very reliable and pretty darn fast:

mt7612u
How to set it up: https://github.com/morrownr/7612u
Where to buy one: https://github.com/morrownr/USB-WiFi

rtl8812au
How to set it up: https://github.com/morrownr/8812au/blob/5.9.3.2/Bridged_Wireless_Access_Point.md

If you try to set one of these up, report any problems in the respective repo.

If you are able to reliably activate WPA3, please let me know.

Regards,

Nick

from 8814au.

@cannonfodder728 @LittleFatHero @qcoumes

iperf3 test for adapter with mt7612u chipset

$ iperf3 -c 192.168.1.40
Connecting to host 192.168.1.40, port 5201
[  5] local 192.168.1.83 port 43192 connected to 192.168.1.40 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  47.6 MBytes   400 Mbits/sec    0   1.50 MBytes       
[  5]   1.00-2.00   sec  52.5 MBytes   440 Mbits/sec    0   1.91 MBytes       
[  5]   2.00-3.00   sec  51.2 MBytes   430 Mbits/sec    0   2.49 MBytes       
[  5]   3.00-4.00   sec  52.5 MBytes   440 Mbits/sec    0   2.49 MBytes       
[  5]   4.00-5.00   sec  50.0 MBytes   419 Mbits/sec    0   2.49 MBytes       
[  5]   5.00-6.00   sec  52.5 MBytes   440 Mbits/sec    0   2.49 MBytes       
[  5]   6.00-7.00   sec  51.2 MBytes   430 Mbits/sec    0   2.49 MBytes       
[  5]   7.00-8.00   sec  51.2 MBytes   430 Mbits/sec    0   2.49 MBytes       
[  5]   8.00-9.00   sec  50.0 MBytes   419 Mbits/sec    0   2.49 MBytes       
[  5]   9.00-10.00  sec  55.0 MBytes   461 Mbits/sec    0   2.49 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   514 MBytes   431 Mbits/sec    0   sender
[  5]   0.00-10.01  sec   511 MBytes   428 Mbits/sec        receiver

Bridged_Wireless_Access_Point.md

from 8814au.

@cannonfodder728

Oh yeah!!! I found the problem. My 8814au adapter is now kicking out some fast data while hooked up to a RasPi4b. It is an excellent AP. It is stable and works well. It has come up before but would not stay up. It is staying up and working like it should now.

What the problem was not:

This driver is good to go as far as supporting 80 MHz channel width and 1300 Mb/s in AP mode.

The 8814au based adapter is very capable.

The Raspberry Pi OS is very capable.

What the problem was:

Electricity.

I had been testing 2 ways in regards to electrical usage, both of which did not cut it.

I have a cheap powered USB 3 hub. I started testing with this hub when this issue came up about 3 months ago. I did not realize until now that the hub I have BACKFEEDS into the RasPi3b. I also did not realize that the Pi4b does not handle backfeeding well at all. The condition that this created basically made for an unsatisfactory situation as far as the wifi adapter was concerned.

I also tested without the hub at times but this was unsatisfactory because I was trying to use more power than was available. The RasPi4b only supports about 1.2A for the entire USB system.

What did I do? I shut a lot of things down... onboard wifi, bluetooth, all LEDs. I underclocked the CPU to 1400. The only thing plugged into a USB port is the 8814au wifi adapter. I'm also running the Pi from an sd card instead of the USB SSD that I was using.

So, I will document this entire adventure over the next few days and I need to find a really good powered USB 3 hub that does not backfeed.

There you have it.

Nick

from 8814au.

How did you find out that the hub is backfeeding?

I have a hub (not very cheap, but not expensive either), and I have an HDD and this adapter connected to it.

Things work roughly the way I expect them to work (I am getting 450Mbit, and my laptop does not support AC, so I don't care about getting 1300), but TX-power seems to be fixed at 12dB, which means that the range of this Access Point is less than a room.

I would like to set it to 20 (and even considered rebuilding the kernel to turn off crda), but maybe the txpower setting doesn't actually matter? Maybe it's the hub?

For clarity:

root@pi:~/non-slackbuilds/8814au# iw reg get
global
country BO: DFS-JP
        (2402 - 2482 @ 40), (N/A, 20), (N/A)
        (5250 - 5330 @ 80), (N/A, 30), (0 ms), DFS
        (5735 - 5835 @ 80), (N/A, 30), (N/A)

root@pi:~/non-slackbuilds/8814au# 

root@pi:~/non-slackbuilds/8814au# iwconfig
lo        no wireless extensions.

eth0      no wireless extensions.

wlan0     IEEE 802.11  Mode:Master  Tx-Power=31 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          
wlan1     IEEE 802.11bgn  ESSID:"my-essid"  Nickname:"WIFI@RTL8814AU"
          Mode:Master  Frequency:5.785 GHz  Access Point: 1C:BF:CE:5A:C1:4C   
          Bit Rate:450 Mb/s   Sensitivity:0/0  
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=88/100  Signal level=66/100  Noise level=0/100
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

So with iwconfig, TX-Power is not even displayed for wlan1.

With iw:

root@pi:~/non-slackbuilds/8814au# iw wlan1 info
Interface wlan1
        ifindex 4
        wdev 0x100000001
        addr 1c:bf:ce:5a:c1:4c
        ssid my-essid
        type AP
        wiphy 1
        txpower 12.00 dBm

So the txpower is 12, which is not at all enough for a decent signal.
Let's set it?

root@pi:~/non-slackbuilds/8814au# iw wlan1 set txpower fixed 20
root@pi:~/non-slackbuilds/8814au# iw wlan1 info
Interface wlan1
        ifindex 4
        wdev 0x100000001
        addr 1c:bf:ce:5a:c1:4c
        ssid my-essid
        type AP
        wiphy 1
        txpower 12.00 dBm

No effect! How come?

Just in case it is useful, same thing with --debug:

root@pi:~/non-slackbuilds/8814au# iw --debug wlan1 set txpower  fixed 20
-- Debug: Sent Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [NETLINK HEADER] 16 octets
    .nlmsg_len = 44
    .type = 22 <0x16>
    .flags = 5 <REQUEST,ACK>
    .seq = 1616298451
    .port = -738187895
  [GENERIC NETLINK HEADER] 4 octets
    .cmd = 2
    .version = 0
    .unused = 0
  [PAYLOAD] 24 octets
    08 00 03 00 04 00 00 00 08 00 61 00 02 00 00 00 ..........a.....
    08 00 62 00 14 00 00 00                         ..b.....
---------------------------  END NETLINK MESSAGE   ---------------------------
-- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [NETLINK HEADER] 16 octets
    .nlmsg_len = 36
    .type = 2 <ERROR>
    .flags = 256 <ROOT>
    .seq = 1616298451
    .port = -738187895
  [ERRORMSG] 20 octets
    .error = 0 "Success"
  [ORIGINAL MESSAGE] 16 octets
    .nlmsg_len = 16
    .type = 22 <0x16>
    .flags = 5 <REQUEST,ACK>
    .seq = 1616298451
    .port = -738187895
---------------------------  END NETLINK MESSAGE   ---------------------------

from 8814au.

I have increased the quality of signal by switching to usb2.

This was actually done by switching to usb2. (even though I am using the usb3 port) And even with USB2, the signal level is not excellent. Not bad, but not very good either.

I have seen the suggestions here: https://ask.csdn.net/questions/1790628 and here: aircrack-ng/rtl8812au#637 .

from 8814au.

@lockywolf

I had somehow missed your previous post. I think it has to do with this being a very old thread.

I've read your last 2 posts and it isn't entirely clear to me what you are trying to accomplish. Can I get you to post a new Issue and include specifics about your hardware and software and a big picture overview of what you are trying to accomplish?

Thanks

from 8814au.

Sorry, I seem to have confused two things here. One thing is txpower, the other one is backfeeding.

I confused them because I thought they were related. Apparently not.

My first hub did backfeed current into Pi, so devices would randomly turn off as if for no reason.
That was a Chinese Orico hub, quite expensive, but apparently not expensive enough.
I still cannot confirm whether it was backfeeding, but I bought a new Transcent hub, and since then, the adapter works with no glitches.

The "low txpower" issue still remains.

from 8814au.

@lockywolf

Backfeeding and txpower are very different issues. If you do an internet search on "backfeeding and raspberry pi" you should find a lot of information. Whicj Trenscent hub did you get?

I merged a pull request yesterday that should have fixed the low txpower issue. Check the other reports for more information.

Also, I am going to close this issue very soon because it far off the topic the topic that it was started with so please start a new issue for future communication.

from 8814au.