ja, és innentől kezdve egy eszközön futhat a kétfajta CapsMan (eredeti wireless és az új WiFi), és kiszolgálhatja az összes AP-t.

Igen, pont ez lenne nekem is a lényeg. Például a rokonságban csináltam egy hAP ac, cAP ac és L009UiGS-2HaxD-IN kombót. Utóbbi a pincében van, ahol bejön a net és fontos ott is a wifi. Nyilván külön hálózatot kellett hozzáadnom, mert az meg az AX miatt csak WW2-vel megy. Kérdés a gyakorlatban mennyire fog sikamlósan menni a dolog, de várom a végleges 7.13-at.

Üdv!
Egy Mikrotik hEX (rev 3) routert használok már évek óta. Alapvetően meg is vagyok vele elégedve, de volna egy kérdésem. Tervezem hogy valamilyen backup internet hozzáférést rakok a jelenlegi Digis mellé (vagy Voda kábel, vagy Telekomos SIM kártyás megoldást USB stickel, még nem döntöttem el). A kérdés, hogy alkalmas-e erre a mostani routerem, vagy inkább másik routerrel próbálkozzak? Ha alkalmas akkor hol találok segédletet erre hogy hogy érdemes és lehet konfigolni a routert. Ha nem alkalmas, akkor melyik routert ajánljátok? Vagy ettől függetlenül lehet jobb ha eleve routert cserélek?
Köszi!

"Microsoft gives you Windows... Linux gives you the whole house."

Kedves kollégák,

Olyan pajtit keresetek aki ki tudna segíteni némi féle iránymutatással, mert a nem létező hajam copfba fontam 3x.

Sajnos LTE internetre kényszerültem, sikerült is vásárolnom egy Huawei B535-333-ast (pedig hányan megmondták, hogy jobban járnék egy Starlinkkel, de persze sose hallgattam rájuk), amivel el is voltam 1 hónapig.
Nem túl acélos a sebesség felénk (20-40mbit).

Majd nem bírtam a véremmel és a nem rég megjelent szintén LTE6 képes Fibocom modemmel ellátott SXT-t vásároltam meg.
Meg kell hagyni, az R11e LTE interfészeseket kerülöm, de ez az új végre, mind hálózati regisztrációban gyors és végre sebességben is van előrelépés a Huawei-hez képest (40-70mbit).

Nos, ezen két LTE eszköz mögötti infrastruktúra egy RB5009 + 2x HAP AX2 capsmannel.

Mivel a szolgáltató biztosított 2 adatsimet, és jelenleg a hülyeségemből kifolyólag is 2 LTE routerrel rendelkezem, adva lenne a lehetőség, hogy "2xWAN load balance"-t meglépjem.
Egyfelől azt várom tőle, hogy kiegyensúlyozottabb lesz az életem, másfelől végre tanulnék is valamit.

Eddig nem jött el a várva várt siker, túlmutatnak rajtam az efféle okító példavideók + leírások.

A opció:
ECMP-t próbáltam belőni ezen régi leírás alapján ami még 6.x-hez készült, megkeresve azt a minimális eltérést ami már a V7.x-re jellemző
Leírás amit használtam. [link]
Videó amit követtem az V6 vs V7 verziók miatt. [link]
És még ez is a segítségemre volt. [link]

Valami előrelépés, mintha lett volna a próbálgatások alatt, de ami szomorú, hogy a speedtest mérések alapján a korábbi 40-es pingemből minden alkalommal 400-as lett, továbbá egymagában az SXT-t hoz 70mbit/s-et, addig "load balance-ban" alig volt meg a 40.
Valamit biztosan elcseszhettem.

B opció:
Policy Based routing mangle szabályokkal.
Itt már annyi szabályt létrehoznak, hogy az elején elakadtam....
Ezt a tutorialt néztem: [link]
Továbbá a hivatalos csatornán lévőt: [link]
Itt alapvetően már az elején elakadtam, az összes példa videóban lévő ISP szolgáltatók statikus IP-t kapnak, nekem meg a két LTE routerből egy folyamatosan változó dinamikus címem jön létre így amikor a routing szabályokat szerkesztik feladtam.

Majd szomorúan széthúztam mindent és jelenleg maradt bejövő netnek a Mikrotik SXT (passthrougtban tolja ki) az ether1-en, amit szűrök a tűzfal szabályaimmal RB5009 oldalon.

Ha esetleg lenne valakinek erre működő configja amit szívesen megosztana, akkor átnyálaznám, de így 3 nappal később elvesztem benne.
Persze nem otthoni környezetbe való bohóckodás 2 ISP-t szimulálni, többnyire azt is failoverbe konfigurálják, de ha már ez a helyzetem áll fent és szar a netem jelenleg, meg szerettem volna próbálni valamit javítani ezzel a felállással.

Köszi eőre is!

[ Szerkesztve ]

Sziasztok!
Kis segítséget szeretnék kérni, hogy merre induljak az alábbi igényemmel/elképzelésemmel:
Van egy RB951G-2HnD routerem amit összekötnék jelenlegi routeremmel (Mikrotik hap ac3). Trunk portot hoznék létre, mert több vlan található.
Szeretném, hogy 2,4 GHz-s wifiket szórja (2db) a megfelelő vlan beállításokkal.
Illetve szeretném felhasználni a többi (4db) ethernet csatlakozót, mint switch. Ezeken is vlan-okat állítanék.

Köszönöm előre a segítséget!

Kérdés, hogy mennyire szeretnéd bonyolítani a dolgot.

A load balance a connection trackingtől fog jól működni, de azt nem tudom, hogy különböző sebesség esetén mikrotiknél hogy megy.

A legegyszerűbb, ha eszközönként bontod szét (elsődleges-másodlagos beállítás mindkettőnél). Így jelentősen egyszerűbb a config.

Szia,

Köszönöm válaszod.
Tudsz esetleg segíteni, minta configot adni hozzájuk?

Az egyszerűbb eset jól értem az lenne, ha RJ45 portonként mondanám meg melyik WAN irányába menjen ki?
Javarészt az eszközeim wifin vannak és ahogy fentebb említettem van 2 CAP-em (AX2-es), azaz: CAP1 = WAN1, CAP2=WAN2?

Forrás ip cím vagy tartomány alapján.
Holnap kigyűjtöm az érdekes részeket.

Nagyon szépen köszönöm előre is!

Forrás IP cím(ek) alapján egyszerűbb … szerintem.
Akár olyan egyszerűen is csinálhatod, hogy két NAT (Masquerade) szabályt hozol létre.
Az egyikben az Out-Interface az egyik internet kapcsolat, a másik NAT szabályban pedig a másik internet kapcsolat.
A forrás mezőbe (Source-Address vagy Source-Address-List) megadod, mely cimek menjenek ki azon a kapcsolaton.
Természetesen, hogy legyen Fail-Over is, ugyanezeket megcsinálod keresztbe is, csak sorrendben később, így csak egy adott internet kapcsolat kiesése esetén lépnek működésbe :-)

[ Szerkesztve ]

A legegyszerűbb failover:

/ip route
add check-gateway=ping comment=wan1 disabled=no distance=1 dst-address=0.0.0.0/0 gateway=8.8.8.8 routing-table=main suppress-hw-offload=no target-scope=11
add check-gateway=ping comment=wan2 disabled=no distance=2 dst-address=0.0.0.0/0 gateway=8.8.4.4 routing-table=main suppress-hw-offload=no target-scope=11
add disabled=no distance=1 dst-address=8.8.8.8/32 gateway=lte1 pref-src="" routing-table=main scope=10 suppress-hw-offload=no
add disabled=no distance=1 dst-address=8.8.4.4/32 gateway=lte2 pref-src="" routing-table=main scope=10 suppress-hw-offload=no

Rekurzív next hop lookup megoldás, vagyis megy egy folyamatos ping mind a két lte-n és ha nincs válasz az adott kapcsolaton, akkor az kiesik a routing táblából ideiglenesen.
(A gateway a weboldalon %lte formátumban látszódik.)

Ezt egészíteném ki egy második routing táblával és még 2 ip route-al:

/routing table
add disabled=no fib name=lte2

/routing rule
add action=lookup comment=lte2 disabled=no src-address=\
192.168.0.0/25 table=lte2
add action=lookup comment=nas-to-lte2 disabled=no src-address=\
192.168.0.200 table=lte2

/ip route
add check-gateway=ping comment=wan2 disabled=no distance=1 dst-address=0.0.0.0/0 gateway=8.8.4.4 routing-table=lte2 suppress-hw-offload=no target-scope=11
add check-gateway=ping comment=wan1 disabled=no distance=2 dst-address=0.0.0.0/0 gateway=8.8.8.8 routing-table=lte2 suppress-hw-offload=no target-scope=11

