Odpojování bezdrátových klientů

sacnok

Nám něco podobného dělaly Omnitiky. Řešil jsem to tady: https://ispforum.cz/viewtopic.php?f=7&t=21790

Nakonec jsme je vyměnili za nové a od výměny je pokoj. škoda, že jsem nevěděl o tom skriptu, možná by pomohl.

honzam

Nám tohle dělá jen jedno staré AP (rb711GA) které máme v plánu na jaře vyměnit. Musím zaklepat že po upgrade této rb711 na 6.37.4 i všech klientů je uptime skoro měsíc

gemb

Pokial mas problem s wlan a mas tam RB711 tak to hned vyhod prec alebo budes mat stastie a vysere sa ti ta RBcka niekedy o polnoci 8)

sacnok

:local macadresa

:foreach i in=[/interface wireless registration-table find] do={

:set macadresa [/interface wireless registration-table get $i mac-address]

:if ([/ping $macadresa count=2] = 0) do={

:log warning "nepinga $macadresa";

/interface wireless registration-table remove $i;

}
}
Zariadenia musi byt v rezime station, ak mate nieco v station bridge a potom nasledny bridge medzi ether a wlan, je treba skopirovat MAC bridgu a tuto MAC zapisat na wlan. Ak toto pri station bridge nespravite, bude vam klienta odhadzovat.

Odskusane len s NV2, funkcne. Tymto scriptom nemrznu APcka uz roky. Proste NV2 neni dotiahnuta do konca a ani nebude :

Funguje ten sklript i na PtP spoje, když je na vzdálené straně Station WDS?

Začal nám tuhnout jeden PtP spoj, který používal NV2, přepnul jsem ho na 802.11, tak uvidím jestli to přestane dělat.

gemb

Na PtP by som NV2 nepouzival (vysoka odozva) radsej nstream, ten je bez problemov. Na PtP si sprav radsej watch dog na oboch stranach.

yaggii1

Dobrý den,

nechce se mi zakládat nové téma, tak jsem hledal nejvhodnějsi, kde bych se mohl zeptat. Resim problem s jednim sektorem a nevim jak na to.

Jako sektor je 30° horn + rb922. Vse fungovalo roky v poradku, az se v poslednich dnech / tydnech vzdy navysi ve vecernich hodinach na vsechny klienty odezva, rate spadne a to tak, ze misto 144.4Mbps-20MHz/2S/SGI / 144.4Mbps-20MHz/2S/SGI je najednou 144.4Mbps-20MHz/2S/SGI / 6Mbps-20MHz/2S/SGI, respektive RX rate spadne na strasne malou hodnotu, u nekoho na 6 Mbps, u jinemu na 39 Mbps apod.

Zkousel jsem preladit i na indoor kanal a dela to i tam. Z toho usuzuji, jako by to rusil nejaky klient. Nevim ovsem, jak toho klienta najit. Dalsim doplnkem tohoto chovani je, ze se klienti odpojuji a pripojuji. Jako klienti jsou SXT a/n, n/ac + SXT SQ, tj. ano, je tam jeste cca 5 zarizeni, kteri maji rate 130Mbps-20MHz/2S.

Vsichni klienti az na ty prastare SXT maji verzi 6.48.1. Prastare SXT s CPU 400 Mhz a normou a/n maji verzi 6.45.6.

Na strane ap je nastavena norma 802.11, po prepnuti do nstreme do ustane, ale odezva je trochu rozletana. Nez nastane uvedeny problem, jede v 802.11 vse v poradku, odezva je nizka a na 1 spojeni udelam na AC klienta i 80 Mbit.

Napada prosim nekoho, cim by to mohlo byt, na co se zamerit? A nebo nad tim neuvazovat a stare SXT se slabym CPU vyhazet ihned?

mpcz

Zdravím, pokud Sergej svádí tento "odpojovací" problém na problém s napájením, zajímalo by mě, jak to zdůvodňuje, když to tvrdí. Protože pokud by i bylo "něco" s napájením, měl by to log měl/mohl podchytit. Na vstupu má každý RB hlídání napětí a pod touto hodnotou odpojí přívod rázem. Pokud má napětí na vstupu v normě, měly by všechny měniče dávat všem sekcím RB napětí v normě. Pokud jsou správně navrženy. Navíc, už se na několika pokusech prokázalo, že po výměně za UPSku nebo napětí přímo ze dvou bateríí 12V problém nezmizel. To Sergejovo vysvětlení mi přijde divné. Do detailů jeho mikrokódu samozřejmě málokdo vidí, ale dle mého by pro tento případ byl možný speciální upravený detailní výpis do logu před a v okamžiku odpojení a bude to jasné. Spíš mě to připadá tak, že sám neví, čím to je nebo to ví a neví co s tím. mpcz, 16mar2021

