Verze 6.36

[pedro4444]

tym co to nabehlo a mali uz cm2 na spojoch pri 6354 prechod na 6,36 nieco pomohlo??

[the.max]

Mám takové tušení, že po aktualizaci z 6.35.4 na 6.36 je problém s CAPS-Manem. Klienti se nepřepínají mezi APčky, ale stále zůstávají na tom, na které se přihlásili, i když mají -89 a jsou v několikacentimetrové vzdálenosti od jiného. Na předchozí verzi se kleinti přepínali korektně, žádné další nastavení se neměnilo.

[pedro4444]

inak taka otazocka uz v tychto verziach funguje skenovanie pasma zo strany klienta bez odpojenia????

[mpcz]

inak taka otazocka uz v tychto verziach funguje skenovanie pasma zo strany klienta bez odpojenia????

Zdravím,
tato velmi potřebná funkce funguje již od pár verzí zpět. Bohužel to má pár nepříjemných vedlejších účinků:
- musíš nahrávat další balíčky pro WLAN. To je dost otravné pro větší množství klientů a hlavně při následném upgrade na vyšší verzi dojde k odpojení klienta a jeho trvalou neodstranitelnou nedostupnost = osobní výjezd. Provedení upgrade lze sice provést určitým postupem, při které je nutno se soustředit, co má upgradovaný klient vlastně za momentální stav a podle toho se řídit. To považuji za naprosto zbytečné a dost nebezpečné. Vůbec ty Sergejovy pokusné balíčky, které ve většině případů nic velice neřeší nechápu.
Scan pak funguje i do FILE, ale pouze na základním protokolu, pokud máš nstreme nebo NV2, napíše to nicneříkající hlášku, chvíli mi trvalo pochopit, že to souvisí s protokolem. Takže musíš přehodit protokol, což = odpojení klientů, dát scan, což některé opět odpojí, pak vrátit NV2, což je opět odpojí. Takže jim to 3x spadne. Toto je výsledek asi 6-letého urgování na podpoře Mikrotiku.
Ještě bych upozornil na formátování textového souboru s výsledkem scanu, které je dost uživatelsky nepříjemné, sloupce jsou poskákané a na obrazovce nečitelné ve většině standardních editorů ve Windows.
Je docela možné, že tyto nectnosti lze nějak eliminovat, používám to nyní tak, jak jsem popsal. Můj sen o naskenování sítí třeba skriptem o půlnoci do souboru zatím realizovat nelze (neumím, nevím). Snad se toho ti mladší od Sergeje dočkají ...
mpcz, 03.08.2016

[hapi]

je vidět že seš mikrotik zelenáč

[mpcz]

je vidět že seš mikrotik zelenáč

Zdravím,
no právě. Dyť právě proto to sem píši, aby se k tomu vyjádřili i ostatní. Od toho přece fórum je. Určitě rád přivítám jakoukoliv relevantní informaci na toto téma. A třeba je nás víc.
mpcz, 03.08.2016

[hapi]

třeba nechápu proč musíš přehazovat protokol...? máme přece any což je ideální volba pro klienty. Pak se nemusí nikdy nic přehazovat. Ale ty asi myslíš ten background scanning co se vyrojil s rep verzí. No, blbý... ale zase furt lepší než nepřesnej scan u ubnt kdy každej další scan ukáže úplně jiný ssidčka který minule nenachytal a aktuálně nachytal jiný ale ty původní zase ne... super kokotina.

Nevim o tom že by se mi klient při přechodu z wireless na wireless-cm2 už nepřipojil. Pravda, běhá nám v dnsku náš vlastní záznam na upgrade mikrotiku směrovanej na náš server kde si namixuji verze balíčků jaký chci a podstrčím mu tam wireless-cm2 přejmenovaný za jenom wireless což teď opačně budu dělat s přechodem zpět na wireless. Jooo, používáme extra package, combine package nám nikdy nechutnalo nicméně to že máš combine řeší přechod za tebe mikrotik sám protože bude existovat už jenom jeden takže by se to mělo po přepínat samo. Ale pokud si hraješ s rc verzemi nebo s čerstvými release verzemi tak musíš počítat s průsery jako v každém odvětví.

[the.max]

Když už mám nějakou verzi ROSu a mám tam vedle standardního balícku i wireless-rep, ktery je aktuálně používán, tak při aktualizaci se stáhne jak základní balík, tak i ty další, ručně doinstalované, takže i wireless-rep. Po rebootu a aktualizaci naběhne nová verze i s novým wireless-rep.

Co se týká scanu. Pokud mám na AP nv2 nebo nstreme, tak na klientovi mám samozřejmě any. Ale pokud na klientovi, který je připojený na APčko, které jede v nv2 nebo nstreme, spustím backgrround scan, tak mi to napíše "Couldn't start - background scan not supportet in this state (6)". Pokud ale přepnu APčko do 802.11, tak teprve pak mohu z klienta provést scan. Teď ověřeno, na AP s 801.11 a na jiném AP s nstreme.

[hapi]

to je taky napsaný v changelogu

[the.max]

co je napsany v changelogu?

To, jak psal mpcz, že po aktualizaci, kdy má aktivní wireless-rep, musí pak ke klientovi jet fyzicky? Tohle se mi fakt nestalo už několik let, že bych po aktualizaci ROSu musel jet RBčko oživovat.
A nebo to jak jsi psal ty o tom bg. scanu že nechápeš proč je potřeba přehazovat protokol, když na klientovi je přece 'any' ?

[hapi]

Kód: Vybrat vše

What's new in 6.35 (2016-Apr-14 12:55):

*) wireless-rep - added support for wireless background scan for 802.11 protocol;
*) wireless-rep - added support for wireless repeater mode for 802.11 protocol;

že scan na pozadí funguje jenom v 802.11 režimu.

Takže v any bg scan nefunguje.

[mpcz]

Zdravim,
to the.max - no co se týká toho scanu, ten šum je způsoben pouze morálně-volní vlastností kolegy Hapi, který prvoplánově musí někoho shodit a dát vyniknout svým přednostem a pak teprve čte a přemýšlí. Tím rozhodně nenarážím na jeho Technické znalosti.
Ano, je to tak, jak píšeš, poukazuji na to, že pokud chci udělat scan na klientovi s AP nstreme / NV2 - což je téměř každý bez shození klienta, musím jednou shodit všechy = přehodit na základní protokol, udělat scan, přehodit zpět na nstreme = shodit všechny. A hlavně, ta chybová hláška "Couldn't start - background scan not supportet in this state (6)" je opravdu geniální, určitě by mohla být aspoň trochu vázaná na skutečnou příčinu problému, což je pouze změna textu, který by byl navíc i kratší.
- Co se týká problému s upgrade, neměl jsem žádnou RC verzi, jen 6.35, a balíček -rep, abych otestoval ten scan na klientovi. Po upgrade na 6.36 se to celé rozhasilo, klienti odpadli a ani po ethernetu jsem to už neuvedl do funkčního stavu. Po downgrade na 6.35 vše naběhlo normálně. Dále jsem ve zkoumání na klientech nepokračoval pro přílišnou nebezpečnost.
- pokud je při upgrade nutno sledovat, které balíčky tam jsou navíc, je to technicky schůdné, ale velmi nepraktické. Pevně věřím, že na to někdo někdy zapomene a doplatí na to. Pokud se to neděje masově, možná proto, že ten scan zatím zajímá málo lidí.
- systém upgrade by měl pracovat nebo se ohradit tak, aby ke kolizi SW Nemohlo dojít i při opomenutí a bez čtení manuálů. Určitě by to problém nebyl. Pokud někdo zastává názor, že se o problému dá dočíst v dokumentaci, a nebo si vytvořit různé berličky, možná má pravdu, ale jen tím vytváří nežádoucí klima neopodstatněné spokojenosti programátorů MKT.
- celá ta negativní zkušenost s balíčky byla popsána z jednoho pokusu o upgrade na RB751U-2HnD. Proč jsem v pokusech nepokračoval, je snad jasné. Jen jsem na to chtěl upozornit, aby se někdo ozval, pokud by to opravdu byla chyba a našlo se přijatelné řešení. Od toho snad tohle fórum je.
Doufám, že jsem tím nikoho neurazil.
mpcz, 04.08.2016

[the.max]

jak jsem psal, s tímhle jsem s enesetkal už mnoho let. Teď asi před cca 14ti dny jsem právě na několika APčkách a na ně připojených klientech aktualizoval z 6.34.x a 6.35.x na 6.36 + wireless-rep. Někde už byl wireless-rep i předim ve startší verzi. Aktualizace jsem prováděl ručně, že jsem si nejdříve nakopíroval přez winbox přetažením wireless-rep a pak dal ve winboxy system -> packages -> check for updates. Bylo v součtu hodně přez stovku zařízení a všude to bez problému prošlo.

[mpcz]

OK,
můj výchozí stav RB751 byl 6.35 + balíček rep. Proběhl upgrade na 6.36 bez balíčku rep., přetažení do files a restart. Klienti se odpojili, WLAN zašedlý, AP tedy nedostupné. Byl tvůj úspěšný postup stejný?
Dík, 04.08.2016

[the.max]

Tak jasně, pokud si tam ručně přetáhneš jen hlavní balík a už tam nedáš ručně wireless-rep, tak by to soudruzi mohli ošéfovat tak, že to spustí alespoň wireless z hlavního balíku. Já to právě aktualizoval jak jsem psal, takŽe si to samo stáhne hlavní balík a i ty další mimo něj.