Hello all!
I see a new beta FW for the GL-SFT1200 (opal).
Is this a new openwrt version?
regards!
@bruce the release notes are empty.
I can go for a uboot recovery later and see if it installs but if the bug that @bpwl1 has documented in detail still exists I don't see any reason to update.
I see still 18.06 and same kernel. But this is a different software, closer to the GL_version4 documentation.
Have to change quite some things here to make some tests. We lost (again?) the possibility to access 5 GHz DFS channels what worked in 4.3.21
Thu Jan 2 20:58:59 2025 daemon.notice wpa_supplicant[24873]: sta1: CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00 status_code=12
Thu Jan 2 20:58:59 2025 daemon.notice wpa_supplicant[24873]: sta1: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="bpacrt_5G" auth_failures=2 duration=20 reason=CONN_FAILED
Thu Jan 2 20:59:11 2025 daemon.err gl-repeater[1709]: (repeater.lua:433) connect timeout
Thu Jan 2 20:59:11 2025 daemon.info gl-repeater[1709]: (repeater.lua: 54) skip disabled bss dc:2c:6e:ed:04:c3
Thu Jan 2 20:59:11 2025 daemon.err gl-repeater[1709]: (repeater.lua: 76) skip bss with dfs channel: bpacrt_5G 48:a9:8a:xx:xx:xx 100
Thu Jan 2 20:59:11 2025 daemon.err gl-repeater[1709]: (repeater.lua: 76) skip bss with dfs channel: bpacrt_5G b8:69:f4:xx:xx:xx 132
Thu Jan 2 20:59:11 2025 daemon.info gl-repeater[1709]: (repeater.lua:1450) switch in 30 seconds...
Thu Jan 2 20:59:11 2025 daemon.info gl-repeater[1709]: (repeater.lua:528) check status exited
Thu Jan 2 20:59:11 2025 daemon.info gl-repeater[1709]: (repeater-nl80211.lua:229) listen event exited
And quite some more options in 4.7 compared to 4.3 ...
- Auto-Enable Login Mode for Public Hotspots
- Enable Camouflage
- Lock BSSID
- TTL
- HL
- MTU
Most don't matter, but I cannot connect now (my AP's are on DFS channels for the stronger signal (yes that's how I use it indoors !))
Will change AP setup at home and test, there are much more changes than the wireless connect (no TOR, +AstroWarp, ...) at first glance only.
7 dB difference between the internal-use-only channels (20dBm) and the everywhere DFS channels (27dBm) for Eurrope ETSI regulation is expected. But seen here is signal strength difference of 30dBm, reception of -55dBm (eg Cudy) and -84dBm for SFT1200 (almost unusable) on my laptop from the same send/receive spots.
And ... are we back to square 1 ???
root@GL-SFT1200:~# cat /sys/module/sf16a18_hb_fmac/parameters/ampdu_max_cnt
32
Have some checks to do ...
My command selection so far:
cat /sys/module/sf16a18_hb_fmac/parameters/ampdu_max_cnt
cat /lib/sfwifi.sh
sh /lib/sfwifi.sh
cd /sys/kernel/debug/ieee80211
ls -Rcd /sys/kernel/debug/ieee80211/phy1/siwifi
cat trx_stats
cat statscd /sys/kernel/debug/ieee80211/phy0/siwifi
cat trx_stats
cat statsls -l /sys/module/sf16a18_lb_fmac/parameters
cat /sys/module/sf16a18_lb_fmac/parameters/*ls -l /sys/module/sf16a18_hb_fmac/parameters
cat /sys/module/sf16a18_hb_fmac/parameters/*iwinfo
cat /etc/config/wireless
cd /sys/kernel/debug/ieee80211/phy0/siwifi
cd /sys/kernel/debug/ieee80211/phy1/siwifi
cat stats
cat trx_stats
cat lmactx
cat lmacrx
cat hwq
cat mibuci show
iw
lsmod
Interesting evolution ... seems now like up to 32 MPDU are aggregated, but up to 64 are received. But many failures (with this too low signal?).
But this does not work here, as it did with 4.3.21, what is as described in the docs
DFS¶
When Repeater to a upstream 5G WiFi, the router WiFi will fellow the upstream WiFi to use or not use the DFS channel.
- If the upstream WiFi uses a DFS channel and is scannable, the router's 5G WiFi will use the same channel.
4 Likes
Hi,
Since the beta firmware is compiled from the new server, I assume the release note probably miss to add, will inform guys to check this.
OK, is quite a list of changes this 4.7.2 version.
Interesting to see, the V4 doc is already an indication. It's an extensive set of information.
Overnight the signal strengt improved (???) up to -77dBm now.
Connection is stable, with no special setting. So no use of (BSSID lock, only one known SSID, MultiWAN checks disabled)
Steady connection for 7 hours.
No connection problem with traffic load.
Transfer rate not optimal, and still these warnings in the LOG ... when doing the speed test with MT Btest tool.
But this is a usable wifi repeater/router connection ( when Btest is not running on PC)
The SFT1200 seems to follow the signal strentgh of the uplink, defining the power to send out its downlink on the same radio. More combination tests (eg 2GHz up, 5 GHz down) to be done.
Conclusion so far. Major improvement !!!
Some things to find out, like what's this,
Fri Jan 3 11:33:46 2025 kern.warn kernel: [30807.436489] lmac[1] vif_mgmt_register, vif_type : 0 status=0 index=3, req_idx=0
Fri Jan 3 11:33:46 2025 kern.warn kernel: [30807.444332] lmac[1] use low txpower table
Fri Jan 3 11:33:46 2025 kern.warn kernel: [30807.686136] lmac[0] tx push bcn fail
Fri Jan 3 11:33:46 2025 daemon.info gl-repeater[915]: (repeater.lua:300) sta0: found 13 networks
Fri Jan 3 11:33:48 2025 daemon.info gl-repeater[915]: (repeater.lua:300) sta1: found 6 networks
Reinstalled, without saving current settings.
Modified country to BE (=ETSI/europe), needs DFS channels
But the log says ...
Fri Jan 3 23:45:38 2025 daemon.notice hostapd: acs_noradar = 1 means that the radar channels will be avoided under acs
Fri Jan 3 23:45:38 2025 daemon.notice hostapd: acs_noradar = 1 means that the radar channels will be avoided under acs
Fri Jan 3 23:45:38 2025 daemon.notice hostapd: acs_noradar = 1 means that the radar channels will be avoided under acs
Fri Jan 3 23:45:38 2025 daemon.notice hostapd: acs_noradar = 1 means that the radar channels will be avoided under acs
Refuses to see the DFS channels on the uplink AP's.
LUCI sees them all in the scan. But that is not the proper way to use them.
And the SFT1200 has a very weak 5GHz own client signal. Too weak to be usable.
Setting country in LUCI seems not being accepted ..
Sat Jan 4 11:13:09 2025 kern.warn kernel: [ 14.204009] sfax8_factory_read_probe...
Sat Jan 4 11:13:09 2025 kern.warn kernel: [ 14.209542] macaddr is 94 83 c4 49 da 40
Sat Jan 4 11:13:09 2025 kern.warn kernel: [ 14.215171] sn is ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Sat Jan 4 11:13:09 2025 kern.warn kernel: [ 14.222903] sn_flag is 0xff
Sat Jan 4 11:13:09 2025 kern.warn kernel: [ 14.228697] hardware version flag is ��
Sat Jan 4 11:13:09 2025 kern.warn kernel: [ 14.234175] hardware version is ��������������������������������
Sat Jan 4 11:13:09 2025 kern.warn kernel: [ 14.241817] model version flag is ��
Sat Jan 4 11:13:09 2025 kern.warn kernel: [ 14.246937] model version is ��������������������������������
Sat Jan 4 11:13:09 2025 kern.warn kernel: [ 14.254428] can not find an vaild country ID[��], use default value[CN]
Sat Jan 4 11:13:09 2025 kern.warn kernel: [ 14.261129] countryID is CN
Sat Jan 4 11:13:09 2025 kern.warn kernel: [ 14.265512] HW feature is 0xffffffff
Sat Jan 4 11:13:09 2025 kern.warn kernel: [ 14.270702] vender flag is ��
Sat Jan 4 11:13:09 2025 kern.warn kernel: [ 14.275269] vender is ����������������
Sat Jan 4 11:13:09 2025 kern.warn kernel: [ 14.280624] product key flag is ��
Sat Jan 4 11:13:09 2025 kern.warn kernel: [ 14.285580] product key is ����������������
Sat Jan 4 11:13:09 2025 kern.warn kernel: [ 14.291329] login info flag is ��
Sat Jan 4 11:13:09 2025 kern.warn kernel: [ 14.296195] login info is 0xffffffff
Sat Jan 4 11:13:09 2025 kern.warn kernel: [ 14.301348] rom type flag is ��
Sat Jan 4 11:13:09 2025 kern.warn kernel: [ 14.306032] rom type is 0xffffffff
Sat Jan 4 11:13:09 2025 kern.warn kernel: [ 14.311063] get wifi version XO
Sat Jan 4 11:13:09 2025 kern.warn kernel: [ 14.320353] get gmac delay: 120a
Sat Jan 4 11:13:09 2025 kern.warn kernel: [ 14.323608] sf_factory_read_sysfs_register, parent :sfax8_factory_read
Sat Jan 4 11:13:09 2025 kern.info kernel: [ 14.336162] Button Hotplug driver version 0.4.1
Sat Jan 4 11:13:09 2025 kern.info kernel: [ 14.346017] exFAT: Version 1.2.9
Sat Jan 4 11:13:09 2025 kern.info kernel: [ 14.383157] gl-repeater: (C) 2024 jianhui zhao jianhui.zhao@gl-inet.com
Sat Jan 4 11:13:09 2025 kern.info kernel: [ 14.392906] gl-tertf: (C) 2021 jianhui zhao jianhui.zhao@gl-inet.com
Sat Jan 4 11:13:09 2025 kern.warn kernel: [ 14.402955] gl-kmwan: (C) 2023 chongjun luo luochognjun@gl-inet.com
2 Likes
After re-install of this firmware, and after full reset firmware, so no tweaking, this still gives:
SFT1200 version 4.7.2 wifi (uplink active on 5 GHz with dedicated SSID)
- TX power fluctuating on 2.4 GHz and constant low TXpower on 5GHz
- Cannot detect or connect to 5GHz DFS channel
- Could not connect to one of the base channels (36-40-44-48) when the same SSID existed on the DFS channels from a different AP.
4.3.21 version performed like Cudy
Somewhere in the beginning of the log, after power-reset .... before ntp (wrong clock!)
Mon Dec 16 10:09:20 2024 kern.crit kernel: [ 40.946118] siwifi_parse_txpower_gain_table_configfile: hb_txpower_table.ini not exsist, use default file.
Tested more, went closer to the SFT1200 to get some signal.
Then learned that from very unstable to best performing in 2GHz is the TXPower setting Max- High-Medium-Low for client network. Yes Low gives best and stable signal.
For 5GHz it is somewhat similar : power goes up from Low to Medium. Just a little bit stronger at High (hitting a limit?) and disappears on Max.
2 Likes
Finally updated one Opal, shows 91% memory usage, and all it's doing is a drop in gateway with an openvpn client and both wifi active.
Seems moderately high with a few clients on it.
No progress now, 2 remaining problems : DFS and TXpower
- Weak signal from SFT1200 can be tweaked somewhat (setting client wireless on LOW or MEDIUM in the SFT1200 GUI gives the stronger measured wifi signal than setting HIGH or MAX) but it is still weak.
- In the OpenWRT files (cfr iwinfo) the signal strength is 8 or 9. "option txpower" can be set to 20 for 2.4GHz and 25 for 5 GHz in /etc/config/wireless, and that brings it back on MAX in the GUI.
- Adding line "option txpower_lvl '2'" to radio0 and radio1 in this file /etc/config/wireless increases the power further. (avoiding that LOW Power table usage?) i think the log entry "kern.warn kernel: lmac[0] use low txpower table" is not there anymore
Are there "better" places to make such adjustments? Quite some subsystems do generate such config files, so maybe adjustments must be made there.
Attempts to get the DFS channels back all failed so far. Adjusted the "acs_noradar" to '0' everywhere, and the country is 'BE' , but the DFS frequency AP's do not appear in repeater for internet connection setup.
Again setting country via Luci might not end up in the correct location for "hostapd".
It might also be something else, with this in the LOG
Tue Jan 14 00:42:39 2025 daemon.warn hostapd: Failed to check if DFS is required; ret=-1
Tue Jan 14 00:42:39 2025 daemon.warn hostapd: Failed to check if DFS is required; ret=-1
Tue Jan 14 00:42:39 2025 daemon.notice hostapd: handle_probe_req: send failed
Tue Jan 14 00:42:17 2025 daemon.notice hostapd: ACS: Survey is missing noise floor
Tue Jan 14 00:42:17 2025 daemon.notice hostapd: ACS: Survey is missing channel time
Tue Jan 14 00:42:17 2025 daemon.notice hostapd: ACS: Survey is missing RX and busy time (at least one is required)
1 Like
Thank you very much for your feedback, is DFS and TXpower an issue only in the 4.7.2 beta? How many 5g wireless networks do you have? We'll confirm both issues; by the way, do you still have the relay disconnect issue in your environment in the 4.7.2 beta?
Hello,
It seems not reproduce:
SFT1200, v4.7.2,
Enable the OpenVPN client, and connected.
Unplug the WAN.
The memory usage range I think it is normal
switched to Wireguard and the memory dropped to 82% usage.
For me now the TX power and the lack of DFS are the only problems remaining with version 4.7.2 beta on SFT1200.
I have been searching quite long with SSH in all readable files , to find if there is any difference between 4.3.21 and 4.7.2beta that could explain why
- TX power in 4.3.21 is strong to very strong and is very weak in 4.7.2beta on SFT1200
- DFS channels can be connected and repeated in 4.3.21 and not in 4.7.2beta (and not in 7.3.19 and before)
Compared all readable files I could find, but found no clue there.
Actually it looks like these files do not always represent what is in the GUI.
The relais problem is fixed with 4.7.2beta , and the possibility to delay the MWAN3 test is an extra.
However looking back to all my tests (and reports of it) which seemed inconsistent at that time, the fact that it works great when there is only one AP with that specific uplink SSID, makes it all consistent. The other tweaks where maybe irrelevant, but resulted in the use of a separate SSID or not.
With the lack of DFS connections, a single AP here has been modified and set with a different SSID to use a non-DFS channel, and all is good. This is only OK if you manage the uplink APs, and if the signal for non-DFS is strong enough.
This is only at home (6 AP, 4 indoor, 2 outdoor). Most are my "bpacrt" SSID, GL (bpacrt.GL5) is connected to dedicated "bpacrt_W", and is now just next to my PC, as this is needed with 4.7.2beta. (The cudy/TR1200 is in another room, with stronger signal received)
My ISP also sends out on 5GHz DFS channels for my private subscription, and also with a public SSID, with ISP subscriber EAP logon. So every home served by this ISP in this country is a usable AP for me. Ideal to connect with a travel router that can handle PEAP logon, like the SFT1200.
I have been fighting connection drops in reapeter mode with every firmware version, Same here with beta 4.7.2, i do think i have narrowed my problem down however. i have always turned off the wifi radios under the wirless tab as i only connect to a wired client. On 4.7.2 if i leave them on the connection becomes stable. if i turn them off i get disconnects about every minute or so. Hope this info helps debugging this
Edit nevermind it worked for about 15 minutes then the disconnects started again
AFAIK in my tests, the 4.7.2beta has the TXpower lowered by 30dB (1000 times lower!) compared to stable ( 4.3.21) and the communication with client devices and the uplink may have reduced MCS values due to the too weak signal.
2 Likes
NEW 4.7.2beta??? Where ?
Checking from time to time, only seeing always the same date and number
openwrt-sft1200-4.7.2-1227-1735237824
Some people on reddit complained about the same power loss.
https://www.reddit.com/r/GlInet/comments/1hs51tx/v472_glsft1200_beta_1/
They might be confused at GL.inet also.
In the 4.3.24 they mention solving the DFS and TXpower problem (exactly for me the most important problems in the 4.7.2beta). DFS was not a problem in 4.3.21 AFAIK, however there are more DFS actions in the log of 4.3.24 . Which still has most of the connection stability problems, and suffers from the 'hotplug' actions such as reloading FW rules, stopping tracked sessions, and taking very long to recover.
1 Like
This should not be the problem. 30dBm is a very high number, right?
In some models it may use different units, e.g. 100 not really mean 100dBm.
I think you mistranslated/understood ... it is not 30dBm ... but lowered with 30dB, it is 30dBm lower than normal, and that is a major problem.
TXpower is not 30dBm, it is 30dBm LESS or LOWER than before, and lower than any other device.
The transmitted TX power is probably 0dBm , 1 milliwatt, 0.001 Watt , it should be between 20dBm and 27dBm, or 100 and 500 milliwatts.
The received signal at my PC drops from -30dBm to -57dBm with the upgrade from 4.3.21 to 4.7.2beta. Signal strength just at 20 centimeter from the OPAL router!
The connected AP(Mikrotik) sees now a RX signal from the OPAL drop to -82dBm, at 2 meters, with open line-of-sight, no obstructions. Interface speed (MCS value) drops, the CCQ is bad now. The Mikrotik has 5dBm antenna gain so receives the signal with that antenna gain. This signal strength is now also 27dBm lower than with version 4.3.21.
Amazing that the TXpower mentioned in the LOG with version 4.3.24 is 27dBm.
I assume the driver gets a zero value for the TXpower with version 4.7.2beta, instead of the intended 27dBm.
This device with version 4.7.2beta is just totally USELESS at the distance of 1 meter from client or uplink AP.
2 Likes
It looks like ....
The 0dBm have always been there for sta0 and sta1 (client wifi for uplink) in LUCI and in SSH with "iwinfo sta0 txpowerlist" and "iwinfo sta1 txpowerlist" . And channel and bandwidth in the GUI referred to the client uplink, but the TX power could be set on the client wifi.
But now with this 4.7.2beta it seems that the TX power is taken from the uplink value, and that value in LUCI and in SSH is 0dBm.
(The bandwidth is, and has been, wrong)
Changing the TXpower of sta0 and sta1 (when they exist) with
root@GL-SFT1200:~# iw sta1 set txpower fixed 10
root@GL-SFT1200:~# iw sta1 set txpower limit 20
root@GL-SFT1200:~# iwinfo sta1 txpowerlist
fails. " iw sta1 set txpower auto" sometimes works for a few seconds (gives 20dBm) in iwinfo. So I cannot test if this value is used, or if it is just some wrong reference used. (Power measurement is too slow to see it)
The txpower of sta and ap are the same. So you can check what is the txpower of ap. Luci may not display correctly.