Toto je původní verze internetového fóra ISPforum.cz do února 2020 bez možnosti registrace nových uživatelů. Aktivní verzi fóra naleznete na adrese https://telekomunikace.cz

odpojení klientů od AP

Problematika MikroTik RouterBoard hardware
Sidi
Příspěvky: 510
Registrován: 8 years ago

Re: odpojení klientů od AP

Příspěvekod Sidi » 4 years ago

whef píše:Myslím, že to blbost není nastavit watchdog na klienta. Na jednom omnitiku to mám a funguje to OK, chce to na klienta, ktetý to nevypíná. :) Záseky se dějí poslední dobou na více RB. :(


Jj, někde to takhle v síti kolega udělal, zapomněl na to, já toho klienta přepojil a pak se půl dne řešilo proč AP padá a málem šlo do kontejneru s mrtvolama :D Od té doby se podobným řešením vyhýbám :D
0 x

Uživatelský avatar
honzam
Příspěvky: 5527
Registrován: 17 years ago

Příspěvekod honzam » 4 years ago

To je taky totální kravina zapnout si watchdog na klienta. Těch scénářů kdy se to posere se dá vymyslet mraky :)
To už je lepší zapnout si watchdog přímo na tom klientovi aby pingal bránu
0 x

kure05
Příspěvky: 886
Registrován: 12 years ago

Příspěvekod kure05 » 4 years ago

Prostě to je vlastnost chipsetů používaných v RB912, SXT HG, SA a Omnitiku. U AC zařízení tenhle problém již není. Máme na to skript, o kterým tu někdo už psal. Jakmile to vyčmuchá, že na bezdrátu není nikdo připojenej, tak ho to na vteřinu vypne a znovu zapne a frčíme dál. Tahle kontrola se dělá každejch 5 minut. Takhle nám to funguje už roky na mnoha zařízeních co se takhle chovaj.
0 x

basty
Příspěvky: 2475
Registrován: 18 years ago
Kontaktovat uživatele:

Příspěvekod basty » 4 years ago

Měl jsem případy kdy nepomůže zapnout a vypnout WiFi ale je potřeba reboot.
0 x

Onas
Příspěvky: 24
Registrován: 13 years ago

Příspěvekod Onas » 4 years ago

U toho skriptu se dá udělat, že kontrolujte více lidí naráz. Čili 2 nebo 3
A když už se to má rebootovat , tak si nechám poslat mail
:if ([/ping 172.17.36.20 count=3] =0) do={
:if ([/ping 172.17.36.24 count=3] =0) do={
/ tool e-mail send to=a.b@seznam.cz subject=AP body=( "AP-Horni-Dolni. Prave rebootuji system - kvuli pingu na 17.36.20 a 17.36.24. Je presne ".[/system clock get time]." hodin")
/ delay delay-time=5
/ system reboot
}




}

není to sice super řešení, ale funguje
0 x
Oňas

CrazyApe
Příspěvky: 790
Registrován: 9 years ago

Příspěvekod CrazyApe » 4 years ago

Dělalo nám to samé jedno jediné SA ještě na 6.39.2. A to máme jak 912,sa a omnitiku hromadu. Pak se upgradovaly fw, biosy, některým klientům anteny pac měli ještě rb411 s cm/groove ... a od té doby to samo prestalo. Je to už asi 2 roky co to neudělalo.
0 x

Uživatelský avatar
Selič
Příspěvky: 818
Registrován: 14 years ago
antispam: Ano

Příspěvekod Selič » 4 years ago

​Dělalo nám to samé jedno jediné SA ještě na 6.39.2. A to máme jak 912,sa a omnitiku hromadu. Pak se upgradovaly fw, biosy, některým klientům anteny pac měli ještě rb411 s cm/groove ... a od té doby to samo prestalo. Je to už asi 2 roky co to neudělalo.

Podle všeho to bylo asi vyřešeno někde od verze 6.44. Nicméně nemám dostatečně velký počet AP na mikrotiku, abych to mohl potvrdit. Podobný problém mělo i UBNT na starších zařízeních a mám dojem, že to pořešili od verze cca 6.14. Takže to byla spíše chyba někde na úrovni ovladače od výrobce čipsetu než chyba v kódu Mikrotiku.
Tam, kde mě to vyloženě vadilo, tak jsem vyměnil AP za Mimosu a od té doby mám klid a větší propustnost.
0 x
"Slepému neukážeš, hluchému nepovíš, debilovi nedokážeš..."

CrazyApe
Příspěvky: 790
Registrován: 9 years ago

Příspěvekod CrazyApe » 4 years ago

Selič píše:
​Dělalo nám to samé jedno jediné SA ještě na 6.39.2. A to máme jak 912,sa a omnitiku hromadu. Pak se upgradovaly fw, biosy, některým klientům anteny pac měli ještě rb411 s cm/groove ... a od té doby to samo prestalo. Je to už asi 2 roky co to neudělalo.

