Mały zgryz mam - zauważyłem, że gniazdka po rekonfiguracji sieci zwracają inny token (na razie w trybie debugu). Wiem ze skryptu, że token zależy od MAC-a dla br-lan - lub jeśli nie istnieje, to eth0 (którego na pewno w tym przypadku nie ma, więc celowe jest zmienienie w skrypcie na wlan0). Ale po kolei (obciąłem info nt. loopbacku, ustawienia globalne itp)

1) system po firstboocie - wygląda zrozumiale dla mnie (łączę się do SSID rozgłaszanego przez gniazdko, IP 192.168.1.1)
adresy MAC interfejsów:
wlan0: 74:da:da:da:69:33
br-lan: 74:da:da:da:69:33

# uci show network
network.@device[0]=device
network.@device[0].name='br-lan'
network.@device[0].type='bridge'
network.@device[0].ports='eth0'
network.lan=interface
network.lan.device='br-lan'
network.lan.proto='static'
network.lan.ipaddr='192.168.1.1'
network.lan.netmask='255.255.255.0'
network.lan.ip6assign='60'
network.wan=interface
network.wan.proto='dhcp'

# uci show wireless
wireless.default_radio0=wifi-iface
wireless.default_radio0.device='radio0'
wireless.default_radio0.network='lan'
wireless.default_radio0.mode='ap'
wireless.default_radio0.ssid='DSP-6933'
wireless.default_radio0.encryption='psk2'
wireless.default_radio0.key='DSP-6933123456'

2) wyłączam "default_radio0", dokładam konfigurację STA do połączenia z moją siecią itp.

uci -q del network.wan
uci -q del network.wwan
uci set network.wwan=interface
uci set network.wwan.proto=dhcp
uci -q del network.bridge
uci set network.bridge=interface
uci set network.bridge.proto=relay
uci set network.bridge.network="lan wwan"
uci set wireless.default_radio0.disabled=1
uci set wireless.radio0.channel=auto
uci set wireless.repeater_sta=wifi-iface
uci set wireless.repeater_sta.device=radio0
uci set wireless.repeater_sta.mode=sta
uci set wireless.repeater_sta.ssid="domowy-internet"
uci set wireless.repeater_sta.encryption=psk2
uci set wireless.repeater_sta.key="12345678"
uci set wireless.repeater_sta.network=wwan
uci set dhcp.lan.ignore=1
uci set firewall.@zone[0].network="lan bridge wwan"
uci commit
/etc/init.d/network restart ; exit

3) Łączę się przez domowy lan, loguję się przez IP nadane przez domowy router. Instaluję relayd.

opkg update && opkg install relayd
/etc/init.d/network restart

adresy MAC interfejsów:
wlan0: 74:da:da:da:69:33
br-lan - nie ma już takiego

4) dokładam konfigurację do rozgłaszania sieci domowej:

uci set wireless.repeater_ap=wifi-iface
uci set wireless.repeater_ap.device=radio0
uci set wireless.repeater_ap.mode=ap
uci set wireless.repeater_ap.ssid="domowy-internet"
uci set wireless.repeater_ap.encryption=psk2
uci set wireless.repeater_ap.key="12345678"
uci set wireless.repeater_ap.network=lan
uci commit
/etc/init.d/network restart

wlan0: 74:da:da:da:69:33
wlan0-1: 76:da:da:da:69:33
br-lan: 76:da:da:da:69:33

I w ten sposób nie zmieniając urządzenia - zmieniam token. W zależności od konfiguracji użyty jest MAC wlan0, albo br-lan - którego pierwszy oktet podbity jest o 2 względem wlan0.

Testowo dołożyłem kolejne AP - i wtedy mam kolejną zmianę:

wlan0: 74:da:da:da:69:33
wlan0-1: 76:da:da:da:69:33
wlan0-2: 72:da:da:da:69:33
br-lan: 72:da:da:da:69:33

Wiem, że to jest pewnie strasznie niszowy problem, ale przerobię skrypt, żeby brał MAC zawsze z wlan0, nie zwracając na (nie)obecność br-lan.

@Cezary jutro podeślę tokeny do przeniesienia statystyk, które były tokenowane wg. br-lan, a które po wyłączeniu rozgłaszania sieci muszę przełożyć na wlan0 (który nie znika i którego MAC raczej nie powinien się zmienić).

Na tym polega dowcip, że bez routera z owrt wszystko śmiga bez problemu, temat był zgłoszony do isp i wg nich to jest problem routera Faktem jest, że wywalając router - usuwam problem. Testowałem również tunelując się przez świat (w przeglądarce z poziomu klienta wpiętego za routerem) - i netflix hula (chociaż połączenie przez tunel wireguard + ssh proxy nie przekracza 20-30 mbit). Ale to jest obejście, a nie rozwiązanie.

