Mikrotik 7.13beta1

lkcz · 2023-11-13T23:28:09+00:00

Notice - Starting from RouterOS version 7.13, significant changes have been made to the RouterOS wireless packages. This is done due to a new product develop...

pgb

Hrál jsem si s capsmanem na 7.13b2 a narazil jsem na takovou klasiku se kterou si síťař poradí raz dva, ale hobíka to může zaskočit 🙂 ... na CAPu má bridge0+ether1 s dhcp klinetem a do něj dynamicky wifi1+wifi2 interface. Jakmile se spojí capsman pře IP, wifi porty se přidají do bridge0 a následně se změní mac adresa bridge0 a tedy i dhcp adresa - následuje odpojení od capsmanu. Tak odpadnou porty a pak to celé zase znovu. Řešení je jednoduché, admin mac nebo statická ip adresa 🙂 na bridge0. Reportováno, ale nevím jestli se touhle vlastností budou chtít nějak zabývat, nebo to nechají být a jen napíšou řádek do dokumentace.

ef

pgb
Mám zafixováno - vždy zadat admin mac.
Ale rozumím, toto je opruz.

hapi

divný je že se přepne sama mac pokud nedošlo k odpojení ether1. Ale máme ve scriptu napsáno aby do bridge nastavoval mac z prvního portu co se vloží do bridge tedy ether1.

maxdevaine

lkcz Hele, myslím, že se pleteš. v7 nepoužívá 4+ kernel. Ze začátku nasadili 4.14.131, ale pak to promysleli a nasadili nakonec 5.6.3. Ono totiž v té 4.14 toho moc nebylo, nebyl tam ani wireguard.
Zdar Max

lkcz

maxdevaine Mate pravdu, podle vseho od verze 7.1 je tam konkretne vetev kernelu 5.6.x.

Ad legacy vs. wifiwave drivers:
"No, the "legacy" wireless driver in v7 doesn't differ from the one in v6" (forum)

Takze stale myslim, ze si chystaji cestu pro zruseni "legacy" casti alespon pro ty zarizeni, ktery by to mohly obsahnout (maji dostatek RAM aj.). Teoreticky by to slo, kdyby ROS byl bez wireless balicku, a ten si kazdy stahoval podle chipsetu (mt7621, ath79, ...) - tuto teorii podle meho nazoru ted zkousi prevest v praxi.

Jit cestou jednoho balicku co obsahuje vse je cesta do pekel, vzdy nejlepsi je mit zkompilovany kod primo pro konkretni kus hardware bez dalsiho generic balastu.

vecino

What's new in 7.13beta3 (2023-Nov-24 13:52):

*) bridge - added automatic "path-cost" values depending on interface rate;
*) bridge - fixed HW offload enable with multiple switches (introduced in v7.13beta1);
*) bridge - improved HW offload enable;
*) certificate - fixed CRL check (introduced in v7.13beta1);
*) certificate - fixed host certificate verification if host is IP address (introduced in v7.13beta1);
*) certificate - fixed manual URL addition for CRL (introduced in v7.13beta2);
*) certificate - improved CRL signature verification and download error messages;
*) certificate - use error topic for CRL update failures;
*) console - added "read" command under "file" menu;
*) console - added unset option for "ssid-regex" and "allow-signal-out-of-range" properties under "interface/wifi/access-list" menu;
*) console - fixed misaligned columns (introduced in v7.13beta1);
*) console - improved stability when removing script;
*) defconf - fixed bogus wifi password on certain Audience devices;
*) defconf - use "WISP Bridge" default configuration mode for RBGrooveGA-52HPacn device;
*) fetch - added "http-auth-scheme" parameter, allows to select HTTP basic or digest authentication;
*) fetch - added raw logging;
*) ospf - fixed LSA Type3 advertisement for OSPFv2;
*) qos-hw - added initial congestion avoidance support for 98DX224S, 98DX226S, and 98DX3236 switch chips (CLI only);
*) qsfp - fixed supported rates for breakout cables (introduced in v7.12);
*) sfp - added "1G-baseT" link mode for modules that supports "2.5G-baseT" mode;
*) sfp - allow 2.5G rates only in forced link mode;
*) sfp - fixed SFP and combo interface handling for CRS328-4C-20S-4S+ device (introduced in 7.13beta1);
*) sfp - ignore "rx-loss" in forced link mode;
*) sfp - ignore irrelevant extended compliance code for SFP modules;
*) sfp - show 10M and 100M supported rates for RJ45 copper modules;
*) ssh - added cipher and hash function acceleration for ARM64 and x86 architectures;
*) supout - include missing wireless information (introduced in v7.13beta1);
*) wifi - enable protected interworking ANQP responses;
*) wifi-qcom - added fast-path for received packets;
*) winbox - fixed memory allocation (introduced in v7.13beta2);

mirek_k

Z manuálu:

Lost features
The following notable features are lost when running 802.11ac products with drivers that are compatible with the 'wifi' management interface
Nstreme and Nv2 wireless protocols
VLAN configuration in the wireless settings (Per-interface VLANs can be configured in bridge settings)
Compatibility with station-bridging as implemented in the 'wireless' package

Jak se vypořádáte se ztrátou NV2 v P2MP? Za mne je mnohem spolehlivější, než 802.11.
Je v novém balíčku něco, co to dožene?

hapi

toto je známé už přes rok.

já myslím že si tady vůbec lidi neuvědomují co je balíček wifi2 a že stále existuje klasický wireless.

