[megoldva] digi furaság 2022 május

Internet: PHP, CGI, stb.

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..

  • 1460 megtekintés

( theadam | 2022. 05. 07., szo – 22:17 )

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"

( BaT | 2022. 05. 08., v – 01:14 )

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.

privat@noti:~$ curl -v https://digi.hu
*   Trying 92.249.128.115:443...
* TCP_NODELAY set
* Connected to digi.hu (92.249.128.115) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):

és itt álldogál :)

( renard | 2022. 05. 08., v – 10:50 )

Szerkesztve: 2022. 05. 08., v – 11:04

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

( p2pking | 2022. 05. 08., v – 11:09 )

Nemzeti tuzfalat allitjak be eppen.

Every single person is a fool, insane, a failure, or a bad person to at least ten people.

( m.informatikus | 2022. 05. 08., v – 12:39 )

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.

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 (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

( bennyh | 2022. 05. 08., v – 13:14 )

Szerkesztve: 2022. 05. 08., v – 13:14

IPv6 nem zavarhat be? Esetleg próbakent kliens interfészén letiltani?

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

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.

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

( m.informatikus | 2022. 05. 17., k – 22:01 )

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