GL-SFT1200 (Opal) stuck in single-radio AP+STA behavior after firmware update

GLiNet_icer · October 2, 2025, 2:05am

Hello,

I’m running into a strange issue with my GL-SFT1200 (Opal). Until recently, I was able to use it in repeater mode where it would connect to my home router (either 2.4 GHz or 5 GHz) and still broadcast both 2.4 GHz and 5 GHz SSIDs for my devices at the same time.

Now, the behavior has changed:

If I connect the Opal’s uplink to my home router on 2.4 GHz, then only the 5 GHz SSID is broadcast. The 2.4 GHz SSID disappears.
If I connect uplink on 5 GHz, then only the 2.4 GHz SSID is broadcast. The 5 GHz SSID disappears.
In other words, whichever band is used for the uplink STA is no longer available as a local AP.

This looks like standard OpenWrt AP+STA band limitation, but it never behaved this way on the Opal before. With the same home router (non-DFS channels), both SSIDs used to be available.

Steps already tried:

Updated to latest stable and beta firmware builds
Factory reset
Removed and re-added Wi-Fi configs
Tested uplink on both 2.4 GHz and 5 GHz networks
Verified home router is not using DFS channels
Confirmed via uci show wireless that both radios are set to AP + one STA

Logs (logread, dmesg) don’t show DFS/radar events.

This problem looks exactly like the “fast lane” behavior on some extenders (uplink on one band, only broadcast the opposite band), but as far as I know the Opal isn’t supposed to enforce that.

My question:

Has there been a recent firmware change that forces this AP+STA limitation?
Is this a known regression on the Opal?
Should I stick to an earlier stable firmware, or is there a way to force one radio (e.g. 5 GHz) to handle both STA + AP again while the other radio stays AP-only?

Thank you for any guidance.

bruce · October 7, 2025, 1:43pm

Hello,

Did downgrading to the previous firmware version and check if it is a good behavior?
Please export the router's configuration backup from Luci and PM it to me? I would like to check it locally.

GLiNet_icer · October 7, 2025, 3:48pm

Thanks Bruce for reaching out.

1.) I’ve downgraded from BETA to v4.3.25
2.) Sent

Hopefully we can resolve this.

bruce · October 8, 2025, 2:58am

Hello,

May I know is it normal behavior in v4.3.25?

Thanks.

GLiNet_icer · October 8, 2025, 3:22am

Since going back to v4.3.25, it's been acting completely abnormal. It’s exhibiting the exact same strange behavior that I experienced with the Beta firmware.

I have two theories that might explain this mystery: first, there could be DFS (Dynamic Frequency Selection) channels lurking in the area, causing interference and instability; or second, I might have unknowingly connected to a DFS-enabled router, which is known to switch channels unexpectedly and disrupt normal operation. Whatever the case, it’s definitely not normal, and I’m on the lookout for a solution—or at least some clarity on this peculiar situation.

bruce · October 10, 2025, 4:31am

Got it!

We've reproduced this issue and have submitted it to R&D for further investigation.

It seems the SFT1200 own AP's channel isn't synchronized with the primary router Wi-Fi's channel, causing the own AP to fail to broadcast properly.

bruce · October 10, 2025, 9:20am

Update a workaround:

Please SSH to router, and execute this:

cat <<'EOF' > /etc/hotplug.d/iface/99_repeater_chan_sync
#!/bin/sh

LOGTAG="hotplug-repeater"
CONFIG_FILE="/tmp/last_channel.conf"

[ "$INTERFACE" = "wwan" ] || exit 0

log() {
    logger -t $LOGTAG "$1"
}

find_radio_by_iface() {
    local iface="$1"
    local section
    for section in $(uci show wireless | grep "=wifi-iface" | cut -d. -f2 | cut -d= -f1); do
        local net=$(uci get wireless.$section.network 2>/dev/null)
        local dev=$(uci get wireless.$section.device 2>/dev/null)
        if [ "$net" = "$iface" ]; then
            echo "$dev"
            return
        fi
    done
    echo ""
}

find_main_radio() {
    local section
    for section in $(uci show wireless | grep "=wifi-iface" | cut -d. -f2 | cut -d= -f1); do
        local mode=$(uci get wireless.$section.mode 2>/dev/null)
        local dev=$(uci get wireless.$section.device 2>/dev/null)
        if [ "$mode" != "sta" ] && [ -n "$dev" ]; then
            echo "$dev"
            return
        fi
    done
    echo ""
}

save_channel() {
    local radio="$1"
    [ -z "$radio" ] && log "No radio found, skip save" && return
    local channel=$(uci get wireless.$radio.channel 2>/dev/null)
    local bandwidth=$(uci get wireless.$radio.htmode 2>/dev/null)
    [ -z "$channel" ] && channel=auto
    [ -z "$bandwidth" ] && bandwidth="HT20"
    {
        echo "radio=$radio"
        echo "channel=$channel"
        echo "bandwidth=$bandwidth"
    } > $CONFIG_FILE
    log "Saved radio=$radio channel=$channel bw=$bandwidth"
}

restore_channel() {
    [ -f "$CONFIG_FILE" ] || {
        log "No saved channel info found, skip restore"
        return
    }
    . $CONFIG_FILE
    [ -z "$radio" ] && log "Missing radio info in $CONFIG_FILE" && return
    log "Restoring radio=$radio channel=$channel bw=$bandwidth"
    uci set wireless.$radio.channel=$channel
    uci set wireless.$radio.htmode=$bandwidth
    uci commit wireless
    wifi reload
}

get_iface_info() {
    local ifname=$1
    iw dev "$ifname" info 2>/dev/null | awk '
        /^[[:space:]]*channel[[:space:]]+[0-9]+/ {
            ch = $2
        }
        END {
            if (ch == "") ch = "auto"
            printf "%s", ch
        }'
}

find_sta_iface() {
    uci get wireless.sta.ifname
}

case "$ACTION" in
    ifup)
        log "WWAN up detected"
        STA_IFACE=$(find_sta_iface)
        MAIN_RADIO=$(find_radio_by_iface "$INTERFACE")
        [ -z "$STA_IFACE" ] && log "No STA iface found!" && exit 0
        [ -z "$MAIN_RADIO" ] && log "No MAIN radio found!" && exit 0

        save_channel "$MAIN_RADIO"

        NEW_CH=$(get_iface_info "$STA_IFACE")
        if [ -z "$NEW_CH" ]; then
            log "Failed to get channel info from $STA_IFACE"
            exit 0
        fi

        CUR_CH=$(uci get wireless.${MAIN_RADIO}.channel 2>/dev/null)
        if [ "$CUR_CH" != "$NEW_CH" ]; then
            log "Updating MAIN ${MAIN_RADIO}: $CUR_CH->$NEW_CH"
            uci set wireless.${MAIN_RADIO}.channel="$NEW_CH"
            if [ "$NEW_CH" = "165" ]; then
                HTMODE="HT20"
                uci set wireless.${MAIN_RADIO}.htmode="$HTMODE"
                log "Force 165 channel to HT20 mode"
            fi
            uci commit wireless
            wifi reload
        else
            log "MAIN ${MAIN_RADIO} already matches channel=$NEW_CH"
        fi
        ;;
    ifdown)
        log "WWAN down detected, restoring channel"
        restore_channel
        ;;
    *)
        log "Unhandled ACTION=$ACTION"
        ;;
esac

exit 0
EOF

Disable and re-enable the Repeater.

GLiNet_icer · October 10, 2025, 9:43pm

Thanks for sending over the repeater channel sync script — I’ve installed and tested it, and it’s working as intended. The 5 GHz channel now stays properly synchronized between the STA connection and the AP broadcast, which resolves the original channel issue.

However, I’m still noticing a recurring problem when the router is under heavy network load. Specifically, whenever I perform a full-speed download or run an internet speed test, the router briefly loses internet connectivity. It looks like the STA connection temporarily drops or resets — I lose internet access for a few seconds before it automatically reconnects.

What’s strange is that this behavior didn’t occur when I first configured the repeater setup about six months ago. At that time, the router maintained a stable STA connection even during high-speed transfers.

Could you help me identify what might be causing the STA link to drop under load?

Happy to share logs or run any diagnostic commands if that helps.

Thanks again for your help — Matthew

bruce · October 11, 2025, 8:58am

Hi,

When this issue reproduced, please check by ping [primary router LAN IP] and ping www.google.com, will the packet loss?
Please try to downgrade to the previous firmware version first and see if the same issue reproduces?

GLiNet_icer · October 12, 2025, 9:17pm

I ran both ping tests while under high load (running a speed test simultaneously). Here are the results:

Ping to primary router (192.168.1.1): ~4.4% packet loss, with latency spikes ranging from 5 ms up to 750 ms.
Ping to www.google.com: ~14% packet loss, with latency fluctuating between 16 ms and 1100 ms.

There’s noticeable instability both locally (to the main router) and externally (to Google). I’m not sure if downgrading to the previous firmware would fully address this, but I can try if you think it’s necessary.

Curious to know if that reverting back to an old firmware means I’m require to recreate the custom script setup again?

bruce · October 14, 2025, 8:27am

Hi,

How is Opal connected to the primary router? If repeater, please connect to the 5GHz WiFi of the Primary router. If not, please let me know your topology.

I think can also try to downgrade to the old firmware version (without keep settings).
If the own AP/WiFi is abnormal after repeater connected to primary WiFi, please again execute the script I posted above.

system · January 12, 2026, 8:28am

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.