A munkahelyemen érdekes hálózati problémánk van már jó ideje, router csere után is fennáll.
Két telephelyünk van:
- A: DIGI 1000 Mbit / sec., fix IP, TUF-AX4200 router, előtte Xiaomi MiWiFi 3G v1, OpenWrt 23.05.3
- B: Vodafone (volt UPC) 300 mbit / sec., fix IP, TUF-AX4200 router, előtte Ubiquiti Routerstation Pro, OpenWrt 23.05.3
És van a production szerverünk, Telekom hosting, ezen megy a webáruház, meg az admin oldalak.
Mindkét router-t el lehet érni kívülről, erős jelszóval vannak védve:
A: http://A.hu:55555
B: http://B.hu:55555
Azért, hogy minél hamarabb értesüljünk róla, ha valahol megszakad a kapcsolat, a production szerveren fut egy script percenként, ami lehívja a két fenti url-t, és ha nem az OpenWrt login oldal jön le, akkor küld egy Telegram alert-et, hogy az adott helyen megállt a net.
Az A telephelyen van egy dev szerver is, ezen fut a céges chat, meg egy Voip PBX szerver, ezen meg a telefonok.
Többször előfordul, hogy mindkét telephelyen rendben van a net, nem szól a percenként futó script, hogy baj lenne, mégis több percig nem elérhető a B telephelyről a céges chat, meg a telefonok, vagyis az A telephely. Ez szinte naponta előfordul, de mindig csak munkaidőben, este, éjszaka soha. Csináltam egy olyan harmadik ellenőrző script-et is, ami az A telephelyen lévő dev szerveren fut és a B telephely router login url-t hívja meg, így azonnal értesülünk ha megállt a két telephely között a kapcsolat, nem csak akkor, amikor átszólnak hogy nem megy a chat, ill. a telefon.
A megállások pár perce alatt minden más kapcsolat mindkét telephelyen hibátlanul, megfelelő sebességgel működik, bármilyen weboldal bejön, beleértve a production szerveren lévőket is, de a teszt parancsom:
curl -v http://B.hu:55555
A telephelyről nem megy, minden más helyről igen. Ami nagyon érdekes, hogy ilyenkor a ping az A telephelyről a B felé megy! Ha a B router WAN interface-t restartolom, semmi változás, nem áll helyre a kapcsolat A felé. Ha az A router WAN interface-t restartolom, akkor azonnal helyreáll a két telephely között a kapcsolat. Ha kézzel nem restartolok, pár perc alatt mindig megjavul magától a kapcsolat.
Mindkét router log-ja át van irányítva file-ba, ill. log szerverre, a leállások alatt semmi rendellenes nem látható. Ellenőriztem a megállásaok ideje alatt a kapcsolatok számát a router-eken, bőven nincsenek kimaxolva.
Mivel viszont a ping megy a leállások alatt is, ezért arra gondoltam, hogy csak a TCP áll meg. Ezért osszedobtam ESP-re nodemcu alatt egy UDP szervert, ami hulla primitív dolgot csinál: a bejövő adatot (ami egy szám) megszorozza 17-el, majd visszaküldi. Ezt a B telephelyen üzemeltem be és a router-en csak az UDP protokoll és csak az A telephely IP-jéről van forward-al beengedve rá. Az A telephelyen pedig a dev szerverre csináltam plusz egy olyan tesztet, ami percenként fut, kitalál egy véletlen számot, ezt elküldi a B telephely IP-jére a kinyitott UDP portra, majd a visszajövő adatot ellenőrzi, hogy a bejövő szám 17-szerese-e, ha nem akkor jön az alert.
És láss csodát, amikor jönnek az alert-ek, hogy nem mennek a TCP tesztek, akkor az UDP vígan megy! Vagyis csak a TCP van ilyenkor blokkolva, az UDP nem.
Van valami ötletetek, hogy mi lehet az oka ennek az anomáliának, vagy mit nézzek, loggoljak, ellenőrizzek?
Hozzászólások
"A" routeren a network-firewall-wan-edit, ott az "MSS clamping" be van kapcsolva?
nekem is volt hasonló problémám, amit ez oldott meg:
https://hup.hu/comment/2783021#comment-2783021
De ez egyből előjött amint DIGI-re váltottam.
zrubi.hu
Igen.
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
Kellene egy packet capture, aztán wireshark-ban meg lehet nézni. Ha lenne a forrásról és a célról is, az még jobb lenne.
Az mtr tud tcp-vel is csinálni trace-t, amikor nem megy, akkor érdemes megnézni az adott portra.
"Sose a gép a hülye."
mtu?
ha a ping meg a par byte-os UDP ok, de a nagy csomagos TCP rossz, efele indulnek eloszor.
Override MTU nincs beállítva.
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
Ha a szolgáltató nem 1500-at ajánl ki, akkor beállítani mindkét oldalon a minimumot.
https://naszta.hu
amit írtam lentebb (wireguard) az ugye az ilyesmit is megoldja helyből
Gábriel Ákos
Rémlik az OpenWRT fórumról valami hw offloading bug. Próbáld meg kikapcsolni a hw/sw offloadingot, vagy próbálj meg egy snapshot OpenWRT verziót.
Valaki torrentezik és betelik a conntrack tábla? :D
Könnyebb lenne az életed, ha pl. Mikrotikra váltanál.
Ez nem fog megtörténni. Amúgy meg nem olyan hülye kérdést tettem fel, hogy mire váltsak, aminél majd nem lesz ilyen hiba.
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
Gondolkodtam egy darabig, írjak-e ide erre, de mint látható, abban maradtam magammal, hogy írjak.
Van egy production rendszered, amit két, home gaming kategóriás szappantartóval kötsz össze, átflesselt barkács szoftverrel. Ez az "izé" ráadásul valamennyi ideje rosszul működik, hosszasan tesztelted, nem hirtelen jött elváltozás.
Feldobja valaki, hogy meg kellene nézni valami ilyesmi feladatra gyártott eszközzel - ami egy valid teszt lenne a megoldás felé vezető úton - erre odavágod, hogy ilyen biztosan nem lesz, és nem azt kérdezted, mivel nem lesz ez a hiba.
Hát, olyanod már van, amivel van ez a hiba, így lehet erről nincs is mit tovább beszélni...
Nyilvánvalóan az OpenWRT-ben áll meg valami szoftveresen, ha egy interfész újraindítás vagy timeout letelés tovább tudja lökni. Most valami varázs ráolvasást vársz OpenWRT gurutól, hogy milyen titkos konfig módosítással lehet ezt elkerülni? Az OpenWRT bugot szeretnéd lenyomozni, vagy a kommunikációs problémát megoldani. Az irány kijelölése után majd a megfelelő emberek írnak, a többiek meg nem.
Be kell tenni rendes router-t legalább tesztelni. Ha úgy hibátlan, akkor lehet variálni, hogy OpenWRT-t cserélgetsz, vagy más modellre/OS-re váltasz.
Nem tudom ismered-e az OpenWrt-t, az "átflesselt barkács szoftver" megnyilvánulásodból úgy gondolom nem. Az általam használt ASUS TUF-AX4200 router a gyári stock firmware-el lehet, hogy "home gaming kategóriás szappantartó", de miután felkerül rá OpenWrt már teljesen más kategória. És MINDEN AMIRE SZÜKSÉGÜNK VAN kifogástalanul megy vele, VLAN, OpenVpn, WIFI, stb. Csak ez az egy fent vázolt hiba áll fenn. Szerencsére ez nem egy világvége probléma, kellemetlen ugyan, de nem akkora dráma. Nyilván emiatt az egy probléma miatt nem fogok váltani egy számomra ismeretlen, zárt forrású, ki tudja milyen hátsókapukat tartalmazó és a hárombetűsöknek jelentgető eszközre.
De kurvára nem erre vontakozott a kérdésem.
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
firmware-rel
Nem értem, miért húzod fel magad és vulgárisan válaszolsz, baromira semmi köze a problémádhoz, mégis szánt rá egy kis időt, inkább köszönd meg.
Főleg, hogy még simán kiderülhet: kérdéses router+openwrt mégis szappantartó kategória (nem mintha a Mikrotikkel nem lennének ilyen-olyan problémák). Esetleg nézd meg OPNSense-szel (bár ahhoz másik hardver kell), akkor nem kell rettegned a hárombetűsöktől.
És ha esetleg egy nem OpenWrt eszközzel nem jönne elő a probléma, akkor attól már tudni fogjuk, hogy PONTOSAN mi is az OpenWrt baja, vagy csak egyszerűen szar és kész?
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
Mi ez a nagy szerelem az openwrt fele egyebkent?
Ez
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
Még az is kiderülhet, hogy nem abban a van a probléma, mert ugyanúgy előjön a hiba, és az a hibának vélt jelenség valami másnak a következménye, ami valójában a hiba.
Ha mással nem jön elő, akkor még mindig két esélyes: openwrt + másik hardverrel mi a helyzet, de neked kell tudnod, mennyire erős a szerelem és erős a kapcsolat: dolgozol rajta és a mélyére ásol, vele élsz vagy lecseréled.
a leiras alapjan eleg gyanus, hogy a dev szerver korul van valami kaki
Ezt miból gondolod?
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
leirasod alapjan,
* B oldalon minden fasza
* A oldalon is minden fasza
* A oldal dev szerveren futo cuccokkal van neha gond, de mellette minden mas fasza
* A oldal a szinten dev szerveren futo curl B:xxxx hivassal van gond, de mellette minden mas fasza
regi es uj szappantartokkal is ugyanez volt a helyzet, egyedul az OWRT kozos, de az B oldalon nem okoz semmi gondot
ez csak egy tipp, de,
* A oldal digi gpon es pppoe?
* B oldal voda(UPC) docsis es dhcp-vel?
Valami félreértettél. A probléma az, hogy néha pár percre az A és B oldal nem látja egymást TCP-vel. B-ből nem érik el az A-n futó chat-et, valamint a voip telefonokat, A-ból nem érem el a B router-ét és fordítva, de minden más irányból elérhető az A és B oldal és A-ból és B-ből is minden más elérhető.
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
A chat, voip es a teszted is a dev szerverrol fut nem?
A VOIP egy teljesen külön szerver az A telephelyen.
A dev szerveren csak a chat fut, meg a tesztem, ami egy pár soros PHP, lehívja a B router url-ét és nézi, hogy az a html jön-e le, aminek lennie kell. Ha nem, akkor Telegram alert.
Nem gondolom, hogy a dev szerver a ludas, mert amikor megáll a két telephely között a kapcsolat, ki szoktam próbálni egy szintén az A telephelyen lévő harmadik szerverről is a fenti teszteket, az eredmény pedig ugyanaz: B telephely felé TCP nem megy, UDP megy.
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
Lehet, hogy a DIGI, vagy a Vodafone hibája. Én már kifogytam az ötletekből, azért kérdeztem hogy mit javasoltok, mit nézzek a JELENLEGI rendszerrel, nem mással. Mivel ezek napi szinten élesben vannak használva, nem tehetem meg, hogy Ha esetleg egyszer kiderül, hogy mi okozza és netán OpenWrt-ben van a hiba, hiszen az sem tökéletes, akkor biztos vagyok benne, hogy van rá megoldás. Lehet, hogy csak valami apró config változtatás.
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
Ilyenkor már nem ötlet kell. Feljebb írtam, hogy csinálj egy capture-t. Állítsd be, hogy a szakadó session IP-it és a protokollt figyelje egyész nap. Aztán, ha egyszer elkapja, akkor ott már lehet látni valamit.
Felteszem nem 7/24-es a cég, hogy ne lehetne egy szabad hétvégét ellőni arra, hogy ideiglenesen kipattintod az OpenWrt-t és két Mikoritkkal megnézed, hogy előjön-e a dolog. Nekem régebben telephelyek között volt ilyen openwrt-t szappantartós megoldás (TPLink 1043ND asszem) ott is volt olyan hogy 20-28 naponta szépen lassan eltűnt a TCP, de az UDP maradt. Mi akkor onnan vettük észre a dolgot, hogy a kamerák jele, amely folyamatosan volt átadva a telephelyekről a központba, szépen leakadt. Váltás volt Mikrotikra és az egész jelenség eltűnt.
Szóval, ha nem 7/24 a cég, akkor nyugodtan szánj rá egy hétvégét, hogy megnézd, másik eszközzel mi van.
Ha meg 7/24, akkor meg azt se felejtsük el, hogy ha ilyen jelenségek vannak, akkor csak kellene egy B terv, hogy mi van akkor ha nem csak pár másodperces kiesés lenne.
Már csak azért is, mert jelenleg fogalmad sincs, hogy a rendszered melyik komponense okozza a hibát. Lehet az ISP, ahogy mondod ... ezt erősen lokalizálni kellene. Ha a végén kiderül, hogy az OpenWrt a ludas, akkor legalább tudod, hogy azt kell gányolnod. Addig meg csak lövöldözöl össze-vissza ...
Jól gondolod, nem 7/24 a cég, de ahogy a nyitó hozzászólásban is írtam, csak munkaidőben fordul elő a hiba, tehát nem sokra mennék egy hétvégi másik router-el való teszteléssel. A másik az, hogy nem szeretnék ezért beruházni két eszközre, ami csak arra kell, hogy kiderítsem a hibát, no meg érteni is kéne ezekhez az új eszközökhöz.
Mivel csak munkaidőben van a hiba, már az is eszembe jutott, hogy esetleg a B telephelyen valakinek meg van fertőzve a gépe és támadja az A telephely router-ét, mire az letiltja pár percre. Viszont ennek gondolom lenne nyoma a log-ban, de nincs.
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
Ha csak alkalmazottaknál fordul elő, akkor lehet alkalmazottakat kellene cserélgetni ... :D
Ha van szabad hétvége, akkor viszont fel tudsz állítani egy olyan tesztkörnyezetet, ahol a két telephely között rendes terhelést nyomsz át (rengeteg kapcsolat, rengeteg sávszél). Aztán ha előjön a hiba - munkavállalók nélkül - akkor tudsz játszani azzal, hogy a túl sok sávszél használat vagy a sok kapcsolat vagy a kettő egyszerre triggereli a hibát.
Magánvélemény: nem azért kellene beruházni, hogy tesztelj, hanem hogy ha a teszten átmegy, akkor a szappantartók mennének archívumba. Sokkal több időt elszöszölsz itt a keresgéléssel, mintha raknál be 2 mikrotik-et, megtanulnád konfigolni őket és mennének sokáig maguktól.
Te már látatlanban borítékolod, hogy az OpenWrt helyrehozhatatlan hibája és nem oldható meg egy egyszerű beállítás változtatással, hanem le kell cserélni mindkettőt, mert a csodabalzsam mikrotik az hibátlan. És ha nem? Ha ugyanúgy előjön a probléma, mert pl. a szolgáltató hibája. Vagy előjön más hiba? Akkor kidobott pénz. De hangsúlyozom még egyszer, nem világvége probléma ez, minden más hibátlanul megy. Ezért nem fogok beruházni, inkább agyalok rajta, kérdezősködök, ha nem oldódik meg, akkor így marad.
Legfeljebb majd írok egy script-et, hogy ha elmegy a két telephely között a kapcsolat, akkor nyom egy WAN restartot az A router-en! :) Lapát föld a szarra. Problem solved!
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
Általában az a tapasztalat, hogy valami vagy megy, van nem megy, de ha néha nem megy, akkor valójában nem megy.
Legalábbis én úgy érzem, hogy nem konfigurációs hiba az ilyen random kiesés.
De mindegy, ne ruházz be. Vegyél két PC-t (az csak van már ott kallódóban, nem?) rakjál rá OpenWrt-t és hajrá!
Nem RouterOS-t akartál írni?
Nem.
Ha meg van győződve arról, hogy konfig hiba és nem akar korrekt eszközökbe fektetni, akkor próbálja meg ugyanazt a konfigot más hardverrel.
https://openwrt.org/docs/guide-user/installation/openwrt_x86
Valójáben problem nem solved, hanem lapát föld a szarra. Alapvetően ez az attitűd ami miatt ebbe a szituba jutottál és ezek a szituk addig nem is fognak változni amíg az attitűd nem változik.
Lásd még Dunning-Kruger görbe teteje.
Gábriel Ákos
Láttad a smile-t, a lapát föld a szarra előtti mondatom végén? Nem volt ám véletlen, elrettentő példaként írtam!
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
"Jól gondolod, nem 7/24 a cég, de ahogy a nyitó hozzászólásban is írtam, csak munkaidőben fordul elő a hiba, tehát nem sokra mennék egy hétvégi másik router-el való teszteléssel"
Tehát nagy az esélye, hogy a hálózati forgalom függvényében jön elő a probléma. Ilyenkor érdemes az aktív session-ök számát, a használt sávszélességet, a conntrack tábla méretét logolni kellő sűrűséggel, és ezeket az adatokat összevetni a leszakadások időpontjával.
Értem én, hogy még a SoC is gyakran ugyanaz, mint egy kisebb enterspájz router-ben, de azért nem mindegy a SoC hardveres körítése sem. Más kérdés, hogy mondjuk egy Mikrotik eszköz nem olyan sokkal jobb ilyen tekintetben, szerencsére kb pont annyival drágább, amennyivel különb.
Valamint az OpenWRT hardverek sokkal változatosabbak. Még Mikrotik esetén is vannak nagyobb bakik a RouterOS-ben, a Wifi része sem az igazi, pedig pl Wifi esetén ragaszkodnak a Qualcomm-hoz (akkor is, ha van a SoC-ban wifi képesség), vért izzadtak kernel váltásokkal, és a csomagokból is kevesebb van, ehhez képest tényleg azt gondolod, hogy OpenWRT esetén a jelenlegi ToH-ban szereplő mind a 2368 eszköz rendesen le lesz tesztelve egy új verziónál az összes opkg csomaggal egyetemben?
En azt latom, hogy ez a csoda asus kb ugyanannyi mint egy hap-ax3, hol van itt a diff arban?
Alza akciókkor :D, egyébként túl vannak árazva.
Én pl mindig akkor vettem AX53u-t amikor vagy a kis zöld genya, vagy a románok olcsóbban adták (17-18ezer, de más típusokkal is voltak akciók). Most meg ráálltam a Cudy-ra. A Cudy-k lesznek az AP-k a két Asus meg a ptp kapcsolat rádiója. Pont próbálgatom, mennyire lehet openwrt alatt a wifi rádiókat egybekötni a luci-proto-bond-dal, hogy ha megszakad egyik kapcsolat még legyen tartalék. Na hát semennyire :( (vagyis de, broadcast policy, azon át meg egy OpenWRT kapcsolat TAP módban (azon legalább a vlan tagging is megy), még titkosítás nélkül is izzad az mt7621 :D) Az RSTP + gretap viszont úgy néz ki, hogy jól müxik, ha bridgbe rakok két WDS kapcsolatot és telepítem ustp-t.
Ez olyan érv mintha azt mondanád, hogy a "Windows 11 Kernel devek is vért izzadnak a kernel váltásokkal és csomagokból is kevesebb van, ehhez képest tényleg azt gondolod, hogy Linux esetén mind a 12312312 eszköz rendesen le lesz tesztelve egy új verziónál az összes csomaggal egyetemben?"
Valszeg pont a Qualcomm miatt ízzadnak vért egyébként, mert nem tudnak/akarnak olyan kódot írni, ami betehető mainlineba.
Nem is megy rendesen mind a 12312312 eszköz Linux alatt sem :D Régen volt itt az a mondás, hogy Linux alá hw-t venni tudni kell... A Windows-nál meg voltak cikkek, hogy annyira nem mernek nyúlni sem a kernelhez (na jó, most pl rozsdásítják) sem pl a fájlrendszerhez, pedig igény volna rá... Eleve arról megy a sírás, hogy csak a csicsa, a kémkedés meg a többi hülyeség van fejlesztve.
Az asus router egy műanyag szappantartó. Amikor lecseréled a gyári szoftverét, akkor is műanyag szappantartó marad, csak onnantól semmi garancia nincs a működésére.
Ismerem az OpenWRT-t, a Linksys WRT54G és TP-Link TL-WR 1043-as időktől követem (muszájból, ügyfelek miatt; ami ~2010?), mert már akkor is sok home "power" user-t kellett támogatni, akik felrakták, és utána néztek mint hal a szatyorban, hogy beállítani sem tudják annyira sem, mint a gyári szoftvert - ha egyáltalán sikerül eltalálni, mit kell feltenniük és egyáltalán elindult. A mai napig otthoni játszós rendszernek tartom.
Ez a mondvacsinált félelem a zárt forrástól meg már kicsit sok is. Pláne úgy, hogy 1000%-ra veszem, hogy nem nézted végig az OpenWRT forráskódját, és semmilyen módon nem ellenőrizted, hogy a szappantartóra töltött bináris FW valóban abból a forrásból készült és nem tartalmaz semmi egyebet... Amit ugye a módon tehetnél meg, hogy Te magad fordítod le a frissen végignézett forráskódból. Egész valószínűnek tartom, hogy nem ilyen bináris került fel.
A "csak ez az egy hiba" azért nem bagatell, hogy elmúlik a TCP forgalom.
De írhatod tovább az anyázást nyugodtan, a legtöbbünk (OpenWRT hívők sem) tudnak majd többet segíteni, ameddig nem deríted ki, hogy a hardvered és/vagy a szoftvered okozza a hibát, vagy rajtuk kívül álló dolog. De ezt meg csak ideiglenes eszköz cserével tudod biztosra megállapítani.
Természetesen nem magam fordítottam, sőt át sem néztem a forrást, hanem az OpenWrt oldaláról letölthető binárist használom. De a hozzáértők, pl. a fejlesztőik nyilván átnézik a beküldött pull request-eket és nem engednek be akármit. Mivel opensource, ezért nem csak a fejlesztői, hanem BÁRKI észreveheti benne a hibákat, mert meg van rá a lehetőségük. Megbízom bennük, eddig nem volt benne rosszindulatú kód. A másik oldalon annál inkább, hogy csak egyet említsek. Az érvelésed alapján úgy tűnik, szerinted azért jó a zárt forrás, mert a lehetőség sem adott, hogy bárki hozzászóljon.
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
Vicces, amikor két különböző véleményt úgy próbáltok védeni, hogy elvakultan csak a saját oldalról állítotok példákat.
Hadd mutassak valamit a marhabiztonságosnak vélt opensource világodból: https://hup.hu/cikkek/20240330/backdoor-t_talaltak_az_xz_utils_library-…
Többen mondták h. próbáld ki másik eszközzel. Az, hogy kapaszkodsz az owrt-be, meg abba h. a másikhoz nincs hozzáértés, az csak és kizárólag terelés. Egy bizonyos cégméret felett nem ördögtől való megbízni valakit, akinek szélesebb spektrumú ismeretei vannak hálózat témában pl, mert amíg házibarkácsolod ezeket a hobbiroutereket, addig gondolom valami hasznosabbat is csinálhatnál. Szándékosan nem írok gyártót, _másik_ eszközzel tessék kipróbálni, hogy ki lehessen zárni azt h. teljesen máshol van a hiba.
Na ezt szokás megfizetni a gonosz kereskedelmi, closedsource termékekben. Beállítod, általában megy, ha nem akkor meg _vettél_ supportot is.
Én nagyon hiszek a nyílt forrásban! Pontosabban nem állok ki a zárt forrás mellett kizárólagosan.
Ahol a MT-nél nagyobb flexibilitásra/tudásra van szükségem, ott OPNsense-t futtatok a célnak megfelelő eszközön. De ahová költséghatékonyan kell egy megbízható, nagy teljesítményű router, oda viszek MT-et és használom a gyári módon, mert egy OPNsense futtatására alkalmas x64-es CPU-val rendelkező, több Ethernet portos, megbízható eszköz nem feltétlen olcsó.
De jó is volt az ópenszósz dd-wrt is...
Én is hiszek benne, sőt. De pontosan az van amit írsz. Mire ezt a fórumot elolvassa a kolléga meg kipróbál 2-3 tippet, az kb. annyi idő (és ezáltal pénz) h. már valami szakértő összerakta volna tokkal vonóval akármilyen rendes routerrel ezt az egészet. Gyakorlatilag a munkáltató (vagy h saját projekt akkor a saját) pénzét pazarolja ilyen hobbidolgokra, amik nagyon punk-ok, de lássuk be prodba nem rakná egy hálózatos se akit én ismerek. Talán még a pfsense opensense kivétel, de ott is inkább olyan vason, ami nem egy pc.
A mikrotyúk is egy műanyag szappantartó szép guival. Érdekes módon néha elfelejtik a gazdák frissíteni és szeretik kicseszni a winbox és társait direktben a netre és ekkor lesz még nagyobb szopacs mint az openwrt.
A hozzá nem értésen és a felelőtlenségen egy gyártó egyetlen terméke sem tud segíteni, ha nyílt, ha zárt a forrás.
Pl. a MT-ben pont az a jó, hogy a legősibb szarokra is feltehető a legfrissebb szoftver, amiben javítják a fellelt hibákat. De ha a user nem telepíti a frissítést...
FYI: Az Asus dobozokon egy saját openwrt változat van gyárilag - "némileg" a hardverre optimalizálva...
Nem csak az Asus-nál, franc fog nulláról router rendszert fejleszteni :)
Sőt, egy időben nézegettem a Unifi fw changelog-okat is és egyikben ott szerepelt, hogy "Update Lede version" vagy hasonpaci...
1. Nem hiszem.
2. Teljesen irreleváns a probléma szempontjából.
"Sose a gép a hülye."
A routerek látják egymást, amikor a routerek mögött lévő gépek nem látják a másik routert (és a másik router mögötti gépeket)?
Igen, amikor minden rendben van, látják egymást a telephelyek router-ei.
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
De nem ez volt a kérdés.
Hanem mi?
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
Szerintem azt kérdezte a kolléga, hogy amikor gebasz van, akkor a két router még látja-e egymást rendesen...
"Normális ember már nem kommentel sehol." (c) Poli
Mi az, hogy rendesen? Leírtam a nyitó postban, hogy amikor gebasz van, csak az UDP megy, TCP nem.
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
Az, hogy amikor a gép1 - router1 - internet - router2 - gép2 felállásban a gép1 nem látja a gép2-t, akkor a router1 látja-e a router2-t és viszont? Illetve én hozzátenném további kérdésként, hogy ugyanebben a (hiba)állapotban a gép1 illetve a gép2 lát-e bármit a routeren túl (internet)?
Ez is benne van a nyitó postban.
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
Bocsánat, én nem láttam a nyitó posztban a kérdésemre a választ. Zeller csak megpróbálta egyértelműsíteni a kérdésemet (jól értette egyébként, hogy mit akartam kérdezni).
A gép1 - router1 - internet - router2 - gép2 felállásban nem mindegy a hibakeresés szempontjából, hogy mi az, ami nem lát valamit. Én azt olvastam ki a nyitó posztból, hogy mindig az egyik router mögött lévő gépről (gép1 vagy gép2) próbálod elérni vagy a másik routert, vagy a másik mögött lévő gépet. Ezért kérdeztem, hogy ha közvetlenül a router-ről próbálod elérni a másik routert, akkor az működik-e. És ezért írtam, hogy ha ez működik, akkor a routeren átmenő forgalommal lehet a probléma, és akkor feltételezhető, hogy nem a szolgáltató, hanem a router a ludas a dologban.
Igazad van, ennyire nem részleteztem ki, mert sokkal kényelmesebb a router mögötti gépről tesztelni, mint magáról a router-ről. De természetesen ezt is kipróbáltam, tehát amikor a leállás van, akkor az A telephely router-én kiadott:
parancs sem hozza le a router login oldalát.
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
Akkor feltehetően nem a routeren átmenő forgalommal van a probléma. Én is a tcpdump-ra szavaznék és az mtr-re (TCP-vel tesztelve).
Akkor csak a routereken átmenő TCP forgalomnak van problémája, ha jól értem, ráadásul csak egyetlen IP irányába (a másik router felé). Már elhangzott, ha jól rémlik, hogy a conntrack táblát érdemes megnézni, esetleg a NAT táblát és az MTU méretét. Meg persze a routerek terheltségét (proci és memória kihasználtsága). És jó lenne egy tcpdump, hátha látszik benne valami... Egyébként egy - a két router között lévő - vpn talán segíthetne a dolgon (ezt is mondták már).
- biztos hogy rendes site-to-site vpn-t csináltam volna a telephelyek és a központi szerver közé is. Vérmérséklettől függően egyet vagy kettőt. Mondjuk wireguard. Ugyanis akkor a telephelyek között _egy_ darab udp kapcsolat van, hogy azon belül mi van ahhoz a hálózati szolgáltatónak már köze nincs, semmilyen limitbe nem akadsz bele. Plusz ugye a titkosítás és tömörítés se rossz dolog
- gaming router az gaming router marad, mert bármilyen firmware van rajta attól se a hűtése se a benne levő ram mennyisége nem változik.
- amikor a tcp megáll (tényleg, biztos tcp az a chat?) akkor nem csak az udp-re csinálok tesztet hanem tcp-re is, hogy _ugyanabban_ a tesztben lássam hogy tényleg, az udp megy tovább, a tcp nem
- btw a ping az amúgy se nem tcp se nem udp hanem icmp (alapból)
Gábriel Ákos
A telephelyek és a központi szerver között van vpn (a központi szerver a szerver, a két router a kliens). Ez azért kellett, mert ha valamelyik szolgáltató áll le, akkor egy USB mobilnettel hidaljuk át a kiesést, és ilyenkor a cgnat miatt nem mennek a port forwardok, ezért a telephelyek nyomtatóit amiknek ez kell, beraktuk vpn alá, így el tudja érni őket a központi szerver akkor is, ha mobilnetről megy valamelyik telephely. Nem láttuk indokoltnak a két telephely között is a vpn-t.
A chat tcp és udp, de browser-ben fut, tehát amikor megáll, akkor a tcp biztosan megáll, lehet hogy az udp megy tovább, de az szerintem a hangra van. Ezt nem teszteltem.
Tudom, hogy a ping icmp, csak azért írtam, mert az volt az első ami feltűnt, hogy a ping megy, amikor a tcp nem. És ezután jött az ötlet, hogy akkor nézzük meg az udp-t is.
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
v.ö. "rendes site-to-site vpn"
Gábriel Ákos
az openvpn a gaming routeren van végződtetve? gondolom igen... na azt simán megeszi az openvpn.
én is szoptam ilyennel, azóta inkább portforwardolom a vpn-t belülre egy "szerverre" és az már elbírja akár wireguard akár openvpn.
Gábriel Ákos
Tudom, nem vállalati kategória, de nézzük meg pl. a hAP ac²-t (azért ezt linkelem, mert ezzel az egy típussal rendelkezem, de nekem nagyon nem jött be a RouterOS). Nincs túlméretezve a hűtése és a RAM is csak 128MB... A TUF-AX4200-ban viszont 512 MB RAM van és egyébként a hűtés is bőven elegendő, az az MTK SoC nem egy melegedős fajta. A Mikrotik SoHo kategóriája HW szempontjából semmivel nem előzi meg a jobb konkurenciát.
nem ertem a problemadat. ha keves a 128 (pppoe-n gigabitet lazan viszi az ac2 is), vegyel olyat amiben tobb van.
Én egy szóval nem mondtam, hogy nekem a RAM mennyiségével lett volna gondom. Azt példaként írtam arra, amit a kolléga írt (idéztem is)...
de mit akartal mondani? olyat kell venni, ami azt tudja amit elvarsz tole.
azzal jonni, hogy X eszkozben Y MB a RAM, Z-ben meg Q, semmit nem jelent.
Ha nem jött le, akkor annyit, hogy egy nem gaming routerben is lehet kevesebb RAM... A kolléga úgy írta, mintha az 512 MB RAM kevés lenne. De mindegy, hagyjuk.
Én több helyen raktam le rokonságban OpenWrt-s routereket (még aktív használatban van 64 MB RAM-al szerelt modell is) és mindegyik gond nélkül üzemel több éve.
tehat azt tudja amit elvarsz tole faszmeregetes (kinek tobb/nagyobb) ide vagy oda
"Rokonság" kontra céges telephelyek összekötése - nem ugyanaz a valós feladat, még ha a használandó eszköz funkcióban azonos is lehet...
Az megvan, hogy most SoHo eszközökről beszélünk? Azaz Small Office, Home Office routerekről. A kolléga nem nyilatkozott a cég méretéről, így simán lehet azonos a kategória.
Megnyugtatlak, hogy nálam a rokonság VPN-en össze van kötve (korábban OpenVPN, most Wireguard), tehát nem sokban különbözik a felvázolt esettől (igazából nálam bonyolultabb, mivel ilyen szempontból több, mint 2 telephely van). Sőt, megkockáztatom, hogy az eszközök száma és a szerverem miatt több aktív kapcsolatom van, mint a kérdezőnél (privátban kérdeztem, nála 3000 környéként van az aktív kapcsolatok száma, nálam stabilan 10000 fölött van, mivel van webkiszolgáló, torrent, gyrekek játszanak, sok IOT eszköz, stb.).
csak maradt a kinek nagyobb :)
Sikerült direkt félreértened. A példát csak azért hoztam, mert egy otthoni hálózat simán lehet bonyolultabb/több elemből álló, több forgalmat/kapcsolatot lebonyolító, mint egy Small Office hálózat...
ami mit is jelent? semmit? :) nem ertettem felre, azzal jottel, hogy nagyobb /bonyibb, tobb eszkozos, whatever/. ennyi.
ha pistikenek nem megy a torrent vagy a kodi 1-2 oran at, kit erdekel. ha egy cegnel a munkanapbol elmegy 1-2 ora, mert nem megy... picit mas kategoria. ezert is rakunk ceghez nem ketpalcas ge'mer cuccot, patkolt firmware-rel, hanem femhazas routert, lehetoleg dupla tappal, szunetmentessel, rackbe szerelve... stb. esetleg rendes szerver vason virtualizaljuk.
Még egyszer mondom: SoHo... És itt be is fejeztem.
en meg, hogy home az nem production :D se kicsit se nagyon se kozepesen.
ha a cegnek belefer az ilyen majomkodas, kiesesek, meg, hogy nem megy a melo vagy ha megszakad a zummitting az ugyfellel, akkor meg tokmindegy, hiszen nincs igeny ra, hogy rendes megoldast rakj oda. se kicst se nagyot se kozepest. minden ilyen alkalommal oda kell dorgolni a management/tulaj orra ala a ticketet, hogy van egyebkent rendes megoldas is, csak ra kellene koltened egy atlag fejleszto fel-1 havi fizujat mondjuk. vagy egy manager 1-2 heti beret. vagy nem kell jovore megvenni a kovetkezo mekkbukkot, hanem bele kell locsolni az infraba. lehet donteni. mondjuk ehhez olyan szaki is kell, aki meg tudja ezt csinalni es nem a ge'mer szar eszkozhoz ert csak, mer'a cse'go' forumban azt irtak az majd milyen jolesz. :)
Csak ugye a kolléga attól tart, hogy egy eszköz csere nem fogja megoldani, akkor pedig nyilván őt veszik elő, hogy minek költ feleslegesen, ha egyszer szolgáltatói probléma. Ezért jött ide kérdezni. Biztos senki nem lehet abban, hogy egy Mikrotikra csere meg fogja oldani. Ha valaki 100%-ra állítja, akkor az csak elvakult fanatikus lehet. Legjobb lenne valahonnan kölcsönkérni egy ilyen eszközt (persze ez sem egyszerű).
Ez sima management-it kommunikációs problémának látszik. Én megvárnám hogy elég fontos legyen a probléma a menedzsmentnek ahhoz hogy érdemben tudjunk beszélgetni róla.
Ha nem fontos a probléma akkor nincs is mit megoldani.
Gábriel Ákos
igen, de ez klasszikus catch 22, mert amig nem csereled az eszkozt valamint nincsenek monitoring/debug infok, addig meg az eszkoz(FW/config/whatever)t nem zarhaod ki.
Ezért mondom, hogy be kellene rakni 2 PC alapú routert (OpenWrt, RouterOS), rendesen felkonfigolni őket és nézni, hogy hol nyuvad meg.
Aztán ha kiderül, hogy a RouterOS is okés, akkor venni Mikrotik-et.
ja, csak 2 pc egy nagysagrenddel dragabb lesz mint ket ~100usd-s mt. ha pedig a kollega megtanulta rajta a RoS-t es/vagy megvan a proof-of-concept, utana lehet venni normalis(abb) eszkoz(oke)t vagy bevirtualizalni szerverre a CHR-t, vagy... :)
Az OP retteg attól, hogy beruházzon normálisabb routerbe. Ezért említettem, hogy akkor vegyen két kallódó PC-t, amire felrakja az OpenWrt-OpenWrt majd később RouterOS-RouterOS párost és nézze, mi van.
HA nincs 2 kallódó PC arrafele, ami elég erős ahhoz, hogy elvigyen két ilyen routert, akkor itt nem technikai problémák vannak.
Itt azon van a hangsúly, hogy ha már nagyon megy a fillérbaszás, akkor akasszon már le valami gépet, nézze meg hogy mi van, hol akad el a dolog és utána döntsön.
Mert ami van itt, az Budapest TV remote gerincműtét, ahol az OP nem akarja valójában megjavítani a dolgokat.
ahol nem telik ket "jatszos"/tartalek mt-re 40k nettoert, ott nem valoszinusitem, hogy lesz olyan tartalek/"jatszos" multi-ethernet PC sem, amin ezt megcsinalna, CHR licensz meg aztan vegkepp :D
Egyelőre még azt sem tudjuk mi okozza a hibát, nincs semmilyen statisztika/log, ami a hiba idején mutatna bármit is - oké, hogy egy "régi vágású" sebészorvos azonnal szikéhez nyúlna, de azért előbb egy alapos kivizsgálás is jó lenne...
"nincsenek monitoring/debug infok, addig"...
mas kerdes, ha nem ert hozza, tobb penzt fog munkaoraban elverni erre, mintha odarakna ket hex s-t netto 20k/db koruli aron :)
aztan ha nagyon hianyzik neki a patkolt FW :)
:)
kérdés, hogy kinek mi a 'patkolt' ;)
Általában ugyanis inkább a 'nagy' cégek tákolják a 'saját' firmware-jeiket:
tehát itt kicsit fordítva vagyon:
A szipiszupi enterspájz cuccon 'patkolt' Linux kernellel futó 'patkolt' - ezer éves - LEDE verzió figyel :)
zrubi.hu
Na ezért tettem én azonnal OpenWrt-t a két Ubiquiti UniFi 6 Plus-ra, ahogy megvettük. Az install kicsit izgi volt, de azóta is kiválóan megy mindkettő, egyszer már volt frissítés is.
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
Ügyes vagy, pont a menedzselhetőséget (többlet értéket) szedted ki belőle. "Kár beléd" az enterprise cucc, egy ciscot is meg@nál ha tudnál.
Gábriel Ákos
Meg biztosan jól megy a fastroaming is :)
Meg hát!
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
a nap ervet lattuk/hallottuk! :)
biztos meglepodnel mennyi enterspajz megoldas valamilyen linux/opensource stack under-the-hood. nem attol lesz/nem lesz valami az. :)
Igen, láthattuk is az imént, hogy az enterspajz UniFi U6+ alapból 6 éves kernelt használ, amire tutira nincs számos exploit azóta...
Többlet érték? Hát az tényleg nagy érték, hogy nincs saját konfig felülete, hanem csak valami plusz szoftverrel, kötelező internet eléréssel lehet beállítani.
Tényleg kár belém...
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
Nem kötelező az internet elérés.
"Sose a gép a hülye."
UniFi AC Pro-nak még kellett.
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
Látszik, hogy nem értesz hozzá. Tényleg kár beléd. :)
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
AC Lite-nak biztos nem kellett, nem tudom, a Pro-nak miért kellett volna. VM-be feltoltam egy JuhNyifi kontrollert és annyi.
Az volt még, ha nem tudott internetet detektálni, akkor lekapcsolta a Wifi hálókat az adott eszköz alapértelmezésnek, de ki lehetett lőni. (Azon gondolkozom, hogy nem is annyira hülyeség, valami szkripttel csekkolni, egyáltalán van-e összeköttetés adott hálózattal, amit szórnia kell, és inkább lője ki, ha uplink gond lenne. Bár vezetékes gerinc mellett ez nem annyira létkérdés viszont Mesh esetén érdekes lehet, ha gond van a háttérben)
Egyiknek se kell.
"Sose a gép a hülye."
mitol is enterspajz router egy unifi AP? :) mert ha attol, hogy az a neve, az csak annyit jelent, hogy beszoptad a marketinget. vagy csak en nem latom a routing/firewall capabilitiest/spect sehol?
szerintem kevered ezzel: https://techspecs.ui.com/unifi/cloud-keys-gateways/cloud-key-enterprise
https://techspecs.ui.com/unifi/cloud-keys-gateways/uxg-pro
tudod, dual tap, rackable, fem haz... :)
Az Unifi csak nevében Enterprise szerintem. Jobb support, gyakoribb firmwarefrissítés, több funkció és jobb dokumentáció szükséges.
(Össze lehet hasonlítani egy Arista, Aruba, Cisco, Dell, Juniper, HPE, stb. switch-csel a fenti szempontok alapján.)
...úgyis jönnek...
ne hari, de ez nekem inkabb tunik egy soho wifi ap konzoljanak, mint egy entespajz routerenek :)
tok jok az unifi cuccok (amig mukodnek :D) wirelessre, de veletlen sem epitenek egy ilyen chipsetre mondjuk core router funkcionalitas tekinteteben :) ha ti igen, az mar a ti bajotok.
Itt az a félreértés, hogy a hAP sorozatnak a "home AP"-ből jön a neve. Az nem a cégeknek szánt kivitel. A tartalma eléggé hasonló a nagyobb modellekhez, a szoftvere meg pont ugyan az, de az az otthonra szánt sorozat.
Ha venne két RB5009-et (ami ugyan ~60e Ft/db, de gondolom ez egy működő céget csak nem fektet meg), akkor kap aránylag erős 4 magos ARM64 CPU-t, HW offload képes L3 switch csipet, 1G memóriát, 1G háttértárat. Fém házban, hogy a műanyag szappantartótól eltávolodjuk fizikailag is. És meg vannak adva olyan (független) mérési adatok, hogy csomagmérettől függő űteresző kéesség, titkosított áteresztő képesség, switch áteresztő képesség, stb. Amikkel lehet tervezni, és amiket tud is a készülék a valóságban.
A MT nagy előnye, hogy a rajta futó SW nagyjából minden nyílt forrású hálózati képességgel rendelkezik, és eléggé stabilan tudja is. Persze itt írják sokan, hogy "deház az is ilyen meg olyan", de nálunk pl. fut a hálózatban az RB411-től CCR1036-ig minden, kb. 2000 db eszköz, és hát nem kell cserélgetni sem meg újraindítgatni sem, pedig sok a "szabadban" van, télen a mínuszban, nyáron a forróságban.
És ha már itt tartunk, én magam a "szerver" oldalára tennék egy harmadik router-t, leválasztanám a hálózatkezelést a szerverről... A három telephelyet mesh-be kötném, és minden forgalom arra menne, amerre tartozik (nincs felesleges terhelés ahol nem kell), és vonal kiesés esetén mehetne alternatív útvonalon az adat, akár automatikus átterheléssel is. Ezt rendes eszközökkel simán meg lehet valósítani, "kicsi" pénzből.
Igen, ezek home routerek, ahogy a kérdező által használt Asus is. Éppen azért hivatkoztam arra.
Nekem a fura az, hogy a B telephelyről nem érhető el az A telephely (TCP-n), miközben az A telephely egy másik végpontról elérhető. Ha itt bármilyen, az A telephelyen lévő router miatt előforduló (pl. conntrack tábla telítődés, stb.) lenne szó, akkor az A telephely semmilyen végpontról nem lenne elérhető. Inkább valamilyen közbenső szolgáltatói eszközre gondolnék. Így egy tcpdump segíthet, ami nem is lenne túlságosan nagy méretű, mert elegendő a B felől az A végpont WAN interface-jának 55555-ös portjára érkező TCP forgalmat monitorozni. Én azt mondanám így látatlanban, hogy elérhetetlenség esetén meg sem érkeznek a csomagok valójában.
Illetve a Mikrotik eszközökre átlállás akár csak kipróbálás erejéig nem biztos, hogy annyira egyszerű, ha ezeken az eszközökön több szolgáltatás is fut (akár olyan is, ami RouterOS-re nem is létezik). Ráadásul, ha a fenti feltevésem igaz, akkor ugyan úgy fennállna a probléma.
Lehet itt szappantartózni, de ezek nem azok, csak SoHo routerek. És bizony vannak olyan cégek, amelyeknek ez bőven elegendő is...
A cégnek elég a soho router, a szakembernek nem elég, mikor hibát kell keresni.
Az eszköz csere pedig ideiglenesen mindenképp szükséges, hogy az eszköz hibát kizárhassa. Eszköz csere nélkül sose tudja meg, hogy az eszköz vagy a vonal a hibás, bármit kódol bárhová.
Ha egy router-en olyan szolgáltatás fut, ami pl. egy MT-en nem elérhető, akkor az a router többet csinál, mint ami a dolga lenne... Az extra szolgáltatásokat nem a router-en kell futtatni.
Én egyébként a router admin oldal lekérést, mint monitorozást sem értem. Egészen biztos az, nem nem pont a "monitorozás" öli meg a dolgot, biztos nem a webadmin kiszolgáló körüli hiba okozza a leállást? Én simán SNMP-n kérném le a router állapotát, ha monitorozni szeretném.
Nem, mert amikor a két telephely között megáll a forgalom, a router admin oldala máshonnan elérhető.
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
qos a routeren hogy van beallitva?
Nincs QoS
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
nem is tennék most, abszolút nem ennek a problémának a megoldására való.
nem mellesleg a szappantartók se igazán supportálják
Gábriel Ákos
Ha nincs hardware akadálya és nem támogatják, akkor az software hiányosság. Mivel OpenWrt-hez van QoS modul, ezért amin megy OpenWrt, arra van QoS is, ha kell.
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
rendben, legyen így.
Gábriel Ákos
Hasonló probléma volt szintén OpenWrt, de ennek a kistesója, mt7621-el.
Egy helyen digi, másikon upc/voda, volt és amikor a voda gondolt néha valamit és a szép fehér upc doboz elkezdett DHCP renew-kat broadcostolni, az OpenWrt kezdett haldokolni... Érdekes módon az EdgerouterX edgeos-el simán túléli, a Mikro RB750GR3-as szintén, de ha OpenWrt van rajta akkor sajna egyik sem.
Az lett a megoldás, hogy a digi végpontra ment az Openwrt, a másik oldalra meg az EdgeOs, openvpn kellett UDP-vel.
Miért kezd el broadcastolni DHCP renew-ot a LAN irányba (azaz a router WAN interface-jára) a Voda HGW? Ha routerként megy, akkor ugye ő a DHCP szerver, tehát nem ő küld DHCP renew-ot, csak a WAN oldalra. Ha bridge módban van, akkor pedig semerre nem küld DHCP renew-t (legfeljebb a management hálón szintén WAN irányba).
Illetve nálad jól értem, hogy meghalt minden? Mert a kollégánál a Voda oldalon (is) továbbra is van net, nem szakad meg semmi. Egyébként OpenWrt alatt éppen a DHCP Renew-ra adott válasz miatt ki van nyitva a tűzfalon a 68-as UDP (de ugye ez UDP, ami a kollégánál él tovább) port. Nálam is kb. 17-18 éve UPC/Voda van, mindig is OpenWrt-t használtam, soha semmilyen gond nem volt.
Ez jó kérdés, de csak ezzel a SOC-al csinálta, pl a QCA9558 immunis volt rá OpenWrt-vel.
4 napja ragjatok a temat es tenyleg nem csinaltatok meg egy tcp dumpot? mindket site-n a routereken es a dev serveren is.
benne lesz a valasz, hogy pontosan ki nem valaszol, ki kuld rst-t, ki drop-olja a csomagot.
Meghalok a rohogestol. xDDD
Jaj fontos ceg, jaj fontos munkahelyek, jaj minden fontos, erre egy hulladek consumer asus router van odarakva egy fozott rommal, es megy a csodalkozas hogy valami nem jo :))))
Ez is olyan nagyon fontos nagyon meno ceg mint az az elozo ettermes topic?
Komolyan nincs szaros 80e forint 2 db mikrotikre amit odalogatsz a helyukre es megnezed hogy ugyis fennall-e a hiba? Ennyire nem er semmit a munkaidod a cegnek hogy ilyen vegelathatatlan debuggolasra meg scriptelgetesre pocsekolhatod el ahelyett hogy ertelmes munkat vegeznel?
Volt egy ugyfelem jo 10 eve mar ahol az irodai halozathoz sorban vasarolgattak a leheto legdragabb asus, tplink stb. routereket (legalabb 4-et vettek) mindegyikkel csak a bajuk volt, most net nincs most wifi nincs most ez a weboldal nemjo, most az.
Kidobtam az egeszet a kukaba, kaptak egy wifi nelkuli mikrotik routert meg ket Unifi AP-t. Nemreg beszeltem az ugyvezetovel csak ugy (mert jo viszonyban valtunk el es kivancsi vagyok mi a helyzet odahaza), az elmult 10 evben miota a csere megtortent csak akkor volt halozati problemajuk az irodaban ha a szolgaltatonal leallas volt.
Ennyit az asusokrol meg tarsaikrol, openwrt-vel meg anelkul is.
Nem írtad , hogy milyen adatok állnak rendelkezésre, lehet csak logok. Első körben, mivel a két telephely közötti stabil kapcsolat high prio, megnézném a monitoringot, mit mutat. (Gondolom van.) Ha nincs, akkor legyen (sok megoldás van, ha nincs semmi bármi jó kezdetnek), mindkét telephelyen. Nem felesleges munka mert ki tudja mitől és miért száll szét. akapcsolat.
Én egymás elérését, internetet, serviceket, eszkozok, cpu, ram, forgalom, stb stb allitanam be, majd egvizsgálnám a kapott eredményeket. 5 nap bőven több mint elég, a lényeg az adatgyűjtés, egy helyen, hogy tudj haladni, következtetni. Az is lehet van egy simán hibás hálózati eszközöd. Bármi lehet a fentiekből leszűrve.
Szijártó Zoltán
Aki tud az alkot, aki nem tud az csak szövegel.