Üdv!
Napok óta képtelen vagyok felfogni egy IP watchdog modul működését, ebben kérnék segítséget. Talán icmp protokollal kapcsolatban hiányosak az ismereteim.
A célom:
Vannak pár nehezen megközelíthető helyszínen 4G routereim. Mögöttük 1, max 2 kamera streamel folyamatosan. A mobilnet sávszélessége elegendő a streamekhez, streamelés közben router WAN-jának a pingideje 30-50ms. Sajnos előfordul néha, hogy a rendelkezésre álló sávszélesség egyik pillanatról a másikra lecsökken, kevesebb lesz mint amennyi kellene a stream továbbításhoz. Ilyenkor a pingidő értelemszerűen megnő 1000ms fölé és a problémát 1 vagy néhány router újraindítás oldja meg. Ezt az újraindítást szeretném automatizálni.
Ebből az IP relé modulból rendeltem párat: https://www.aliexpress.com/item/1005001729638858.html
Azt szeretném, hogy egy megadott IP-t pingeljen 5 másodpercenként, és ha az utolsó 10 ping idő több, mint 1000ms, akkor a relével indítsa újra a routert. (elveszi tőle áramot pár mp-re)
Bár semmi doksi sincs, de elég egyértelműnek tűnik, hogyan kell ezt beállítani. A alábbi ábrán látható "ping interval"=5, "timeout"=1, "Retry times"=10 beállításokkal szerintem pontosan ezt kellene csinálnia.
A beállított Watch IP (62.100.224.141) egy teszt VPS-em, amin magas ping időket tudok szimulálni. Jelenleg a 2000ms késletetése van, azaz minimum 2000ms a pingideje. Az eszköz szerint viszont ONLINE van, pedig 1sec a ping timeout, azaz OFFLINE kéne lennie.
Össze-vissza játszottam a beállításokkal, de egyszerűen nem jöttem rá, hogy mi a működési logika. 2 napja chatelek az állítólagos fejlesztővel de nem jutok vele semmire, mintha nem egy bolygón élnénk.
Végül az alábbi kérdést tettem fel neki:
Az alábbi beállítások esetén:
- ping interval=2
- timeout=1
- retry time=3
Az IP OFFLINE, ha az IP tényleges ping ideje 2000ms. De az IP ONLINE, ha az IP tényleges ping ideje 1500ms.
Ezt a választ kaptam, amit bevallom nem értek:
the first "ping->interval" >= "ping->timeout"
if "ping->interval" time get right flag response, "ping->timeout" is ignore
Tök jó lenne ha ezt valaki értené és el tudná magyarázni, hogy mi történik itt :)
Köszönöm szépen!
UPDATE:
További magyarázatok a kínaitól, amik szintén "kínai" nekem:
when ping the packet with flag , so the ping only receve right flag, the prev flag is ignore
example: interval=2, timeout=2, ping response=1500ms, retry times=3
ping1 with flag=1, response with in 1500ms, "retry times" clear to 0, ----> "online"
ping2 with flag=2, response with in 2500ms, "retry times" add 1 ----> "online"("retry times"=1 < 3)
ping2 with flag=3, response with in 1500ms, "retry times" clear to 0, ----> "online"
example: interval=1, timeout=2, ping response=1500ms, retry times=3, this config is not ok(interval < timeout)
ping1 with flag=1, response with in 1500ms(but ping2 with flag=2 is start), "retry times" add 1 ----> "online" ("retry times"=1 < 3)
ping2 with flag=2, response with in 1500ms(but ping3 with flag=3 is start), "retry times" add 1 ----> "online" ("retry times"=2 < 3)
ping3 with flag=3, response with in 1500ms(but ping4 with flag=4 is start), if "retry times" >= 3 ----> "offline"
ping4 with flag=4, response with in 1500ms(but ping5 with flag=5 is start), wait device restart
i think strict "ping->timeout" check is not a good idea in an Internet
what is "right flag response" ?
ping send data with flag to check last packet
example;
ping times1, flag is 1, reponse check if not "flag 1" means lost packet
ping times2, flag is 2, reponse check if not "flag 2" means lost packet
ping times3, flag is 3, reponse check if not "flag 3" means lost packet
"ping->interval" min is 1 second
if "ping->interval"=1, then ping times interval with 1 second,
if "ping->interval"=2, then ping times interval with 2 second,
...
example "ping->interval"=2, "ping->timeout"=1
"ping->interval start"|------2-------|
"ping->timeout start"|--1---|
relay toggle only when "online" -> "offline"
Hozzászólások
Na tudom, én se a kérdésre válaszolok, de valami Mikrotik alapú mobilnet routerrel jobban jártál volna, van watchdog, a hw hibák miatt, meg van netwatch, amiben elég jól állítható az időzítés, scriptből meg újraindítható csak a modem is, hogy ne kelljen már az egész routert lelőni, de persze egy tiszta újraindítást is ütemezhetsz, ami egészségesebb, mint kirúgni egy egész router alól a tápot.
Haladóknak meg egy bedobozolt OpenWRT router, ami szétscriptelhető, de vannak is előre elkészített csomagok, hogy ne kelljen mindent neked megírni, hanem csak webes felületről beparaméterezni.
Köszi! Számítottam ilyen válaszra :) Sajnos a router adott és ezek butus Tp-Link MR6400-asok. Ez egy hobbiproject, madármegfigyelés, költségek minimalizálása a cél.
Ha havonta max 1-2x elveszem tőle áramot, nem lesz baja, de értelek és tudom, hogy nem a legszebb megoldás.
Viszont az OpenWRT mint opció felmerült, mert úgy olvastam felmegy erre a routerre, de nem mertem meglépni. Vagy legyek merész? :)
Egyet lehet be kellene áldozni, hátha. Onnantól már "csak" másolni kell a konfigot :D
Én kicsit máshogy értelmezem a beállításokat:
A "Ping" 3 beállítása 1-1 ping ciklusra vonatkozik: 5 másodpercenként 1 sec timeout-al 10 próba. Ha ebből 1 válasz is jön, akkor OK. (lehet, h v.mi implementációs hiba miatt ha a 2. timeout alatt jön meg az 1. ping válasza, azt is megeszi)
Ami a reboot-ot intézi, az szerintem a "Fail Retry" lesz, ami az előző ping ciklusból 100-at csinál 4 percenként és csak utána reboot-ol.
...de a tévedés jogát fenntartom. Valójában én is inkább Mikrotik-el és annak a saját, beépített watchdog-jával csinálnám. Tisztább, szárazabb...
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
Mikor már agyvérzés közeli állapotban voltam, a teszt VPS-en leloggoltam az icmp csomagokat. Ha a ping interval=5, akkot 5 másodpercenként küld 1 darab pinget.
A fail retry-t _elvileg_ értem.
Frissítettem a postot, további magyarázatokkal a kínaitól, hátha segít (nekem nem)
Ahogy én értem, a flag, amiről hadovászik, az a sequence number, és hosszasan azt próbálja kifejteni, hogy hiába jön meg timeout időn túl a válasz, azt már ignorálni fogja, csak ráadásul a példát is elbaszta, azt kellett volna mondani neki, hogy a második pringre jön meg az első válasza.
Ha jól értem, alapvetően azt csinálja, hogy intervallonként küld egy icmp echo requestet, ha timeout időn belül arra megjön a (megfelelő, tehát azonos seq-ű) válasz, akkor örül. Ha nem, azt elveszettnek ítéli. Ha egymás után retry times db elveszett ping van, akkor megy offlineba a host. Az offlineba menés triggereli a relét.
Azt is mondja, hogy a timeout nem lehet nagyobb, mint az interval, mert nem az fog történni, amit gondolsz. Mivel az interval kiküldi az új csomagot, ezért már annak a válaszát fogja várni, tehát hiába jön meg később (de még a timeout előtt).
a flag lehet seq.number is, a lényeg hogy ez alapján tudja a kérést és a választ párosítani.
az intervalnak nagyobbnak kell lennie mint a megadott timeoutnak.
amit a fenti példákból levettem, a retry time az határozza meg, hányszor kell menjen a ping a timeout fölé hogy "offline"-nak mondja az eszközt.
Ha közben egy jó ping válasz jön, az nullázza a hibaszámlálót és kezdi elöröl a számolást.
ez három egymásutáni magas válszidejü ping esetén lesz érvényes, evileg a harmadikra ugrana.
A retry_time=10 lehet hogy csak nagyon lassan jön össze, mert ha a 9. után jön egy timeout alatti ping, rögtön kezdi elöröl a szämolást.
milyen módok vannak még? Lehet másik módban másképp müködik.
Ahogy leírod, pontosan így kéne működnie, de nem így működik, hiszen akkor a fenti példa esetén 1500ms és 2000ms pingidő esetén is OFFLINE kéne legyen az IP, de valamiért 2000ms esetén ONLINE-nak veszi, holott a timeout 1000ms-en van.
2000ms esetén lehet azért ONLINE mert pingválasznak elfogadja az előző pingre érkezett választ??? De ez nem elmeroggyant?
Itt vannak "részletezve" alul az üzemmódok. Szerintem a Cycle reset a jó nekem.
https://pero.hu/hup/h02.jpg
A Cycle Reset-et nem vitatom, csak a indító hsz-ben, kevesebb info van mint ebben a képben.
azt írja hogy a Cycle Reset esetén a Fail Retry is játszik, ha oda 100 Próbálkozást írsz 4 Percenként akkor az kb 6 óra mire elfogy (ha úgy müködik mind a ping retry)
Én tesztként kisebb számokkal próbálkoznék, majd addig finomítanám amíg nem tetszik.
A képben valóban több infó van. Abból ítélve a "Fail Retry" azt jelenti, hogy ha reset után sem áll helyre a kommunikáció, akkor 4 percenként, 100x újra reset-eli az eszközt, míg az első módnál elvileg csak 1x, aztán vagy jó lesz, vagy nem. (újabb reset-hez ott az kellhet, hogy jó legyen és csak aztán menjen el újra)
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
A Fail retry csak akkor játszik, ha már egyszer OFFLINE volt az IP. De én nem jutok el idáig, mert azzal az algoritmussal van baj vagy csak nem értem hogy működik, ami eldönti hogy az IP offline vagy online van.
Pont az a lényeg, ha nem jön meg a válasz timeout időn belül, akkor az olyan mintha nem pingne az IP.
De hogy a bánatban lehet, hogy 1000ms timeout esetén egy IP 1500ms ping idővel ONLINE, de 2000ms-el meg OFFLINE :D
Az második kiküldött ping esetén válasznak veszi az első pingre ékező választ??? Normális??
Igen, így kéne működni, de megy így működik. Bármit irok neki csak értelmezhetetlen válaszokat ad.
Azt értem, hogy az interval nagyobb kell hogy legyen mint a timeout. Ezt is állandóan írja, holott nem is küldök neki olyan példát, ahol kisebb lenne.
Yep, szerintem is, csak a példa volt foscsi. Illetve hittem, de most már értem, hogy jót írt:
> example: interval=1, timeout=2, ping response=1500ms, retry times=3, this config is not ok(interval < timeout)
> ping1 with flag=1, response with in 1500ms(but ping2 with flag=2 is start), "retry times" add 1 ----> "online" ("retry times"=1 < 3)
Ez itt azt mondja, hogy hiába jön meg 1500 után a response, mert addigra már elküldte a második pinget, tehát már annak a válaszát mondja (csak rosszul értelmeztem első olvasásra, és azt hittem azt mondja, hogy már flag2 jön vissza).
Passz :D Vagy mégsem úgy delayelsz, vagy az ő kódjában van valami szar időzítés, alszik be, ilyesmi.
Nem, kifejezetten állítja, hogy ezt nem teszi.
Én ezt az ő leírásából szűrtem le :)
Szerintem csak magyarázni próbálja, hogy működik részleteiben, azért.
Én adnék neki egy kurva wiresharkot, hogy nézegesse :)
A ping delayem bizti jó, pingeld csak meg az IP-t :)
Szerintem pont azt állítja, hogy elfogadja összevissza a pingválaszokat, ami magyarázná is valamennyire az anomáliát
"i think strict "ping->timeout" check is not a good idea in an Internet" Ez pl mit jelenthet? Hogy nem lehet szigorú egy timeout ellenőrzés?
Nem, ennek biztosan az ellenkezőjét állítja:
when ping the packet with flag , so the ping only receve right flag, the prev flag is ignore
Ez vmi furcsa angolul azt jelenti kb, hogy nézi a flaget, és az előző flaget (tartalmazó választ) onnan ignorálni fogja.
example: interval=1, timeout=2, ping response=1500ms, retry times=3, this config is not ok(interval < timeout)
ping1 with flag=1, response with in 1500ms(but ping2 with flag=2 is start), "retry times" add 1 ----> "online" ("retry times"=1 < 3)
ping2 with flag=2, response with in 1500ms(but ping3 with flag=3 is start), "retry times" add 1 ----> "online" ("retry times"=2 < 3)
ping3 with flag=3, response with in 1500ms(but ping4 with flag=4 is start), if "retry times" >= 3 ----> "offline"
ping4 with flag=4, response with in 1500ms(but ping5 with flag=5 is start), wait device restart
Ez a példa is ezzel konzisztens: Megérkeznek a válaszok 1500 után, de ignorálja őket, mert addigra már a következőt várja. (bár ha tippelnem kellene, akkor a kódban nem ez történik pontosan, szerintem akkor növeli, mikor elindítja az új pinget. Ha nem... hát az végig kéne gondolni, mert abból eshetnek ki faszságok)
Passz. A legjobb tippem kb az volna, hogy egy darab szar pingre ne ugorj, vagy ilyesmi :)
Igen, csak Te gondolom érted, hogy ez nem válasz a kérdéseimre.
Megkérdem tőle, hogy miért ONLINE egy 1.5sec ping idejű IP, ha timeout 1sec. Erre ilyeneket és ehhez hasonló faszságokat ír, aminek semmi köze a kérdéshez és teljesen kikészít idegileg.
Értem én, csak most nekem hiába magyarázod, mintha én mondanék marhaságot :) Azt kérted, hogy segítsünk megérteni, mit ír. Szerintem kiderült, hogy azt írja, amit te is gondoltál a működésről, szóval lehet, hogy tcp dumpot kéne odatenni az orra alá, hogy nézd, 2000 ms delayyel mennek a csomagok, és mégis online, tehát valami nem jó a cuccodban, mert nem az történik, amit írsz.
De most, hogy elárultad, hogy a teszt ipd kint van a neted, sajnos gyanús, hogy valójában a teszed szar :)
❯ ping 62.100.224.141
PING 62.100.224.141 (62.100.224.141) 56(84) bytes of data.
64 bytes from 62.100.224.141: icmp_seq=1 ttl=55 time=2129 ms
64 bytes from 62.100.224.141: icmp_seq=2 ttl=55 time=2128 ms
64 bytes from 62.100.224.141: icmp_seq=3 ttl=55 time=2127 ms
64 bytes from 62.100.224.141: icmp_seq=4 ttl=55 time=2125 ms
64 bytes from 62.100.224.141: icmp_seq=5 ttl=55 time=313 ms
64 bytes from 62.100.224.141: icmp_seq=6 ttl=55 time=313 ms
64 bytes from 62.100.224.141: icmp_seq=7 ttl=55 time=2121 ms
64 bytes from 62.100.224.141: icmp_seq=8 ttl=55 time=2122 ms
64 bytes from 62.100.224.141: icmp_seq=9 ttl=55 time=2123 ms
64 bytes from 62.100.224.141: icmp_seq=10 ttl=55 time=2122 ms
64 bytes from 62.100.224.141: icmp_seq=11 ttl=55 time=2123 ms
64 bytes from 62.100.224.141: icmp_seq=12 ttl=55 time=2122 ms
64 bytes from 62.100.224.141: icmp_seq=13 ttl=55 time=2123 ms
64 bytes from 62.100.224.141: icmp_seq=14 ttl=55 time=2123 ms
64 bytes from 62.100.224.141: icmp_seq=15 ttl=55 time=2123 ms
64 bytes from 62.100.224.141: icmp_seq=16 ttl=55 time=2124 ms
64 bytes from 62.100.224.141: icmp_seq=17 ttl=55 time=2124 ms
64 bytes from 62.100.224.141: icmp_seq=18 ttl=55 time=2124 ms
64 bytes from 62.100.224.141: icmp_seq=19 ttl=55 time=2124 ms
64 bytes from 62.100.224.141: icmp_seq=20 ttl=55 time=2124 ms
64 bytes from 62.100.224.141: icmp_seq=21 ttl=55 time=2126 ms
64 bytes from 62.100.224.141: icmp_seq=22 ttl=55 time=2128 ms
64 bytes from 62.100.224.141: icmp_seq=23 ttl=55 time=2131 ms
64 bytes from 62.100.224.141: icmp_seq=24 ttl=55 time=2128 ms
64 bytes from 62.100.224.141: icmp_seq=25 ttl=55 time=2128 ms
64 bytes from 62.100.224.141: icmp_seq=26 ttl=55 time=2128 ms
64 bytes from 62.100.224.141: icmp_seq=27 ttl=55 time=2128 ms
64 bytes from 62.100.224.141: icmp_seq=28 ttl=55 time=2127 ms
64 bytes from 62.100.224.141: icmp_seq=29 ttl=55 time=2126 ms
64 bytes from 62.100.224.141: icmp_seq=30 ttl=55 time=2127 ms
64 bytes from 62.100.224.141: icmp_seq=31 ttl=55 time=2127 ms
64 bytes from 62.100.224.141: icmp_seq=32 ttl=55 time=2126 ms
64 bytes from 62.100.224.141: icmp_seq=33 ttl=55 time=2135 ms
64 bytes from 62.100.224.141: icmp_seq=34 ttl=55 time=2128 ms
64 bytes from 62.100.224.141: icmp_seq=35 ttl=55 time=334 ms
64 bytes from 62.100.224.141: icmp_seq=36 ttl=55 time=322 ms
64 bytes from 62.100.224.141: icmp_seq=37 ttl=55 time=2125 ms
64 bytes from 62.100.224.141: icmp_seq=38 ttl=55 time=2124 ms
64 bytes from 62.100.224.141: icmp_seq=39 ttl=55 time=2122 ms
64 bytes from 62.100.224.141: icmp_seq=40 ttl=55 time=2121 ms
64 bytes from 62.100.224.141: icmp_seq=41 ttl=55 time=2122 ms
64 bytes from 62.100.224.141: icmp_seq=42 ttl=55 time=2122 ms
64 bytes from 62.100.224.141: icmp_seq=43 ttl=55 time=2123 ms
64 bytes from 62.100.224.141: icmp_seq=44 ttl=55 time=2123 ms
64 bytes from 62.100.224.141: icmp_seq=45 ttl=55 time=2127 ms
64 bytes from 62.100.224.141: icmp_seq=46 ttl=55 time=2131 ms
64 bytes from 62.100.224.141: icmp_seq=47 ttl=55 time=2136 ms
64 bytes from 62.100.224.141: icmp_seq=48 ttl=55 time=2137 ms
64 bytes from 62.100.224.141: icmp_seq=49 ttl=55 time=2136 ms
64 bytes from 62.100.224.141: icmp_seq=50 ttl=55 time=2136 ms
64 bytes from 62.100.224.141: icmp_seq=51 ttl=55 time=2136 ms
64 bytes from 62.100.224.141: icmp_seq=52 ttl=55 time=2137 ms
64 bytes from 62.100.224.141: icmp_seq=53 ttl=55 time=2136 ms
64 bytes from 62.100.224.141: icmp_seq=54 ttl=55 time=2134 ms
64 bytes from 62.100.224.141: icmp_seq=55 ttl=55 time=2133 ms
64 bytes from 62.100.224.141: icmp_seq=56 ttl=55 time=2143 ms
64 bytes from 62.100.224.141: icmp_seq=57 ttl=55 time=2132 ms
64 bytes from 62.100.224.141: icmp_seq=58 ttl=55 time=2133 ms
64 bytes from 62.100.224.141: icmp_seq=59 ttl=55 time=2133 ms
64 bytes from 62.100.224.141: icmp_seq=60 ttl=55 time=2133 ms
64 bytes from 62.100.224.141: icmp_seq=61 ttl=55 time=2131 ms
64 bytes from 62.100.224.141: icmp_seq=62 ttl=55 time=2127 ms
64 bytes from 62.100.224.141: icmp_seq=63 ttl=55 time=2126 ms
64 bytes from 62.100.224.141: icmp_seq=64 ttl=55 time=2125 ms
64 bytes from 62.100.224.141: icmp_seq=65 ttl=55 time=2125 ms
64 bytes from 62.100.224.141: icmp_seq=66 ttl=55 time=265 ms
64 bytes from 62.100.224.141: icmp_seq=67 ttl=55 time=264 ms
64 bytes from 62.100.224.141: icmp_seq=68 ttl=55 time=2123 ms
64 bytes from 62.100.224.141: icmp_seq=69 ttl=55 time=2124 ms
64 bytes from 62.100.224.141: icmp_seq=70 ttl=55 time=2124 ms
64 bytes from 62.100.224.141: icmp_seq=71 ttl=55 time=2124 ms
64 bytes from 62.100.224.141: icmp_seq=72 ttl=55 time=2124 ms
64 bytes from 62.100.224.141: icmp_seq=73 ttl=55 time=2124 ms
64 bytes from 62.100.224.141: icmp_seq=74 ttl=55 time=2124 ms
64 bytes from 62.100.224.141: icmp_seq=75 ttl=55 time=2124 ms
64 bytes from 62.100.224.141: icmp_seq=76 ttl=55 time=2124 ms
64 bytes from 62.100.224.141: icmp_seq=77 ttl=55 time=2124 ms
64 bytes from 62.100.224.141: icmp_seq=78 ttl=55 time=2124 ms
64 bytes from 62.100.224.141: icmp_seq=79 ttl=55 time=2132 ms
64 bytes from 62.100.224.141: icmp_seq=80 ttl=55 time=2131 ms
64 bytes from 62.100.224.141: icmp_seq=81 ttl=55 time=2132 ms
64 bytes from 62.100.224.141: icmp_seq=82 ttl=55 time=2132 ms
64 bytes from 62.100.224.141: icmp_seq=83 ttl=55 time=2132 ms
64 bytes from 62.100.224.141: icmp_seq=84 ttl=55 time=2132 ms
64 bytes from 62.100.224.141: icmp_seq=85 ttl=55 time=2132 ms
64 bytes from 62.100.224.141: icmp_seq=86 ttl=55 time=2132 ms
64 bytes from 62.100.224.141: icmp_seq=87 ttl=55 time=2130 ms
64 bytes from 62.100.224.141: icmp_seq=88 ttl=55 time=2130 ms
64 bytes from 62.100.224.141: icmp_seq=89 ttl=55 time=2128 ms
64 bytes from 62.100.224.141: icmp_seq=90 ttl=55 time=2128 ms
64 bytes from 62.100.224.141: icmp_seq=91 ttl=55 time=2128 ms
64 bytes from 62.100.224.141: icmp_seq=92 ttl=55 time=2128 ms
64 bytes from 62.100.224.141: icmp_seq=93 ttl=55 time=2128 ms
64 bytes from 62.100.224.141: icmp_seq=94 ttl=55 time=2129 ms
64 bytes from 62.100.224.141: icmp_seq=95 ttl=55 time=2127 ms
64 bytes from 62.100.224.141: icmp_seq=96 ttl=55 time=288 ms
64 bytes from 62.100.224.141: icmp_seq=97 ttl=55 time=288 ms
64 bytes from 62.100.224.141: icmp_seq=98 ttl=55 time=2123 ms
64 bytes from 62.100.224.141: icmp_seq=99 ttl=55 time=2123 ms
64 bytes from 62.100.224.141: icmp_seq=100 ttl=55 time=2123 ms
64 bytes from 62.100.224.141: icmp_seq=101 ttl=55 time=2124 ms
64 bytes from 62.100.224.141: icmp_seq=102 ttl=55 time=2128 ms
64 bytes from 62.100.224.141: icmp_seq=103 ttl=55 time=2124 ms
64 bytes from 62.100.224.141: icmp_seq=104 ttl=55 time=2125 ms
64 bytes from 62.100.224.141: icmp_seq=105 ttl=55 time=2131 ms
64 bytes from 62.100.224.141: icmp_seq=106 ttl=55 time=2135 ms
64 bytes from 62.100.224.141: icmp_seq=107 ttl=55 time=2135 ms
64 bytes from 62.100.224.141: icmp_seq=108 ttl=55 time=2135 ms
64 bytes from 62.100.224.141: icmp_seq=109 ttl=55 time=2136 ms
64 bytes from 62.100.224.141: icmp_seq=110 ttl=55 time=2134 ms
64 bytes from 62.100.224.141: icmp_seq=111 ttl=55 time=2135 ms
64 bytes from 62.100.224.141: icmp_seq=112 ttl=55 time=2157 ms
64 bytes from 62.100.224.141: icmp_seq=113 ttl=55 time=2191 ms
64 bytes from 62.100.224.141: icmp_seq=114 ttl=55 time=2204 ms
64 bytes from 62.100.224.141: icmp_seq=115 ttl=55 time=2204 ms
64 bytes from 62.100.224.141: icmp_seq=116 ttl=55 time=2204 ms
64 bytes from 62.100.224.141: icmp_seq=117 ttl=55 time=2197 ms
64 bytes from 62.100.224.141: icmp_seq=118 ttl=55 time=2156 ms
64 bytes from 62.100.224.141: icmp_seq=119 ttl=55 time=2122 ms
64 bytes from 62.100.224.141: icmp_seq=120 ttl=55 time=2122 ms
64 bytes from 62.100.224.141: icmp_seq=121 ttl=55 time=2123 ms
64 bytes from 62.100.224.141: icmp_seq=122 ttl=55 time=2122 ms
64 bytes from 62.100.224.141: icmp_seq=123 ttl=55 time=2122 ms
64 bytes from 62.100.224.141: icmp_seq=124 ttl=55 time=2122 ms
^C
--- 62.100.224.141 ping statistics ---
126 packets transmitted, 124 received, 1.5873% packet loss, time 125201ms
rtt min/avg/max/mdev = 263.658/2012.954/2204.282/450.579 ms, pipe 3
Foglamam sincs ezt hogy hoztad össze. Én napok óta pingelem és ilyen sose volt. Most kiküldtem 500 pinget, mint >2000ms
De tételezzük fel, hogy így is van, és van néhány "jó" ping, akkor is annyi timout lenne, amitől húznia kéne a relét.
A linuxon ezzel késleltetek: tc qdisc add dev eth0 root netem delay 2000ms
Azóta is beszélek a emberrel, de már teljesen nyilvánvaló, hogy ha valóban fejlesztő, akkor játsza a hülyét. (De szerintem nem fejlesztő)
Beírtam, hogy ping ip :)
Mondom, csinálj egy tcp dumpot, ahol látod konkrétan teszt közben, hogy mi történik. Ha tényleg így van, ezt told az orra alá, hogy szar. Nem hiszem, hogy a hülyét játsza, csak bénán kommunikál. Mármint nekem úgy tűnik, hogy magyarázni próbál, mert nem értette meg, hogy javítandó bug van.
Vagy hagyd a picsába a kínait, és hackolj rá vmi custom firmwaret. Az értékelésekben írja a faszi, hogy lehet. :)
Nemnemnem :))) Hidd el, hogy tök hülye, de már nem idegesítem magam. Ott van a bug, hogy timeoutnak nem a megadott timeout-ot használja, hanem az interval-t. Ezerszer leírtam neki, és nem foglalkozik vele, példákkal alátámasztom, de nem reagál rájuk.
Ennél a beállításnál maradtam:
Interval=2
Timeout=1 (ez látszólag nincs semmire se használva)
Retry times = 10
Ez esetben 2 másodpercenként pingel és akkor húzza a relét, ha az utolsó 10 ping idő nagyobb mint 2000ms (>1000ms-nél kéne, de lesz@rom)
Sajnos nem lehet 1000ms alatti timeout vagy interval értéket megadni, viszont az eredeti célom az volt hogy 500ms feletti pingek esetén legyen router reboot.
Erre a workaround-om: Ha a pingelt IP-nek van egy fix 1500ms késleltetése, akkor 500ms-nél már azt fogja hinni a watchdog, hogy 2000ms a ping és reboot indul :)
Hibajegy lezárva :D
Azt is írja hogy előre kell szólni, mikor küldi, hogy olyant küldjön, ami flash-elhető. De ezek sajnos már itt vannak a kezemben. De a fenti megoldás nekem megfelel egy hobbiprojekthez. :)
Köszi h szántál időt a émara :)