coolerman1

Nene to je problém celého systému ,rušenie +zle signály od klienta +vysoké nároky klientov ,niekedy aj jeden zabije celé ap

gemb

coolerman1 ja som myslel, ze temu o tom ako funguje wifi mame za sebou ale po 20 rokoch to niektori ISP stale nevedia. Je uplne jedno ake je rusenie, vzdialenosti atd...podstatne je ako stabilna je linkova rychlost. Idealny pripad bude ked vsetci klienti maju 144Mbit oboma smermi a stabilne. Ak jeden napr z dovodu rusenia bude mat 78Mbit a zaroven prenasa data tak regraduje cele AP. Rovnako klienti A,N na AC sektore. Klienti na bocny lalok, cez stromy, prekazky, odraz signalu atd - toto vsetko degraduje AP, stupa odozva, jitter je masivny, na niektore aplikacie potom uplne nepouzitelne. Myslene samozrejme na veduceho vyssie, zakladatela. Toto nebol pred par rokmi az taky problem, tarify boli nizsie, naroky taktiez. Teraz sa realne ukazuju kvality, kto rozmyslal pri zavadzani tarifov a kto to daval len na papier ale realita bola inde. Poznam stale firmy (robia to iste uz xy rokov) pripajanie bez priamej viditelnosti, na -85 a pod 😃 Potom to nejde cele bohuzial, nieje to LTE.

mpcz

gemb Zdravím, no já tedy nemám ani potuchy, jak Wifi funguje, jsem rád, že se tady alespoň základy dozvím. Teď už vím, co vše zpomaluje provoz, ale nijak z toho nečtu, proč by se měl klient odpojit a hnedle zase připojit. A o to v této kauze jde především. A proč to nejde nějak ošetřit. Snad jen ještě otázka: dělá to i zastáncům UBNT AP? Učitě jich tady je spousta. Dík, mpcz, 16mar2021

mpcz

Zdravím, pro případ, že se klient připojuje a odpojuje, což není moc příjemné a naštve to klienta a následně i poskytovatele, používám malý skript, který dopady na nervy obou téměř řeší, popř. zmírňuje na výpadky téměř nepostřehnutelné . Je to sice pouze berlička, ale aspoň něco. Skript pracuje tak, že jakmile klient nalezne a ustálí spojení na AP, změní rozsah hodnoty "scan-list" na tu jednu frekvenci, na kterou je přichycen. Při odpojení z jakéhokoliv důvodu pak dojde k znovupřichycení okamžitě, čímž je eliminován klasický výpadek spojení v délce desítek sekund. Přeladění frekvence AP poskytovatelem je řešeno tak, že pokud nenajde AP po zadanou dobu, změní si "scan-list" na default, najde AP a historie se opakuje. Nervy klienta to sice uklidní, ale situaci s odpojování to samozřejmě neřeší. To by měli řešit jiní. mpcz, 16mar2021

myghael

mpcz Ano, takový skript mám také. Faktem ale je, že občas musím někde pověsit a "shazovat" pokusného klienta, protože po osázení AP horny atd. u mě problém s odpojováním klientů v podstatě zmizel.

mpcz Tak někteří prostě vzali anténu a zkoušeli, jiní (jako já) u toho študýrovali i teorii. UBNT tento "problém" teoreticky nemá, tak se totéž projevuje "divným" chováním v podobě silně kolísající rychlosti a "létajících" odezev, nicméně způsob detekce (spektrální sken atd.) a léčba (kvalitnější antény, dodržovat LoS atd.) je naprosto stejná bez rozdílu jestli Američan nebo Lotyš.

coolerman1

mpcz tak ja nemam nič proti ubnt ani miktoriku ale mám jedným smerom k sebe horn s mikroitkom a horn s prismom a jedine čo sa mi odpojilo a pripojilo z dôvodu “extensive dáta loss” bolo lhg a to je 500m priamy výhľad plny signál

mpcz

