Hi all,
a last result according to the caps configuration in wlanap.cgi for the ac mode..
After more testings with the BrosTrend 650AC Stick and Hostapd on IPFire, here is my current configuration for HT and VHT Caps that runs currently stable (in a radius from 4 to 8 meter, one test also with one wall (a thin one) in between with a one third loss of link quality and data throughput). The AC signal get quickly lost and the mode is not usable if more comes in between:
HT Caps:
Use the combination
[HT40+][SHORT-GI-20][SHORT-GI-40][HT-CAPS-0x196e]
The explicit flags [HT40+], [SHORT-GI-20], and [SHORT-GI-40] are essential for Hostapd to initialize the access point properly. The hex bitmask [HT-CAPS-0x196e] completes the set with all hardware-specific HT capabilities. Using only the hex bitmask for HT alone causes Hostapd initialization failures.
VHT Caps:
Use the full hex bitmask
[VHT-CAPS-0x03d07122]
This bitmask should fully represents all Very High Throughput capabilities of the wireless adapter and is correctly handled by Hostapd.
This configuration leads to successful Hostapd startup without critical errors, except for some DFS warning messages, which can generally be ignored if no DFS channels are in use.
Notes:
The [HT40+] flag indicates 40 MHz channel width with the secondary channel above the primary; it is critical for 802.11n performance.
[SHORT-GI-20] and [SHORT-GI-40] enable short guard intervals to improve throughput.
The hex codes are extracted directly from iw phy phy0 info and represent the hardware capabilities.
DFS warnings ("Failed to check if DFS is required") are normal unless you use DFS channels explicitly.
This approach avoids crashes and unstable AP states seen when only the hex masks are used, especially for HT capabilities.
Have used this command and output:
iw phy phy0 info | grep -E -A 15 'Capabilities:|VHT Capabilities'
which delivered here this results:
Capabilities: 0x196e
HT20/HT40
SM Power Save disabled
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: 2 usec (0x04)
HT Max RX data rate: 150 Mbps
HT TX/RX MCS rate indexes supported: 0-7, 32
Bitrates (non-HT):
* 1.0 Mbps
* 2.0 Mbps
* 5.5 Mbps
--
Capabilities: 0x196e
HT20/HT40
SM Power Save disabled
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: 2 usec (0x04)
HT Max RX data rate: 150 Mbps
HT TX/RX MCS rate indexes supported: 0-7, 32
VHT Capabilities (0x03d07122):
Max MPDU length: 11454
Supported Channel Width: neither 160 nor 80+80
short GI (80 MHz)
SU Beamformee
MU Beamformee
+HTC-VHT
VHT RX MCS set:
1 streams: MCS 0-9
2 streams: not supported
3 streams: not supported
4 streams: not supported
wlanap.cgi looks liek this:
Wifi Status on wlanap.cgi shows:
WiFi Status
Interface blue0p0
ifindex 4
wdev 0x100000001
addr d8:3a:dd:45:e8:3d
ssid IPF-Rasp
type AP
wiphy 1
channel 36 (5180 MHz), width: 80 MHz, center1: 5210 MHz
txpower 25.00 dBm
Station 8e:43:a2:a5:bd:8d (on blue0p0)
inactive time: 1000 ms
rx bytes: 81519
rx packets: 428
tx bytes: 4720556
tx packets: 82005
tx failed: 0
tx bitrate: 433.3 MBit/s
rx bitrate: 6.0 MBit/s
authorized: yes
authenticated: yes
associated: yes
WMM/WME: yes
TDLS peer: no
DTIM period: 2
beacon interval:100
connected time: 150 seconds
current time: 1760857845424 ms
Client (Fedora) uses:
$ iw list | grep -E -A 15 'Capabilities:|VHT Capabilities'
Capabilities: 0x11ef
RX LDPC
HT20/HT40
SM Power Save disabled
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 3839 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 4 usec (0x05)
HT Max RX data rate: 300 Mbps
HT TX/RX MCS rate indexes supported: 0-15
Bitrates (non-HT):
* 1.0 Mbps
--
Capabilities: 0x11ef
RX LDPC
HT20/HT40
SM Power Save disabled
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 3839 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 4 usec (0x05)
HT Max RX data rate: 300 Mbps
HT TX/RX MCS rate indexes supported: 0-15
VHT Capabilities (0x039071b0):
Max MPDU length: 3895
Supported Channel Width: neither 160 nor 80+80
RX LDPC
short GI (80 MHz)
TX STBC
SU Beamformee
MU Beamformee
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
and Wavemon on client side looks like this
Current client speedtests via Ookla deliverd:
Down Mbps 77.19
Up Mbps 26.96
Ping ms 14 196 16
According to the an Mode with Channel 36 (5Ghz), the stability is better (AP is reachable in places where it is not in AC mode) and the speed is a kind of similar. Have used only the HT Caps (the same as above) in AN mode.
Speedtest:
Down Mbps 78.26
Up Mbps 29.54
Ping ms 13 285 17
Wifi Status from wlanap.cgi
WiFi Status
Interface blue0p0
ifindex 4
wdev 0x100000001
addr d8:3a:dd:45:e8:3d
ssid IPF-Rasp
type AP
wiphy 1
channel 36 (5180 MHz), width: 40 MHz, center1: 5190 MHz
txpower 25.00 dBm
Station 8e:43:a2:a5:bd:8d (on blue0p0)
inactive time: 0 ms
rx bytes: 39902
rx packets: 172
tx bytes: 4963144
tx packets: 86038
tx failed: 0
tx bitrate: 200.0 MBit/s
rx bitrate: 135.0 MBit/s
authorized: yes
authenticated: yes
associated: yes
WMM/WME: yes
TDLS peer: no
DTIM period: 2
beacon interval:100
connected time: 14 seconds
current time: 1760865555353 ms
So for my usage, currently the best setup with this stick.
So far from here.
Best,
Erik
P.S.: One patch has been delivered wlanap.cgi: Save IEEE80211W 'optional' value correctly - Patchwork .
@jon , the TX Power patch does work here so far, did you checked it ? Does it fit your needs according to the bugzilla entry ? If yes, i would make a merge request, currently not sure if it makes sense.
may you can go for checkout on this ?
