-
Fototrend
DIGI internet Gyakran Ismételt Kérdések
(Kattints az Összefoglaló kinyitása feliratra!)
Utolsó frissítés: 2024. február
Aktív témák
-
alvardes
csendes újonc
válasz
dchard
#108358
üzenetére
> Bár a fene tudja mi történik akkor, ha már van egy session-öd és megpróbálsz még egyet folyamatosan felépíteni, lehet bizonyos számú próbálkozás után a kiszolgáló oldal küld egy PADT-t mindenkinek.
Alapból az authentikációnál utasítja el a kapcsolatfelépítést ha ha már van session:
Tue Apr 18 13:45:23 2023 daemon.info pppd[32444]: Using interface pppoe-test
Tue Apr 18 13:45:23 2023 daemon.notice pppd[32444]: Connect: pppoe-test <--> eth0.2
Tue Apr 18 13:45:26 2023 daemon.info pppd[32444]: Remote message: Too many sessions^J
Tue Apr 18 13:45:26 2023 daemon.err pppd[32444]: PAP authentication failed
Tue Apr 18 13:45:26 2023 daemon.notice pppd[32444]: Connection terminated.
Tue Apr 18 13:45:26 2023 daemon.info pppd[32444]: Exit.
Tue Apr 18 13:45:27 2023 daemon.notice netifd: Interface 'test' is now downKipróbáltam, nálam, ha van elő kapcsolat, ha nagyon sokszor kézzel egymás után próbálok másodjára csatlakozni is akkor sem szakad meg az élő session, nem küld nekem PADT-t.
-
alvardes
csendes újonc
válasz
adika4444
#107488
üzenetére
Nincs olyan hogy upstream DNS. Bárki végiglépkedhet és lépésenként tartományonként feloldhatja egy domain név IP címét.
Linuxon pl "dig +trace www.index.hu"
dig +trace www.index.hu
; <<>> DiG 9.16.37-Raspbian <<>> +trace www.index.hu
;; global options: +cmd
. 621 IN NS k.root-servers.net.
. 621 IN NS g.root-servers.net.
. 621 IN NS m.root-servers.net.
. 621 IN NS f.root-servers.net.
. 621 IN NS e.root-servers.net.
. 621 IN NS h.root-servers.net.
. 621 IN NS l.root-servers.net.
. 621 IN NS i.root-servers.net.
. 621 IN NS a.root-servers.net.
. 621 IN NS d.root-servers.net.
. 621 IN NS c.root-servers.net.
. 621 IN NS b.root-servers.net.
. 621 IN NS j.root-servers.net.
;; Received 239 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms
hu. 172800 IN NS ns-com.nic.hu.
hu. 172800 IN NS d.hu.
hu. 172800 IN NS e.hu.
hu. 172800 IN NS b.hu.
hu. 172800 IN NS a.hu.
hu. 172800 IN NS ns2.nic.fr.
hu. 172800 IN NS c.hu.
hu. 86400 IN DS 2104 8 2 65F5D64B860F26FEAE0BDE3CA51B730B38381678C8C316F16B37E551 105EBAC5
hu. 86400 IN RRSIG DS 8 1 86400 20230406170000 20230324160000 951 . tp+hEwKSCIkirS/BOuXuzcIqQ5gBMDVuqmKtWXdG67KUoG+Ofs1di1Ko xKDQtuLTi8PgXcq0wv2gxUGnn4Tpzpk4MrTU6VriAPGD7Mc3spqn+P9d LpDfr7zrrtjhEDB8KjkRdJvN1Us0SUlmMSfNHDDfw6br1KjTX77lfenz q92xqZ1JytoDyjGtKYUmrcxBrzNjc0+y2PueNt6GebYAsbJh96s0guQz 6cdw/YqeO/4WqDMqyO/z8+nYjsorn5hSTOgYGwkHEv99Sta+8Fi7pf9F tNpU5duOGWZxS0sJER09u72OtjreR9M/lOsT0Yo0dkgSFJVCVzBwrXzf 9AZEAw==
;; Received 845 bytes from 192.112.36.4#53(g.root-servers.net) in 19 ms
index.hu. 86400 IN NS ns.index.hu.
index.hu. 86400 IN NS ns.inventra.hu.
h89gmc0fg5lrnl90ou37edeobci4ni5f.hu. 3600 IN NSEC3 1 1 5 A40D31F1F11B56C1 H89LCKBHV1H9JP33MI5ELJDB1G7026J9 NS SOA TXT RRSIG DNSKEY NSEC3PARAM
h89gmc0fg5lrnl90ou37edeobci4ni5f.hu. 3600 IN RRSIG NSEC3 8 2 3600 20230416113013 20230319050055 49896 hu. vVQzg54sd0jPS4UZEDpbOFQliJn9TFSHLXl1MXho0B7JpKkHBGvPKJem cJjswLeihEbpfjPZty2nxyH2EXVzakVOd2SBRXHn5ZePPubIie4lZUKu aW/bkG+0NsfueHXiV0pZKGxj7loyI0zFT/2qbp5OS85vL1kvW3ZROXxj 6z0=
nsjtg7di1rggefal2brjngmtfinbtbhe.hu. 3600 IN NSEC3 1 1 5 A40D31F1F11B56C1 NSK72QI17T4A7JU4IIT0FKUFPGPU0EE6 NS DS RRSIG
nsjtg7di1rggefal2brjngmtfinbtbhe.hu. 3600 IN RRSIG NSEC3 8 2 3600 20230415203757 20230319050055 49896 hu. mYejqjpg7+x4QXEpIY2QaMBzCFnqIN4TEHZCFRMo5eFhgPM7M4w4ADk3 kjdCjJ6Sv3p7y/kIPl294dZSCafINLnoeCqsMb5ZeeVwlOA0Qp3zP23X V8RJTgkw5D1Bb1qVET24vrXWybwXq5ZidcfifEjyEU1BfcSoBYV8A2dj kZQ=
;; Received 615 bytes from 2a00:e6a0:3:1014::53:99#53(d.hu) in 0 ms
www.index.hu. 300 IN A 217.20.130.99
index.hu. 60 IN NS ns.index.hu.
index.hu. 60 IN NS ns2.index.hu.
;; Received 152 bytes from 195.56.65.172#53(ns.index.hu) in 0 ms -
alvardes
csendes újonc
válasz
adika4444
#107483
üzenetére
> A Google 8.8.8.8-ról váltottam, mert az is sokat kimaradt, újonnan a CF is csinálja.
Szerintem értelmetlen az alábbiak közül, magyarországon bármelyiket is használni:
1. A "privászférádat védő" agyonreklámozott, nem céges, fizetős VPN.
2. Külső szolgáltató által nyújtott rekurzív DNS resolver. (Legalábbis alapértelmezetten, elsődlegesen nem)Vagy használd a saját helyi szolgáltatód szerverét, vagy ha egy telephelyet üzemeltetsz akkor csinálj saját rekurzív feloldó szervert.
Hozzáteszem normális körülmények között a kliensen be lehet állítani backup DNS szervert amit csak akkor használ ha az alapértelmezettek nem használhatóak.
Ha ilyet a te rendszered nem is tud, akkor is meg tudod azt csinálni, hogy DNS1-ként a szolgáltató egyik szerverét állítod be DNS2-nek meg mondjuk a 8.8.8.8-at. Így akkor azt kivédted, amikor a szolgáltató szervere nagyritkán lehal. Elvileg ugye a DNS1-et kéne alapból használnia mindig és a másodlagos DNS2-t csak akkor kéne használnia amikor a DNS1 nem működik. Nem tudom ezt betartják e pl windowson névfeloldáskor, de még mindig jobb mint kibaszni a helyi névszervert és bejárkálni valami random harmadik fél szolgaltató hálózatába egy szaros rekurzív névfeloldó szerverért.
(Látható mennyire tartom jó ötletnek ezt az egész DNS szerver lecserélgetését gondolom.... 😅)
-
alvardes
csendes újonc
Az ECS (edns client subnet) lényege, hogy az authoritív szerverre a DNS lekérdezéskor elküldik a client IP címét. (pontossabban, csak a client ip tartományát amiben benne van.)
A cloudflare ezt privacy okokra hivatkozva nem teszi meg, pedig ez teljesen értelmetlen.
Az adott weboldal/szervice tudni, fogja, pontosan, hogy mi a te ip címed hiszen azért oldod fel a domain nevét valaminek, hogy hozzá csatlakozz. Vagyis legkésőbb a csatlakozáskor tudni, fogja a PSN/más szolgáltatás, hogy mi az IP címed. Vagyis az egész DNS feloldás keretében megpróbálni megvédeni a kliens IP címét egy faszság. Semennyire nem növeli ez a privacy-t.
-
alvardes
csendes újonc
Ebben nem vagyok biztos, viszont szerintem a DNSSEC nem függ a rekurzív rezolvertől.
Ha van DNSSEC akkor az lesz az ISP-s DNS szerveren is.
A gond nem ezzel van vagy pedig a DNS over TLS-szel, hanem az Enhanced dns client subnettel (edns client subnet) amit a cloudflare privacy okokból nem támogat így elosztott georedundáns szolgáltatások amik DNS alapon próbálnak terheléselosztani (az által, hogy egy domain nevet a klienshez legközelebbi szerverre resolválnak) nem tudnak működni.
-
alvardes
csendes újonc
válasz
Varszegig
#107469
üzenetére
> Olyan, mintha a digi hálózatáról időnként nem lenne elérhető a cloudflare dns.
Az még nem merült fel benned, hogy lehet, hogy ez a csodálatos cloudflare dns a szar?
Egyébként évekkel ezelőtt is volt már ezzel kapcsolatban jelzés a cloudflarenek, hogy a "privacy" nevében idiótaságokat csinálnak. A válaszuk az volt, hogy hurr durr nekünk van igazunk, mert "privacy".
Azóta sem lett nekik igazuk cserébe le vannak szarva mindenki által. Egyébként pedig magával a DNS szerverrel megpróbálni növelni a "privacy"-t is egy agyrém és rámutat arra, hogy alapfogalmakkal nincsennek tisztában ott a tüzesfelhőnél (pl., Vajon miért old fel valaki egy domain nevet? A vicc kedvéért? Vagy esetleg csatlakozik e hozzá utána?).
-
alvardes
csendes újonc
válasz
dchard
#103610
üzenetére
> a PPPoE driver linuxon is egy szálas, nade az hogy egy i7-en egy magot kikoppant és nem tekeri ki, na az nekem is új (bár eddig nem is nagyon próbáltam ezt).
> Ha valakinek van értelmes magyarázata erre, vagy ötlete, kíváncsian hallgatom.
A "linuxon" itt mit jelent? Ugyanazon a gépen linux-szal vagy pedig egy routeren amin ugye linux van?
EDIT: jah "i7-en" szóval nyilván nem router...
-
alvardes
csendes újonc
válasz
JustGamer
#103602
üzenetére
> kép: [link] De az is boztos hogy az a port beállítás is legalább 3 éve így van.
Az első forwardingnál miért 0-as forrásportra korlátozod a szabályt? Egyébként is szabálytalan a 0-ás port használata, de egy általános szerver-kliens port forwardnál felesleges a forrás portra szűrni/korlátozást alkalmazni a szabályban.
A másik ami ugye érdekes lehet még (és bármennyire ciki ezt én is besz*tam már túl sokszor ) az a helyi gépen a tűzfalszabályok. Biztos nyitva van (minden) tűzfalon az a port a bejövő kapcsolatokra?
-
alvardes
csendes újonc
> Utána kézzel kellett csatlakoznom sajnos.
Hát igen, ha 0-ra veszük az lcp-echo-faiulre-t akkor ez van :\
Valami adatforgalom volt akkor?
Van egyébként az openwrt-s ppp-ben adaptive_echo:
https://github.com/openwrt/openwrt/tree/master/package/network/services/ppp/patches
A luciban a kapcsolat advanced settings részénél nem lehet beálltani, nincs ilyen opció?
Ha nincs akkor elvileg be ssh-zva kézzel szerkesztve a config fájlt elvileg be tudod kapcsolni. https://openwrt.org/docs/guide-user/network/wan/wan_interface_protocols
(Sajnos, hogy pontosan, hogy kell azt nem tudom
)Amit én még megpróbálnék az az, hogy meghagynám 20 vagy 10 másodpercre az lcp-echo-intervalt visszaraknám az lcp-echo-failure-t 10-re. (ez 1 vagy 2 perc alatti újracsatlakozást jelent) és bekapcsolnám az adaptive echo-t és ami még nagyon fontos beálltanék egy scriptet, hogy egy loopban folyamatosan megnyissa a google.com-nak a kezdőoldalát. Alternatíva lehet, ha valami más TCP alapú adatforgalmat csinálsz folyamatosan.
Ilyenkor ugye az adaptive echo miatt lcp echo request miatt nem szakadhatna meg a kapcsolat. Még akkor sem ha csomagvesztés van. A TCP miatt ugye az elveszett csomagok újraküldésre kerülnének. (ezért fontos, hogy valami TCP alapú dolog legyen amit folyamatosan loopolsz).
2 lehetőség van:
* Ettől megjavul. Ekkor csak bizonyos időközönként esik ki valamivel több (lcp echo) csomag.
* Teljes szakadás van. A TCP-s kérésed egyszercsak nem kap több bejövő forgalmat, ekkor a router adaptiv_echo alapján elkezdi újra lcp echo-val tesztelni a linket. Teljes szakadásnál nyílván az sem fog menni. Ekkor újracsatlakozik.Ha ezt megcsinálnád akkor már legalább az kiderülne, hogy ilyenkor a teljes kapcsolat tényleg megszakad vagy csak egyes (lcp echo reply) csomagok vesznek el.
(Sima ICMP echot nyomni folyamatosan egy loopban nem jó mert az nem TCP alapú így ott nincs retransmission.)
Ha ugye kiderül, hogy teljes szakadás van időnként az viszont biztosan a digi oldalán lévő hibát jelez. (Bár ha windows alól jó akkor remélhetőleg nem ez a baj. Az a baj, hogy pontosan nem tudom, hogy az ottani pppoe clientnek mi a beállítása erre vonatkozólag. :\ )
-
alvardes
csendes újonc
Szívesen
; még annyit, hogy:Amúgy van egy olyan (nem standard hanem patchcsel behozott) beállítási lehetőség is, hogy "lcp-echo-adaptive". Ez ha van bejövő adatforgalom a linken nem echozik és így echo failure alapján nem is bontja a kapcsolatot. Akkor kezd csak ez echozni ha nincs amúgy adatforgalom.
https://gitlab.labs.nic.cz/turris/openwrt/commit/c617d28017748e65beddeaf1805abf55c86ceb9e
Amit kiemelnék a commit messageből az ez:
When adaptive LCP echo is enabled, LCP echo requests are only sent if the link is idle, this avoids the common situation where a congested PPP link (e.g. during torrenting) is falsely detected as disconnected because the LCP replies are not received in time.
Hát igen. Az első dolog minden hálózatos könyvben az, hogy:
A csomagok:
* elveszhetnek/nem érkeznek meg
* több mint egyszer érkeznek meg
* különböző útvonalon utazhatnak
* fordított/más sorrendben érkeznek meg mint ahogy el lettek küldve
* fel is lehetnek darabolva. (és még pláne ezek a darabok is fordítva is megérkezhetnek
)Ha a lépcsőházi OLT-nek van egy 10Gbites uplinkje és van rajta 15 gigabites előfizető akkor simán előfordulhat olyan, hogy ez az uplink tele lesz. Még ha el is jut az echo request ilyenkor a szerverhez és az küld is vissza egy echo reply-t akkor is szerencsétlen közbülső router az OLT elött mit csináljon vele ha egyszerűen nem fér bele az OLT irányába menő linkbe? Hát eldobja
>Csak miért lehet hogy ez csak február óta jelentkezik?
Hát most kezdtek el pont elveszni azok a csomagok kellően ütemesen
Biztos lett hozzá elég előfizető. Amúgy a sebesség tekintetében 800-900-as letöltési sebesség megvan? Ha nem akkor az annak is lehet a jele, hogy valahol az előfizető(k) felé már túl keskeny valamelyik link, vagyis túl sok az előfizető.>Mennyire állítsam akkor hogy ha megszakad akkor azonnal csatlakozzon? A gyári fw-vel ha volt szakadás nagyon gyorsan csatlakozott, kb azonnal.
Igen meg ha nem volt válasz akkor is azonnal újracsatlakozott. Az adaptive-echo tényleg megoldaná ezt de ez nincs benne a mainline-ban.
Nincs mágikus érték. Én 20 és 15-re állítanám.>Azt szeretném elérni hogy ne szakadozzon le.
Elvileg ugye a te routered bontja a kapcsolatot mert azt hiszi meg szakadt. Amúgy nem szakadna meg. Tényleg az adaptiv-echo lenne erre a helyes megoldás.
-
alvardes
csendes újonc
>Eddig csak TP-link routerekkel próbáltam a dolgot, lehet ez a hiba?
Igen lehet. A saját tapasztalatom is az egyébként, hogy ezeket a hibaüzeneteket én is rendszeresen láttam a saját régi 1043ND v2-es routeremben.
>A "Wan Connection Mode:" az "Connect on Demand" -on van, a "Max Idle Time: " az pedig nulla. Mindig is azon volt. Ezen kellene változtatni?
Nem ezek nem azok. Ha jól láttam a kódban akkor ezek nem megváltoztatható config beállítások a TP link gyári firmware-ben.
>Közben felraktam a TP-LINK WDR3600-ra a Vargalex-es openwrt-t.
Tegnap én is megnéztem otthon az openwrts routerben mi van beálltva: nálam, az lcp-echo-interval 20-ra volt állítva az lcp-echo-failure pedig 0-ra. Én ezeket a beállításokat nem módosítottam openwrtben szóval nekem mikor beállítottam lucival a PPPoE kapcsolatot ezek lettek az alapértelmezések.
Oda is van írva magyarázatként a rublika alá, hogy ha valamelyik 0-ra van állítva az kikapcsolja azt, hogy lcp echo failure esetén bontottnak érzékelje a kapcsolatot.Nálam ez működött úgy egy ideje. Viszont ha jól értem ha ténylegesen megszakad valami miatt a kapcsolat akkor ezekkel a beállításokkal nem fog soha újracsatlakozni.
Akármire is állítod, a két érték szorzata ideig nem lesz újracsatlakozás ha valami miatt ténylegesen megszakad, ezt tudd!
Én az lcp echo intervalt valami 10-300 közötti értékre állítanám de inkább 10-120 közé. A failure threshold meg lehet valami 10-30.
A 80, 20-as beállítással 80 echo failure után fogja bontottnak/megszakadtnak venni a kapcsolatot. 20 másodpercenkénti echo-kal ez 26 perces downtime egy tényleges megszakadás után
. Te tudod mekkora a toleranciád. Lényegében az elveszett echo reply-ok és a gyors kapcsolatmegszakadás/újratárcsázás között kell egyensúlyt teremtened.
Az alapértelmezett értékek azt hiszem 60 és 10 tehát az lcp-echo-interval az 60 az lcp-echo-failure pedig 10. Mondjuk én a 60-at már kicsit soknak érzem. Meg ugye ennek a szorzata is 10 percre jön ki ami szerintem kicsit túl sok. :\
A TP LINK-es alapbeállítás a másodpercenkénti echo-val amire ha 5ször nem érkezik válasz akkor újratárcsáz szerintem kicsit túl agresszív.
>Csak fura hogy a másik tp-link amin openwrt van azzal is szakadt
Azon mire voltak ezek a beállítások állítva?
-
alvardes
csendes újonc
válasz
alvardes
#79737
üzenetére
Megnéztem egy régebbi tp link router forráskódját (az 1043nd v2-t az újabb archer c7 helyett). Ott ténylegesen 13 ennek a hibának a kódja. Valószínűleg egy régebbi routered van.
Próbálj meg esetleg firmware-t frissíteni egy újabbra hátha ott javították.
Amúgy ha beírod a googleba, hogy "pppoe lcp-echo-interval" akkor találhatsz egy rakat találatot arról, hogy szakadozik az ADSL, PPPoE kapcsolat és ha jól látom ahol lett megoldás ott az lett, hogy ezeket az értékeket állították át nagyobbra.
-
alvardes
csendes újonc
Szia
Apr 2 12:12:44
PPP
INFO
send_phase 2196 pppd_phase = 0xdEz egy nagyon érdekes hibaüzenet. Ha megnézed akkor ilyen "phase" (13-as idjű) nincsen a pppd-ben. Lásd itt:
https://github.com/wkz/pppd/blob/master/pppd/pppd.h#L375
Ha a TP LINK weboldáláról letöltök a router GPL forráskódját akkor viszont ebben a fájlban más van, át lett írva, van egy ilyen benne:
//added by yangxv for lcp-echo-request time out, 2008.05.09
//脰禄脢脟脦陋脕脣路艙卤茫拢卢脣霉脪脭露拧脪氓碌艙脮芒脌茂拢卢虏垄虏禄脢脟PPPD脢鹿脫脙碌艙碌脛脪禄啪枚脳沤脤卢拢卢虏禄禄谩啪脛卤盲脮没啪枚鲁脤脨貌碌脛phase
#define PHASE_REQTIMEOUT 113ez már legalább phase és 13-ra végződik
Ez alapján a PPPOE szervertől nem jött az LCP echo requestre válasz.
Ráadásul a konfigban ez van:
lcp-echo-failure 5
lcp-echo-interval 1Ha jól értem ez azt jelenti, hogy az alapértelmezés 60 másodperc helyett másodpercenként baszogatja a PPPOE szervert. Lehet, hogy ez a másik oldalnak nem tetszik. Vagy egyszerűen csak annyi van hogy 5 alkalommal elveszik a válasz pl
Megnéztem egy régebbi tp link router forráskódját (az 1043nd v2-t az újabb archer c7 helyett). Ott ténylegesen 13 ennek a hibának a kódja. Valószínűleg egy régebbi routered van.
Próbálj meg esetleg firmware-t frissíteni egy újabbra hátha ott javították.
Amúgy ha beírod a googleba, "hogy pppoe lcp-echo-interval" akkor találhatsz egy rakat találatot arról, hogy szakadozik az ADSL, PPPoE kapcsolat és ha jól látom ahol lett megoldás ott az lett, hogy ezeket az értékeket állították át nagyobbra.A szerző kérésére módosítva.
[ Módosította: Intruder2k5 ]
)
; még annyit, hogy:
)
Aktív témák
Olvasd el az összefoglalót!
Társtopikok:
● DIGI kábel TV
● DIGI Mobil
● DIGI műholdas TV
● DIGI vezetékes telefon
Router kérdésekkel ezekbe a topikokba fáradjatok!
● Milyen routert?
● Router gondok
- BESZÁMÍTÁS! Asrock B450M R5 5500 16GB DDR4 512GB SSD GTX 1660 Super 6GB Zalman T3 Plus DeepCool 400W
- Gamer PC-Számítógép! Felsőkategória! R7 9800X3D / RX 9070XT / 32GB DDR5 / 2TB SSD / Noctua !
- Apple iPhone 12 128GB,Újszerű,Dobozaval,12 hónap garanciával
- BESZÁMÍTÁS! ASUS H110M i3 6100T 8GB DDR4 250GB SSD GTX 1050 Ti 4GB Kolink Inspire K2 aRGB 400W
- Apple Watch Series 10 46mm Jet Black használt karcmentes 100% akku garancia 2026.10.26.-ig
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest