- Radeon RX 9060 XT: Ezt aztán jól meghúzták
- Atomenergiával dübörögnek tovább az Amazon adatközpontok, SMR-ek is jöhetnek
- Macron betiltatná az EU-ban a közösségi médiát a 15 év alattiaknak
- Az NVIDIA ipari AI-felhőt épít a németeknek, együtt az OpenAI és a Google
- Két új Ryzen közül választhatnak a kézikonzolok
- Fujifilm X
- Milyen videókártyát?
- Sony MILC fényképezőgépcsalád
- AMD Navi Radeon™ RX 9xxx sorozat
- Autós kamerák
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Radeon RX 9060 XT: Ezt aztán jól meghúzták
- HiFi műszaki szemmel - sztereó hangrendszerek
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Házi hangfal építés
-
PROHARDVER!
Mikrotik routerekkel foglalkozó téma. Mikrotik router típusok, hardverek, router beállítások, programozás (scriptek írása), frissítés, és minden Mikrotik routerrel kapcsolatos beszélgetés helye.
Új hozzászólás Aktív témák
-
Vektor77
tag
válasz
Davebowman
#23999
üzenetére
Dugd másik portba és állítsd át a routert hogy ne az legyen a wan portja.
-
#23999
Davebowman
senior tag
Davebowman
senior tag
Sziasztok, érdeklődnék, hogy van-e valami extra teendő, ha egy Mikrotik ax3 router 2500-as portjából egy cat5e kábellel egy pc usb3-ba dugott aliexpresszről húzott 2.5Gbit-es kütyüt tettem, a winbox-al a router csak Mac cím alapján érem el, maga a router ip címet ad neki DHCP-n, és az 5-ös portjába dugott másik eszközt tudom pingelni, deeee a routert nem. Ezt 2 ilyen eszközzel is eljátszotta. Van bármi amit így elsőre kihagyhattam? Win11, linux, alatt a pc ugyaz ezt teszi. Vagy egyszerre dobjam a kukába ezeket? Sima 1000-es usb-s ethernettel megy minden, tehát nem gondolom, hogy beállítás gond lehetne... valaki így elsőre?
hálásan köszi -
Gyurka6
őstag
Már, hogy a logba ne jelenjen meg ennyiszer:
2025-03-13 02:11:08 dhcp,error pool6 refused acquire: bad preferred prefix length! (1)
2025-03-13 02:11:09 dhcp,error pool6 refused acquire: bad preferred prefix length! (1)
2025-03-13 02:11:09 dhcp,error pool6 refused acquire: bad preferred prefix length! (1)
2025-03-13 02:11:09 dhcp,error pool6 refused acquire: bad preferred prefix length! (1) -
Gyurka6
őstag
Szevasztok!
Váltottam digi-ről t-re, a log ilyennel van tele
2025-03-12 16:38:35 interface,info ether4 link up (speed 100M, full duplex)
2025-03-12 16:38:48 dhcp,error pool6 refused acquire: bad preferred prefix length! (1)
2025-03-12 16:38:49 dhcp,error pool6 refused acquire: bad preferred prefix length! (1)
2025-03-12 16:43:37 interface,info ether2 link down
2025-03-12 16:43:39 interface,info ether2 link up (speed 10M, full duplex)
2025-03-12 16:44:48 radvd,warning invalid mtu 1998 on ether1 from fe80::d692:5eff:fe89:22478
Ezzel lehet kezdeni valamit? -
ekkold
Topikgazda
válasz
laracroft
#23992
üzenetére
Tehát, ha jól értem adott egy publikus IP, amin egy mikrtotik router van. A router mögött két szerver, az egyik üzemel, a másik tartalék. A router megnyitja az 5000-es portot, és továbbítja az adatokat az egyik szerver felé. Ha az adott szerver nem működik, akkor a router a másik szerver felé továbbítja az adatokat.
Ez gyakorlatilag megoldható úgy, hogy egy szkript módosítani tudja az ehhez tartozó port forward (destination NAT) szabályt. Azt kell megoldani, hogy a szkript tudomást szerezzen a szerver működéséről. Pl. pingeli a szervert, és ha nem elérhető, akkor átvált a tartalék szerverre. Vagy lehet, hogy ennél ügyesebb módszer is adódhat, amivel ellenőrizheti, hogy a szerver működik-e (pl. lekér a szervertől egy weboldalt, ha sikeres, akkor üzemel a szerver).
A két szerver szerintem dolgozhat független adatbázisba, csak naplózni kell, hogy mikor melyik szerver üzemelt. A lekérdezéseknek pedig tudnia kell mindkét adatbázisból lekérdezni. És/vagy meg kell oldani, hogy a két adatbázis időnként össze legyen fésülve... -
laracroft
senior tag
válasz
ekkold
#23990
üzenetére
Ezek az eszközök riasztó berendezések átjelzői, amik egy IP/portra küldözgetnek életjelet/riasztást stb. A user oldali változtatás nem igazán lehetséges - akár hardver cserével sem - mert túl sok van belőle elszórtan. Az eszközökhöz nem lehet csatlakozni, mert mobilnetes elérésük van és az IP mindig változik.
Marad tehát a mostani irány, hogy az eszközök csatlakoznak hozzánk.
A 2 szervernek nem kell együtt működnie.
Minél inkább belemélyedek, annál bonyolultabnak tűnik nekem. Erről a port mirroring-ról már lemondtam, szerintem itt a közös adatbázis lesz a megoldás. Persze azt is szinkronizálni, ha baj van átállni stb elég bonyinak tűnik, ha automatán szertném.
Meg persze átváltani a forward-ot gep2-re ha gep1 nem megy (ezt gondolom mikrotik tudja).
Szóval tényleg csak ha ötletet szinten is érdekel véleményetek.
-
What's new in 7.18.2 (2025-Mar-11 13:59):
*) console - fixed issue with file-name completion (introduced in v7.18);
*) container - fixed repository name handling to prevent redirect issues when basic authentication is used;
*) lte - additional fixes for eSIM management support;
*) lte - AT modems, improved redialing when modem lost connectivity without notifying host about APN status change;
*) netinstall - fixed socket reset (introduced in v7.18);
*) queue - fixed system failure when CAKE kind queue was configured but queue type definition does not exist anymore (introduced in v7.18);
*) wifi - improved stability for wifi interfaces;
*) winbox - improve graphing efficiency when communicating with WinBox; -
ekkold
Topikgazda
válasz
laracroft
#23989
üzenetére
A TCP csomagok nem fognak tudni egyszerre két helyre eljutni - legalábbis ezt a mikrotikkel nem tudod megoldani szerintem. Tehát máshol/máshogyan kell "belenyúlni" a dolgokba.
- Pl. a távoli berendezések nem módosíthatók úgy, hogy két helyre is elküldjék az adatokat?
- Vagy a protokollnak kellene másképp működnie pl. nem a távoli eszköz küldi az adatot, hanem a szerver kérdezi le. Így akárhány szerver lehet aki adatot gyűjt.
- Esetleg az eszközök küldhetnek broadcast csomagokat, akkor mindkét szerverhez eljuthat.
- Vagy a broadcast csomag csak jelzi, hogy "itt az idő most ébren van az eszköz lehet lekérdezni"... és mindkét szerver lekérdezi az adatokat...
- Esetleg mindkét szerver működhet eszközként is, és egymásnak is elküldik a kapott adatokat.
Esetleg ha egyik sem megy, akkor lehetne egy központi gyűjtő szerver szerűség, ami csak cache-el, és két helyre továbbítja az adatokat: erre viszont egyedi célszoftver kell(het). Persze továbbra sem tudjuk miről is van szó, így csak találgatni lehet.Ha nem feltétel, hogy egyszerre működjenek, akkor a két szerver IP címét pl. fel lehet cserélni, vagy ami még egyszerűbb, domén nevet kell hozzá rendelni, a domén név pedig mindíg az éppen működő szerverre mutat. A mikrotik támogat statikus domén név bejegyzéseket, de akár az ARP táblában is manipulálható a MAC - IP összerendelés...
-
#23989
laracroft
senior tag
D-LAN|FuRioN
#23977
laracroft
senior tag
válasz
D-LAN|FuRioN
#23977
üzenetére
A cél: Ha gép1 kiesik akkor gép2 vegye át a feladatait úgy, hogy szinkronban tűpontos másolata az elsőnek. A cél az lenne, hogy minél kisebb időkiesés nélkül tudjon a rendszer tovább működni.
Az 5000-es portra távoli berendezések küldenek csomagokat bizonyos időközönként, azt veszi egy a gépen futó progi és menti egy adatbázisba.
Ha nem port mirroring, akkor ti hogyan oldanátok ezt meg?
Inkább az adatbázist duplikálni?
Viszont mi van ha az közös adatbázis sérül? -
laracroft
senior tag
ekkold, stopperos, D-LAN|FuRioN,
Köszi a válaszokat -
#23987
poli27
veterán
donjohnson
#23985
poli27
veterán
válasz
donjohnson
#23985
üzenetére
Nem közbe már kiderült az arp táblában ütközött egy másik eszközzel valamiért... tábla törlés megoldotta
-
mrots
junior tag
válasz
laracroft
#23971
üzenetére
Szerintem mindez siman megoldhato es nem jelent kihivast - egy kivetellel: az egy csomag ket celba torteno kozvetiteset. En nem tudok olyan mikrotik beallitasrol vagy modszerrol aminek segitsegevel egy csomagbol kettot csinalnal, mivel altalaban a routerek nem tamogatnak olyan metodust, hogy egy csomagbol ketto legyen.
A multicast egy picit kivetel, ott valoban tortenik csomag duplikalas, de nem feltetlenul az a router vegzi aki az egesz halozat elejen van, hanem a multicast forgalom tovabbitasa soran ugyanazt a csomagot kuldik ki tobb helyre (kb mint a switchek, amikor meg hubok voltak) attol fuggoen, hogy hol van feliratkozo az adott multicast csoportra.
Logikus, hogy a mikrotik az egyik helyre kuldi csak ki a csomagot, hiszen megy vegig fentrol lefele a NAT szabalyokon es ami eloszor passzol azt csinalja, utana nem keres tovabb. Ha jol tudom - de lehet rosszul tudom.
Mivel azt irod, hogy a masodik cim az elso tartaleka csupan, ha semmikeppen nem tudod a forgalmat ket helyre kikuldeni es mas iranybol kozelitenek es felvennem a masodlagos gepen (megfelelo ellenorzesek utan) az elso IP cimet es ugy mukodne tovabb. Mint egy IP alias. Nem a kerdesedre a valasz, de mukodne.
Ha mindenkepp kozpontilag akarod megoldani, akkor valoszinuleg egy reverse proxyra van inkabb szukseged.
-
poli27
veterán
Van 2 Bambulab nyomtatóm, az egyik fel van csatlakozva a wifire (nem próbáltam meg törölni mert működik, és nem akarok azzal is szívni
) a másik valamiért lecsatlakozott róla, és nem tudom visszatenni, mert ipcímet kap a nyomtató wifire felmegy, de a felhőbe nem tud bejelentkezni... ha berakok egy köztes routert akkor hibátlanul felmegy... de hiába adom neki ugyanazt a nevet addig kikapcsolva a mikin a wifit, utána már nem csatlakozik át a mikrotikre, hogy elérhető is maradjon... mi a fenét tudok vele csinálni?
-
#23977
D-LAN|FuRioN
aktív tag
laracroft
#23973
D-LAN|FuRioN
aktív tag
válasz
laracroft
#23973
üzenetére
Ilyesmit nem így szoktak megoldani. Nem router segítségével. Amit írtál megoldás erre nem jó szerintem. Nem írtad, hogy ezt az 5000-es portot pontosan mire használod, milyen szolgáltatás van mögötte. Mit szeretnél megvalósítani magas rendelkezésreállást terhelés elosztással vagy folyamatos adat replikát? Amit írtál nekem az jön le, hogy a 2. gép csak backup. Szóval ha gép 1 kiesik akkor nem érdekes, hogy megáll az a bizonyos szolgáltatás, a lényeg, hogy legyen replikád róla. Vagy a cél az, hogy ha gép1 kiesik akkor gép2 vegye át a feladatait úgy, hogy szinkronban tűpontos másolata az elsőnek? Mindenre van megoldás, de egyiket sem router szinten szokás megvalósítani. Főleg ha csak abba gondolunk bele, hogy ha UDP-t tükröznél ott nincs hibatűrésed, TCP esetén meg ha csak "hallgatózól" nincs garancia arra, hogy pont az az adat pont olyan formában érkezik oda a gép2-re mint ami a gép1-re, hiszen nincs tcp retransmission. Lehet HA megoldást is csinálni ebben az esetben viszont a gép1-gép2 között szokás egy a routeres hálózattól független fizikai kapcsolatot létesíteni, ez általában nem 1gbit/s-es adatkapcsolat. Ebben az esetben is a pfw gép1-re megy, az adatok tükröződnek a saját kapcsolaton gép2-re, ha ez a kapcsolat kiesik akkor pedig gép2 átveszi gép1 szerepét. Ezek nem két perces megoldások egyébként. AI nem fogja neked megoldani.
Viszont szerintem ezen a vonalon olvasgass: Linux, DRBD, Heartbeat, High Availability Cluster. Itt első körben ami érdekes lesz majd neked a Linux alapon DRBD cluster. -
stopperos
senior tag
válasz
laracroft
#23971
üzenetére
1) Ilyet haproxy-val oldottunk meg máskor. Egy közös IP-n osztoztak, és aktív-passzív állapotban voltak. Amikor az aktív eltűnt, akkor a passzív átvette az IP címet és az lett az aktív.
2) Mikrotik-en is hasonlót kell megcsinálni, csak visszafelé. De ez bonyolult és sok munka (8-10 óra). Az AI nem fogja tudni megoldani. Ez is aktív-passzív megoldás.
TCP miatt nem megy a mirror (ahogy írták is mások). UDP esetén egyszerűbb a helyzet. -
ekkold
Topikgazda
válasz
laracroft
#23973
üzenetére
TCP esetén alacsony szinten mindenképpen megy válasz is, mert nyugtázni kell a csomagokat, nyugta meg csak egy helyről jöhet.
Lehet, hogy létezik valamilyen megoldás, de ezt szerintem semmilyen router nem tudja alapból megoldani, mert ehhez tárolni kell a csomagokat, a saját nevében nyugtáznia kell, majd elküldeni mindkét kliens felé, és mindkettőtől megvárni a nyugtát.
Az UDP azért egyszerűbb mert ott nincs nyugtázás, a küldő elküldi a csomagot, a címzett meg általában megkapja (néha meg nem). Természetesen felette lehet olyan réteg ami megoldja a hibamentes adatátvitelt (pl. csomagismétléssel) UDP esetében eleve lehet olyan egy adatcsomag, hogy nem csak egyetlen címzettnek szól.
-
ekkold
Topikgazda
válasz
laracroft
#23971
üzenetére
Ehhez elvileg boradcast vagy multicast kell, azaz UDP csomagok esetén elvileg megoldható. TCP esetén pont-pontkapcsolat épül fel, ezért szerintem TCP-n nem működne ilyesmi. A cél eszközök mit kezdenek ezekkel a csomagokkal, pl. valamilyen választ fognak küldeni?
Pontosan ilyet még nem kellett csinálnom, így kész megoldásom sincs erre, de ha pontosabban megírnád, hogy mi a célod, akkor talán jobb tippeket lehetne adni. -
laracroft
senior tag
Sziasztok
Nem vagyok mikrotik agy, szóval kérlek segítsetek.
Adott ez a feladat:
Egy router mögött lévő eszköz utp csatlakozójára érkező csomagokat továbbítsa a 10.0.0.1-es és 10.0.0.116-os ip-kre az 5000-es porton.
Egy gyors keresés és AI használata után azt az infót kaptam, hogy mikrotik router képes erre is. Van is egy RB750GR3-as amin próbálkoztam. Sajna csak az jött össze, hogy az egyik IP címre tükröződött a kívánt adat, a másikra nem (NAT forward mindkettőre+még vmilyen mangle megoldást erőltetett, ami mindíg hibára futott)
Az ai sokszor bevitt az erdőbe ezért már kissé szkeptikus vagyok vele, hogy ez így nem fog menni.
Olvatsam még a Port mirroring+Port switching megoldásról is, amit csak bizonyos mikrotik routerek tudnak hardversen, gondolom azok nem ilyen árkategóriában vannak.
Szerintetek hogyan tudnám ezt megoldani, ha lehet ezzel a routerrel?
előre is köszi a megoldásokat -
#23970
Zwodkassy
senior tag
Merula Alba
#23969
válasz
Merula Alba
#23969
üzenetére
De esetleg írhatsz a Telekom-os topikba is.
Egy kérdést megér :-)
( FórumokHálózat, szolgáltatókTelekom otthoni szolgáltatások (TV, internet, telefon) ) -
#23968
Zwodkassy
senior tag
Merula Alba
#23967
válasz
Merula Alba
#23967
üzenetére
Telekomnál vannak 1/1 Mbit-es SIM kártyák is.
A jelenlegi munkahelyemen is sikerült ebbe belefutni
-
Merula Alba
tag
válasz
lionhearted
#23966
üzenetére
Sziasztok.
Az alany egy Mikrotik R11-LTE eszköz, van külső MT antenna is hozzá kötve a jobb jelszint érdekében.
Telekomos kártya van benne, beállítottam amit kell mobil és WIFI téren.
A problémám az hogy 1/1 Mbit sávszélnél fentebb nem kúszik a sebesség. Pedig olyan helyen is teszteltem ahol a térerő nemigen lehet probléma.
Mikrotik eszközökkel nem igazán van tapasztalatom, biztos valamit nem veszek észre.
10/10-es nettel is kibékülnék már, de az 1/1 az kevéske.
Valakinek van ötlete erre a problémára? -
#23966
lionhearted
őstag
Edorn
#23965
-
What's new in 7.18.1 (2025-Feb-28 13:31):
*) bridge - improved stability in case of configuration error (introduced in v7.15);
*) bridge - show warning instead of causing error when using multicast MAC as admin-mac (introduced in v7.17);
*) cloud - fixed issues when BTH is toggled fast between enable/disable;
*) cloud - improved "BTH Files" web page design;
*) console - fixed issue with files when using scripts (introduced in v7.18);
*) console - improved file add/remove process stability;
*) dhcpv6-relay - clear saved routes on DHCP release;
*) dhcpv6-relay - show client address;
*) disk - add "sector-size" property in print detail;
*) disk - improved stability when formatting crypted partitions;
*) l3hw - remove VLAN tag before VXLAN encapsulation (fixes pvid behavior for bridged VXLAN);
*) lte - fixed modem recovery after firmware upgrade for R11e-LTE modem;
*) lte - fixed Router Advertisement processing issue for AT modems when an APN with "ip-type=ipv6" was configured;
*) ovpn - disable hardware accelerator for GCM on MMIPS CPUs (introduced in v7.18);
*) poe-out - fixed health showing 0V voltage when using PoE-in for RB960;
*) poe-out - upgraded firmware for 802.3at/bt PSE controlled boards (the update will cause brief power interruption to PoE-out interfaces);
*) route - show BGP session name instead of cache-id;
*) switch - improved stability when enabling IGMP snooping with VXLAN (introduced in v7.18);
*) system - improved internal "flash/" prefix handling for different file path related settings;
*) winbox - fixed missing SMB client on non-ROSE devices; -
ekkold
Topikgazda
A WOL-t MAC addressre küldd, ne IP-re (és akkor nem kell statikus ARP bejegyzés sem), persze a DHCP leases-be vedd fel az eszköz MAC addressét.
Vagy ha mindenképpen kizárólag IP alapon kell, akkor vegyél fel egy nem használt IP-t, az ARP táblába ami a broadcast MAC címhez tartozik. Ezután az erre küldött WOL-t mindenki megkapja, de mivel a WOL csomag is tartalmaz MAC address-t, csak azt kelti fel akinek az üzenet szól. Nálam ez utóbbi megoldás is jól működik, szükség esetén akár távolról is fel tudom ébreszteni amit szeretnék. -
kress
aktív tag
Van egy eszkoz a halozaton amit WOL-al lehet felkelteni.
Ez egy statikus IP cimmel tortenik, van egy statikus ARP bejegyzes melle, hogy tudja hova menjen a WOL. A bridge reply-only arp-n van, az ARP cimeket a DHCP szerver kezeli.
Minden szep es jo, viszont amikor felkel az eszkoz megkapja az IP cimet a dhcp szervertol, es a dhcp akarna hozzaadni ARP bejegyezest is neki, de mivel az ott van statitkusan csak egy hibat ir a logba, hogy mar van ilyen ARP bejegyezes.
"failed to add arp entry for IP XXX: already have such arp (6)"A kerdes, hogy lehetne ezt a hozzaadasi probalkozast elkerulni, mashogy kene csinalni?
-
Gyula888
tag
válasz
MPeti2
#23954
üzenetére
Ha esetleg olvastad volna a korábbi hozzászólásaimat, vagy éppen részletesebben, akkor pontosan tudnád, hogy én pont emiatt nem is javasoltam az UniFi rendszert, mert felhő nélkül nem működik. Én magam is mindig a VPN használatát javaslom, netre semmit sem rakok ki. A saját rendszerem is úgy működik, hogy a kamerás VLAN-ból sehová sem lehet menni(még a netre sem), a többi hálózatból is csak kizárólag az NVR-t és annak bizonyos portjait lehet elérni. A kamerás app esetén maximum iOS-ről lophatnak bármit is, mert ott nincs különösebb lehetőség a jogosultságok szabályozására.
-
hogyan tudok wifis eszközt deautholni? csak annyit szeretnék, hogy eldobja egy pillanatra aztán csatlakozzanak is újra (és megkapják az új dhcp konfigot)
Wifi / registrationnél érdemes törölni? vagy a dhcp clientek közül? -
#23955
E.Kaufmann
veterán
MPeti2
#23954
E.Kaufmann
veterán
válasz
MPeti2
#23954
üzenetére
Az se jó, hogy bactatják az internetet, anélkül nem működnek és volt már, hogy felhős vezérlésű cuccokat gyártó bezárta a bazárt az eszközeik meg azon nyomban drága veszélyes hulladékok lettek. Normál (üzemre is képes) eszköz max nem kap több frissítést és körbetűzfalazva még használható nyugodtan.
-
MPeti2
csendes tag
válasz
Gyula888
#23938
üzenetére
Frigate NVR-nél a webes felülettel semmi probléma nincs, tökéletesen működik, telefonon is. Ott PWA mivolta miatt natív appszerűen is telepíthető.
A Tailscale használata, és a gyártói app messziről kerülése nagyon jó ötlet, ha nem azért veszed adott gyártó termékét mert 100%-ig megbízol benne, hanem mert az van ami elérhető, adott minőségért adott árkategóriában (vagy egyáltalán).
Vannak akik nem törődtek bele abba hogy a google facebook és mennyi más cég össze vissza adatbányászkodik róluk, és sajnos a népszerű kamera gyártók szoftvere pont úgy tele van adatbányászattal, arról nem is beszélve hogy ki tudja mit csinálnak a felvételekkel amik keresztülhaladnak a felhőszolgáltatásaikon.
Ha téged nem érdekel hogy a házadon kívül ki mit lát az életedből, az a te dolgod, viszont a kamerád képén valószínűleg nem csak te leszel rajta, hanem jó eséllyel a szomszédság is, ha kilát az utcára. És itt nem a "nem vagyok érdekes"/"unalmas vagyok" dologról van szó, ezt én is így gondolom magamról. Senkit sem néz valaki a kameragyártótól, az automatizált, tömeges adatbányászatról van szó, ami például "személyreszabott ajánlatokhoz" és képfeldolgozó mestint tanításhoz történik.De a Tailscale/Wireguard nem csak adatvédelmi szempontból jó ötlet, biztonsági szempontból is. Ha nem kell portot nyitni a berendezésnek, nem lehet az internetről kihasználni a sebezhetőségeit. A Wireguard pedig egy egyszerű VPN szerver, ráadásul hálózatbiztonsági szakértők készítik, sokkal kisebb a sebezhető felülete. Be van építve a Linux kernelbe, ami egy magas szintű minőségbiztosítás, ráadásul sokkal de sokkal tovább fog biztonsági frissítéseket kapni, mint bármelyik kameragyártó hulladéka.
A kamera topik összefoglalója meg sem említi a kínai olcsó kamerarendszerek használatának a következményeit, majdhogynem ajánlja is őket.Személy szerint én senkinek nem ajánlanék nyilvános felhőalapú kamerarendszert, a mai közegben legalábbis biztosan. És mélyen megvetem azokat, akik köztereket, az utcát veszik vele.
-
-
D!esel
csendes tag
Sziaszok!
Segítséget szeretnék kérni, ki van építve 2 telephely között egy pont-pont kapcsolatos Mikrotik RBLHG2nD-XL eszközöm, és valamikor fél óra , valmikor 1 nap után eldobja belső lan kapccsolatot véletlenszerűen, kültéri feszített cat5e kábellel van kivitelezve a rendszerem, minden frissítve lett a 2 eszköz között, jelenleg 7.17.2 verizó van telepítve mind a kettő eszközre, ilyen esetben mi lehet a probléma? esetleg találkoztatok már ilyenekkel? kétszer már újra krimpeltem az RJ-45 dughót, de sajnos ugyan ez a hiba jön elő. Képeket mellékeltem a hibáról is, [kép] [kép] [kép] [kép] [kép] [kép]
Köszönöm a segítséget,
Üdv:
D!esel -
RouterOS 7.18
A changelogot most nem másolom ide, mert nagyon hosszú lenne, de alább olvasható -
#23945
ekkold
Topikgazda
lionhearted
#23944
ekkold
Topikgazda
válasz
lionhearted
#23944
üzenetére
Szerintem az utolsó mondatod volt a lényeg:
* dobod az FTP-t, mondjuk SFTP-re cserélve.
Manapság egy titkosítás nélküli FTP használata nem biztos, hogy a leg-szerencsésebb dolog, és valljuk be, hogy az FTP egyszerre két portot használó megoldása sem igazán jó megoldás manapság. Az SFTP egyetlen portot használ, stabil, megbízható, és biztonságos... -
#23944
lionhearted
őstag
Edorn
#23939
Feltételeztem, hogy az FTP port nyitásai ismeretesek mindenkinek, de ha nem, akkor:
* aktív FTP kapcsolat: kliens nyit egy TCP sessiont szerver felé (command channel), majd a szerver visszafelé a kliens felé (data channel)
* passzív FTP kapcsolat: kliens nyit két TCP sessiont a szerver felé, úgy, hogy egy random porton kezd el hallgatni a szerver és oda várja.Legtöbbször nem a fenti, hanem a lenti szokott megvalósulni, mivel kliens oldalon senki nem tud/akar tűzfalat bontani, és még NAT is lehet közben... szóval van egy helper a Mikrotikben (IP->Firewall->Service ports), ahol a tűzfal figyeli az FTP forgalmat és kiolvassa belőle a port nyitási szándékot a random porton.
Segítség lehet, ha:
* egy a szerveren megadsz egy szűk tartományt, amit erre fenntartasz, és fixen beengeded a szerver felé.
* felépítesz egy VPN tunnelt, és azon keresztül FTP-zel.
* dobod az FTP-t, mondjuk SFTP-re cserélve. -
hoffman_
nagyúr
válasz
Gyula888
#23942
üzenetére
így visszanézve lehet, hogy ROS alatt beállítva egy további külön subnetet csak a kameráknak és onnan beállítani a Wireguardot, nem szenvedtem volna többet. majd legközelebb
mindenesetre a Tailscale is jól működik, most már, a beállítása egyszerűbb (elvileg), a trouble-shooting volt nem várt feladat. most viszont a kamera subnet a routerig se jut el, a NAS egyik NIC-je az átjáró gyakorlatilag, csak a tailnet-en keresztül érem el.akkor azért rendesen kiakadok, ha nem ment volna browser alól, ebben a kérdésben mindegy, hogy Wireguard vagy Tailscale.
ui.: nem nagy diszkomfort, plusz két-három kattintás. az IP kirakva ikonnal a kezdőképernyőre, login elmentve, lokális pw manager beolvassa, Tailscale app indítás után bent is vagy. gondolom ez kb. ugyanígy lenne WG-vel is.
-
Gyula888
tag
válasz
hoffman_
#23941
üzenetére
Működni működik, de nem éppen komfortos. Ne használj telefont, ha ilyen permission félelmeid vannak, pláne ne Apple-t
Igen, viszont szerintem ha a wireguard a routeren fut, sokkal egyszerűbb a helyzet. Gyakorlatilag magadnak nehezíted és bonyolítod ezekkel a dolgokat, ami nem baj, hiszen azért vagyunk itt, hogy segítsünk egymásnak, csak ezeknek gyakran fejfájás a vége értelmetlenül Bevallom, nekem meg sem fordult a fejemben ilyen, hogy majd te telefonon böngészőből szeretnéd a kamerákat nézegetni. Régebben(de lehet még most is) Linuxon az UniFi Firefox-on sem működött például, egyszerűen nem ment a stream. -
hoffman_
nagyúr
válasz
Gyula888
#23938
üzenetére
te nem láttál, én meg igen. ha átugrottál volna tegnap éjjel hozzám, láttál volna te is
sikerült megoldani, a local a fw upgrade az NVR-on végül megoldotta. utána is voltak furcsaságok, nem akartak menni a böngészők, hw acceleration hibára hivatkozva, aztán sok próbálkozás meg restart után egyszer csak megette. nem pipáltam még ilyet. tán azért, mert nem ezekkel foglalkozom napi szinten
a saját alkalmazását fentebb írtam. app permission ide vagy oda, nem lettem volna komfortos. a Tailscale kérdést nem értem. az gyakorlatilag a Wireguad layer.
-
Tamarel
senior tag
A packet sniffert még soha nem használtam, így arról nem tudok nyilatkozni.
A beállításokban vannak zavarok, a tűzfal szabály elnevezések is mutatják a bizonytalanságod.
Kezdésnek: ipv6 kikerüli a proton wireguard vpn-t. A nasról mindenképp le kell szedned az ipv6-ot, ha úgy egyébként vpn-en belül szeretnéd tartani a forgalmát.
Ha a routeren van ipv6, akkor a dns-edben is lesz, aztán az ftp vagy megoldja majd vagy nem.Vlan, guest, routing: kell némi (szabad)idő a kibogozásához.
-
#23939
Edorn
senior tag
lionhearted
#23934
Edorn
senior tag
válasz
lionhearted
#23934
üzenetére
Feltételezem úgy gondolod, hogy ezzel a válasszal közelebb jutattál a megoldáshoz... de nem.
-
#23937
hoffman_
nagyúr
lionhearted
#23936
hoffman_
nagyúr
válasz
lionhearted
#23936
üzenetére
azt nem próbáltam, ilyen szutykokat nem szeretek felrakni. nem lakossági cucc, működjön már web alól... firmware frissítés az utolsó mentsváram, van némi remény, de nem biztos, hogy megoldja, éjszaka kiderül. ha sikerül, azt meg írom, mert akkor mégis használható use-case, hátha másnak hasznos.
-
#23936
lionhearted
őstag
hoffman_
#23935
-
hoffman_
nagyúr
válasz
hoffman_
#23794
üzenetére
tudom, nem mikrotik téma, de kaptam ajánlást a VIGI rendszerre, amit meg is fogadtam, sok keresés után én is erre jutottam. erről most lebeszélnék mindenkit, aki hasonlóan egyedi forgatókönyv mellé szeretné, nehogy így járjon. jóval több szívás volt felállítani a Tailscale-t, mint vártam, de végül sikerült és a routerhez nem kellett nyúlni. a szép az egészben, hogy a nagy ünneplés közepette, iOS alatt, mint végső céleszköz, minden böngésző elhasal. elérhetetlen az NVR webes felülete. így kell kidobni közel 200k-t : ' )
-
#23934
lionhearted
őstag
Edorn
#23933
-
Edorn
senior tag
Erre esetleg tudnátok valami tippet, hogy mitől lehet?
A Mikrotik routeremre van kötve egy NAS, amire minden nap több biztonsági mentés érkezik több helyről ftp kapcsolaton keresztül.
A probléma: azt vettem észre, hogy el "vannak akadva" a mentések. Ahonnan érkeznek, ott csak teker a csík, hogy folyamatban van. NAS-on látom, hogy pár MB már megérkezett. De pl most aktuális egyik mentésem ekkor indult el: 01:34 AM, és kb 300MB méretű. Most pár perce még nem ért át. Viszont elindítottam a routeren egy PacketSniffer-t az ftp portjára leszűrve és pár pillanat múlva megindult a forgalom. És ugyanez volt pl 20GB-os mentéssel. Amíg megy a PacketSniffer, addig jönnek az adatok, amint megállítom, lassan az adafolyam is leáll... De ha bekapcsolva hagyom a háttérben, akkor pikk-pakk lejön a 20GB-os mentés is.
Mi okozhatja ezt?
Beállítások: https://codefile.io/f/ZQVj4gFbKw
(most úgy működik a dolog jó ideje, hogy nonstop bekapcsolva hagyom a Mikrotik PacketSniffer-t, és disconnect-el lépek ki a Mikrotik-ről...)
-
ekkold
Topikgazda
válasz
Tamarel
#23931
üzenetére
Hasonló logikával csináltam én is. Ezek szerint tényleg a fasttrack-al akadhat össze. Az az érdekes, hogy ha csak egy sima routing rulest hozok létre akkor simán megy - de most már értem miért: mert olyankor nem kell külön megjelölni a sem a kapcsolatot sem a routingot. Köszönöm mindenkinek! Cserébe feltettem egy kis érdekességet a weblapomra mikrotik témában...
-
Tamarel
senior tag
válasz
ekkold
#23929
üzenetére
Ezekkel a szabályokkal csinálok ilyesmit, vpn-en kívül tartani meghatározott forgalmat.
Az első mangle a kimenő forgalom megjelölése, a második a bejövő irányból felépülő eset.
Minden szabály elől legyen./ip firewall filter
add action=accept chain=forward comment="no-vpn no fasttrack" connection-mark=no-vpn connection-state=established,related/ip firewall mangle
add action=mark-connection chain=prerouting dst-address-list=no-vpn in-interface-list=LAN new-connection-mark=no-vpn
add action=mark-connection chain=prerouting dst-port=5510 in-interface-list=WAN new-connection-mark=no-vpn protocol=tcp
add action=mark-routing chain=prerouting connection-mark=no-vpn new-routing-mark=no-vpn passthrough=no protocol=tcp/routing rule
add action=lookup-only-in-table comment=no-vpn disabled=no routing-mark=no-vpn table=main -
#23930
lionhearted
őstag
ekkold
#23929
válasz
ekkold
#23929
üzenetére
Kb 1 hete futottam bele ugyanebbe.
Ha jól értelmeztem az a mögöttes probléma, hogy a routing mark nem jól működik együtt fasttrackkel (gondolom neked is aktív ).
A feloldásra pedig azt találtam, hogy kell mindkettő szabály a mangle-be, de még nem volt időm tesztelni:/ip firewall mangleadd connection-state=new dst-address=10.10.0.0/16 chain=prerouting action=mark-connection new-connection-mark=vpn1 passthrough=yesadd chain=prerouting connection-mark=vpn1 in-interface-list=LAN action=mark-routing new-routing-mark=to_vpn1 passthrough=no/ip firewall filteradd action=fasttrack-connection chain=forward connection-state=established,related connection-mark=no-mark -
ekkold
Topikgazda
Újabb kérdésem merült fel az előzővel kapcsolatban:
Megpróbáltam routing mark-al szabállyal megjelölni az adott végpont csomagjait, és itt kiválasztottam a létrehozott második routing táblát. Elvileg így is kellene működnie (külön routing rules nélkül is) ha jól gondolom. A gyakorlatban viszont nem megy vagy csak hihetetlenül lassan. A régebbi RouterOS-ben eleve ilyen csomag megjelöléssel kellett megoldani ilyesmit, és nem volt több routing tábla. Mi lehet a gond?
A csomag megjelőléses módszenek az lenne az előnye, hogy ahhoz lehetne pl. IP listát rendelni később. -
mrots
junior tag
válasz
ekkold
#23925
üzenetére
Minden halozatomban van ilyen, mert mindenhol igenye volt a csaladnak erre.
Szerintem a kerdesnek nem lenyeges resze, hogy a wireguard-e a kapcsolat, ez csak egy technikai reszlet. Altalanossagban a lepesek a kovetkezoek:
1 a helyi halozatban mindekninek ugyanaz a default gw, ami a helyi mikrotik
2 a helyi mikrotikban kell egy PBR a kivalasztott forras IP-re, a next hop a tavoli mikrotik
3 a tavoli mikrotiknak ismernie kell a helyi IP cimeket (tudja, hogy merre kell route-olnia)
4 a tavoli mikrotiknak PATolnia is kell, hiszen alapesetben valoszinuleg csak a sajat helyi halozatara PATolA legkonnyebb a 4. Normalis esetben a MASQ szabaly ugy nez ki, hogy forras IP cim legyen a helyi halozat tartomanya, outbound interfesz legyen az amin a kapcsolat az internet fele kilep, action masquerade. Duplikald meg a szabalyt, a forras IP cim az a /32 lesz, akit kivalasztottal a tuloldalon, minden mas ugyanaz.
A masodik legkonnyebb a 3. Egyszeruen egy /32 route-ot fel kell vegyel a tavoli mikrotikon (aki kilepteti a kapcsolatot) ami a helyi mikrotik fele mutat (ahol a kliens valojaban talalhato). Nyilvan a route a wireguard-ba fog mutatni.
Ha szoros tuzfal szabalyaid vannak, akkor elkepzelheto, hogy modositanod kell ezeken is, hogy a forgalom a ket mikrotik kozott kozlekedni tudjon.
A tobbit pedig kronologiailag. Tehat 1. valoszinuleg adott, DHCP oszt egy gw-t ami a helyi mikrotik LAN interfesze.
Marad a 2. En elsokent felvennek egy uj routing tablat. Routing / Tables, +, adj neki nevet, es legyen FIB is. Ezt a routing tablat fogja hasznalni az az egy vegpontod.
Koveetkezo lepesben ebbe az uj routing tablaba vegyel fel egy darab route bejegyzest: IP / Route, +. a cel a 0.0.0.0/0, a gateway a tavoli mikrotik wireguard cime, a routing table mezonel pedig valaszd ki az uj routing tablat amit letrehoztal.
Ez utan a route tabladban ket default gateway bejegyzes lesz. Az egyik amit eddig is hasznaltal, a main tablaban, a masik amit most vittel fel az uj tablaba, ezt meg nem hasznalja senki.
Az utolso lepes, egy routing szabaly felvetele: Routing / Rules, +. A forras cim legyen az az egy host akinek masfele kell mennie, az action legyen 'lookup only in table', a table pedig legyen az uj tabla amit most hoztal letre.
Ennyi. Ugyelned kell, hogy ha a tuzfal szabalyok tul szigoruak, akkor mindket oldalon at kell engedned a legitim forgalmat ami eddig nem volt, valamint a forras oldalon, ahol a kivetelezett egy darab vegpont van, ha tul laza a PAT szabaly, akkor ellenorizd, hogy erre az egy hostra ne vonatkozzon cimforditas. Mivel a PAT szabaly resze a kimeno interfesz is, ennek a hostnak pedig mar nem ez lesz a kimeno interfesze (hanem a wireguard) elvileg az eddigi PAT szabaly nem fog ra mar vonatkozni, de ellenorizd.
-
ekkold
Topikgazda
Adott két mikrotik router a netre csatlakoztatva (publikus IP-vel) amelyek között van egy működő wireguard kapcsolat (192.168.111.1 - 192.168.111.2 helyi címekkel). Az egyik routeren az egyik kliens (mondjuk 192.168.0.2 címmel) esetében azt szeretném beállítani, hogy a wg kapcsolaton keresztül a másik router publikus -ipjén keresztül kapjon internetet.
Hogyha a kliens csatlakozik közvetlenül WG-vel a másik routerre akkor ez működik is, de hogyan lehet ezt a legegyszerűbben a mikrotiken megoldani. Régebben valahogy megoldottam hasonlót, de közben változott pár dolog, ahogy nézem talán külön routing táblát kell létrehozni ehhez a klienshez. -
mrots
junior tag
válasz
yodee_
#23919
üzenetére
"*) lte - fixed R11e-LTE no traffic flow when modem with older firmware version is used;"
Ezt kiszurtam en is, koszonom, hogy bemasoltad ide. Ugyan nem pontosan passzol, ez R11e-LTE -rol szol, a kerdeses eszkozben R11e-LTE6 van, de egye fene. 7.16-hoz irtak, en 7.11 -en futok jelenleg. Ez egy nagy ugras tavolrol. Ugy latom nem vagyok egyedul akik nem biznak a ROS upgrade-ben. Viszont a bug azt mondja a bug akkor letezik, ha regi firmware verzio volt. Nem specifikalja mi a regi, de a firmware frissitest kisebb rizikonak ereztem, mint a ROS frissitest, tavolrol, ugyhogy most igy fut:
/interface/lte/firmware-upgrade lte1
installed: R11e-LTE6_V038
latest: R11e-LTE6_V038Ez, illetve atmenetileg betettem egy 12 orankenti feltetel nelkuli ujraindulast. Meglatjuk par napig, hogy valtozik-e valami. Ha igy stabil, akkor 24 orankenti ujrainditas, utana meglatom.
-
#23921
mrots
junior tag
lionhearted
#23914
mrots
junior tag
válasz
lionhearted
#23914
üzenetére
"Kritikus" rendszert építettél egy SPoF-re. Ha elpukkan a tápegység, akkor mi van?
Idezojelbe tetted, szoval nem tudom pontosan mit ertesz alatta. A rendszer nem kritikus, csak par kamera aminek a kepe nezheto tavolrol. Mi tortenik ha a kamerak kepe nem nezheto? Igazabol semmi. Ennyit a kritikussagrol. Ha valoban kritikus lett volna, akkor nem egy es nem mikrotik eszkozt teszek oda
" mint írtam voltak rá panaszok, konkrétan az LTE modemre is."
A konkretumok erdekesek lehetnek, de azt nem irtal. Ugy altalanossagban en is olvastam sok panaszt, de nem tartottam oket relevansnak. Lehet, hogy a rossz helyen olvastam?"nem mi írjuk, nem is tudunk adni changelogot"
Talan felreerthetoen fogalmaztam, vagy talan nem ment at amit mondtam. Nem azt vartam, hogy itt valaki irjon change logot, hanem azt, hogy segitsen valaki megtalalni. A release notes-ot megtalalom a ROS-hoz, de a firmware-hez nem. En ahhoz vagyok szokva, hogy a gyarto aminek a termeket hasznalom ha kihoz egy uj szoftvert, megmondja mi valtozik benne. Ezt kerestem es segitseget kertem abban, hogy hol talalom a change logot." RSRP: nem összetévesztendő az RSSI-vel"
Nyilvan en osszekevertem, de koszonom a magyarazatot."a workaround meg már csak ilyen, melós, szenvedős"
nincs ezzel semmi baj, csak nem erre szamitottam, ennyi. -
#23917
lionhearted
őstag
Reggie0
#23916
-
#23916
Reggie0
félisten
lionhearted
#23914
Reggie0
félisten
válasz
lionhearted
#23914
üzenetére
Amugy en nagyon sok ilyen helyzetben voltam(es vagyok) csak sajat eszkozunk van, nem mikrotik
-
Reggie0
félisten
-
#23914
lionhearted
őstag
mrots
#23910
"De pontosan azert tettem mikrotik eszkozt az LTE vegere, hogy ne kelljen ilyen barkacsolasokat csinalnom."
"- a netwatch mukodese: pontosan ez az amire szuksegem volt, csak valoszinuleg nem tudtam megfogalmazni rendesen."
...változik a probléma?
"Kritikus" rendszert építettél egy SPoF-re. Ha elpukkan a tápegység, akkor mi van?-HW hiba: mint írtam voltak rá panaszok, konkrétan az LTE modemre is. Van egy LTAP minim, napokat ment mellettem, beszereltem az autóba és kb sose ment (néha ment csak), nem látta az LTE modemet (nem Tikes modem). Persze én is nézelődhettem volna akármerre, aztán csak kiderült, mellettem stabil 5V-ot kapott (talán fölötte is?!), az autóban pedig nem. Átépítettem 9Vosra a tápellátását, és megy, stabilan. Varázslat vagy tudomány? Logban nem köpte ki, de a neten voltak ráutaló posztok.
-FW hiba: nem mi írjuk, nem is tudunk adni changelogot. Van egy mondás, hogy ha nem romlott el, ne javítsd meg. Ez elromlott, de lehet már valaki megjavította. Mi mondjuk meg? Miből?
Küldjél be support ticketet az MT-nek.- RSRP: nem összetévesztendő az RSSI-vel (nálad -72dBm volt), a -103dBm nem vészes, van -110 körül is "élet". Ezek a bejövő jelerősséget mutatják, a "minőségi" mutató az RSRQ, ami nálad -7.5dB egy teljesen jó jelet mutat.
Senki sincs pontosan ugyanabban a helyzetben amiben te, a workaround meg már csak ilyen, melós, szenvedős.
-
Reggie0
félisten
Biztos meg lehet oldani, csak ki kell talalni a scriptet.
Arra is gondoltam, hogy felhuzhatsz egy openvpn tunnelt is, amit aztan nem hasznalsz, viszont annak a security profile-ban meg lehet adni up es down scriptet. Igy ha lemegy az openvpn kapcsolat akkor ujra lehet inditani az lte interfeszt.
Viszont ez is csak egyszer fut le, amikor lemegy az interfesz, ha nem jon fel akkor nem fogja rendszeresen ujraprobalni. -
mrots
junior tag
válasz
Reggie0
#23906
üzenetére
Ezt nem ketlem, hogy a legtobb cucc hatterben kezeli, csak itt eppen nem kezeli. Egy masik eszkoz:
gw#sho logging | i Cellular0/1/0
Feb 17 09:00:37.835: %LINK-5-CHANGED: Interface Cellular0/1/0, changed state to reset
Feb 17 09:00:38.835: %LINEPROTO-5-UPDOWN: Line protocol on Interface Cellular0/1/0, changed state to down
Feb 17 09:00:42.835: %LINK-3-UPDOWN: Interface Cellular0/1/0, changed state to down
Feb 17 09:03:46.178: %LINK-3-UPDOWN: Interface Cellular0/1/0, changed state to up
Feb 17 09:03:47.178: %LINEPROTO-5-UPDOWN: Line protocol on Interface Cellular0/1/0, changed state to up
Feb 17 15:30:38.803: %LINK-5-CHANGED: Interface Cellular0/1/0, changed state to reset
Feb 17 15:30:39.803: %LINEPROTO-5-UPDOWN: Line protocol on Interface Cellular0/1/0, changed state to down
Feb 17 15:30:43.803: %LINK-3-UPDOWN: Interface Cellular0/1/0, changed state to down
Feb 17 15:31:46.504: %LINK-3-UPDOWN: Interface Cellular0/1/0, changed state to up
Feb 17 15:31:47.504: %LINEPROTO-5-UPDOWN: Line protocol on Interface Cellular0/1/0, changed state to up
Feb 17 22:00:38.486: %LINK-5-CHANGED: Interface Cellular0/1/0, changed state to reset
Feb 17 22:00:39.486: %LINEPROTO-5-UPDOWN: Line protocol on Interface Cellular0/1/0, changed state to down
Feb 17 22:00:43.486: %LINK-3-UPDOWN: Interface Cellular0/1/0, changed state to down
Feb 17 22:03:46.848: %LINK-3-UPDOWN: Interface Cellular0/1/0, changed state to up
Feb 17 22:03:47.848: %LINEPROTO-5-UPDOWN: Line protocol on Interface Cellular0/1/0, changed state to upEzzel peldaul tudok elni. Hat - het orankent egy-harom percre leszakad es visszajon. Mert visszajon. Azt gondoltam tud hasonlot a mikrotik es ezert gondoltam:
[root@oob] > interface/lte/monitor lte1 once without-paging
[...]
session-uptime: 5h38m13s -
#23910
mrots
junior tag
lionhearted
#23903
mrots
junior tag
válasz
lionhearted
#23903
üzenetére
Elhiszem, ha amit irok ezt a latszatot kelti. Hadd vilagitsam meg, miert nem csak vagdalkozas szerintem amit irok:
- hardver hiba: ez kb az utolso utani lehetoseg, amikor mar semmilyen megoldas nem mukodik. ez nagyjabol az a kategoria, hogy fogalmam sincs de akkor mondjuk ra, hogy hw hiba, mert ugysem lehet bebizonyitani, hogy az vagy sem. Mindaddig, amig barmilyen modon lehet szoftveresen elore jutni, ez az opcio nem jatszik, hiszen mielott leraktam az eszkozt oda ahova, ket hetig nyuztam ugy, hogy mellettem volt es semmi baja. Szoval egyelore ez a hardver hiba ez nem tobb, mint egy vaktaban lott tipp.
- firmware hiba: megint csak azt mondom, hogy ket hetig mukodott mellettem. Igen, idonkent leszakadt, ujra csatlakozott - ezt be lehet tudni a mobil terero sajatjanak, ha idonkent megtortenik. Nem hinnem, hogy a mostani helyen lett hirtelen hibas a modem firmware. Az, aki javasolta ezt, nem adott linket changelog -ra, hogy a ket fw verzio kozott mi a kulonbseg, en sem talaltam ilyet sehol. Vaktaban nem upgrade-elek firmware-t, mert mint irtam, az eszkoz 1500 km-re van tolem. Ha nem sikerul, vagy offline meg valami entert kene nyomni, vagy megerositeni valamit, az nem fog menni tavolrol, mivel ha jol tudom a fw frissites OTA. Legalabbis egyet frissitettem, mielott letelepitesre kerult. Szoval mivel a riziko nagy, a benefit meg kicsi (igazabol senki se tudja, mi a kulonbseg a ket verzio kozott, szoval tudomanyos alap nelkuli a javaslat) ezert jelenleg nem opcio. De meg mindig jobb, mint a hw hiba tipp.
- mobil terero: most, hogy tobben is irtak ezt a 103-mat, illetve osszehasonlitottam mas lerakott eszkozzel kezdem atertekelni a dolgot. Eddig azert huztam ki, mint potencialis hibaforras, mert a helyszinen 30-50 mbit kozott ment. Tobb sim kartyaval probaltam, huzamosabb ideig egy T kartya volt benne aminek botranyos terereje volt, at kellett helyezni de meg azzal is stabilan ment par napot. Az eszkozt athelyezni nem tudom, szoval az egyetlen opcio: rakenyszeriteni egy masik mobilszolgaltato halozatara, hatha az jobb. De ez is borderline ugyanaz a riziko, mint a fw frissites: ha nem csatlakozik, vagy az rosszabb, akkor vegleg kizarom magam, tehat kb ez a javaslat is olyan, hogy most eppen nem tudok vele mit kezdeni
- a netwatch mukodese: pontosan ez az amire szuksegem volt, csak valoszinuleg nem tudtam megfogalmazni rendesen. Amikor lattam, hogy instabil, akkor a netwatch tunt kezenfekvo megoldasnak, de mint most mas megvilagitotta, a korlatai miatt nem teljesen alkalmas arra, amire hasznalni akarom. Ez momentan a legjobb utvonal elore, mivel kizarni nem tudom magam tavolrol, viszont a helyzethez alkalmazkodni tud egy jol megirt script es ki tudja hozni a helyzetbol a maximumot.
Nem azzal van bajom, ha fw-t kell frissiteni, vagy hw-t kell cserelni. Azzal van bajom, ha minden tudomanyos alap vagy teny nelkul kellene valamit csinalni ugy, hogy a kovetkezmenyeket a javaslat nem veszi figyelembe.
-
Reggie0
félisten
Amugy baromi sok problema van a mobilnettel, csak a legtobb cucc hatterben kezeli. Nem csak az LTE, hanem a normal is rendszeresen ledobodik. A szolgaltato nem szereti, ha tul sokaig online valami, de szamit a prioritas is(pl. ha kifejezetten iot kartyat veszel akkor hatra lesz sorolva a normal felhasznalokhoz kepest), bejatszik a tornyok kozotti load balance(azert dobjak le, hogy masikra atmenjen).
-
Ebben nem jó a Mikrotik. Hogy más gyártó hogyan oldja meg,titokban újraindul és nem is tudsz róla,de működik. Az más téma.
Ha más márka vált be vegyél olyat. Sajnos ez ilyen. De olcsón,ilyen nyereségű lte eszköz nem nagyon kapsz ilyen tudással. Ebben ez a jó.
Lte timeout: A szolgáltató is azt csinál,amit akar. Ha akarja letiltja a simet,mert nem tetszik neki. De nem fogja nyilvánosan megmondani az indokokat. -
#23903
lionhearted
őstag
mrots
#23901
Van amúgy célja ennek a sorozatos kiakadásnak? Két nagyon valószínű dolog lehet a háttérben: hardver hiba, volt néhány panasz anno a Tik saját LTE modemjére hosszabb távon; FW hiba. Utóbbit nem frissíted, előbbiről elvből nem hallasz.
Mit szeretnél ezek után a topik lakóktól? Csak kendácsolni lehet. -
mrots
junior tag
válasz
grabber
#23899
üzenetére
Szia,
ne erts felre, halas vagyok az otletert, illetve a tanacsert. De pontosan azert tettem mikrotik eszkozt az LTE vegere, hogy ne kelljen ilyen barkacsolasokat csinalnom. Mar a napi 1 reboot is feszegeti a hatarokat. Ettol meg a tenda is jobb volt, ami eveken keresztul logottt az LTE-n ujrainditas vagy barmi nelkul es teljesen jol mukodott.
Miert szedtem ki? Mert tavolrol nem menedzselheto, kellett valami ami VPN kepes. Azt gondoltam, hogy egy mikrotik van olyan szinten, mint egy huszezer forintos szappantarto.
hálásan köszi
Viszont szerintem ezen a vonalon olvasgass: Linux, DRBD, Heartbeat, High Availability Cluster. Itt első körben ami érdekes lesz majd neked a Linux alapon DRBD cluster.
Új hozzászólás Aktív témák
Hirdetés
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged