MikroTik hAP mini a výpadky připojených zařízení

[Buldr]

Řeším nepříjemný problém s Mikrotikem a jejich "zakletou" WiFi. Problém tkví v tom, že připojená zařízení při nečiinosti přechází do úsporného režimu a po opětovné aktivaci znovu nedokáží připojit. Z nějakého důvodu vůbec DHCP nepřijme požadavek na přidělení adresy.

- Mikrotik hAP Mini 7.22.2 (Stable), identicky se chová i na 7.21.4 (LT)
- Režim AP, bez CAPSMAN či čehokoliv dalšího (WAN je statické)
- DHCP Server ve standardní konfiguraci (Lease 30 min) 10.5.10.0/24
- Připojení (Security Profile) pouze s dynamickým WPS2-PSK AES CCM
- WAN je nastaven staticky na 10.5.0.100
- WIFI 2.4 GHz B/G/N 20MHz kanál, MTU 1500 (2412/20/gn(18dBm))
- band steering, izolaci klientů, access listy ... nic takového

Největší problém je vysavač (Tesla) a čistička vzduchu (Xiaomi), protože obě zařízení se po nějaké době, nebo po resetu AP (např.: po update RouterOS) zkrátka nepřipojí, zkouší to (z aplikace žádné logy nevyrazím) a Mikrotik se tváří, jako by žádný požadavek ani nedostal, což mi přijde min. divné a jedniné řešení je resetovat zařízení, tedy otravné a nikde není psáno, že to projde bez resetu do továrního nastavení a opětovném nastavování.

Těch zařízení je samozřejmě více např.: Eheim pro akvária s tím má v podstatě ten samý problém. Zajímavé na tom je, že Zyxel a Ubiquiti s tím nemají sebemenší problém, dělá to pouze Mikrotik a nemohu přijít na důvod (např.: telefon i notebook se bez problémů připojí), stejně tak jsem zkusil RouterOS a vzít jiné AP (v domě jich mám více, včetně rozdílných modelů - CAPsMANv2 ... potíž je, že je mám na 5GHz, které není všemi zařízeními podporováno). Nemá s tím problém ani hlavní router (Turris), jen a jen Mikrotik.

Neuměl by někdo nakopnout správným směrem?

Manuální nastavení Wi-Fi konfigurace u vysavače bohužel není podporováno. Zařízení nemá uživatelsky dostupné rozhraní, přes které by bylo možné síťové parametry nastavit napevno, a k dispozici není ani script, servisní příkaz nebo jiný postup, kterým by šlo obejít standardní párování přes aplikaci TESLA Smart.

Připojení probíhá pouze přes párovací proces v aplikaci.

Pokud se zařízení v aplikaci najde, ale následně se vůbec nepokusí připojit k AP a párování skončí timeoutem, bude potřeba ověřit, zda se problém váže ke konkrétní konfiguraci sítě/AP, nebo k samotnému zařízení.

 

Doporučujeme ještě provést tyto kroky:

obnovit vysavač do továrního nastavení,

v telefonu odinstalovat aplikaci TESLA Smart, znovu ji nainstalovat v aktuální verzi a znovu se přihlásit,

ověřit párování přes zcela jednoduchou testovací 2,4GHz síť, ideálně vytvořenou jako hotspot z jiného telefonu,

pokud se přes hotspot připojí, bude pravděpodobně příčina v některém parametru konfigurace AP,

u Mikrotiku doporučujeme pro test vypnout pokročilé funkce typu WPA3/PMF, 802.11r/k/v roaming, band steering, izolaci klientů, access listy, případně použít pouze WPA2-PSK/AES, viditelné SSID a běžný 20MHz kanál.

 

Pokud se zařízení nepřipojí ani k jednoduchému hotspotu z jiného telefonu, bude vhodné zařízení reklamovat u prodejce, aby mohlo být odborně zkontrolováno. Postup pro reklamaci najdete zde: https://eshop.tesla-electronics.eu/reklamace-servis-a-vraceni

[Reklama]

[CFM]

A ta zlobivá zařízení "jen" nedostanou adresu z DHCP, nebo nejsou ani připojené k WiFi - tj. vidět na daném AP v seznamu WiFi->Registration?

[Buldr]

Bohužel, platí oba případy ačkoliv většinou není ani v listu (@WLAN1-WIFI > Registration) a moudřejší nejsem ani z logů, protože se nemám čeho chytit. Jako správný blbec jsem jsi nezálohoval logy, než jsem udělal upgrade na 7.23.2, čili jsem přišel i o to málo k prohledání, protože problém neumím nasimulovat.

Přikládám log, při kterém se vysavač chytil, ačkoliv byl v podstatě 12 hodin v úsporném režimu, což je přesně důvod, proč neumím problém nasimulovat.

[CFM]

Mimochodem je tam dost různých subnetů (v textu a obrázcích vidím 10.5.0.x, 10.5.1.x, 10.5.10.x). Jsou tam i VLANy? Je tam jen jedno DHCP? wlan1 je slepená do bridge1 s ethX? Na jakém interfejsu je konkrétně DHCP server (bridge1, ethX, wlan1, ...)? Nejvíc pomůže celý config:

Kód: [Vybrat]

/export hide-sensitive.

[Buldr]

Pouze jeden, 10.5.1.0/24 je vnější síť, protože se k AP připojuji z "WAN", tedy vnější sítě. Podotýkám izolovaný subnet, protože všechny připojené zařízení mám izolované od zbytku sítě. Čistě pro jistotu, podobně jako kamery, které mám na samostatném subnetu (10.5.4.0/24). Nechci, aby různě děravá zařízení, včetně čínských průzkumníků, přístup do sítě a veškeré zabezpeční, přístupy, ... si řeším na Turrisu.

Samotné AP má nastaveno (trvalé přirazení) ether1 10.5.1.100, vnitřní potom 10.5.10.0/24.

Kód: [Vybrat]

# 2026-05-09 12:23:57 by RouterOS 7.22.3
# software id = IQ44-75XY
#
# model = RB931-2nD
# serial number = H*******X
/interface bridge
add name=bridge1
/interface ethernet
set [ find default-name=ether1 ] name=ether1-WAN
set [ find default-name=ether2 ] name=ether2-LAN1
set [ find default-name=ether3 ] name=ether3-LAN2
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
add authentication-types=wpa2-psk mode=dynamic-keys name=BTR \
    supplicant-identity=""
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-b/g/n country="czech republic" \
    disabled=no frequency=auto mode=ap-bridge name=wlan1-WIFI \
    security-profile=BTR ssid=MKAP5-IOT
/ip pool
add name=dhcp_pool0 ranges=10.5.10.2-10.5.10.254
add name=dhcp_pool1 ranges=10.5.10.2-10.5.10.254
add name=dhcp_pool2 ranges=10.5.10.2-10.5.10.254
add name=dhcp_pool3 ranges=10.5.10.2-10.5.10.254
add name=dhcp_pool4 ranges=10.5.10.2-10.5.10.254
add name=dhcp_pool5 ranges=10.5.10.2-10.5.10.254
add name=dhcp_pool6 ranges=10.5.10.2-10.5.10.254
/ip dhcp-server
add address-pool=dhcp_pool6 interface=bridge1 name=dhcp1
/interface bridge port
add bridge=bridge1 interface=ether2-LAN1
add bridge=bridge1 interface=ether3-LAN2
add bridge=bridge1 interface=wlan1-WIFI
/ipv6 settings
set disable-ipv6=yes
/interface wireless access-list
add interface=wlan1-WIFI mac-address=1C:EA:AC:1E:E6:2B
/ip address
add address=10.5.10.1/24 interface=bridge1 network=10.5.10.0
/ip dhcp-client
add default-route-tables=main interface=ether1-WAN name=ether1-WAN
/ip dhcp-server network
add address=10.5.10.0/24 gateway=10.5.10.1
/ip dns
set servers=10.5.1.1
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1-WAN
/system clock
set time-zone-name=Europe/Prague
/system identity
set name=MikroTikAP5
/system ntp client
set enabled=yes
/system ntp client servers
add address=0.us.pool.ntp.org
add address=1.us.pool.ntp.org
add address=0.cz.pool.ntp.org
add address=1.cz.pool.ntp.org
/system routerboard settings
set auto-upgrade=yes

[Reklama]

[CFM]

Na první pohled nevidím nic, proč by DHCP nemělo fungovat.
Jiné AP se stejným SSID tam předpokládám není (případně situace, že by si vysavač pamatoval SSID/heslo více sítí a pak se hlásil jinam)?
Neběží na některém zařízení též DHCP server?
"nebo po resetu AP" tohle je opakovatelné (vždy, náhodně)?

Poznámky:

Kód: [Vybrat]

/interface wireless access-list add interface=wlan1-WIFI mac-address=1C:EA:AC:1E:E6:2BNemá žádný efekt, pokud se nenastaví "default-authentication=no" na wlan1-WIFI interface.

Kód: [Vybrat]

frequency=autoPrý zohledňuje jen počet ostatních sítí a ne jejich sílu či jiné rušení na kanálu.

Kód: [Vybrat]

add name=dhcp_pool0 ranges=10.5.10.2-10.5.10.254
add name=dhcp_pool6 ranges=10.5.10.2-10.5.10.254
Asi ničemu nevadí(?), když se používá jen jeden pool.

Použití NATu vypadá podivně a není vypnuté forwardování.

[Buldr]

Odůvodněně zcela primitivní nastavení, základní, bez komplikací. Nechci se zabývat ničím zbytečným, nota bene nechci zjistit, že v něčem byl bug.

U Mikrotiku je DHCP prokletí, užil jsem si nimi při pokrývání firemních prostor, kdy běžel zakázný DHCP server dodržující lease 10 min, takže po 10 minutách od připojení mi telefony a notebooky hlásili "bez internetu". Následek byl takový, že Nebula UMT SP okamžitě dotčené klienty zařízla. Další legtace byla s randomizoavnými MAC, jistě fajn pro veřejné sítě, ale všechny Samsungy A52 (telefony pro dámy v kancelářích) a jeden iPhone SE ..., kterým sice DHCP (CAPsMAN v2) přiradil IP ... ale nikam je nepustil, čili všechny telefony "bez internetu" a v logu ani čárka. Mikrotik hned po vybalení z krabice musí dostat tvrdý reset, všechno tovární zlikvidovat a nastavit od základu, jinak potom běží DHCP ačkoliv není povolené, natož nastavené. Do třetice ne všechny telefony mají rádi MESH... s Mikrotikem problém nemám, jen občas přijde duchařina a je těžké se něčeho chytit.

Náhodně, kdyby se jednalo o systémovou chybu, měl bych se čeho chytit. Proto netuším a nechápu, proč zrovna tyhle vysavač, čistička a ovládání světel aktária jsou takový problém, respektive proč mají problém čistě s Mikrotikem. Když je šoupnu na Ubiquiti, Zyxel, ... je po problému.

Příčina bude "úplná blbost", proto zabere tolik času vůbec příjit na to, v čem přesně je problém.

[panpanika]

kde bezel zakazany dhcp server?

[CFM]

Kdyby to byl problém jen s restartem AP, tak bych podezdříval tu automatickou volbu kanálu, že se třeba vybere kombinace, kterou nějkterá zařízení nepodporují. Nicméně to by pak asi nereagovalo na uspání klienta. Pro jistotu bych zkusil fix kanál.
Dál bych zkusil (dočasně) povolit i horší šifrování (TKIP).
Zvýšit log level pro DHCP a WIFI.
Spustit DHCP jinde, aby se ukázalo, zda jde o problém čistě s DHCP nebo spíš s připojením k WIFI.

[M_D]

Zkusil bych si i zapnout WMM, který má mikrotik na AP default vypnut. Pod ním je schována i část logiky řízení klientů v power save módu. Je to v advanced parametrech wifi (wmm-support=enabled). Ale to má vliv na duchařinu typu, že AP se snaží vysílat a klient to nevidí nebo se nepotkávají okna zapnutí wifi klienta. Nemělo by to asi řešit to, že po restartu AP se klient už nepřipojí.
Ty blbnoucí klienti ti jedou v jaké normě wifi a rychlosti, když se drží?
Pokud nebudu mít klienty vidět, že jsou připojení v registration, tak do té doby nemá smysl moc řešit, zda jde o problém s DHCP. Takže ano, debug na wifi/dhcp a pak se uvidí.

[Buldr]

Blbnoucí cAP AC (NAAMKR1037) jsou tři roky stará historie, která se dávno vyřešila a od té doby šlapou jak hodinky (LT RouterOS), bez sebemenších problémů. Jen mě to nepříjemně překvapilo a už si dávám pozor. Dům se zahradnou mi pokrývá kombinace interních cAP AX (CAPGi5HAXD2HAXD) s externími (RBWAPG5HACD2HND) v kombinaci 5+3 (CAPsMANv2) a šlapou jak hodinky, bezproblémové a naprosto spolehlivé. Nelze říci křivého slova, stejně tak na Omni 2020, nebo switche.

Mně jde čistě o jedno jediné AP (10.5.10.0/24) na izolovaném subnetu a tím je právě hAP Mini RB931-2ND (čistě 2.4GHz), které mám v pracovně. Izolované a izolované zůstane, proto ho vůbec nechci pouštět do sítě. Hned bych s tím narazil s CAPsMAN (v1 není kompatibilní s v2). Když potřebuji, prostě se telefonem/notebookem připojím na ono AP, nastavím a zbytek nechávám žít vlastním životem, protože připojení se světem není potřebné. Výjimkou zůstává NTP. Nebýt oněch přiblblých aplikací, nepotřeboval bych na to extra AP (nic jiného, než 2.4GHz to zkrátka neumí). Mám ty malé mrchy u rodičů a fungují dobře, čili buďto mám vadné AP, nebo je tam nějaká nekompatibilita.

Díky, zkusím nastavit.

P.S.: Bugy např.: 7.13.3, 7.16, 7.20.2 ... stane se.

[Buldr]

Menší aktualizace stavu. Po update na 7.22.3 jsem to nechal být v zakonzerovaném stavu a neměl jsem čas ani chuť se v tom vrtat, vše překvapivě funguje a v logách za 2 dny není nic zajímavého. Špatné je, že netuším proč, protože 7.22.3 vlastně nic podstatného neopravuje, respektive nic co by se vztahovalo na hAP Mini. Při verzi7.22.2 těch oprav bylo dost a čistě pro pokus jsem nahodil zpět 7.22.2 ... a popsaná situace na sebe nenechala dlouho čekat.

WMM jsem prozatím nezapínal, jen jsem si nastavil logování

[lojza007]

Možná se dívám blbě, ale v té konfiguraci nevidím nastavení pro Group Ciphers a Group Key Update a ten nastavit aspoň na několik hodin. Od nějaké poslednější verze je to potřeba nastavit, jinak může to připojování blbnout. Možná jsou tam nějaké výchozí hodnoty a chyba je úplně jinde, ale minimálně není na škodu to ověřit.