Podle všeho to bylo asi vyřešeno někde od verze 6.44. Nicméně nemám dostatečně velký počet AP na mikrotiku, abych to mohl potvrdit. Podobný problém mělo i UBNT na starších zařízeních a mám dojem, že to pořešili od verze cca 6.14. Takže to byla spíše chyba někde na úrovni ovladače od výrobce čipsetu než chyba v kódu Mikrotiku.
Tam, kde mě to vyloženě vadilo, tak jsem vyměnil AP za Mimosu a od té doby mám klid a větší propustnost.


Já mam asi 200 mikrotik vysílání (sektory, semtam nějaký ptp na kilometr max) a neděje se mi to nikde (krom jedné zmíněné kdysi driv) a z toho bych usoudil, že problém bude fakt v souhře něčeho, co jiní ISP dělají jinak než já. Jedná se o SA,HG5, SXT lite s L4, 911,912,921,922UAGS,RBM+karta
U MK je potřeba obecně dodržovat hodně věcí což spousta lidí nedělá a pak řeší tyto věci....


Primarně je třeba mít FW klient vs. AP + bios vždy všude stejný a hlavně nemixovat A/N a podobně...Jeslti si nekdo mysli že dá sektor SA a na to připojí vše od 133C3 přez 411 s CM9 až po LHG AC a že to pojede dobře tak to se dost plete a nedejbože na tom sektoru ještě hodit queue, routing nebo tak něco. To je totalní nesmysl to zařízení musí mít CPU uplně nezaměstnané... a to samé platí o klientských radiich. Už jsem viděl par frajerů co si na tom nastavili shaping, vytaceli vpn atp. a CPU pak 80%ˇa pak se má ještě starat o nějaký bezdrát ...

P.S: Myslim, ze vymena AP za mimosu nezvetsila propustnost. Je to furt pětka a je uplně jedno jeslti za sektor napojíš rocket lite, nebo 922. Je to primárně o anténách. To jeslti tam mas mimosu, mk, ubnt nebo cambium je uplne jedno. Jede to vše +- pár procent stejně... Důležité je co je tam za anténu. My už kupujeme jen Horny 30 a 45 st. nic jiného nemá smysl...
0 x

coolerman1
Příspěvky: 326
Registrován: 17 years ago

Příspěvekod coolerman1 » 4 years ago

CrazyApe píše:
Selič píše:
​Dělalo nám to samé jedno jediné SA ještě na 6.39.2. A to máme jak 912,sa a omnitiku hromadu. Pak se upgradovaly fw, biosy, některým klientům anteny pac měli ještě rb411 s cm/groove ... a od té doby to samo prestalo. Je to už asi 2 roky co to neudělalo.

Podle všeho to bylo asi vyřešeno někde od verze 6.44. Nicméně nemám dostatečně velký počet AP na mikrotiku, abych to mohl potvrdit. Podobný problém mělo i UBNT na starších zařízeních a mám dojem, že to pořešili od verze cca 6.14. Takže to byla spíše chyba někde na úrovni ovladače od výrobce čipsetu než chyba v kódu Mikrotiku.
Tam, kde mě to vyloženě vadilo, tak jsem vyměnil AP za Mimosu a od té doby mám klid a větší propustnost.


Já mam asi 200 mikrotik vysílání (sektory, semtam nějaký ptp na kilometr max) a neděje se mi to nikde (krom jedné zmíněné kdysi driv) a z toho bych usoudil, že problém bude fakt v souhře něčeho, co jiní ISP dělají jinak než já. Jedná se o SA,HG5, SXT lite s L4, 911,912,921,922UAGS,RBM+karta
U MK je potřeba obecně dodržovat hodně věcí což spousta lidí nedělá a pak řeší tyto věci....


Primarně je třeba mít FW klient vs. AP + bios vždy všude stejný a hlavně nemixovat A/N a podobně...Jeslti si nekdo mysli že dá sektor SA a na to připojí vše od 133C3 přez 411 s CM9 až po LHG AC a že to pojede dobře tak to se dost plete a nedejbože na tom sektoru ještě hodit queue, routing nebo tak něco. To je totalní nesmysl to zařízení musí mít CPU uplně nezaměstnané... a to samé platí o klientských radiich. Už jsem viděl par frajerů co si na tom nastavili shaping, vytaceli vpn atp. a CPU pak 80%ˇa pak se má ještě starat o nějaký bezdrát ...

P.S: Myslim, ze vymena AP za mimosu nezvetsila propustnost. Je to furt pětka a je uplně jedno jeslti za sektor napojíš rocket lite, nebo 922. Je to primárně o anténách. To jeslti tam mas mimosu, mk, ubnt nebo cambium je uplne jedno. Jede to vše +- pár procent stejně... Důležité je co je tam za anténu. My už kupujeme jen Horny 30 a 45 st. nic jiného nemá smysl...


Dovolim si nesuhlasit ,mam AP RB M11G + R11e-5HacD v nadstaveni A/N a klienti SXT 5 A/N do 500m 6 klientov a druhy sektor 10 klientov,posledny FW a cca pol roka Fajn ,mzslel som ,ze som vyriesil odpajanie klientov a bum zacalo to zas ,tak ja davam navine rusenie .( na sajt som nic nepridaval anepridaval som zariadenia ,mam 3 horny a medzi sebou sa vidia na -70cca)
0 x