Az eredmény egy kézi load balance + automatikus failover.

Most raktam össze kézzel, így a saját default route bejegyzéseddel még össze kell simítani (ha van). Valamint úgy tűnik így 2x2 ping fut majd.

[ Szerkesztve ]

Érdekes lenne ezt látni működés közben.

A masquerade előtt hogy történik a forgalom terelése?
Pl ip1-wan1 szabály akkor lép életbe, ha eleve arra megy a csomag. Nem?

Ez így nem működik! Kell csinálnod route táblát és mangle rule-t ami a forrás címétől függően van használatban és az alapértelmezett átjáró be van rajta állítva! A NAT szabály csak azt nézi, melyik out interface-en akar kimenni, majd ha az stimmel nézi meg a source címet, hogy kiengedheti-e.

Szia,

Kezdem azt érezni, hogy megértem miért írtad, hogy akarom-e bonyolítani
Mert már ez is túlmutat rajtam, bár volt idő, mikor a "capsmant"-t sem értettem.
Elvonulok, emésztgetni.

Köszönöm!

Gyakorlatban teszi a dolgát.
A NAT szabályok sorban futnak le.
Ha ki tud menni az adott kapcsolaton, akkor megcsinálja.
Ha nem, a következő NAT szabály lép érvénybe :-)
Természetesen a kívülről bejövő csomagok megfelelő kezeléséhez már kell a Mangle

Bár "Check Gateway" funkció ebben nincs.
Igaz, azt nem is itt kell megoldani.
De ezt már leírták előttem.

Hoppá! Lehet, hogy tényleg tévedek!
Ha a route szabály nem azt akarja, akkor a NAT sem fog menni.
Akkor lehet, hogy Mangle-t is használtam?
Igaza lesz Audience-nek!
Meg kell néznem a konfigot

Szinte biztos. Mikor a tuzfal NAT tablaja lefut, addigra mar megvan a routing decision. Tehat, ha ott probalsz meg trukkozni legfeljebb annyi fog tortenni, hogy nem jut ki a csomag, de utvalasztas nem. A kimeno interfeszt pedig alapvetoen a routing tablaban levo default route alapjan valasztja ki(internet elereserol van szo), nem a nat szabalyok elemzese alapjan.

[ Szerkesztve ]

order of operation...
[link]

Újra nekifutottam, de úgy néz ki valamiért a MIPSBE alapú router kernel pánikol 5-10 percenként, ha belövöm az LDP+VPLS-t, míg az ARM32 alapú fő router állva marad. Más is tapasztalt hasonlót? EoIP64 stabil a két router között.

[ Szerkesztve ]

Le az elipszilonos jével, éljen a "j" !!!

Gondolom ehhez nem kell hatalmas sávszélesség. Akkor az EOIP miért nem jó?
Lehetne valamilyen layer2 VPN kapcsolatot is konfigurálni (L2TP vagy PPTP), ezek is jól működnek tapasztalatom szerint.

Reggie0 és Jerry311
Ezért nem jó mobilról válaszolni
De igen, már átgondoltam.
És hát logikus is 😂

De biztos, viszont ennek is működnie kellene, elvileg kisebb terhelés mellett, zárt hálózaton. 5 percig működik is, és csak az egyik oldal kernelpánikol.

Le az elipszilonos jével, éljen a "j" !!!

Sziasztok!
Egy kis segítséget szeretnék kérni, hátha valaki tapasztalt már hasonlót, vagy van bármilyen ötlete.

Mikrotik hAP ac van itthon, aránylag szépen teszi a dolgát. Lett egy új Samsung Galaxy A34 5G telefon, és alig akar csatlakozni a wifire, legyen az 2,4GHz vagy 5GHz, teljesen mindegy (ezen csodálkoztam is). Elvileg csak a Mikrotikkel csinálja, máshol nem volt tapasztalható ilyen gond. S9+ hotspotjával pl mindkét sávon tökéletesen működött a telefon, és publikus wifikkel is ment.

A pontos jelenség az, hogy a telefonon bekapcsolom a wifit, várok hogy csatlakozzon, vagy kézzel rányomok, és hibás jelszót ír. A jelszó nyilván jó. A telefon saját mac-re van állítva, kikapcsoltam a randomizálást. DHCP-n van hozzá társítva fix ip (mint minden más eszközhöz), de még pluszban beállítottam rajta statikusan is. Ez talán hozott némi javulást, de így is fennáll a gond. Ilyenkor a mobilon ki-be kell kapcsolgatni a wifit, nyomkodni az AP nevét, és egyszercsak rá fog menni, van hogy percekig kell vele küzdeni. Még esetleg az is fontos lehet, hogyha be van kapcsolva rajta a bluetooth, akkor mégkevésbé akar csatlakozni.