to Myghael: to jsem rád, že se do toho skriptu někdo pustil na profesionální bázi. Je to velký pomocník, když už člověk neví, kudy kam. Na mě se obrátilo pár lidí o ten skript, můžu je na tebe přeposlat, nebo je to pouze tajná verze? Ten můj skript sice funguje, ale možná by u leckterého programátora vyvolával úsměv.
to Myghael: to je škoda, že s toho jak píšeš extended "študýrování teorie" zde není více poznatků. Protože poznatky z běžné praxe mluví Statisticky jasně bez jakýchkoliv hlubších znalostí: odpadávání klientů se děje v prostředí se silným okolním a popř. i vlastním provozem a rušením. V žádném případě neplatí, že by museli přednostně odpadávat klienti se slabým signálem. Kromě cizích zdrojů má negativní vliv i vyzařování sousedních cizích i vlastních antén, které slyším na -30 a silněji v důsledku blbého umístění, protože to třeba jinak nejde. Asi to bude částečně i nekvalitou (levných) vstupních filtrů, které silný signál nedovedou ořezat tak, jak bychom potřebovali i když je mimo kanál. Ale to jsou jen moje domněnky. Stále zastávám názor, že nejblíže problému musí být Sergej, který přesně ví, co se děje při hlášce “extensive data loss” a co udělá on. Vycházím z teorie kolemjdoucího, že určitě čeká nějakou dobu, než to shodí. Jak dlouhou? Čím je určena? Chtělo by to možná větší průzkum, pokud má někdo přístup k hlubším informacím. mpcz, 18mar2021

myghael

mpcz Skript je stále ve vývoji, ale předpokládám, že dříve nebo později ho zveřejním. Jestli bude někomu ještě k užitku je samozřejmě otázkou.

Co se teoretických poznatků týče, on nebyl důvod je tu rozvádět, ty sice mají smysl v pochopení, proč to dělá, co to dělá, ale to podstatné se dá odpozorovat poměrně rychle i prostým zkoumáním (dovolí-li to trpělivost zákazníků). Ať už tu wifinu navrhl a vyrobil kdokoliv, pořád je to obousměrné rádio jako každé jiné a základní věci se mezi CBčkem a wifinou nebo třeba 10 GHz pojítkem příliš neliší. To podstatné už tu padlo. Nemít antény nalepené na sobě a nejlépe ještě na stejných nebo překrývajících se kanálech (šířka kanálu wifiny nastavená na 20 MHz neznamená, že to mimo daný kanál nevysílá) a to všechno ostatní, co se tu probírá pořád dokola. Kvalitní antény s dostatečnými rozestupy, přímá viditelnost, signály atd. U Wi-Fi o to více, protože Wi-Fi má být hlavně levná, nějaké pořádnější vstupní filtry z pohledu výrobce zbytečně prodražují zařízení, které si na sebe za svou krátkou morální životnost musí vydělat, protože kromě pár nadšeneckých sítí a soukromých spojů typu "dům->stodola" to na ty střechy věší komeční operátoři.

svestka

Nám se na UBNT, kde AP je prismAC a klient je starší M verze děje v posledních dnech toto:

Z logu klientské stanice:
Mar 18 15:19:47 wireless: ath0 Received deauth from f0:9f:c2:e6:e5:53. Reason: Unspecified reason (1).
Mar 18 15:19:47 wireless: ath0 Sending deauth to f0:9f:c2:e6:e5:53. Reason: Disassociated because sending STA is leaving (or has left) BSS (8).
Mar 18 15:19:47 wireless: ath0 New Access Point/Cell address:Not-Associated
Mar 18 15:20:24 wireless: ath0 Set Mode:Managed
Mar 18 15:20:24 wireless: ath0 Set Frequency:5.5 GHz (Channel 100)
Mar 18 15:20:24 wireless: ath0 New Access Point/Cell address:F0:9F:C2:E6:E5:53

Na AP je v logu vidět, jak se cizí klientská stanice pokouší připojit (šifrováno máme WPA2):
Mar 19 12:47:26 wireless: ath0 Received auth from 22:ef:01:95:fc:f6. Status: Successful (0).
Mar 19 12:47:26 wireless: ath0 Authenticated Station 22:ef:01:95:fc:f6 (Successful)
Mar 19 12:47:26 wireless: ath0 Sending auth to 22:ef:01:95:fc:f6. Status: Successful (0).

Zkoušeli jsme kde co, četli fóra, atd., zatím bez stoprocentního úspěchu 🙁

Na AP je zapnuta funkce Wireless Network Protection.

Nějaká rada?

gemb

svestka jednoducha rada ktoru nebudes chciet pocut. Neprevadzkuj mixed a M radu vyhod prec.

svestka

gemb tos mě teda nepotěšil. Ale díky.

gemb

svestka kolko tam mas klientov a ktorych? Nemas lepsie ak je vela M klientov tam dat druhy sektor len na nich?

svestka

gemb zatím jen jeden klient. Je to nový sektor, a klientovi se otáčela anténa na nově vybudovaný sajt, kde už je AC. Holt mu vyměníme CPE. Předtím byl na sektor s Mkovým vysílačem.

Další stránka »