wifi2 by se dalo říct je pouze na home ap na stůl se všemi funkcemi co by člověk čekával od domácího AP v dnešní době (roaming atd...). Nic extra na víc co si napsal mikrotik jako nstreme nebo nv2 tam není. I když to asi lze používat venku tak stále nemáme AX venkovní jednotky jako třeba disc ax. Ano, lze to nahrát do disc ac ale nepředpokládám že to aktuálně nějak suprově pojede ve venkovním prostředí na kilometry.

"starý" balíček wireless funguje dál právě pro to jak ho používáme venku včetně všeho na co jsme zvyklý ale bez featur z 802.11ac/ax. Ale má nstreme a nv2. Neřekl bych že to budou někdy implementovat do wifi2. Není proč, technologicky by protokoly 802.11ac/ax měly poskytovat lepší výkony než nv2 nebo dokonce stařičký nstreme. Pokud někdo má wifi sítě na 6.49+ tak asi už ví že tam wifi jede ve většině případech lépe na 802.11 než na těch ostatních dvou.

Navíc je příliš brzy dělat nějaké závěry když na CPE jednotky má mikrotik stále pouze jenom AC jednotky.

okoun

hapi nevim ale nový balíček by měl 802.11ac pomoci se dostat alespoň na úroven ubnt ac které už roky používá nové ovladače narozdíl od MK 🙂
ubnt má také airmax a nejde venku čistě na 802.11ac a myslím že oni vědí proč.
v rušeném prostředí venku nám tedy daleko stabilněji jede nv2 než čisté ac, ale ty rychlosti jsou žalostné.

hapi

okoun pokud spravuješ sítě na ubnt i mk tak víš že obojí jede +- stejně. UBNT umí ject stejně špatně jako MK a MK umí ject stejně dobře jako UBNT. Např: 802.11ac, protokol 802.11, 20MHz, PTMP, 130Mbit, špička 145Mbit 1TCP MKv 6.49.10. A opět se bavíme o zcela ideálních podmínkách na arm procesorech tedy na ac wave2 s 4core cpu. Stačí lehké rušení a přenosovka jde dolu a to samé u ubnt a airmaxu. Stejně tak airmax dokáže znefunkčnit celý sektor tak to dokáže nv2. Jak říkám, poslední dobou se dává 802.11 u MK s verzí v6.49+ případně v7 a jede to bomby.

Ale co naplat, vždy je to o tom jestli honím sektor na max hranici kde latenci 802.11 nedává a nebo to hlídá shaper. Řekněme 80% maximální zátěže se 802.11 chová velmi slušně a s větší rychlostí než NV2.

lkcz

Odpoved je prave 802.11 ktery ze svy podstaty pocita s tim, ze se vysilac a klienti navzajem vsichni "vidi". Davno uz jsme zapomenuli na doby bez Airmaxu/nstreme/nv, kde se kazdemu klientovi pocitalo RTS/CTS podle vzdalenosti 🙂 a jak to bylo taky pekne na hovno, protoze se to muselo manualne menit a kolikrat s pocasim a zhorsujicim se signalem.

Pamatuju si, jaky skok prinesly prvni Nanobridge a Nanostationy s Airmaxem VS v te dobe bezne uzivany 802.11b/g za pomoci ruznych Ovislinku a vseho moznyho, co melo RSMA konektor. No doba pokrocila, nastesti a zaroven trochu i bohuzel (se slzou vzpominam na prvni pokusy o lamani WEP klicu s PCMCIA kartou od Orinoco 😃)

Obecne jinak 802.11 venku nedoporucuji pouzivat, myslim jako nejaky druh FWA. Na zahradu dobry, na velky vzdalenosti a nebo s vetsim poctem klientu se vyhybat jak cert krizi a radeji hledat neco jako treba ten Airmax, ktery implementuje napriklad TDMA.

Edit pozn.: A je jedno jestli se bavime o 11b, g, n nebo ax a jine - mozna to z toho nevyplyva, beru 802.11 jako celou protocol family.

okoun

hapi no právě že vím že to +- stejně nejede, to přeci vidíš na domácím ac2 když dáš teď nové ovladače kolik to jede a kolik to jede ve staré verzi 6.
já mám pocit že tady na foru už několikrát o MK píšeš jak to jede dobře s novou verzí XY, já mám spíše pocit, že to je takový placebo efekt, to že MK se díky několikaleté ignoraci dělat na nové V7 totálně odepsalo nové ovladače na wifi je prostě fakt, to je jasný a nechci slyšet, že je to fuk a že ty staré ovladače vlastně jednou stejně dobře jak jiné novější na ubnt...
jasně na MK v čistém ac uděláš 130Mb ale k čemu ti to je když ti to někdo potom sfoukne jako svíčku, to si tam potom raději zapnež stabilnější nv2, která dá jen 90Mb ale jede to a nemusíš furt ladit a furt dělat výpadky, každé lazení je výpadek a to lidé hned pocítí 🙁
a airmax ac který dá 120-130Mb prostě není tak tupej jako mk ac, určitě je odolnější

hapi

mícháš indoor a outdoor

okoun

hapi já ti jen píšu o tom jak se chová wifi s "novým" a starým ovladačem
problém je však v tom že MK zatím umí nový ovladač v indoor teprve pár dnů, ale na airmaxu je už nějaké roky 🙂

hapi

nevšiml jsem si že by unifi mělo airmax 🙂

okoun

hapi tak znovu

ubnt unifi ac (dávno nové drivery) vs mikrotik ac (nové drivery až teď po letech)
ubnt airmax ac (dávno nové drivery) vs mikrotik nv2 ac (staré drivery)
jasný?

« Předchozí stránka