A routeren az 5GHz wifit már állítgattam össze vissza, próbáltam más csatornára tenni, semmi javulás. Minden más eszköz megy hibátlanul, kivéve ez az egy telefon.

Illetve hasonló jelenség akkor jött elő, ha S8-at vagy S9+t dex padra tettem, mert a dokkolás pillanatában leszakadtak az 5GHz wifiről, és csak 2,4GHz-n voltak hajlandóak menni. Ez kb 1 éve volt, akkor rájöttem hogy elvileg magasabb frekvenciára téve megy hibátlanul, ezt viszont egy Xiaomi MI A1 nem bírta... Viszont az A34-nek semmi nem jó, bárhogy állítom be.

Bárkinek bármilyen tipp? Előre is köszi minden ötletet. Ha több infó kéne a jelenlegi wifi konfigról, kifotózgatom.

Mi a szoftververzió?
Van SA Query timeout a naplóban?

Amúgy legyen külön ssid-t a két sávra, telefon / tábla / laptop csak 5Ghz, okosotthon / vendég 2.4Ghz-re.

(A két rádió között roaming-ol, ami kliens döntés és a 7.11 óta van egy kis zavar vele. Remélhetőleg a 7.13ban javítják.)

[ Szerkesztve ]

Szia,

3 napig ültem hasonló felett egy iphone-al.
A végén nem volt más út a troubleshootinghoz, mintsem kikapcsoltam a security profilt, azaz nyílt lett a wifi és láss csodát, felment egyből, nem kínlódott.
Na akkor jöttem rá, valami ott lesz elásva.

Végül Én barom a WPS funkciót engedélyezve hagytam.
Nincs rálátásom mi az istenért zavart be, de amit "disable"-re tettem egyből kapcsolódott az eszköz és azóta sincs gond.
Más kérdés, hogy nekem ez a hiba akkor jött elő, mikor standalone AP-ról váltottam CAP vezéreltre.

Ettől függetlenül egy új SSID létrehozása alapbeállításokkal adhat segítséget a további hibakeresésben. Legalábbis én nem a meglévő és más eszközökkel jól működő WI-Fi-t kezdeném tekergetni

Hali!

Adott egy CCR két L2TP klienssel egy távoli gateway-re.
A távoli GW-nek van két publikus IPv4 címe, a CCR-en routing table + rule kombókkal van megoldva, hogy a kábeles neten épüljön fel az egyik L2TP és a backup LTE-en át a másik. Ennek oka, hogy management célból mindig minden irány működjön. Ez így működik is rendben. Van 1--2 kliens, amiken tesztből azt is meg tudom így tenni, hogy a LTE-n át, a kábeles neten vagy a VPN-en át menjen ki, szóval itt teljes az öröm.
A kábeles L2TP-n OSPF-fel megy át elég sok routing szabály. Miként tudnám azt kivitelezni, hogy ha a kábeles L2TP down állapotba kerül, akkor, de csak is akkor, a LTE-n felhúzott L2TP-n át menjen az OSPF, azaz azon át hirdesse magát? Addig megvan, hogy fel van véve két routing rule, egyik 1-es distance-szel a kábeles L2TP-re tolja a forgalmat, egy magasabb distance pedig a LTE-re.
Gondolom az OSPF-nél a két L2TP interface-t kéne rangsorolni, de itt elakadtam. Miként tudnám ezt megtenni? Ha az első IF megáll, az OSPF másszon át a másikra, de ha az első feléled, térjen is vissza. Egy lehetséges opció on-up és on-down script-ek implementálása, de próbálok bízni benne, van egyszerűbb út
Köszi!

[ Szerkesztve ]

üdv, adika4444

OSPF + manual interface path cost. Az elsődleges L2TP-t hagynám alapértéken, a másodlagoson pedig megemelném. (Már ha jól emlékszem, remélem kiigazít aki jobban ért OSPF-hez.)

Sziasztok!
Köszönöm a tippeket, próbálkoztam állítgatással, de nem lett jobb a helyzet.

