- Samsung Galaxy Watch4 és Watch4 Classic - próbawearzió
- Samsung Galaxy Watch6 Classic - tekerd!
- Xiaomi 14T Pro - teljes a család?
- Elite szett, óriás telep és szuperfényes kijelző
- Xiaomi 15 Ultra - kamera, telefon
- VoLTE/VoWiFi
- Szívós, szép és kitartó az új OnePlus óra
- Motorola Razr 60 Ultra - ez a kagyló könnyen megfő
- Honor Magic6 Pro - kör közepén számok
- Xiaomi 14 - párátlanul jó lehetne
Új hozzászólás Aktív témák
-
dchard
veterán
válasz
AstraCDX
#2867
üzenetére
A helyzet nagyon egyszerű: ha a sebesség router nélkül normális, akkor egyértelműen a routerrel van a gond.
Átállítottad a modemet bridged módba és a router végzi a PPPoE tárcsázást ahogyan írtam? Ha nem, akkor tedd meg. Ezen kívül a routerben a PPPoE beállításoknál állítsd az MTU-t 1492-re, illetve kapcsolj ki minden fölösleges dolgot (QSS, UPNP, QoS, tűzfal és minden hasonló fölösleges baromságot). Ha ez sem segít, akkor érdemes lehet még más FW-t kipróbálni a routeren, akár nem gyárit is. Ha ez sem segít, akkor másik router a megoldás.
Dchard
-
dchard
veterán
válasz
AstraCDX
#2859
üzenetére
Ne tedd, nem elég erős hozzá. 380T-ben a DHCP szervert letiltani, majd berakni a router van portjára, hadd tárcsázzon.
Ha így is el akarod érni, ahhoz át kell állítanod a modem IP címét mondjuk eggyel nagyobbra, majd a WAN portot berakni ugyanabba a VLAN-ba, amiben a LAN portok is vannak, Így továbbra is a router fog tárcsázni, de modem elérhető marad a belső hálózatról a router mögül is. Ehhez általában a gyári FW a routeren kevés, ddwrt vagy sokkal inkább openwrt kell hozzá.
Dchard
-
dchard
veterán
válasz
AstraCDX
#2856
üzenetére
A 380T ha úgy van beállítva, képes routolni, maga végzi a PPPoE tárcsázást és ő ad címet a mögé dugott eszközönek. Ha ez egy router WAN portja ahol dinamikus címlekérést állítottál be, akkor merő véletelnségből működhet így a dolog. Valószínűleg a routered és a modem is a 192.168.1.1-es címen érhető el, ez pedig címütközés.
Mindazonáltal ez nem helyes beállítás. A modemben lévő DHCP szervert le kell tiltani, majd bridged módba állítani, és a routeren beállítani a PPPoE tárcsázást.
Dchard
-
dchard
veterán
válasz
csacsa72
#2847
üzenetére
A ZTE eszközödben is Broadcom chipset van, akárcsak a 321B-ben (a fejlettebb VDSL2-t ismerő verzió, BCM6368). Ezért ha probléma van, az inkább vonali hiba lehet. Esetedben azt mondanám, hogy határ eset vagy távolság ügyileg, igazából örülhetsz, hogy erre a vonalra megkötötték a 20megás VDSL2-t, mert ugyanez a csomag ADSL2+ technikával nem menne ennyivel.
Esetleg a háztartás telefonhálózatát érdemes átnézni, és a modemet olyan közel vinni az átadási ponthoz, amennyire csak lehet, megszüntetni minden toldást, ha pedig VOIP telefon van, a szűrő sem kell.
Dchard
-
dchard
veterán
válasz
csacsa72
#2845
üzenetére
A DSl-321B maximum 20megás ADSL2+-hoz jó. Általában a VDSL portok képesek érzékelni, hogy régebbi modem van rajtuk és modulációs technikát váltanak a kompatibilitás miatt. De ha a szolgáltató kényszeríti a DSLAM portot, akkor előfordulhat, hogy a VDSL2-re állított port kizárólag VDSL2 módban fog összeállni.
Dchard
-
dchard
veterán
válasz
ssarosi
#2843
üzenetére
A tuti megoldás a zaj ellen az árnyékolt (fali) FTP vagy SFTp kábel. A másik még ennél is jobb megoldás, hogy olyan közel helyezed a modemet az átadási ponthoz amilyen közel csak lehet és olyan rövid kábellel, amilyen röviddel csak lehet, onnan pedig etherneten viszed oda, ahova jól esik. Én ezt ajánlom, és akkor a printer kábelt sem kell cserélned.
Ha esőkor romlás van az több minden is lehet, leginkább beázó, párától nedvesedő kötés. A kábel kapacitása az esőtől nem változik.
Dchard
-
dchard
veterán
válasz
zyndian
#2833
üzenetére
Mindenképpen maradjon így, mert jól láthatóan nőtt az SNR margin és az adásszint is. Várható volt, mivel így a kapcsolat a spektrum használható részében koncentrálódik. De ez még mindig kevés az 5 megához, mert:
A problémám továbbra is ezzel a homorú jelalakkal van: a vonalt átviteli karakterisztikája a kép alapján jó, és zaj sincs ehhez hasonló, mégis ott van. És a jellegéből leginkább az átviteli karakterisztika hibájára tudok gyanakodni, ami leginkább hibás kötés, kábel vagy egyéb kontakt jellegű hibára utal.
Én azt javaslom, hogy az első képen a piros-piros (1) és a fehér-fehér (2) kábeleket közvetlenül kösd össze, lehetőleg forraszd és szigeteld le. Mivel azért van zaj is, a nem használt érpárokat érdemes közösíteni (az összeset, beleértve a szolgáltatótól jövőket is!) és földelni. A legegyszerűbb, ha a szolgáltatótól jövő (3,4,5,6) kábeleket közösíted a jobb oldali fekete és szürke vezetékekkel, majd bent a lakásban a kötődoboznál (második kép) a szürke-fekete kábelt az árnyékoló fóliával együtt földeled. A föld lehet fém fűtéscső (a festéket ilyenkor le kell kaparni), vagy a konnektor földje is, ha rendesen földelt a hálózat.
Ezen túl, ha már átellenőriztél mindent, akkor valahol feljebb a hálózatban van ez a probléma: például egy eloxidált kötés, vagy kábelhiba, ezt csak a szolgáltató tudja elhárítani. Hangsúlyozom: az 5megára elsősorban akkor van esély, ha az a borzalmas átviteli hiba eltűnik a képből.
Dchard
-
dchard
veterán
válasz
zyndian
#2830
üzenetére
Ezen önmagában a paraméterezés biztosan nem segít. Borzalmasan nagy a csillapítás (messze vagy a DSLAM-től), de ami ennél érdekesebb az a hupli a 128-as vivő környékén: sem a frekvencia menet, sem a zaj karakterisztika nem indokolja ezt.
Én első körben átnézném a házban az összes kötést és csatlakozást (különösképpen a padláson, vagy a ház falán lévő kötődobozban ahol megérkezik a föld vagy légkábel), illetve mindenképpen ki kellene próbálni úgy, hogy a modemet rögtön a bejövő kábel végére rakod mindenféle elosztás, toldás, szűrő stb. nélkül.
A másik, hogy a DMT-s monitorozást érdemes lehet többször is megismételni, hogy nagyobb legyen az átfogás időben. Illetve mivel ilyen brutálisan nagy a csillapítás, én átraknám ADSL2+-ról ADSL2-re, hogy meg se próbálja a magasabb frekin lévő vivőket használni.
A lényeg, hogy ezeket próbáld ki, és csináld a képeket meg a DMT-s mérést (a képek elegek, nem kell a szöveges részeket is kilistázni).
Dchard
-
dchard
veterán
A kossuth rádió által érintett két vivőt biztosan érdemes lenne kizárni, a többi viszont inkább áthallási zajnak tűnik, amit a törzskábelen szed össze a kapcsolat, azzal nem tudsz mit kezdeni.
Továbbra is azt gondolom, hogy ezen a vonalon legalább 8-9megával mennie kéne a dolognak, de kis szerencsével a 10-nek is mennie kellene. Régen hasonló(an szar) vonalam volt, de a 10megát ki lehetett belőle préselni. Igaz akkor még nem volt DSM, ami eltekergette a vonalak paramétereit, mint most...
Dchard
-
dchard
veterán
válasz
zyndian
#2824
üzenetére
Nálam chrome alatt tökéletes, de IE alatt mindig is szar volt.
Annyit tudok mondani, hogy táveléréssel rá tudok nézni, vajon a változó értékeket miért nem írja ki. Én nem hiszem, hogy ez magától megoldódik, és kíváncsi lennék az okára. Lehet, hogy valami új HW verzió ez a modem, bár ha a board és a flash ID is támogatott, akkor tökéletesen mennie kéne...
Persze ehhez kell egy működő netkapcsolat meg egy router.
Dchard
-
dchard
veterán
válasz
zyndian
#2822
üzenetére
Értem.
És a DSL beállításokon kívül próbáltál még bármi más paramétert megváltoztatni? Úgy értem, hogy a modem elindul, belépsz weben, beállítod a DSL beálltásokat, Save, és ez az eredmény, vagy előtte még más dologkat is bizeráltál?
Egyébként olybá tűnik, mintha nem volna hajlandó a flash memóriába írni a paramétereket.
Dchard
-
dchard
veterán
válasz
zyndian
#2818
üzenetére
Ennél pontosabban kéne leírni a problémát:
Tehát sikerült felraknod a FW-t, el is indul, odamész a DSL beállításokat tartalmazó oldalra, elvégezd a leírás szerinti (!!!) beállításokat, majd rányomsz a Save gombra. Pontosan mi történik ezután? Kiírja hogy saving data, de soha nem kapod vissza a beállító panelt? Vagy visszakapod a panelt, de újraindítás után még mindig nem működik a DSL kapcsolat?
Képekkel, esetleg videóval illusztrálva jó volna látni, pontosan mi történik. Pár ezren használják ezt a szoftvert, de ilyen hiba még soha nem fordult elő.
Dchard
-
#2816
dchard
veterán
adriankoooo
#2815
dchard
veterán
válasz
adriankoooo
#2815
üzenetére
Neked most 20megás kapcsolatod van, nem tudom mire fizettél elő, de ezek a 20megás előfizuhoz tartozó értékek.
Ha a DSLAM VDSL2 képes, akkor már fizethetsz is elő. Telefonálj be és kérdezd meg.
Dchard
-
#2814
dchard
veterán
adriankoooo
#2813
dchard
veterán
válasz
adriankoooo
#2813
üzenetére
Jól sejted, ezen nincs mit optimalizálni. Egy kezemen meg tudom számolni, hogy hány ADSL2+ vonalon láttam életemben 20megánál nagyobb vonali sebességet a tesztlaboron kívül. A te 23megád gyakorlatilag a legjobb amit eddig valaha éles hálózaton láttam.
Szerintem örüljél és ne piszkáld.
Viszont jó hír, hogy ha elérhető gyorsabb csomag (30/5), az is menni fog minden további nélkül. Szerencséd van.
Dchard
-
#2812
dchard
veterán
adriankoooo
#2811
dchard
veterán
válasz
adriankoooo
#2811
üzenetére
Nem javaslok túl sok kísérletezést. Első körben gyári értékekkel készíts vonaldiagnosztikát (modem webes felületén a Status --> DSL status alatt látható négy grafikon + ugyanitt alul az Info gomb teljes kimenete), az alapján lehet tovább haladni.
A modemben összesen 6MB memória van, mire számítottál? A gyári szoftverben még ennyi sem volt.
Dchard
-
#2810
dchard
veterán
adriankoooo
#2809
dchard
veterán
válasz
adriankoooo
#2809
üzenetére
Az új fw-rel a modem kizárólag bridge módot tud, ergó igen: a router fog tárcsázni. Az MTU-t edig a routerben kell beállítani. A többi paraméter az ADSL fizikai rétegére vonatkozik, így nincs jelentősége annak, hogy routert használsz-e vagy sem.
Dchard
-
-
dchard
veterán
Mert bizonyos esetekben a DSLAM nem tud különbséget tenni szakadás és áramtalanítás között, ennek eredménye pedig a visszakorlátozott sávszélesség lesz (a DSM azt látja hogy minden nap többször is "megszakad" a kapcsolat, ennek értelmében növeli az SNR margin-t, amitől lassul a sebesség).
Dchard
-
dchard
veterán
Tény, hogy nem éppen a szomszédban van a DSLAM, de ettől még legalább 3megával gyorsabbnak kéne lennie. A probléma forrása a DSM nevű rendszer, amely automatikusan igazít a vonalakon, ha azon nagy mértékű bithiba, netán szakadozás van. A gond az, hogy a DSM sokszor minden alap nélkül is beavatkozik. Nem kapcsolgattad ki a modemedet éjszakára például?
Amit ajánlani tudok: állítsd át a target SNR margin-r 130-ra, alkalmazás, újraindítás, és készítsd el a fenti képeket és az Info gomb kimenetét újra, és hagyd így néhány napig.
Dchard
-
dchard
veterán
Biztos hogy a képek készítése előtt a target margin vissza lett állítva 100-ra, mentés, és újraindítás megvolt?
Amúgy elég magas a csillapítás, de tény, hogy ennél gyorsabban kéne mennie. Szerintem itt a DSM korlátoz, láthatóan minden valódi ok nélkül. Ezért sem javult a helyzet az SNR margin állításával. Ez ellen nemigen lehet tenni semmit. Nézd át a lakás/ház telefonhálózatát, hátha lehet javítani rajta valamit (rövidíteni a modem és az átadási pont közötti távolságot).
Dchard
-
dchard
veterán
-
-
dchard
veterán
Az SNR ne tévesszen meg. Az értékek jók, ennek ellenére a DSM korlátozza a vonaladat: ezt a 9mega körüli vonali sebesség egyértelműen mutatja. Ennek a 10-es csomagnál 12.480-nak kéne lennie, amire a vonalad képes is. Ha most váltottál vissza akkor várni kell pár napig, és semmiképpen se áramtalanítsd a modemet, vagy húzd ki a telefonkábelt, mivel ezek a korlátozások általában szakadások környékén szoktak rákerülni a vonalra (persze számos esetet láttunk, amikor ez minden ok nélkül történt...).
Dchard
-
dchard
veterán
válasz
krobika
#2755
üzenetére
Sajnos simán el fogják utasítani, mivel 15-ös csomag nincs, a 20-ast pedig egyértelműen nem bírja, hacsak nincs más technológia is (kábelnet, vagy VDSL2). Sokszor még olyankor is elutasítják ha pontosan tisztában vagy vele, hogy csak 15mega fog jönni 20 helyett, és elfogadod ezt a helyzetet.
Dchard
-
dchard
veterán
válasz
vlaci79
#2750
üzenetére
Ezzel a módszerrel valószínűleg addig fogunk eljutni, hogy megállapítjuk: a gyári konfiggal le van tiltva benne a telnet/ssh. Ahhoz hogy érdemi munkát lehessen rajta végezni, itt kéne lennie az asztalomon.
De azért csak kipróbálom, hátha távolról is tudunk valamit mókolni, bár kicsi rá az esély.
Dchard
-
dchard
veterán
Mivel az új Speedport és a ZTE 931 lesznek a két hosszú távon velünk maradó eszközök, így megéri ebbe erőforrást ölni. Én többször is kértem, hogy ajánljanak fel ilyen eszközt, anélkül nem lehet hozzá támogatást írni. Nekem van ZTE 931-em, amihez egyszerűen lehet telnetet varázsolni, de a Speedportot mindenképpen kezelésbe kell venni, azon le van tiltva minden értelmes felület. AZ SNMP is max a DSL interfészen van egnedélyezve...
Dchard
-
dchard
veterán
Pénteken elküldöm neked a logokat a ZTE-ből amiket ígértem.
Egyetlen dolgot kéne még implementálni, a QLN monitor funkciót:
ha kiadod az "xdslctl qlnmntr --time 3600 --freq 4000" parancsot, a modem QLN teszt módba kapcsol egy óra erejéig másodpercenként 4000-szer vesz mintát a teljes spektrumból (ez a DSL szimbólumsebessége). Ilyenkor elég csak a QLN táblát pollingolni, valószínűleg lényegesen gyorsabban látszódnak majd a változások.
Ilyenkor a modem offline állapotba kerül, ebből az xdslctl connection --up paranccsal lehet kivenni, a mérés végén sem vált vissza magától!
Dchard
-
dchard
veterán
Küldök neked ilyet holnap.
Amivel mindenképpen érdemes lehet még kiegészíteni, az a diag megkezdése előtti saját parancs futtatási lehetőség. A broadcom parancsok nagy része szintaktikailag nagyon hasonló vagy ugyanaz, csak annyiban térnek el, hogy:
1. Van olyan modem, ahol ki kell adni az "sh" vagy más parancsokat, hogy rendes temrinált kapjon az ember.
2. Sok helyen más-más neve van a binárisnak: "adslctl" vagy "xdslctl" vagy "xdslcmd" vagy "adslcmd". Ezek mind szintaktikailag azonos kimenetet adnak, csak a nevük más.
Így az alkalmazásod szinte minden BCM képes modemmel kompatibilis lehet.
Dchard
-
dchard
veterán
Na ez az amit nem érdemes csinálni. Sokkal jobb megoldás scrollozni és megtartani az összes vivőt. Én így csinálom. Az átlagolás elkenhet furcsa hibákat és érdekes jelenségeket, amik például csak 1-1 vivőt érintenek. Csak azt kell megoldani, hogy a képernyőre így egyben ki nem férő adatokat a progiból el lehessen menteni egy PNG-be.
A vivők egyébként kapcsolat bontás esetén is adnak vissza értéket:
a bit és SNR 0-t, a QLN a következő sikeres újraszinkronizálásig az előző mérést tartalmazza, a Hlog szintén, meg az eleve nem változik. De ennél egyszerűbb ha az adslctl info --show parancsból szűrsz a kapcsolat állapotára és csak azoknak a lekérdezéseknek az adatait veszed figyelembe, ahol a kapcsolat állapota "showtime", ez jelenti ADSL-nél a connected vagy operational állapotot. Persze a QLN méréshez ezen majd változtatni kell, hiszen ott nem lesz showtime mód, de csak a QLN táblát kell pollingolni és a progi amúgy is tudni fogja, hogy most éppen QLN mérés van, hiszen onnan indítod el
Dchard
-
dchard
veterán
A forrást külön köszönöm, így könnyen lehet majd módosítani VDSL2-höz is. Ha gondolod tudok küldeni logokat róla és pikk pakk meg lehet írni a támogatást. Ugyanúgy néz ki mint ez, csak nem 512 elemű egy lekérdezés, hanem 4096. Meg a csillapításokat bandonként értelmezi, de ez semmi.
A mérések gyakoriságát le tudom tesztelni laborban, de nincs valami sok időm. Ha akarsz, gyere be hétfőn az egyetemre és szórakozhatsz a mérőkörrel, és nézegetheted milyen gyorsan jelenik meg a becsatolt zaj. Kipróbálhatod több FW verzióval is.
Dchard
-
dchard
veterán
Valóban létezik olyan beállítás amivel 10dB target margin és 20megás profil mellett tökéletes vonalon is csak 8mega jön ki, csakhogy itt a bitallokációs tábla is "összeesik", akárcsak az "SNR lock"-os eseteknél.
A kifejezést valóban én találtam ki, mivel ez írja le a lehető legjobban a jelenséget.
Ezt a DSM nevű rendszer csinálja, rosszul. És ráadásul nem is a magas tagret marginhoz "ragaszkodik" ahoygy írtad, ez már csak következmény de nem az ok.
Az oka az "SNR lock"-nál a mgas marginnak az, hogy a DSLAM-ben a porton fix sebesség limitet is be lehet adni, ezzel kényszerítik ki, hogy soha ne léphesd túl a sebességet amiért fizetsz. Namost ha egy vonal elbír 15megát, de én 10-re korlátozom, akkor az e fölött maradó minden bit tartalék lesz és növeli az SNR margin-t.
Lehet hogy az új Huawei DSLAM-ek valamit nem jól csinálnak és ez a furcsa helyzet áll elő?
Legyél már olyan jó és frissíts az általam írt firmware-re amiben lényegesen újabb BCM driverek vannak, nézd meg hogy azzal is csinálja-e. Lehet hogy a gyári szoftver szar. Eleve egy raklappal több paraméter érhető el, és ugyanúgy működni fog a házilag írt progid is, amit mellesleg közzétehetnél. A két FW parancs-kompatibilis.
Dchard
-
dchard
veterán
Mondjuk ha letagadják az hazugság. Emiatt bőven lehetne az NMHH-nál vagy a GVH-nál feljelentést tenni. Szerintem ha voltak is korábban ilyenek azok azért pattantak le, mert nem szakember fogalmazta meg a panaszt amiből egyértelműen látszik, hogy pontosan értjük a dolog működését így nem rázhatnak le egy ilyen kamu szöveggel, hogy nincs semmilyen korlát.
Én már többször mondtam, hogy szívesen átnézek és javítok, támogatok bármilyen beadványt, de mivel nekem nincs ilyen szolgáltatásom, így én feljelentést tenni nem tudok.
Dchard
-
-
dchard
veterán
" Eddig azt hittem, azt mutatja, hogy az egyes csatornákon aktuálisan hány bitet tud átvinni a modem ill. a DSLAM."
Nem. A bitallokációs tábla azt mutatja, hogy éppen hány bitet visznek (és nem vihetnek) át a vivők.
A vivőn átvihető maximális elméleti kapacitást úgy kapod meg, hogy a vivőn mért SNR-t elosztod hárommal, majd szigorúan lefelé kerekítesz. Ezt ugye zajtartalék nélkül kell érteni. Ha ebből kivonod a vivőhöz tartozó bitallokációs táblában lévő értéket és visszaszorzod 3-mal, akkor megkapod az adott vivőre vonatkozó aktuális zajtartalékot.
Példa: a vivőn 50-es SNR és 11 kódolt bit van:
50 / 3 = 16,66 --> 16
16 - 11 = 5 --> 5 x 3 = 15
tehát 50-es SNR és 11 kódolt bit mellett a vivőn 15dB tartalék van. A példa persze csal, hiszen lehet akármekkora az SNR, 15bitnél nem kódolható több adat egy szimbólumban. De azt hiszem a lényeget érted.Az SNR Margin amit a modem kiír egy aggregált és átlagolt érték az összes DS és US vivőre, azonban jó néha látni, hogy ez hogyan oszlik el. A szinkronizálás után nyilván arányos, de a különböző helyeken felbukkanó zajokkal ez változhat.
Nálad nincs egetrengető zaj. Nem mondom, hogy szép, de ez a pár dB változás mondhatni normális. Ha már átnézted a lakás hálózatot, akkor a zaj kívülről jön, nem tudsz vele mit kezdeni.
Dchard
-
dchard
veterán
Olyan nagy "beleböfögés" azért nincs. A probléma az hogy nem látom a zaj nagyságát, nem átlagot, hanem abszolút minimumot/maximumot kéne mérned. A jó időszakok adatai elhúzzák a mérési eredményt, mi nem erre vagyunk kíváncsiak.
A zaj forrását kéne megállapítani, és amennyire lehet eltűntetni.
Dchard
-
dchard
veterán
A QLN, vagy parasztosan magyarra fordítva "csendes vonali zaj" mérés akkor történik, amikor a vonal "csendes", vagyis nincs rajta aktív ADSL kapcsolat. Normális körülmények között a trainelés során 1-3 másodpercig mérik a modemek a spektrumot és azt látod a QLN táblában. Ellenben rá lehet kényszeríteni a modemet, hogy ezt egy meghatározott ideig - akár több óráig - csinálja. Ilyenkor változnak a QLN tábla értékei, már ha van változás a vonalat érő zajban.
Dchard
-
dchard
veterán
A problémának nincs köze a módosított fw-hez, mivel a driver és vele együtt a broadcom adslctl user space progi binárisa is eredeti, nincs hozzájuk forrás. Az egyetlen dolog amivel jobb felbontást lehet elérni az a zajvizsgáló funkció, de azt csak offline módban tudod használni, tehát ha elindítod, nem lesz DSL kapcsolat a mérés erejéig, és ott is csak 17 sec-enként frissül, ellenben magának a megjelenített mérésnek a felbontása már szimbólum sebességű. A zajvizsgálatot az
adslctl qlnmntr --start 60
paranccsal tudod elindítani, ilyenkor 60 másodpercig fut a mérés offline módban, és a QLN tábla lekérdezésével láthatod az eredményt. Kvázi spektrumanalizátort csinál a modemből. Épp most fejezem be a várhatóan utolsó FW verziót, ami ezt a mérést is tartalmazni fogja, így a DMT-re a továbbiakban nem lesz szükség.
Dchard
-
-
dchard
veterán
Bontsuk ketté a dolgot:
1. Az ADSL fizikai rétege, amint érzékeli a LOS-t, azonnal alaphelyzetbe áll, és ismét megkísérli a kézfogást és az újracsatlakozást. Meglehetősen jól definiált ez az állapot gép, nem láttam még ezzel kapcsolatban problémát.
2. A PC vagy router PPPoE része már lehet gázos, beragadhat a tárcsázási folyamat stb.
Szóval ha a modem a ledek alapján újrakapcsolódott, akkor érdemes ránézni a routerre, ami alap esetben always on, vagy auto reconnect vagy erre hajazó módba kell tenni (nem manual, vagy on demand módba).
Amenniyben a router nem kapcsolódik újra, akkor restart, illetve szoftver frissítés lehet a megoldás.
Persze előfordulhat, hogy a szélben folyamatosan elmozduló kötés vagy kábelhiba miatt egyszerűen álandóan szakad a kapcsolat, ezt a modem megfelelő állapot LED-jéből lehet kideríteni (a modem állandóan vagy sűrűn újraszinkronizál).
Dchard
-
dchard
veterán
Nekem volt szerencsém látni VDSL2-es porton működő ADSL2+ modemet minden további nélkül, műszaki okát sem látom, hogy miért ne menne. Persze létezhet olyan port konfiguráció, amikor egyszerűen letiltják az összes többi (nem VDSL) technológiát, de ez egyszerűen hibás gyakorlat, mivel az összes telekomos hardver kompatibilis visszafelé. A gyártók kínálatában sem láttam még olyan port kártyát, ami a VDSL2 mellett ne tudott volna ADSL2+-t, ADSL2-t, sőt G.DMT-t is.
Dchard
-
dchard
veterán
Ez nem magyarázat a problémára, mert:
1. A szürke 360R C3 pont ugyanúgy nem tud VDSL-t mint a feket 360R, akkor viszont miért működik?
2. És mert a VDSL-re húzott portok is fallback-elnek, ha a kézfogás során érzékelik, hogy a végberendezés nem támogatja a VDSL portokolt. Általában nem elsőre, de egy pár próbálkozás után jellemzően összeállnak 2+-on.Dchard
-
dchard
veterán
válasz
hosszug
#2679
üzenetére
A modemnek nyilván semmi baja, főleg akkor nem ha hoztak ők is és az sem ment. Az meg, hogy a régi szürkével megy, a feketével meg nem, egyenesen nevetséges.
Szerintem valamilyen konfigurációs probléma lehet a fekete 360R-rel, mást nem nagyon látok a háttérben.
A szolgáltatónak semmilyen módja nincs DSL technológiánál befolyásolni azt, hogy melyik eszköz képes felregisztrálni a hálózatra és melyik nem. Kizárólag olyan probléma lehet, ha mondjuk ADSL2+ módot kényszerítünk egy olyan DSLAM-en ami ezt nem tudja, vagy Annex A módot használunk miközben a DSLAM Annex B üzemmódon megy, esetleg az ATM beállítások nem stimmelnek.
Dchard
-
dchard
veterán
A modem valóban regisztrált szakadást, elfogadható magyarázat azonban nincsen rá, mivel a vonal fullos, nem látok semmilyen olyan problémát ami miatt ez előfordulhatna, zajtartalék is megfelelő mennyiségben áll rendelkezésre.
Esetleg kötési hiba valahol a hálózatban, ami egy kis szél hatására elmozdul annyira, hogy megszakad a kapcsolat. Nem tudom most mennyin áll az SNR margin a modem webes felületén de próbáld ki, hogy hozzáadsz 30-at, mentés, újraindítás és figyeled hogy mi történik.
Dchard
-
-
dchard
veterán
válasz
Hunsaman
#2651
üzenetére
Hát ez érdekes. Én azt mondanám told rá fel újra a firmware-t a leírás szerint. Ilyet nálam nem csinál, pedig egészen extrém terhelést totlok neki. Lehet hw hiba is a modemben.
Peltár:
360T-re nem jó az általam írt firmware, mivel ebben nem Broadcom, hanem Texsas Instruments chipset van.
360T-re a routertech által készített frmware jó, de meglehetősen macerás felrakni, és nem viszonylag kevés diag funkció érhető el benne. Az egyetlen dolog az ADSL2+ képesség amiért érdemes frissíteni. Itt egy videó arról hogyan kell:http://www.youtube.com/watch?v=-k9V3zL3PJ8
Dchard
-
dchard
veterán
válasz
Hunsaman
#2649
üzenetére
Ennél egy kicsit több infó kéne.
Milyen modem, mi van rajta, hogy van beállítva és mit csinálsz pontosan?
Ez egyébként akkor szokott előjönni, ha a modemet telneten és/vagy DMT-vel is basztatod, meg a webes interfészét is nyúzod. Ilyenkor a kevés memória miatt összeomlik a webszerver a modemen. Ugyanez a jelenség lehet akkor is, ha mondjuk a Status --> DSL status oldalon agyatlanul nyomkodod a frissítés gombot. A grafikonok kirajzolása elég sok memóriát megeszik, így ennek megint csak lehet webszerver összeomlás a vége.
Dchard
-
dchard
veterán
Kedves fórumlakók!
Elsősorban azokhoz fordulok, akik használják vagy korábban használták az általam írt firmware-t. Hosszú idő után úgy döntöttem, hogy érdemes lenne foglalkozni a szoftver fejlesztésével, mivel van néhány olyan funkció és hiba, amiket érdemes lenne kijavítani illetve létrehozni.
Ilyen probléma például a webes felület és a DMT párhuzamos használatakor fennálló összeomlás, illetve olyan funkciókat is szeretnék bevezetni, mint a webes felületről elérhető delta SNR és Bit monitorozás, valamint a delta QLN monitorozás, melyek lényegesen pontosabb képet adnak a vonal valódi állapotáról.
Ezeknek a funkcióknak a kivitelezéséhez viszont segítségre van szükségem. A fejlesztéshez használt eddigi modemem a közelmúltban elhalálozott, ami nélkül nem lehet érdemi munkát végezni a szoftveren. Ezért kérek mindenkit, hogy nézzen körül otthon: amennyiben van feleslegessé vált fekete színű 360R modemed és szívesen felajánlanád, akkor kérlek keress meg privátban.
Dchard
-
dchard
veterán
Ha volnál olyan jó és csinálnál egy nagy felbontású fotót a modem belsejéről akkor beljebb volnánk. A lényeg, hogy a chipeken látható feliratok olvashatóak legyenek. Nekem nagyon gyanús, hogy ebben nem broadcom chip van, ha pedig ez a helyzet akkor ez az első olyan 321B amivel nem fog menni a firmware-em.
Dchard
-
dchard
veterán
válasz
beldeczki
#2630
üzenetére
Hú, ez bitang szar.
Ugye nem volt vivőkizárás amíg a teszt futott?
Próbáljuk meg elemzeni a képet:
A minta alapján azt mondanám, hogy van legalább 4 zavarforrás, ami azért érdekes, mert elfogadható magyarázat csak az elsőre van: az a Kossuth rádió. De mivel már más adó nem üzemel az AM sávban, ezért a többi kérdéses.
Ezzel még lehetne együtt élni, de a brutális mértékű áthallási zajjal már nem annyira. Ráadásul érdekes, hogy azonos frekin is hullámzik a teljesítmény, pedig sima áthallásnál nem így kéne lennie.
Jól csináltad te azt a kábelezést? Nem lehet, hogy az egyik ér a DSL által használt érpárból véletlenül a földre ment?
Első körben mindenképpen csinálj SNR monitorozást úgy, hogy nincs vivőkizárás, margin 100, és a házilag barkácsolt föld nincs bekötve. Nekem gyanús, hogy a zaj egy része a lakás hálózatról érkezik, tehát a földelés nem igazán sikerült jól. És az SNR monitorozásnál tarts be a 3 órát, nem véletlenül kell annyinak lennie. Most szerencséd volt, mert a sárga kék csík ami elindul nem takarta ki az SNR monitorozás eredményét, de ez pusztán mázli. Természetesen megteheted azt, hogy 3 óra után megállítod, lemented a képet és indítasz még 3 órát.
Második körben győződj meg róla, hogy valóban nem a telefon érpár egyik tagját sikerült bekötni a földbe, és most az dsl egy nem használt éren megy félig. Igen, akár egyetlen éren is tud működni a dolog, de rettenetesen rossz lesz a sebesség és a stabilitás.
Dchard
-
-
dchard
veterán
A baj az, hogy a romlás mindkét irányban arányosan nagy és szembetűnő. Kevéssé hiszem, hogy ez házon belüli probléma lenne, de mindig ezzel kezdjük, hogy a szolgáltató ne passzolhasson le minket ilyen szöveggel. A biztonság kedvéért jó lenne egy köclsön modemmel is megnézni a csillapítás értékeket (akár régi szürke 360R + SM50B progival).
Tényleg úgy néz ki, mintha jelentősen nőtt volna a csillapítás, ennek pedig valami oka van. Ekkora növekedésnél én arra tippleke, hogy véletlenül átkötöttek másik DSLAM-re ami lényegesen távolabb van. Ne feledjük az SNR vagy a csillapítás is dB-ben van mérve ami nem lineáris hanem logaritmikus skála: 3dB változás a jelszint feleződését/duplázódását jelenti. A nálad mért változás pedig sokkal nagyobb egy vonalhibánál vagy kötési hibánál, ráadásul akkor nem csak lassulna a vonal, de szakadna is.
Dchard
-
dchard
veterán
A vonalon látványosan megnőtt a csillapítás, ezért tlejesít rosszabbul, mint korábban. A korábbi képek szerint lazán menne a 10mega.
Olyan mintha átkötöttek volna egy távolabbi alközpontra ami elég furcsa, mert éppen fordítva szokták, nem cél az hogy elrontsák a kapcsolatot. Hacsak nem valami kábelezési hiba, eloxidált kötés vagy ehhez haosnló okozza a gondot. Először házon belül néznék szét, hátha valami laza csatlakozó vagy beázott kábelcsatlakozás (családi háznál külső falon). Az a baj, hoyg a képeket hiába mutogatod nekik, nem tudják azt értelmezni, nem értenek hozzá ezen a szinten.
Dchard
-
dchard
veterán
-
dchard
veterán
válasz
razor01
#2605
üzenetére
Semmit, ez a vonal ennyit tud.
trance89:
Legalább butaságot ne beszélj, ha már tanácsot adsz. Világosan le van írva, hogy akkor csökkentünk SNR Margint (és nem SNR-t), ha a vonal jól működik. Ha nem működik jól, akkor SNR margint növelünk, vivőkizárunk, stb.
Troy:
Te meg olvasd már el figyelmesen a leírást, mert amiket kérdezel arra mind van válasz, ezen kívül meg amit privátban is megírtam: vonaldiag kell, amit az én szoftverem felrakása után már gyerekjáték megcsinálni.
Dchard
-
dchard
veterán
Az ilyen modem/router párosokkal a múltban is csak a baj volt, de nem árt ha tudod, hogy a szürke 360R is hemzseg a hibáktól. A most elérhető legjobb ADSL2+ modem a Dlink 360R T1E fekete színű (!) modeme, amit akár újonnan akár használtan elég olcsó és egyszerű beszerezni, ennek fényében azt javaslom érdemes volna keríteni egy ilyen modemet. Az is lehet, hogy a tplink-nek csak a modem oldala haldoklik, és egy rendes modemmel a router része még használható, de az is lehet, hogy az egész kuka. AKárhogy is van az új fekete 360R beszerzése erősen ajánlott.
Dchard
-
dchard
veterán
Mivel a vonalad elképesztően jó, meg kell kérdezzem, hogy mindkét modemeddel ezt csinálja? A szürkét valóban csak diagnosztikai célokra érdemes használni, de ha a TP-Link-kel is szakad, és főleg ha az ADSL led nem alszik el, akkor valószínűleg nem az ADSL kapcsolat szakad meg, hanem a PPPoE kapcsolat. Érdekes, hogy mostanában ez egyre sűrűbben előforduló jelenség, aminek egyértelmű okát még nem találtuk meg. A routerben a PPPoE beállításoknál érdemes az MTU 1492-re állítani, illetve volt már akinek az segített, hogy a routerben lévő QoS beállításokkal kissé a fizikailag elérhető sebesség alá korlátozta a sebességet. Ezen túl a router naplóját lehet még érdemes megnézni, mivel abból látszik, hogy az ADSL is megszakad-e vagy csak a PPPoE kapcsolat.
Dchard
-
dchard
veterán
-
dchard
veterán
A kapcsolatok számának router nélkül semmi jelentőssége nincs, mivel a modem bridged módban működik, ergó semmit nem lát a töméntelen mennyiségű TCP kapcsolatból. Ráadásul a legötbb mai router nem is jön zavarba 2-3-400 kapcsolattól, van bennük elég memória ennek a kezeléséhez.
Sokkal inkább MTU hibás beállítása lehet, vagy ami valószínűtlenebb, a PPPoE szerver és a DSLAM között lévő útvonalon lehet probléma. Akárhogyan is: ha a modem DSL uptime számlálója nem indul újra, akkor a PPPoE kapcsolat szakad meg, nem az ADSL.
Dchard
-
dchard
veterán
válasz
tegyebek
#2572
üzenetére
A probléma az, hogy nem kérdezel hanem kijelentesz. Például úgy is megfogalmazhattad volna a két dolgot, hogy "ha a földelőszálon kívül van árnyékoló fólia is, akkor azt is közösíteni kellene", illetve "bekapcsoltad a vivőkizárást? ha igen, érdemes kikapcsolni, mert a képen nem látszik zavaró forrás az érintett vivőkön". Remélem érzed a különbséget a kettő között.
A vivőtartalékolásos dolog is ismert jelenség, itt a topikban sem az első bitallokációs tábla, amin látszik ez a dolog, de jobbat mondok: labor körülmények között ahol 2-3 méternyi kábel volt csak, szintén látszott de csak BCM modemekkel (ennek ellenére minden más modemnél jobb sebességet produkált ugyanazon a vonalon).
Egyébként a kérdésedre szerényen azt mondanám, hogy tőlem.
Ha van kérdésed, tedd fel itt a topikban és válaszolni fogok rá. Ez egyébként sokkal szívesebben teszem, mint ha ki kellene javítanom valakit a téves tanácsok, vagy hibás következtetések miatt. Ha érdekel a technológia és jó az angolod, tudom még ajánlani a vonatkozó DSL specifikációkat is, bár elég száraz és terjedelmes irodalom, de legalább hozzáférhető.Dchard
-
dchard
veterán
válasz
tegyebek
#2569
üzenetére
Jobban meg kéne nézned a képet, ugyanis belenagyítva látszik, hogy a fólia nem fémes, hanem átlátszó, nem árnyékol semmit, jelentőssége csupán a légkábel szerkezeti integritásában van. Ez nem koax kábel (sajnos). A telefonkábeleknél sajnos nincs fóliás árnyékolás.
Janaman01 pedig nem zárt ki egyetlen vivőt sem, DSL-nél előfordul, hogy bizonyos vivőket a DSLAM tartaléknak jelöl meg, így biztosít nagyobb mozgásteret a bitswap számára.
Tudom, hogy jót akarsz, de ismét megkérlek, hogy legyél figyelmesebb, vagy ha nem vagy biztos valamiben, akkor inkább kérdezz, mert ezek a kommentek megint elég félrevezetőek lettek.
Dchard
-
dchard
veterán
válasz
janaman01
#2566
üzenetére
Ezt már hiába buherálod, annyit nem fog gyorsulni, amennyi munka lenne mondjuk kifacsarni belőle még egy megát. A DSL technológia ilyen, ha messze van az alközpont, akkor a maximális sebesség egyre kevésbé lesz elérhető. Ismerve a teljes infrastruktúracsere árát, különösen vidéken még mndig inkább az érné meg, hogy kihelyezett miniDSLAM-ekkel közel vigyék a VDSL2-t az előfizetőhöz, és akkor simán menne ez 70-80megával is lefelé, és 40-50-nel felfelé. Még mindig sokkal olcsóbb és gyorsabban kivitelezhető, mint egy optikásítás, amire belátható időn belül esély sincs.
Dchard
-
dchard
veterán
válasz
janaman01
#2560
üzenetére
Ne menj 70% alá. Minimálisat lehet nyerni, ellenben ha elkezd szakadni a vonal, akkor lekorlátozhatnak úgy, hogy már az SNR margin állításával sem tudjuk megoldani.
beldeczki:
Csak akkor használd ha fali UTP (értsd: merev vezető van benne, majdnem mint a telefonkábelben).
Dchard
-
dchard
veterán
válasz
janaman01
#2555
üzenetére
Csak azt tudom megismételni ami a leírásomban van. Mostmár olyan szájbarágós, hogy talán túlságosan is részletes. Nem írhatom le minden alkalommal ugyanazt, hogy kapcsljuk ki a tűzfalat, antivírust, iktassuk ki a routert, pontosan állítsu be a hálókártyát és akkor, úgy és olyan sorrendben nyomjuk és addig a reset gombot, ahogy le van írva. Mindennek jelentőssége van, például a reset gombot már nyomni kell, amikor áramalá helyezzük. Ha csak egy pillanatra véletlenül felengedjük (ami megtörténhet mert hát nincs 3 kezünk), akkor már nem jó.
Ilyesmikre kell figyelni. Usernevet jelszavat meg nem fog kérni. A puttyos lépést kihagyhatod, fekete 360R esetén ez kell: Board ID 96338L-2M-8M: Letöltés v. 1.9
Dchard
-
dchard
veterán
Új hozzászólás Aktív témák
Hirdetés
- Luck Dragon: Asszociációs játék. :)
- Gyúrósok ide!
- Samsung Galaxy Watch4 és Watch4 Classic - próbawearzió
- PlayStation 3
- Linux kezdőknek
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- Samsung Galaxy Felhasználók OFF topicja
- Milyen pendrive-ot vegyek?
- ASUS ROG Ally
- Samsung Galaxy Watch6 Classic - tekerd!
- További aktív témák...
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RX 9070 XT GAMER PC termékbeszámítással
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 16/32/64GB RAM RX 7700XT 12GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! CSAK KIPRÓBÁLT! ASUS ROG Ally X (2024) 1TB kézikonzol garanciával hibátlan működéssel
- Új! Targus - USB-C Dual HDMI 4K HUB - 2 HDMI-vel. Saját töltő nélkül 2 monitorral (120Hz)
- Apple iPhone 13 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: Promenade Publishing House Kft.
Város: Budapest