So this might be a (major) problem with the max number of packets in the A-MPDU aggregation limited to 32.
Where IEEE802.11 explains it as designed for 64 packets, the SFT hardware seems to be limited to 32.
If this limit is not send/negotiated with the AP, and the AP has no means to restrict the number of MPDU packets in a A-MPDU, then faults will occur. ! Which introduces disconnects, which trigger the hotplug rundown code for firewall and IP stack (DHCP). Making this connection performing very badly.
Amazing for Mikrotik as AP, with it's own rather small buffers, the total A-MPDU will be at the lower end, for its total size. The number of small MPDU (A-MSDU) might be up to 64 however.
But with many clients behind the SFT1200 when sending in router mode as just one device (MAC) to just one AP ... A-MPDU aggregation will happen frequently (same source - same destination!) for all AMSDU/MPDU in the queue.
The only option with Mikrotik is to set AMPDU aggregation OFF then. Increasing the wifi wasted air-time between short transmissions, and lowering the wifi performance for all !!!
" h t t p s : / / siflower_dot_github_dot_io/2021/11/29/wifi_debug
Blockquote
6.2 TX AMPDU Maximum Number of Aggregate Packets
Modify the ampdu_max_cnt value in the /lib/sfwifi.sh script (the current default value is 32) to control the maximum number of AMPDU aggregation packets. Note: Due to the space limitation of the chip, the current maximum number of AMPDU aggregation packets is 32.
The config file is just reachable on the SFT1200 via SSH ...
cd /sys/module/sf16a18_hb_fmac/parameters
cat ampdu_max_cnt
the answer is 32 !
With AMPDU disabled on the uplink Mikrotik AP, the 5GHz connection just holds for many days (4 days, 2 days, ...)
Just using the SFT1200 here (connected to 2.4GHz with laptop, 5 GHz uplink to Mikrotik, reading and writing on this forum en doing some Google lookups, give me these statistics
Only 32 MPDU in a A-MPDU IS A MAJOR PROBLEM
LOG full of "Total force ps drop len : 6" now.
So also A-MSDU limit of 6 is a problem.
root@GL-SFT1200:/# cat /sys/kernel/debug/ieee80211/phy1/siwifi/stats
TXQs CFM balances [0]: 0 [1]: 0 [2]: 0 [3]: 0 [4]: 0
queue stop [0] start [0]AMSDU[len] done failed received
[ 0] 9799761 0( 0%) 37433773
[ 2] 0 0( 0%) 482017
[ 3] 0 0( 0%) 46299
[ 4] 0 0( 0%) 14001
[ 5] 0 0( 0%) 7756
[ 6] 0 0( 0%) 4906
[ 7] 3580
[ 8] 2473
[ 9] 1224
[10] 858
[11] 873
[12] 1316
[13] 132
[14] 110
[15] 138
[16] 49
[17] 53
[18] 231
[19] 65
[20] 82
[21] 102
[22] 35
[23] 78
[24] 32
[25] 23
[26] 111
[27] 16
[28] 6
[29] 2
[30] 3
[31] 1
[32] 50AMPDU[len] done received
[ 0] 3670273 37561434
[ 2] 803481 42925
[ 3] 170768 11472
[ 4] 94576 8229
[ 5] 68161 5136
[ 6] 50581 3068
[ 7] 39044 1634
[ 8] 31622 992
[ 9] 24354 731
[10] 19368 525
[11] 16097 483
[12] 13496 390
[13] 11642 312
[14] 10028 275
[15] 8330 233
[16] 6824 203
[17] 5759 210
[18] 5035 187
[19] 4216 160
[20] 3632 139
[21] 3131 142
[22] 2870 136
[23] 2531 126
[24] 2220 104
[25] 1974 106
[26] 1750 89
[27] 1583 93
[28] 1466 167
[29] 1257 85
[30] 1114 104
[31] 1020 175
[32] 10230 1036
...
[64] 0 96357
Should we change this line in "/lib/sfwifi.h" .
From " ampdu_max_cnt=${ampdu_max_cnt-32}"
To " ampdu_max_cnt=${ampdu_max_cnt-64}"
I expect the chip physical limit being the entire buffer size, not the number of packets in that buffer. Reduced packet number as AP can make sense, reduced packet number as Station is a problem. Or much better: Reduced packet number as Sender makes sense, reduced packet number as Receiver is a problem.
If we disable "Network acceleration/Hardware acceleration" can we avoid the chip buffer limit?
A-MPDU is typically done in the driver, and in hardware.