Szoftvert akkor frissítettem amikor megvettem a routert, 6.49.5 van rajta. Nem éreztem szükségét hozzányúlni, mert nem volt vele semmi gondom. Érdemes frissíteni? Csak jobb lehet, rosszabb nem? [kép]

SA Query timeout bejegyzést nem láttam sehol, a log csak annyit írt amit fotóztam. Valahol be kéne kapcsolni plusz logolást?

3 ssid van, egy a 2G-nek, egy virtuális a 2G-n, és egy az 5G-nek. Minden eszköz ami viszi az 5G-t azon van, 2G-n csak a butább, nem kompatibilis eszközök mennek.

Az ötletnek megfelelően próbáltam nyílt wifit csinálni, azzal sem csatlakozott, csak próbálkozott majd megunta.

Kifotózgattam a wifi beállításokat, ha valaki átnézi lehet kiszúrja mi van rosszul téve, régebben a tplink/dd-wrt cuccokat elég jól be tudtam állítani, de ez a mikrotik lehet hogy most kifog rajtam. [wifi konfig] [jelszo beallitas] [csatlakozott kliensek]

Még annyi érdekességet mintha észrevettem volna, hogy a kliensek közt a laptopom és az s9+ SGI módban van csatlakozva, stabil/néha váltogat. Ha csatlakozok az A34-el, azon nem megy az SGI, sőt a többi eszköz is egyre kevésbé fogja használni, néha aktív lesz az SGI, de általában nem. Ez mitől lehet?

Köszi a segítséget!

https://mikrotik.com/download/changelogs

6.49.5 óta volt sok változás Wi-Fi területen, meg máshol is.
Ha nem is telepíted a frissítéseket azonnal, azért érdemes átnézni és követni a változásokat. Aztán ha van valmi, ami érinthet akkor frissíteni.

Ezzel az alaplappal a 6.49.x megy, vagy a 7.x is erre való, még újabb verzió?

Ha nem lesz más ötlet, akkor elmentem a konfigot és nekimegyek a frissítésnek, hátha.

Bemásolom, hogy kereshető legyen topikon belül, illetve nem láttam még beírva a 7.13 changelog-ot ide.

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 developemnt which will require more disk space for hardware drivers so we had to split it in order to maintain old products alongside the new ones. More wireless packages are yet to come.

1. When upgrading by using "check-for-updates", all versions earlier than 7.12 will display 7.12 as the latest available version. Upgrade from v7.12 to v7.13 or later versions must be done through 7.12 in order to convert wireless packages automatically. Fresh installation with Netinstall or manual package installation works in the same manner as always.

2. Drivers for older wireless and 60GHz interfaces, as well as the wireless management system CAPsMAN, are now part of a separate "wireless" package instead of being a part of the bundle package. This package can be uninstalled if not needed.

3. The existing "wifiwave2" package has been divided into distinct packages: "wifi-qcom" and "wifi-qcom-ac", and the necessary utilities for WiFi management are now included in the RouterOS bundle. RouterOS and "wifi-qcom-ac" packages alongside each other now fit into 16MB flash memory.

What's new in 7.13 (2023-Dec-14 09:24):