Hej, @Cezary czy w związku z "zamknięciem" 21.02 rozważyłbyś budowanie 22.03 na WDR3600/4300 w wersji 16MB?
Chociaż pytam bez większego przekonania, zwłaszcza że jak widzę to jesteśmy wraz z rodziną jedynymi użytkownikami

Zapiszczało (słyszalnie dla mnie) po odpięciu lampek. Gdy lampki były wyłączone (przekaźnikiem) - więc brak obciążenia, to nie piszczało. Gdy obciążeniem jest sama elektronika gniazdka - też piszczy.

Co do zalania - mogę spróbować. Ale chyba na początek muszę wymienić kondensator, bo nieco spuchnięty

Zazwyczaj robię aktualizacje z zachowaniem konfiguracji i na tyle się przyzwyczaiłem do włączonych statystyk, że mnie to zmyliło
A akurat z tym egzemplarzem robiłem teraz bez konfigów, więc wydało mi się to aż dziwne

Skrypt wrzuciłem jako /usr/bin/ac.sh
W luci mam skonfigurowane

config command 'on'
    option name 'on'
    option public '1'
    option command 'ac.sh on'

config command 'off'
    option name 'off'
    option public '1'
    option command 'ac.sh off'

config command 'switch'
    option name 'switch'
    option public '1'
    option command 'ac.sh switch'

config command 'status'
    option name 'status'
    option public '1'
    option command 'ac.sh'

(oczywiście command może zawierać pełną ścieżkę do pliku, ale ponieważ /usr/bin znajduje się w $PATH to nie trzeba).
I uderzam np. do http://adres/cgi-bin/luci/command/statuss i wiem, że świecą mi się lampki na choince (swoją drogą chyba czas rozebrać...) A ponieważ dałem to public=1 to nie potrzebuję logowania do luci od "gniazdek", zakładam że to jest tylko w LANie albo po VPN.

Osobnym tematem jest jakaś apka do zarządzania paroma gniazdkami. Pewnie gdzieś ktoś już coś takiego robił, ale nie zachodziłem dotychczas w rejony automatyki (chętnie skorzystam, jeśli ktoś podrzuci w którą stronę iść).
Póki co mam wrzuconą do /www/power.html na głównym routerze domowym prymitywną stronkę z linkami do posiadanych gniazdek z czterema opcjami wynikającymi z powyższej konfiguracji. Więc w domu po wifi albo spoza domu po wireguard wejście na stronkę - i śmiga.

Ten paczka jest ok, dzięki. Brakowało chyba case'ów dla 16m.

Jeśli dobrze kojarzę, to na tym urządzeniu robiłem aktualizacje kolejnymi buildami 22.03 bez zachowania konfiguracji, nawet przejście z 21.02 chyba w ten sposób mi się udało zrobić. Więc braki w sieci jakoś pominąłem.

Ale że nie ma nikogo z tym sprzętem, to nieco mnie smuci. Kolejny "wynalazek", którego używam tylko ja (+znajomi/rodzina).

BTW. Szukając źródeł do Twojego Mifi trafiłem na https://eko.one.pl/openwrt/ - wygląda to na nieco porzucone, patrząc po datach

Fakt, nie doprecyzowałem. To Twój obraz (leciało ostatnio z mifi-22.03-snapshot-r20035-aa5023b9cd-nexx_wt3020-16m-squashfs-sysupgrade.bin)
Rzeczony plik zawiera:

nexx,wt3020-16m

Przy okazji (chociaż nie wiem, co się skąd bierze) /etc/board.json zawiera:

{
    "model": {
        "id": "nexx,wt3020-16m",
        "name": "Nexx WT3020 (16M)"
    },
    "network": {
        "lan": {
            "device": "eth0",
            "protocol": "static"
        }
    }
}

Testuję te sprzęty, które mam u siebie. Nie zauważyłem piszczenia, niezależnie od tego czy przekaźnik jest załączony, czy nie. Zarówno za dnia, jak i późnym wieczorem, kiedy nie ma tylu dźwięków tła. Ale możliwe, że po prostu mam już załączony biologiczny filtr odcinający takie częstotliwości

A ogólnie - ładnie chodzą, jak na moje potrzeby. Po doinstalowaniu relayd, ekooneplstat+luci-app-ekooneplstat, kmod-wireguard+wireguard-tools z wszelkimi zależnościami - zostaje ~80KB miejsca.

Odnośnie identyfikatora sprzętu -  @cezary jeśli miałby nastąpić kolejny build może warto zmienić "B1" na "B1/B2", skoro mamy potwierdzone działanie również na B2?