Fórumok
webböngészőben:
bix.hu OK
arukereso.hu - A kapcsolat időtúllépés miatt megszakadt
digi.hu - A kapcsolat időtúllépés miatt megszakadt
stb.
vajon milyen issue lehet a diginél h. vmelyik oldal bejön, vmelyik nem? (elsőre gondoltam volna h. külföldi vonal vs. belföldi, de nem..?)
2 másik telóról nézve is. GPON/saját OWRT már reboootolva. pár napja szórakozik.
downdetectoron délután még írt hibát digire, most már nem, pedig még mindig issue van
telón protonvpn-t bekapcsolva simán megy minden weboldal, hoppá (free netherland server).
privat@noti:~$ traceroute bix.hu
traceroute to bix.hu (193.41.47.210), 30 hops max, 60 byte packets
1 valami.lan (192.168.xx.1) 1.169 ms 1.339 ms 1.618 ms
2 192.168.1.1 (192.168.1.1) 3.364 ms 3.475 ms 3.768 ms
3 10.0.0.1 (10.0.0.1) 5.726 ms 11.192 ms 11.404 ms
4 * * *
5 ae-16.cr02.budapest.digicable.hu (78.131.3.127) 13.969 ms 14.569 ms ae-16.cr01.budapest.digicable.hu (78.131.3.22) 28.408 ms
6 78.131.3.51 (78.131.3.51) 17.283 ms 7.835 ms ae-2.xr01.budapest.digicable.hu (78.131.3.53) 10.513 ms
7 r1.bix.iszt.hu (193.188.137.7) 10.730 ms 11.017 ms 10.652 ms
8 www.bix.hu (193.41.47.210) 11.282 ms 11.824 ms 11.424 ms
privat@noti:~$
privat@noti:~$
privat@noti:~$ traceroute arukereso.hu
traceroute to arukereso.hu (80.249.166.51), 30 hops max, 60 byte packets
1 valami.lan (192.168.xx.1) 2.850 ms 3.134 ms 3.109 ms
2 192.168.1.1 (192.168.1.1) 3.086 ms 3.063 ms 3.040 ms
3 10.0.0.1 (10.0.0.1) 9.614 ms 9.808 ms 9.785 ms
4 * * *
5 ae-16.cr01.budapest.digicable.hu (78.131.3.22) 12.831 ms ae-16.cr02.budapest.digicable.hu (78.131.3.127) 13.126 ms 13.723 ms
6 ae-2.xr01.budapest.digicable.hu (78.131.3.53) 79.092 ms 74.364 ms 78.131.3.51 (78.131.3.51) 9.274 ms
7 81.183.2.160 (81.183.2.160) 9.422 ms 9.662 ms 9.629 ms
8 81.183.3.168 (81.183.3.168) 9.819 ms 81.183.3.42 (81.183.3.42) 11.412 ms 81.183.3.36 (81.183.3.36) 11.834 ms
9 81.183.3.163 (81.183.3.163) 12.417 ms 81.183.3.167 (81.183.3.167) 9.504 ms 81.183.3.135 (81.183.3.135) 10.648 ms
10 81.183.2.210 (81.183.2.210) 10.570 ms 81.183.3.4 (81.183.3.4) 9.502 ms 81.183.3.24 (81.183.3.24) 8.771 ms
11 * * *
...
privat@noti:~$ traceroute digi.hu
traceroute to digi.hu (92.249.128.115), 30 hops max, 60 byte packets
1 valami.lan (192.168.xx.1) 2.885 ms 3.066 ms 3.049 ms
2 192.168.1.1 (192.168.1.1) 3.034 ms 3.020 ms 3.277 ms
3 10.0.0.1 (10.0.0.1) 9.896 ms 10.200 ms 10.185 ms
4 * * *
5 ae-16.cr02.budapest.digicable.hu (78.131.3.127) 13.812 ms 14.354 ms ae-16.cr01.budapest.digicable.hu (78.131.3.22) 13.389 ms
6 * * *
...
privat@noti:~$ date
2022. máj. 7., szombat, 21:52:56 CEST
privat@noti:~$
van itt diginél dolgozó ember? :D lehet gyorsabb lenne, mint az ügyfélszolgálat..
Hozzászólások
A 192.168.1.1 is hozzád tartozik? Csak mert az első hop-nál az IP-ben az alhálózatot kitakartad, de a másodiknál már nem, és csak ezután van a 10.0.0.1. HA nem a te hatáskörödben van, én erre indulnék el. Mi az az extra hop? Ahogy elnézem FTTH, az ONT bridge módba rakása esetleg nem segítene? Ha bridge-ben van, az MTU rendesen be van állítva?
TheAdam
Nálam is digi van, néha nálam is tetű lassú és furcsaságokat csinál. Nem hiába, már állami (na jó, államközeli). Nem bridge az eszköz, a digi ZTE cucca osztja a netet.
Hasonló a kimenet itt is, a 192.168.1.0/24 az saját belső hálózat, a 10.0.0.1 lövésem sincsen micsoda, de nem helyi dolog. Feltételezem a digi saját belső hálózata, az omci is 10-es hálón megy, meg gondolom a voip is. Itt a végponton a ZTE eszközön publikus IP-t látok és nem a 10.0.0.1-et, ez tuti, mögötte nem tudom mi van.
$ traceroute -n bix.hu
traceroute to bix.hu (193.41.47.210), 30 hops max, 60 byte packets
1 192.168.1.1 6.929 ms * *
2 10.0.0.1 13.323 ms 13.041 ms 13.279 ms
3 * * *
...
Utóbbi időben szokott olyan lenni, hogy a CATV led piros, de minden rendben működik (tv+net).
"Az élet tele van kérdésekkel. Az idióták tele vannak válaszokkal."
"Its easier to fool a man than it is to convince they have been fooled"
Nekem volt hasonló problémám pár hónapja. Csak a Windows 10-es gépemen jött elő, más kliensen (telefonon) be tudtam tölteni bármilyen oldalt. Illetve kapcsolódni lehetett minden hosthoz, csak az SSL handshake-nél akadt el a dolog, de az klienstől függetlenül. Mivel a hibák csak egy gépen jöttek elő, ezért nem is gyanakodtam sem a Digire se az ONT-re. De miután minden más hibajavítási kísérlet sikertelen volt, újraindítottam az ONT-t és megoldódott a probléma.
Nem tudom, hogy ez az információ segít-e, mivel látom nálad picit mások a tünetek. Mindenesetre egy
curl -v https://digi.hu
kimenet érdekes lehet.és itt álldogál :)
Igen, ugyanez volt nálam is. Látom az újraindítás segített.
Telekom hálózatából nálam is hasonlóak az eredmények traceroute esetén, viszont a weboldalak böngészőből bejönnek.
A pingekre is megérkeznek a válaszok, és természetesen telnettel tesztelve is minden rendben (pl. telnet digi.hu 80 és telnet digi.hu 443).
Vagyis a traceroute nem perdöntő jelen esetben.
Szerk.: digi.hu esetén nincs a pingekre válasz, de az árukeresőnél van.
Szerk. 2.: -T esetén rendben lefut a traceroute, vagyis az ICMP van tiltva.
Tehát ezekre jó eredményeket kapok:
traceroute -T digi.hu
traceroute -T arukereso.hu
traceroute -T arukereso.com
Nemzeti tuzfalat allitjak be eppen.
Every single person is a fool, insane, a failure, or a bad person to at least ten people.
4iG végeznek is vele...
a digi optikáján levő GPON-nak a wifijéhez csatlakozva ugyan az a hibajelenség :D szóval nem az én nanorouter-emen levő OpenWRT bármi beállítása a ludas imho.
Számomra ez tcpmss problémának tűnik, indítsd újra azt a GPON eszközt és ellenőrizd újra. Ha továbbra sem OK és tudsz a routereden tcpmss-t módosítani tűzfalból akkor tesztre állíts egy biztonságos méretet a csomagokon és próbáld újra.
GPON rebooot igen, segített :D
nincs semmi extra beállítás a digi GPON-on és örülök h. ha egy mezei port forwardot se felejt el egy idő után :D
szóval rárakok időzítőt, ami hajnalban elveszi 1 percre az áramot, majd vissza, LOL. diginek megpróbálom bejelenteni a hibát, de... csak a türelmemmel játszok szerintem h. ha ügyfélszolgálaton keresztül kell magamat átvergődnöm.
fura h. idáig működött. sajnos firmware verziót se tudok meglesni a GPON-on, nincs a webguijában
Írod, hogy "örülök h. ha egy mezei port forwardot se felejt el egy idő után". Miért nem kéred át bridge módba az eszközt, ha már úgyis van OpenWRT mögötte? Én még az optikás átkötéskor (talán 2018?) kértem a bridge módot, azóta nem kellett hívni az ügyfélszolgálatot.
Aztán mar volt h. "visszaállt" bridge módból nekem az eszköz egy pár hónap után. Vmit basztattak a backend-en, és forced restart+konfig reloadot nyomtak minden eszközre, köztük az enyémre is. Ami így szépen visszaállt a defaultra, ami a nem-bridged-mód. Telefonálni kellett, és gyorsan megfixálták.
Gondolom a gond a kivételkezeléssel (néhány ezer okostojás user nem azt kéri, mint a többi százezer) van.
Nálam semmi probléma nem volt a bridge móddal az elmúlt 4 évben (akkor kértem).
Illetve publikus IP-t kértem még előtte, de az se "állt vissza".
Mondom, személyes tapasztalat volt. Lehet régió / településfüggő.
Nálam (pár éve) a digi átállásnál egyből előjött hasonlóan megfoghatatlan probléma, amit pár napos debugolás után ez oldott meg:
$IPT -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
zrubi.hu
Pedig ez annyira nem új dolog :-)
Lásd Linux Advanced Routing & Traffic Control HOWTO
lehet hogy nem új dolog, de addig (digi átállás) SEHOL nem volt erre szükségem.
zrubi.hu
IPv6 nem zavarhat be? Esetleg próbakent kliens interfészén letiltani?
Majd alkalomadtán elmesélhetnéd, hogy jön ide az IPv6
Normális esetben nem lehet gond az IPv6-tal, viszont
- Volt már, hogy meghalt a komplett v6-os forgalom. Volt cím, volt prefix, de a 2. hop-nál sosem jutott tovább. Természetesen rám akarták tolni, és tagadták a hibát. Egy hétig saját routerrel, laptoppal, másik routerrel, másik laptoppal sem működött. Utána egyszer csak huss, a korábban problémás routeren helyrejött, és hirtelen az összes többi eszközön is. Prohardver fórumon nem csak én tapasztaltam, más is írt hasonlót.
- Az egyes gyártók eszközei közel sincsenek felkészülve az IPv6-ra. A hardveres offload hiánya csak egy gond a sok közül, de előfordul olyan eszköz (elsősorban router), ami okoz érdekes v6-os problémákat és csak a tiltás segít. Én először ASUS RT-AC66U B1-gyel kezdtem, ott néha voltak érdekes v6-os lassulások. Utána jött egy MikroTik hAP ac2, majd most ac3, ezeken sosincs ezzel gond.
A leírt problémánál egyébként én is kétlem, hogy a v6 kavarna be. A BIX-nek van v6-ja, ahogy a DIGI-nek is, de az Árukeresőnek nincs, és amúgy is v4-es traceroute-okat kaptunk.
A fenntebbiekhez:
Bridged mód nekem 2018 óta ok teljesen, nem állt vissza, nem élet fel magától a Wi-Fi, sokkal jobb, mint a ZTE volt routerként, dupla NAT-tal.
Illetve a 10.0.0.1 a DIGI PPPoE peer-je, az normális, hogy mindenkinek megjelenik.
TheAdam
VPN-nél vettük észre, hogy nem megy a névfeloldás. Kiderült, azért, mert ugyan IPv4-en rendesen regisztrálva lett a DNS szerver, viszont a Windows már a szolgáltatótól kapott v6-os DNS szervereket használta volna, ami persze mit sem tudott a VPN-en keresztül elérhető címtartományról.
A Windows úgy néz ki, szeretné inkább a v6-ot használni, ha elérhető. Viszont, ha pl valamelyik oldalnak nem stabil a v6-os linkje, esetleg gond van v6-on a névszerverrel, akár magyarázat is lehet némelyik furcsaságra. Nekem régen, mikor HE tunellel szórakoztam, némelyik oldal elérése bizonytalan lett, másoké meg nem változott, tesztek szerint élő volt a v6-os kapcsolat.
Vegyük észre, hogy a noti linuxos volt, a 3 példa közül pedig a működőnél volt IPv6 target és az egyik nemműködőnél. De OK.
digi support meglepően gyorsan, fél nap alatt válaszolt a hibabejelentős mailemre h. távolról állíottak a gpon-jukon, azóta tökéletesen működik, levettem már akkor az időzítőről, yaaaay