!) package - convert "wireless" and "wifi" packages automatically, if upgrading from v7.12;
!) wifi - split existing "wifiwave2" package into separate packages "wifi-qcom", "wifi-qcom-ac", and include required utilities for WiFi management into bundle;
!) wireless - separate "wireless" package from bundle and build as a standalone package;
*) bridge - added automatic "path-cost" values depending on interface rate;
*) bridge - added bridge interface property "port-cost-mode" with "short" and "long" arguments;
*) bridge - fixed bogus VLAN entries from wifi when vlan-filtering is not enabled;
*) bridge - improved HW offload enable;
*) bridge - improved host flush when removing VLAN on HW offloaded bridge;
*) bth - added "VPN Prefer Relay Code" option;
*) bth - improved automatic firewall rule generation process;
*) certificate - add support for multiple DNS names for Let's Encrypt;
*) certificate - added HTTP redirect support for CRL download;
*) certificate - added support for certificates with key size 16384;
*) certificate - fixed CRL updating;
*) certificate - fixed certificate auto renewal via SCEP when certificate contains "subject-alt-name";
*) certificate - improved CRL signature verification and download error messages;
*) certificate - improved initial certificate creation using SCEP;
*) certificate - use error topic for CRL update failures;
*) cloud - improved re-connect speed after network related connection errors;
*) console - added ":grep" command;
*) console - added ":onerror" command;
*) console - added ":serialize" and ":deserialize" commands for converting values to/from JSON;
*) console - added "interface" name when printing "interface/pppoe-server" entries;
*) console - added "read" command under "file" menu;
*) console - added "where" functionality for "export" command;
*) console - added flags to "print" command with "value-list";
*) console - added interface helper for "gateway" property under "ip/route" menu;
*) console - added unset option for "ssid-regex" and "allow-signal-out-of-range" properties under "interface/wifi/access-list" menu;
*) console - clear console history when resetting configuration;
*) console - disallow setting existing "name" under "system/script" and "system/scheduler" menus;
*) console - fixed "export" boolean arguments when saving output to file using API;
*) console - fixed "interface/ethernet/switch/port-isolation" export;
*) console - fixed "on-event" argument highlighting under "system/scheduler" menu;
*) console - fixed graphic distortions in WinBox;
*) console - fixed issue where API incorrectly asks for missing arguments;
*) console - fixed printing to file using API;
*) console - ignore negative values for ":delay" command;
*) console - improved flag printing in certain menus;
*) console - improved stability when running "tool/ping" from API;
*) console - removed "route-cache" setting from "ip/settings" menu;
*) console - replace reserved characters in file and script names with underscores;
*) console - resolve "wifiwave2" directory to "wifi";
*) console - show "l2vpn-link" address family under "routing/route" menu;
*) console - use more compact login screen for empty branding;
*) defconf - expire password when reverting configuration;
*) defconf - fixed bogus wifi password on certain Audience devices;
*) defconf - fixed configuration for Audience with "wifi-qcom-ac" package;
*) defconf - fixed wireless band and channel-width selection (introduced in v7.12);
*) defconf - hide default configuration for users without "sensitive" policy;
*) defconf - improved wifi interface detection after upgrade;
*) defconf - updated configuration with new "wifi" directory;
*) defconf - use "WISP Bridge" default configuration mode for RBGrooveGA-52HPacn device;
*) defconf - use "fan-min-speed-percent=25" for CRS354-48P-4S+2Q+ device;
*) defconf - use device factory preset credentials when using CAPs mode;
*) defconf - use one SSID and enable FT when using "wifi" packages;
*) disk - fixed hang on reboot when network file systems mounted;
*) ethernet - improved packet CPU core classifier for Alpine CPUs for non IPv4/IPv6 traffic;
*) ethernet - improved system stability for L009 and hAP ax lite devices;
*) fetch - added "http-auth-scheme" parameter, allows to select HTTP basic or digest authentication;
*) fetch - added "http-content-encoding" setting;
*) fetch - added raw logging;
*) fetch - allow to receive HTTP response headers;
*) fetch - require "ftp" user policy;
*) firewall - added "nat-pmp" support;
*) firewall - added new IPv6 filter arguments "icmp-err-src-routing-header" and "icmp-headers-too-long" for "reject-with" setting;
*) firewall - do not mark all IPv6 GRE packets as invalid;
*) firewall - fixed IPv6 address-list timeout;
*) firewall - fixed altered address-list when upgrading from RouterOS v6;
*) firewall - fixed connections being tracked when tracking is disabled;
*) firewall - removed "prohibited" and "unreachable" IPv4 address-type arguments;
*) ftp - improved upload and download speeds;
*) health - dynamically add and remove invalid sensors (e.g. sfp-temperature);
*) hotspot - fixed incorrect host moving to VLAN 0 when receiving packets through bridge;
*) ike2 - fixed ike2 double reply;
*) iot - fixed incorrect LoRa ACK packet handling during downlink messaging (introduced in v7.12);
*) ipv6 - do not send out IPv6 RA deprecate message for re-used prefix;
*) isis - added IS-IS protocol support (CLI only);
*) l3hw - fixed routing for IPsec encapsulated packets;
*) leds - fixed LED indication in multi-APN setup for Chateau;
*) leds - improved LED indication during modem registration state for Chateau;
*) log - added "fetch" topic;
*) lora - added CUPs protocol support;
*) lora - fixed issue with lost LoRa configuration when rebooting the device;
*) lte - added RNDIS support for neoway N75-EA modem;
*) lte - added support for FOTA firmware upgrade from custom URL for R11eL-FG621-EA;
*) lte - disabled IMS service for Chateau 5G on A1 HR network;
*) lte - fixed rare cases where Chateau 5G in passthrough mode may stop forwarding packets;
*) lte - improved SIM slot status change notification handling for MBIM modems;
*) lte - replaced "passthrough-subnet-selection" with "passthrough-subnet-size" setting (CLI only);
*) lte - show each CA band in a new line;
*) mipsbe - improved system stability when removing USB devices;
*) mmips - properly mount and unmount USB devices;
*) modem - added option to read SMS using MBIM interface;
*) mpls - added "te-tunnel" property for VPLS monitor (CLI only);
*) mpls - fixed IPv6 RSVP-TE;
*) mpls - improved logging;
*) netinstall-cli - added more details to help messages;
*) ospf - fixed LSA Type3 advertisement for OSPFv2;
*) ospf - fixed missing OSPF interface on L2TP interface reconnect;
*) ospf - fixed missing opaque bit in opaque LSA;
*) ovpn - improved memory allocation during key-renegotiation;
*) ovpn - removed "ping-timer-rem" option from client config file;
*) package - added warning log about missing "wireless" or "wifi" package;
*) pimsm - improved elected BSR change;
*) poe-out - improved firmware upgrade stability for AF/AT controlled boards;
*) ppc - fixed RouterOS bootup (introduced in v7.12);
*) ppp - added remote-ipv6-prefix to IPv6 firewall address-list if "address-list" property is provided;
*) ppp - allow at-chat and info commands in "waiting for packets" state for modems with shared data/info channel;
*) ppp - improved IPv6 link-local address uniqueness;
*) pppoe-server - fixed connection count limit per license level;
*) profiler - improved "disk" and "supout.rif" classifiers;
*) qos-hw - added initial congestion avoidance support for 98DX224S, 98DX226S, and 98DX3236 switch chips (CLI only);
*) qsfp - added support for QSFP-to-SFP adapters;
*) qsfp - fixed supported rates for breakout cables (introduced in v7.12);
*) quickset - show DDNS name as VPN address for devices with new style serial number;
*) route-filter - improved performance;
*) 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 link establishment with S+DA0001 DAC cables;
*) sfp - ignore irrelevant extended compliance code for SFP modules;
*) sfp - improved SFP interface handling for 98DX224S, 98DX226S, 98DX3236, 98DX8208, and 98DX8216 switch chips;
*) sfp - improved link establishment for SFP copper modules;
*) sfp - improved link establishment with certain modules for hEX S device;
*) sfp - show 10M and 100M supported rates for RJ45 copper modules;
*) ssh - added cipher and hash function acceleration for ARM64 and x86 architectures;
*) ssh - fix error that caused large chunks of text not being pasted in their entirety into console;
*) supout - added VXLAN FDB section;
*) supout - added multiple WiFi sections;
*) switch - fixed service VLAN tagged IP multicast packets for 98DX8208, 98DX8216, 98DX8212, 98DX8332, 98DX3257, 98DX4310, 98DX8525, 98DX3255 switches;
*) system - added "rtrace" debugging tool (CLI only);
*) system - improved incoming and outgoing TCP connection performance;
*) system - improved internal process communication performance;
*) traffic-generator - improved system stability when modifying interfaces;
*) usb - added support for RTL8152 USB ethernet on ARM, ARM64 and x86;
*) vpls - improved performance when decapsulating data;
*) vrf - fixed ICMP reply lookup;
*) webfig - allow to display comments in multiline or compact modes;
*) webfig - make table headers always visible;
*) webfig - use local storage for user preferences;
*) wifi - added "flat-snoop" tool for surveying WiFi APs and stations (CLI only);
*) wifi - added "radio-mac" variable for "name-format" provisioning setting;
*) wifi - added "remove" command in "capsman/remote-cap" menu;
*) wifi - after radar detections, avoid selection of channels not permitted by the user;
*) wifi - changed CAPsMAN generated certificate common name;
*) wifi - create first interface without number when using "name-format" provisioning setting;
*) wifi - enable protected interworking ANQP responses;
*) wifi - fixed EAP authentication failures when the Session-Timout RADIUS attribute is defined;
*) wifi - fixed occasional failures to start on 20/40mhz-eC channels for 2.4GHz 802.11ax interfaces;
*) wifi - fixed overridden datapath settings on CAP when unsetting from CAPsMAN;
*) wifi - improved CAPsMAN stability during provisioning;
*) wifi - make slave APs use datapath bridge settings inherited from master by default;
*) wifi - removed "openflow-switch" setting;
*) wifi-qcom - added fast-path for received packets;
*) winbox - added "Hw. Offload" property under "IP/Firewall/Filter" menu;
*) winbox - added "Ping" button under "IP/DHCP Server/Leases" menu;
*) winbox - added "Tx bps" and "Rx bps" monitor values under "WiFi/Registration" menu;
*) winbox - added "none" argument for "Preshared Key" under "WireGuard/Peers" menu;
*) winbox - added icon to entries under "WiFi/Access List" menu;
*) winbox - added missing "qos-classifier" argument for "Hw. Caps" under "WiFi/Radios" menu;
*) winbox - added missing arguments for "MAC Format" under "Wireless/Security Profiles/RADIUS" menu;
*) winbox - allow opening entries under "WiFi/Registration" menu;
*) winbox - fixed default "Name Format" property under "WiFi/Provisioning" menu;
*) winbox - fixed minor typo under "Routing/BFD" menu;
*) winbox - improved connection speed;
*) winbox - updated "wireless" and "wifi" menus;
*) wireless - fixed "wlan1" default name for RBSXTsqG-5acD and RBLDFG-5acD;
*) wireless - fixed snooper information gathering from re-assocation requests;
*) wireless - keep configuration after manual package removal;

