-
IT café
DIGI internet Gyakran Ismételt Kérdések
(Kattints az Összefoglaló kinyitása feliratra!)
Utolsó frissítés: 2024. február
Új hozzászólás Aktív témák
-
McLaca
őstag
Az a feladó fog látszani, amit Te megadtál, ha freemailest adsz meg, akkor az.
cannyon#3231: ezeket hol látod összesítve a torrent progiban?
Üdv!
A magyar nyelvben nincs -al, -el rag. Van helyette -val és -vel. Ha nem vagy biztos benne, hogyan írd, inkább olvass utána: http://helyesiras.mta.hu/helyesiras/default/akh
-
McLaca
őstag
Nekem sehogy se megy szinkronban a max. Vagy fel, vagy le, de ha mindkét irányban töltök, a fel és letöltésem összege a lefelé sávszélem lesz, és 3/4 - 1/4 arányban oszlik el a letöltés javára (jelenleg 15/5). Routerrel, vagy anélkül, kényszerített 100Mb full duplexszel, vagy automatikus detektálással egyaránt.
Üdv!
A magyar nyelvben nincs -al, -el rag. Van helyette -val és -vel. Ha nem vagy biztos benne, hogyan írd, inkább olvass utána: http://helyesiras.mta.hu/helyesiras/default/akh
-
Dot
őstag
Nekem routerrel most királyul megy!!! az 1ik gépen nyomatom a seed-et 23Mbittel, a másikon töltök le 48Mbittel! 2-2Mbit odavész naés? Egyébként a routerem: Belkin N1 vision 27800Ft volt de megérte
élj a mának! sz@rd le a holnapot! szidd a tegnapot!!
-
MDanny
senior tag
Gyarmat utca FTTH stabil, sebesség legtöbbször a kínált. Szentmihályi út FTTB stabil, sebesség legtöbbször éppen a garantált felett.
Vajon ez a zuglói hálózatépítés valaha be lesz fejezve? Olyan helyeken is fent van a kábel dobozolva, ahol mindkét vége üresen végződik és a közelben sincs földkábel. A Tihany utcában készült útburkolat alatti átvezetés és a Zsálya utcában trolivezeték feletti. A 77-es troli külső hurkon belüli terület nincsen összekötve a gerinccel, pedig a felsővezeték tartóoszlopait is használták, ezzel együtt a külső oldal sem üzemel, viszont ugyanerről a gerincről üzemel a Mogyoródi út páratlan oldala a pataktól a Cinkotai útig. Itt valami nagyon nem úgy sikerült, ahogy szerették volna, az elején nagy volt a lendület, azóta is csak olyan címek kerültek fel újonnan, ahol az épületek falán vagy segédoszlop használatával el tudták vezetni a kábelt.
Xiaomi 11 Lite 5G NE 8/128GB EEA (Yettel VoLTE + Vodafone VoLTE), POCO F3 8/256GB EEA (Telekom VoWiFi); DIGI 1000/300 FTTH, Telekom 250/10 ED3 + Telekom TV M, Direct One Plus HD TV
-
MDanny
senior tag
Szomszédok nem tapasztalják? Mindenképpen jelentsd be a hibát és ragaszkodj a kiszálláshoz, hiszen ha folyamatosan leszakad, akkor talán a kiszálláskor is tapasztalható lesz. Persze csak akkor, ha Nálad minden csatlakozó és saját eszköz biztosan jó. Valószínű be fogják lengetni, hogy ha kimennek és nem találnak hibát, akkor önköltséges lesz a kiszállás.
Xiaomi 11 Lite 5G NE 8/128GB EEA (Yettel VoLTE + Vodafone VoLTE), POCO F3 8/256GB EEA (Telekom VoWiFi); DIGI 1000/300 FTTH, Telekom 250/10 ED3 + Telekom TV M, Direct One Plus HD TV
-
#42556672
törölt tag
Nyilván ebben a helyzetben amiben vannak nem tudnak/akarnak kötbért fizetni tömegesen. Hidd el pontosan tudják, hogy igazad van vagy sem, látják a hálózati eszközeiken a forgalmat. Egy cég etikus működése és felhasználóbarát hozzáállása nem akkor derül ki amikor nincs gond hanem most.
Ne engedd, hogy lezárják a hibajegyet és kérd el a hangfelvételt a későbbi bizonyíthatóság miatt. Azt meg lehet érteni, hogy most döcög mert alulméretezték azonban van egy szerződésben vállalt kötelezettségük kötbér jár ha nem tartják be...ne aggódj rajtad az utolsó fillért is behajtanák!
-
adika4444
addikt
-
LoyalGuard
tag
Szia!
Nálam március 6.-án kötötték be, de kb 2 napja jelentkezett ez a leszakadozás, mondjuk még a routerben turkálok hogy hol a hiba.
Kellemetlen ha call közben száll el minden...
Ma reggel 8-9 körül egyszer, majd most 14.30 körül. 13.ker.[ Szerkesztve ]
"A pénztártól való távozás után reklamációt nem fogadunk el!" - Ősi kínai mondás
-
adika4444
addikt
Lehet rossz felvetés, de ha az ÜFSZ csak egy eszközt lát nem lehet, hogy valakinél szarul van bekötve és cseszegeti a switch-en lógó többi eszközt? Pl. egy router LAN portja DHCP-vel, és egyéb finomságokkal. Közvetlen rákötött géppel ennek mondjuk hamar ki kell bukni.
Gépről amúgy meg lehet osztani a netet ha nagyon nélkülözhetetlen a többi eszközön.
üdv, adika4444
-
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 ]
-
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
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.
[ Szerkesztve ]
-
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. :\ )
[ Szerkesztve ]
-
trec12
addikt
-
adika4444
addikt
2018 őszén volt a vízválasztó, akkor volt egy elég durva dugulás / lassulás az október 23-ai hétvégén, nekem azóta rémlik rendszeresen gond. Én 2016 óta vagyok DIGI-s, az a két és fél év maga volt a kánaán, tényleg kb. soha semmi gond nem volt, azóta viszont egyre sűrűbbek a problémák, főleg tavaly decembertől.
Hogy pozitívumot is írjak, elindítottam egy pingelést, 500 csomagnál jár, és 6 ms fölé nem megy a bix.hu felé. Ez mindenképp haladás, ilyen jó eredményt eddig nem nagyon értem el még hajnalban sem.
üdv, adika4444
-
-
Dragon3000
veterán
Nem tudom, nálam nem történt változás, gigabites fttb-ről kötöttek át gigabites ftth-ra, így még várnom se kellett a sebesség növekedésre és plusz szolgáltatást sem aktiváltak. Itt még papír alapon kellett aláírni, így meg is tudtam nézni, hogy mi szerepel rajta.
[ Szerkesztve ]
-
Dragon3000
veterán
Milyen gépekkel mérsz, meg ez a senkinek nem megy annyival, azért mert pár embernél vannak gondok erős túlzás. Amúgy ha neked elég a 100/100, akkor nem tudom mi a gondod, elvégre ugyanannyiért kapod az 1000/300-at, ami megy többel, egyelőre kérdés, hogy digi oldalon van gond, vagy a Te hardvereid gyengék. A telefon miatt meg hívd őket, hogy miért került be.
[ Szerkesztve ]
-
adika4444
addikt
-
ElektrikusDE
senior tag
Szia!
Speedtest alkalmazásból mérve:
Böngészőből mérve:
Ennyit számít a gép! (C2 Quad több mint 10 éves gépem van)
Ui:
Romániai DIGI előfizetésem van! (RCS RDS)
A feltöltési sebességem nem tipikus!
Még Romániában sem!
[ Szerkesztve ]
“Lex malla, lex nulla. A bad law is no law.” A rossz törvény, nem törvény! DW: The Moment is Coming || Doctor Who BBC www.youtube.com/watch?v=uZAO6E2x9xs
-
Dragon3000
veterán
Ha visszarakod a routerre a gyári firmware-t, és az építi majd fel a kapcsolatot, akkor a gépen is mehet nagyobb értékkel, mert nem fogja még ez is terhelni, de ez majd akkor kiderül. A toldás lényegtelen, ha azzal gond lenne, akkor nem menne gigabittel a link és max 95-96Mbps-t mérnél.
Új hozzászólás 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
- Kerékpárosok, bringások ide!
- iRacing.com - a legélethűbb -online- autós szimulátor bajnokság
- Bivalyerős lett a Poco F6 és F6 Pro
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Ukrajnai háború
- Tenisz topic
- sziku69: Szólánc.
- Azonnali VGA-s kérdések órája
- exHWSW - Értünk mindenhez IS
- Politika
- További aktív témák...
- Lenovo ideapad C340 / i3-10110U / 8 GB / 1 TB SSD / FullHD érintőkijelző
- RAZER BlackWidow V4
- Eladó/cserélhető iPad Pro (2018) 11", 64 GB, WiFi, Space Gray, 94% BH + tok
- Dell UltraSharp U2415b, AH-IPS, 100% sRGB, FHD+, pivot talp, számla +garancia 1 év
- Acer Predator Helios 500 - 17"- GTX 1070 - Gamer
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen