Hi, can you send me a full log of the SFT1200 relay Mikrotik drop? Thanks!
@Bruce: This is excellent news !!! The SFT1200 is far from EOL, or EOL like, in that case, as some people suggested here and did on Reddit.
2 Likes
@dawei.liu . I'll collect what I can. Here in my home the connection is steady with the BSSID lock on my "bpacrt" SSID.
I had to point people on how to activate it, as the option only appears with a new SSID selection, or later only when set at that initial time.
However in the remote holiday resort, with 35 Ap's sending the same SSID , the BSSID seems to works (no other active connections to other APs succeed, it sticks on hAP12) , but still the connection breaks. Maybe the SFT1200 is panicking about it's clock, requesting SNTP over and over?
SYSLOG dump (all Mikrotik) , almost no other activity, as the resort is deserted now.
192.168.22.83 is the SFT1200 WAN address
192.168.20.42 is the locked Mikrotik AP hAP12
I'll try to fetch the SFT1200 log
How to send a log file to you? Cannot upload, and it's not interesting for everyone.
OK. Done!
Sorry for being ignorant on this forum feature 
OK files have been sent (Syslog for Mikrotiks, and SFT1200 log)
As can be seen still not perfect or stable enough for real use. The SFT1200 disconnects and reconnects, and there is no reason given that I can find.
In the mean time doing more tests. I learned before that a good 2.4GHz connection is even better than a 5 GHz connection.
So changed the remote SFT1200 to use a different SSID that is 2.4GHz only, and entered the BSSID lock. Not easy to set up as error panels block acccess to the BSSID lock switch if there is no connection. But I managed to set it.
Checked half an hour later, and the connection was on 5GHz again. Why? Yes it is still in the known network list.
Checking while connected to the LAN side via another MT AP , set as station, ... the 2.4GHz uplink connection fails in the first 20 seconds.
Checking the upstream AP. Well the connection is with -30dBm signal. That is too much for a hAP ac2 AP ! Lots of malformed packets expected. Actually the access lists in my Mikrotiks normally blocks those strong transmitters. (A new setting introduced after some tourists brought 5 GL.inet travel routers and disturbed all wifi connections on my nearby AP's, this summer.)
Ok now connected with -34dBm. It's close, but works..
Is this the reason for those many "siwifi_calculate_legrate invalid legrate: 4" messages???
Remote site is more than 1000Km away, so devices cannot be moved, but there are 37 potential MT AP's candidates to be used for testing.
SFT and MT are on Europe (ETSI) regulation, with 20dBm max EIRP. However the SFT log is all the time saying larger numbers.
Thu Dec 5 22:38:03 2024 kern.warn kernel: [ 1525.421870] lmac[1] final dsss power is 28 ofdm power is 28
Thu Dec 5 22:38:03 2024 kern.warn kernel: [ 1525.451868] lmac[1] final dsss power is 28 ofdm power is 28
Thu Dec 5 22:38:03 2024 kern.warn kernel: [ 1525.562721] lmac[1] final dsss power is 28 ofdm power is 28
Thu Dec 5 22:38:03 2024 kern.warn kernel: [ 1525.592688] lmac[1] final dsss power is 28 ofdm power is 28
It was time to switch to 2.4GHz . Every time I tell someone it works ... then it fails shortly after.
For no known reason the 5GHz connection started flapping again, and stopped flapping without intervention.
This cannot be used as helpfull tool. It works for hours and then just fails suddenly.
2.4GHz uplink is now up for 17 hours. No problems seen yet. The connection is not stress loaded, but 5GHz was neither. Learned again that 2.4GHz can be better than 5 GHz.
But this time even without limiting to 802.11g and no multicast helper. Fairly out of the box default config.
Only setting: on the SFT1200 as said ... BSSID lock, and only one known network to link to.
5GHz (MT wlan2) was flapping connection with no reason found ...
Flapping , caused by "kern.warn kernel: [x.y] lmac[1] vif working channel(44) is different from channel(0) of received beacon frame, notify that we are lost!" ???
Or caused by background scan ?
"Station" doing a background scan (to find a better AP), and then the connection was lost due to this background scan , is something I have seen before.
Short term fix then was to disable the "station roaming" option on the client.
Later Mikrotik changed this to the "station roaming disabled" as "default" setting of a wifi station.
https://forum.mikrotik.com/viewtopic.php?p=953696#p746070
Also ... we might need "force_link" in OpenWRT 'wireless' (do not invoke hotplug handlers) to avoid or at least delay the UGLY part of any disconnect. (give it a time-out before it is activated, and avoid it completly if it returns to the same connection in time)
Blockquote
force_linkboolean no
1 for protocol static, else 0
Specifies whether ip address, route, and optionally gateway are assigned to the interface regardless of the link being active ('1') or only after the link has become active ('0'); when set to '1', carrier sense events do not invoke hotplug handlers
Blockquote
Force link setting comes with using static IP address, mentioned in LUCI for WWAN as 'Set interface properties regardless of the link carrier (If set, carrier sense events do not invoke hotplug handlers).'
So this is an extra step to help the GOOD , and here it is used together with mwan3 tracking with Interface Status Tracking Method to disabled 'Internet always available when the interface is connected', set in Multi WAN.
Settings all this in the GL.inet GUI, and Luci is only used to check, together with looking with SSH 'cat' at '/etc/config' files.
The SFT1200 in repeater/router mode (with NAT and firewall) should be configured as an internet edge gateway. There the internal LAN structure is not blown up, when there is a glitch on the internet link.
This is done on the Mikrotik, right?
From the image seems that the 5G repeater is disconnected and trying to associate again.
I cannot confirm it is due to wifi scanning. Maybe due to the AP send signal asking the station to roam.
It is like an option of "band steering" in Ubnt.
Lowering the power of the 2.4GHz client interface didn't help. The uplink is probably the 'master' controlling the radio setting, also for any other use of that radio.
See no method to set the uplink wifi power.
Yes it was then done on the Mikrotik client, and mitigated the problem.
Here is no band steering possible in this Mikrotik WLAN driver.
The 2.4GHz connection failed because the received signal was too strong (stronger than -30dBm)
Has been stable at this -32dBm for 20 hours; Just one glitch 4 hours ago.
No readable log in the SFT, which is full of
Sat Dec 7 11:15:33 2024 kern.warn kernel: [133375.920318] siwifi_calculate_legrate invalid legrate: 4
Sat Dec 7 11:15:37 2024 kern.warn kernel: [133378.942013] siwifi_calculate_legrate invalid legrate: 4
Sat Dec 7 11:15:40 2024 kern.warn kernel: [133381.957217] siwifi_calculate_legrate invalid legrate: 4
Sat Dec 7 11:15:43 2024 kern.warn kernel: [133384.978390] siwifi_calculate_legrate invalid legrate: 4
5GHz disconnect in SFT log is each time after
"kern.warn kernel: [x.y] lmac[1] vif working channel(44) is different from channel(0) of received beacon frame, notify that we are lost!"
It looks like these disconnects are here with GL.inet for a while, until they fix the causes.
In the mean time there is a workaround, to mitigate the bad experience. Knowing that the wifi link reappears quite fast, there are 2 levels of workaround
Level 1
- enforce the GOOD and avoid the BAD, by using BSSID lock, and having only one known SSID
- mitigate the UGLY effect of a temporary disconnect. Set "Force Link" on the uplink. (E.G. set fixed IP address , or set Force Link in LUCI as many public networks will not allow devices that do not use DHCP)
- Disable the mwan3 internet tracking, or give it better parameters.
Level 2:
if this separation of OSI L2 glitches from OSI L3 actions did not fully succeed, then 2 SFT1200 are needed to make that needed split between the OSI layer L1-2 and the upper layers
- set the first device in Repeater/extender mode and make the uplink connection. Repeater/extender should work in L2 only. (It has no IP address)
- connect both devices with an ethernet cable (SFT-1 LAN to SFT-2 WAN)
- set the second SFT1200 in repeater/router mode. It will do all the L3 - L7 work, but now based on a ultra stable L2 ethernet connection.
Having the wifi uplink on SFT-1 and the wifi down links on SFT-2, will not only improve performance but might just solve the 'beacon frame channel 0' error as well.
EDIT: remote installed connection is connected now with 2.4GHz for 56 hours continously, with level 1 workaround (BSSID lock and fixed IP address)
The 5GHz link has a different problem ... the A-MPDU index>31 error should be avoided (A-MPDU can only be disabled not reduced in numbers on a Mikrotik host AP)
SFT1200 is not according the IEEE 802.11ac standard, it should accept 64 MPDU's. 32 MPDU is for 802.11n MAC level Throughput comparison: 802.11ac vs. 802.11n - ScienceDirect
So yet another workaround step needed. Reduce the 5GHz client mode on the SFT to N mode. (it cannot handle 802.11ac, so should not connect as ac)
(Actually the 802.11n seems to be 64 MPDU in a A-MPDU as well, so this might not be enough)
1 Like
Thanks for the link, going to check if another Siflower chipset has the same fault, the BPI-WiFi5, arrived yesterday.
2 Likes
Thanks for the feedback. Will ask engineers to have a check.
2 Likes
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.
1 Like
That's interesting as if you read this, apparently both GL.iNet and Siflower are aware of relevant WiFi patches being required for the new Openwrt version.
Is the current 18.06 SDK just bugged.
Now that I fixed the connection with the uplink AP, by disabling A-MPDU aggregation on that AP, it becomes clear that the number of packets restriction on the SFT1200 for a A-MPDU, is a major problem for the connecting clients also. There I don't have the control to disable or restrict the MPDU number of packets in a A-MPDU. And the wifi connection, while not disconnecting, suffers in performance.
With
grep -rnw "mpdu" /sys/kernel/debug/ieee80211/phy0/siwifi
(the downlink client)
I get
/sys/kernel/debug/ieee80211/phy0/siwifi/trx_stats:2:mpdu last rx 0
/sys/kernel/debug/ieee80211/phy0/siwifi/trx_stats:9:rx mpdu missed 171078
/sys/kernel/debug/ieee80211/phy0/siwifi/trx_stats:14:mpdu tx retry 47668
/sys/kernel/debug/ieee80211/phy0/siwifi/trx_stats:16:mpdu tx failed 48554
/sys/kernel/debug/ieee80211/phy0/siwifi/trx_stats:17:mpdu tx flush 0
/sys/kernel/debug/ieee80211/phy0/siwifi/trx_stats:18:mpdu tx discard 0
And with
grep -rnw "mpdu" /sys/kernel/debug/ieee80211/phy1/siwifi
(The uplink wifi)
/sys/kernel/debug/ieee80211/phy1/siwifi/trx_stats:2:mpdu last rx 0
/sys/kernel/debug/ieee80211/phy1/siwifi/trx_stats:9:rx mpdu missed 0
/sys/kernel/debug/ieee80211/phy1/siwifi/trx_stats:14:mpdu tx retry 3105
/sys/kernel/debug/ieee80211/phy1/siwifi/trx_stats:16:mpdu tx failed 3105
/sys/kernel/debug/ieee80211/phy1/siwifi/trx_stats:17:mpdu tx flush 0
/sys/kernel/debug/ieee80211/phy1/siwifi/trx_stats:18:mpdu tx discard 0
How to change that ampdu_max_cnt parameter for a sys module ??????????
Looks like the root-cause of all the SFT1200 wifi problems !
The number of MPDU packets restriction on the SFT1200 for a A-MPDU, when receiving, is a major problem
I don't understand how this parameter setting/mod works
Editing /lib/sfwifi.sh
So it contains ... ampdu_max_cnt=${ampdu_max_cnt-64}
And executing that /lib/sfwifi.sh, or reboot of the SFT1200
Did not change the value in /sys/module/sf16a18_hb_fmac/parameters/ampdu_max_cnt
3 Likes