"Got any other secret weapons?"

Szerintem igen, de majd valaki okosabb megerősíti.

Sziasztok.
Alany Mikrotik RB4011iGS+ vezetékes router 7.7-es routeros. Ha frissítem 7.12-re akkor szinte nem működik semmi rajta. Mi lehet ez?
Hiba, ilyenkor pl azt írja hogy NAT-olt hálózat mögött vagyok. Ez nincs így, mert a szolgáltatóval is egyeztettem, plusz megnéztem a szolgáltatói router beállítást is, és van publikus IP (Telekom).
Ahogy visszateszem a 7.7-et úgy minden megy rendesen.
Köszönöm szépen

Szia
Azt meg tudom erősíteni, hogy a 7.12-vel nekem nem volt bajom, ugyanezt a típust használom és szintén T-nél vagyok.
Mit jelent az, hogy semmi nem működik? A router írja, hogy NAT mögött vagy? Ezt hol?
Talán a konfigban lehet valami ami nem tetszik neki vagy megkavarja. Firmware-t is frissítettél?

Rendszergazda vagyok....ha röhögni lát, mentsen

Alapvetően jó, egyedül az 5 perces group key update zavarhat be. Próbáld ki 1 órával.

Úgy általában: szerintem is firmware upgrade kellene először, még long term esetén is a 6.49.10 2 évvel újabb.

Köszi, meggyőztetek, valamikor a hétvégén megpróbálom megcsinálni. De a hibajelenség akkor is elég érdekes...

Ip/cloud-nál írja.
megkavarja rendesen. Látszólag van net, de közbe nincs. A routerig van net, mert tud keresni frissítést.

A RB4011iGS+ wifisre nem tudom telepíteni a 7.13-at, de egy Chateau-ra simán felment.

A tűzfal szabályoknál nincs semminél valami piros megjegyzés, hogy hibás lenne?

Le az elipszilonos jével, éljen a "j" !!!

CAPSMAN-os frissítés elég mókás lett így, mert architektúrán belül nem volt gond eddig. RB5009 a capsmanom, 2 db cap ax és egy hap ax2 a cap. Fel kell rakni minden csomagot a capsmanra, ami kell a cap-nek. Jelen esetben nálam csak a wifi-qcom hiányzott.

[ Szerkesztve ]

Na ez érdekes. 7.11.2 fut jelenleg, de a 7.12-re sem frissül fel. Ilyet mi okozhat?

Minden ok ott. Amint 7.7 megy vissza. Megy is minden.

netinstall?

sikerült végül a packages alatti check update tool-al. Gondolom valamelyik csomag, feltehetőleg a container fogta meg az updatet.

Másik, közbenső verzióval nem próbálkoztál? Pl. [ 7.11.2 ]

A látszólag van net issue-t kellene felderíteni miért. (ha még fent van az ominózus verzió)
A routerről kimegy a csomag? Nevet felold? Ha kimegy, melyik tűzfalszabályig jut el visszafelé.

Rendszergazda vagyok....ha röhögni lát, mentsen

Internet detect? Elvileg csinál egy dhcp klienst, az azért összekavarhat sokmindent.

7.7 van rajta. Nem tudom meddig jut el. Bár én konfigoltam be jó pár éve, de közel sem vagyok profi.