[KaLeun]

Szeretném a 360T-s modemem (B3, 20060222 firmware) normálisan beállítani, de az elérhető kezelési útmutató (DSL-360t_man_en_Manual-040304.pdf)még a régebbi felületet
mutatja. Találkozott már valaki újabb kézikönyvvel?

[Coppermine]

Idézet: KaLeun - Dátum: 2010. 06. 27. 14:35

Szeretném a 360T-s modemem (B3, 20060222 firmware) normálisan beállítani, de az elérhető kezelési útmutató (DSL-360t_man_en_Manual-040304.pdf)még a régebbi felületet
mutatja. Találkozott már valaki újabb kézikönyvvel?

hivatalos oldalon is ez van kint, valószínűleg még nem rakták össze a pdf-et el tudom képzelni. dobj egy emailt a magyar D-Link hivatalos oldalnak, aztán csak tudnak valamit mondani.

-C0pp3rM!n3-

[hun_azazel]

Sziasztok!

Az internetem úgy döntött, hogy megőrjít, így muszáj vagyok kérdezni.

A helyzet a következő: Enternetes aDSL net van bekötve, D-Link DSL-360r modemmel, egy D-Link DIR-120 routerrel, amiről az asztali gép direktben megy, két laptop pedig egy DAP-1160-as AP-n keresztül. A hibajelenség úgy kezdődött, hogy néhány héttel ezelőtt gyanúsan gyakran kezdett szakadozni a net-hozzáférés. Ennek örömére belenéztem a router logjába, ahol a következőt találtam, elképesztő mennyiségben:

Jul 9 03:36:46 PPP LCP Down :Peer not responding! 
Jul 9 03:36:46 PPPoE disconnected 
Jul 9 03:36:56 PPP LCP Up! 
Jul 9 03:37:00 PPPoE connection established.My IP is 83.216.xxx.xxx
[...]
Jul 9 08:22:06 PPP LCP Down :Peer not responding! 
Jul 9 08:22:06 PPPoE disconnected 
Jul 9 08:22:30 PPP LCP Up!
Jul 9 08:22:33 PPPoE connection established.My IP is 77.111.xxx.xxx
[...]
Jul 9 08:23:53 PPP LCP Down :Peer not responding! 
Jul 9 08:23:53 PPPoE disconnected 
Jul 9 08:24:17 PPP LCP Up! 
Jul 9 08:24:20 PPPoE connection established.My IP is 83.216.xxx.xxx

És így tovább, néhány óránként. Írtam erről egy szerelmes levelet a szolgáltatónak, erre kijött a Telekom szakembere, végignézte a szűrőt, bemérte a vonalsebességet, közölte, hogy itt minden rendben van, majd elvonult. A hiba természetesen nem szűnt meg, úgyhogy leadtam egy újabb hibabejelentést. Ezúttal a Telekom felhívott, és megkérték, hogy a modem kiiktatásával teszteljem a kapcsolatot. Ma reggel kilenc körül modem ki, közvetlen kapcsolat beállít, netre fel, wireshark indít, majd a 9:30-as csatlakozás után következő történt:

szolgáltató->én Jul 11, 2010 09:37:52 PPP LCP	Echo Request
én->szolgáltató Jul 11, 2010 09:37:52 PPP LCP	Echo Reply
én->szolgáltató	Jul 11, 2010 09:42:40 PPP LCP	Echo Request
én->szolgáltató	Jul 11, 2010 09:43:41 PPP LCP	Echo Request
én->szolgáltató	Jul 11, 2010 09:44:42 PPP LCP	Echo Request
én->szolgáltató	Jul 11, 2010 09:45:43 PPP LCP	Termination Request
én->szolgáltató	Jul 11, 2010 09:45:46 PPP LCP	Termination Request

Ez megismétlődött bőt tíz perccel később, majd utána tökéletesen működött a kapcsolatom. Délután egykor felhívott a Telekom, hogy ők reggel tíz óta figyelik a vonalat, és azóta nincs szakadás, lezárják a hibát. Említettem nekik a két, tíz óra előtti szakadást, amire az volt a válasz, hogy ennek az elmúlt három órában is elő kellett volna jönnie, szerintük jó a vonal. Én ezen felbátorodva visszakötöttem a routert, aminek az lett az eredménye, hogy újabb tíz perc múlva vonalat vesztettem. Router ki, direktbe vissza, wireshark indít, 17:52-kor wireshark szabálytalan művelettel kilép, közben a kapcsolat megszakad. Utána újratárcsázás, és most várom az újabb szakadást, hátha ezúttal loggolni is tudom. A következő merült fel bennem: a routerrel érezhetően gyakrabban volt hiba, vajon van aktív LCP-echo a másik irányba is ilyenkor? Lehet, hogy a router hamarabb kér echot, mint a hálókártya, ha nem kap echo-kérést egy ideig? Előfordulhat, hogy a vonal ugyanolyan gyakorisággal hal meg, router nélkül is, csak épp a router türelmetlenebb, és hamarabb csatlakozik újra? Vagy esetleg a router lehet bedögölve, ahogy a Telekom állítja? (Márciusban vettem a készüléket, tehát viszonylag friss példány.) A wireshark logon kívül hogyan tudnám ellenőrizni, hogy él-e a kapcsolatom? Indítsak egy "ping -t"-t, és írjam fájlba a kimenetet, figyeljem a csomagvesztést? Van olyan verzió, ami 24 óra alatt nem fog többszáz megás log-fájlt generálni?

Úgy általánosságban, van valakinek ötlete, hogy mi lehet a probléma? A hibaüzenetek alapján nekem úgy tűnik, a szolgáltató oldalán van a galiba, de a harmadik hibabejelentéssel már úgy akorok előállni, hogy tényleg ne legyen kétségem a hiba felől. Valami javaslat?

Köszi a segítséget!

[Coppermine]

Idézet: hun_azazel - Dátum: 2010. 07. 11. 18:31

...

Namost, az LCP-ről tudni kell, hogy a PPP session felépítésében játszik szerepet (Link Control Protocol). A PPP kapcsolat, mint WAN kapcsolat az ADSL-nél, hasonlóképp épül fel, mint a 3-utas TCP-kapcsolat. Az Echo-zás pedig a kapcsolat fentartása érdekében megy oda-vissza. Hogy most a szolgáltató oldalról miért nem dobál vissza Echo reply-t, az ebből nem derül ki (DSLAM config/fizikai hiba, vonalhiba, szűrőhiba, modem hiba, router hiba).
A PPP linket a CSU/DSU cuccok tartják fent, ehhez sok köze nincs a hálókártyádnak.
Első körben megpróbálnám egy másik modemmel, aztán esetleg egy másik routerrel. Valószínűleg eszközhiba, a kettő közül valamelyik lesz.

-C0pp3rM!n3-

[hun_azazel]

C0pp3rM!n3!

Köszönöm a tippet!

Idézet: Coppermine - Dátum: 2010. 07. 17. 15:35

Namost, az LCP-ről tudni kell, hogy a PPP session felépítésében játszik szerepet (Link Control Protocol). A PPP kapcsolat, mint WAN kapcsolat az ADSL-nél, hasonlóképp épül fel, mint a 3-utas TCP-kapcsolat. Az Echo-zás pedig a kapcsolat fentartása érdekében megy oda-vissza.

Eddig stimm, hálózatokból ezt nálunk leadták, tehát nem tök hülyén ülök a szitu előtt, csak azt nem értem, hogy a Telekom szakemberei (látszólag) miért nincsenek ezekkel az információkkal tisztában...

Idézet: Coppermine - Dátum: 2010. 07. 17. 15:35

Hogy most a szolgáltató oldalról miért nem dobál vissza Echo reply-t, az ebből nem derül ki (DSLAM config/fizikai hiba, vonalhiba, szűrőhiba, modem hiba, router hiba).

Én a DSLAM-re gyanakszom, esetleg a modemre, mondom, a router kiiktatása semmit sem segített a problémán, a vonalat mérték, állítólag az jó, a szűrőt meg vagy két hete cserélték, valami közeli villám tönkrevágta. (Mondjuk a modemmel kapcsolatban is kissé szkeptikus vagyok, nemrég volt errefelé hálózatújítás, ekkor lett felénk az ADSL-ből ADSL2+, amihez új modemre volt szükség, tehát ez a modem saccra fél éves lehet (persze ettől még bedögölhetett, de a gyanúm mégis a DSLAM hibája).

Idézet: Coppermine - Dátum: 2010. 07. 17. 15:35

A PPP linket a CSU/DSU cuccok tartják fent, ehhez sok köze nincs a hálókártyádnak.

A dilemma a következő: amikor csak a modem van bekötve, router nincs a rendszerben, akkor jóval ritkábban, de ugyanúgy előjön a hiba. Mivel a modemem kis buta (ugye 360R, nem a flancos 380T széria), így ha közvetlenül használom, akkor a LCP echo a hálókártyához jön, és az válaszol rá, mert a modem ehhez hülye. Legalábbis nekem ilyen emlékeim vannak (és a wireshark log is ezt látszik alátámasztani). Az a furcsa számomra, hogy amikor a router is üzemben van, akkor gyakrabban vesztek vonalat, de rövidebb időre. Az echo protokoll ugye úgy néz ki, hogy a szolgáltató időről időre küld nekem egy echo requestet, amire én válaszolok egy echo replyjal. Amikor gyanúsan sok ideje (úgy tűnik, ez közvetlen, router nélküli konfigban kb 5 perc) nincs request a szolgáltató oldaláról, akkor az én oldalamon ráun a protokoll, és ő kér egy echot. Amikor a router is bent van, sokkal hamarabb történik meg a szakadás érzékelése, ezért merült fel bennem, hogy ilyenkor korábban kér választ a router a túloldalról, mintha csak a modem lenne direktben a hálókártyára kötve. Ráadásul amíg a direkt modemes verzióval látom wiresharkban az LCP csomagokat (tehát azok eljutnak a hálókártyáig), addig routerrel nem (hiába a promiscous mode, nyilván a router foglalkozik a kapcsolat fenntartásával, így a hálókártyámig az LCP információ már nem ér el). Ezért gondolom, hogy a router érzékenyebb a dologra, mint a közvetlen kapcsolat.

Idézet: Coppermine - Dátum: 2010. 07. 17. 15:35

Első körben megpróbálnám egy másik modemmel, aztán esetleg egy másik routerrel. Valószínűleg eszközhiba, a kettő közül valamelyik lesz.

Router nélkül ugyanúgy előjön a hiba, a Telekom azt mondta, hoznak egy csere-modemet, hátha arról van szó, úgyhogy ez lesz a következő lépés. Még egyszer köszönöm a javaslatokat!

[Coppermine]

Idézet: hun_azazel - Dátum: 2010. 07. 17. 17:13

C0pp3rM!n3!

Köszönöm a tippet!

Eddig stimm, hálózatokból ezt nálunk leadták, tehát nem tök hülyén ülök a szitu előtt, csak azt nem értem, hogy a Telekom szakemberei (látszólag) miért nincsenek ezekkel az információkkal tisztában...

Én a DSLAM-re gyanakszom, esetleg a modemre, mondom, a router kiiktatása semmit sem segített a problémán, a vonalat mérték, állítólag az jó, a szűrőt meg vagy két hete cserélték, valami közeli villám tönkrevágta. (Mondjuk a modemmel kapcsolatban is kissé szkeptikus vagyok, nemrég volt errefelé hálózatújítás, ekkor lett felénk az ADSL-ből ADSL2+, amihez új modemre volt szükség, tehát ez a modem saccra fél éves lehet (persze ettől még bedögölhetett, de a gyanúm mégis a DSLAM hibája).

A dilemma a következő: amikor csak a modem van bekötve, router nincs a rendszerben, akkor jóval ritkábban, de ugyanúgy előjön a hiba. Mivel a modemem kis buta (ugye 360R, nem a flancos 380T széria), így ha közvetlenül használom, akkor a LCP echo a hálókártyához jön, és az válaszol rá, mert a modem ehhez hülye. Legalábbis nekem ilyen emlékeim vannak (és a wireshark log is ezt látszik alátámasztani). Az a furcsa számomra, hogy amikor a router is üzemben van, akkor gyakrabban vesztek vonalat, de rövidebb időre. Az echo protokoll ugye úgy néz ki, hogy a szolgáltató időről időre küld nekem egy echo requestet, amire én válaszolok egy echo replyjal. Amikor gyanúsan sok ideje (úgy tűnik, ez közvetlen, router nélküli konfigban kb 5 perc) nincs request a szolgáltató oldaláról, akkor az én oldalamon ráun a protokoll, és ő kér egy echot. Amikor a router is bent van, sokkal hamarabb történik meg a szakadás érzékelése, ezért merült fel bennem, hogy ilyenkor korábban kér választ a router a túloldalról, mintha csak a modem lenne direktben a hálókártyára kötve. Ráadásul amíg a direkt modemes verzióval látom wiresharkban az LCP csomagokat (tehát azok eljutnak a hálókártyáig), addig routerrel nem (hiába a promiscous mode, nyilván a router foglalkozik a kapcsolat fenntartásával, így a hálókártyámig az LCP információ már nem ér el). Ezért gondolom, hogy a router érzékenyebb a dologra, mint a közvetlen kapcsolat.

Router nélkül ugyanúgy előjön a hiba, a Telekom azt mondta, hoznak egy csere-modemet, hátha arról van szó, úgyhogy ez lesz a következő lépés. Még egyszer köszönöm a javaslatokat!

igen, valószínűleg a vonal szakadását a router "alacsonyabb tűrőképessége" okozhatja, valószínűleg a modem annyira nem echozza szét a vonalat, mint amennyire a routered.

viszont ha a modemmel is csinál ilyet, akkor nagy valószínűséggel modem és/vagy szűrő hiba (bár a szűrő ugyebár passzív eszköz frekvencia vágásra, nem hiszem, hogy az LCP ott úszna el).

azért kíváncsi leszek csere-modem mit fog alkotni, remélhetőleg meggyógyul. ha mégsem, akkor viszont vonal vagy dslam.

-C0pp3rM!n3-

[Doky586]

Idézet: Coppermine - Dátum: 2010. 07. 17. 16:32

igen, valószínűleg a vonal szakadását a router "alacsonyabb tűrőképessége" okozhatja

Igen, de szerintem a hőmérséklet -tűrőképességével..
Ha nem egy max. 20°C klimatizált teremben próbáltad, vagy véletlen rátetted a modemet a router tetejére főni, akkor máris megvan az ok..

[Coppermine]

Idézet: Doky586 - Dátum: 2010. 07. 18. 01:14

Igen, de szerintem a hőmérséklet -tűrőképességével..
Ha nem egy max. 20°C klimatizált teremben próbáltad, vagy véletlen rátetted a modemet a router tetejére főni, akkor máris megvan az ok..

találkoztam hasonló adsl-szakadásos szindrómával, ahol a modem rosszul volt kondizva (szériahiba). tény hogy nincs ideális hőmérséklet, de azért egy ilyen eszköz lehetőleg bírja már a 25-30 fok meleget (tervezési hiba?).

-C0pp3rM!n3-

[hun_azazel]

Idézet: Doky586 - Dátum: 2010. 07. 18. 01:14

Igen, de szerintem a hőmérséklet -tűrőképességével..
Ha nem egy max. 20°C klimatizált teremben próbáltad, vagy véletlen rátetted a modemet a router tetejére főni, akkor máris megvan az ok..

Ez bennem is felmerült, annak ellenére, hogy a router és a modem nem egymás tetején főnek. Ugyanakkor éjjel, nyitott ablaknál, húsz fok környékén ugyanúgy előjön a szakadás, mint délben, 30 fokban, valamint a hiba már hetek óta fennáll, tehát nem ebben a melegben kezdett rá. (Az elektronikai oldalához ugyan nem értek a dolognak, de így alaposan meggondolva a közelmúlt eseményeit, nemrégiben sistergett a vonal, kijöttek, kitalálták, hogy rossz helyen van a szűrő, előadtam, hogy az a szűrő hat éve van ott, és a vonal most krepált be, rábeszéltem őket a szűrőcserére, és megszűnt a probléma, ekkor mondták, hogy jellemzően a statikus elektromosság, vagy a nagyobb viharok tudják tönkrevágni a szűrőt, amiben azért volt részünk mostanában. Lehetséges, hogy a szűrő után a modem is kapott abból a viharból, és ez okozza a problémát? De akkor miért ilyen rendszertelen? )

[Gyula2222]

Idézet: Coppermine - Dátum: 2010. 07. 18. 09:46

találkoztam hasonló adsl-szakadásos szindrómával, ahol a modem rosszul volt kondizva (szériahiba). tény hogy nincs ideális hőmérséklet, de azért egy ilyen eszköz lehetőleg bírja már a 25-30 fok meleget (tervezési hiba?).

-C0pp3rM!n3-

A szemétvilág termékei ezek, konstrukciósan beléjük építve a ciklusidőre beépített halál.
Ezt leggyakrabban egy nagy frekvencián üzemeltetett kapcsolóüzemű tápkonstrukcióval érik el, amely szépen, a beállított idő alatt, kinyírja az impulzusüzemben járatott kondenzátorokat.
A tönkremenetelnek (általában) van egy olyan szakasza, amikor a táfeszzaj csak időnként lépi túl a jó működést még biztosító értéket. Ekkor jelentkeznek igen változatos, még mással is jól magyarázható hibák.
Remélem, hamarost ébred az emberiség és elzavarja a világ jelenlegi urait, akik a kényelmes élősködésük kedvéért ezt a világot kényszerítik ránk elvéve az életünk nagyrészét és tönkretetetve velünk a biológiai létalapunkat adó földet.

[Coppermine]

na igen, de hol csodálkozunk, mikor minden erre van kihegyezve.



-C0pp3rM!n3-

[Jakuza]

Idézet: Coppermine - Dátum: 2009. 06. 21. 00:05

mivel a hivatalos oldalon is csak (DSL-380T_fw_revA_300B01T02EU_ALL_eng_20060126.zip) a 2008-as van fent, ezért gondolom nincs újabb.

-C0pp3rM!n3-

Kozben talaltam ujabbat a D-Link spanyol oldalon. (DSL-380T_V3.00B01T02.EU.20080124)
Hogy mi benne az ujdonsag ne kerdezd, mert arrol egy szot nem irtak, se az oldalon, sem a tomoritett allomanyban.
Mindenesetre nalam mukodik.

ftp://ftp.dlink.es/A...EU.20080124.zip

[Coppermine]

Idézet: Jakuza - Dátum: 2010. 07. 24. 18:07

Kozben talaltam ujabbat a D-Link spanyol oldalon. (DSL-380T_V3.00B01T02.EU.20080124)
Hogy mi benne az ujdonsag ne kerdezd, mert arrol egy szot nem irtak, se az oldalon, sem a tomoritett allomanyban.
Mindenesetre nalam mukodik.

ftp://ftp.dlink.es/A...EU.20080124.zip

köszi a linket

-C0pp3rM!n3-

[Echelon]

D-Link DSL-2740B routerem van. Az a problémám, hogy elfelejti a beállításokat, miután este kikapcsolom az UPS-t, ami ellátja árammal. Az nem megoldható, hogy mindig be legyen kapcsolva. A Quick Install CD-vel kell az Internet kapcsolatot beállítanom minden reggel. A http://192.168.1.1 címen található konfigurációs oldal is csak ritkán működik, akkor is csak Internet Explorerből.

[Coppermine]

Idézet: Echelon - Dátum: 2010. 07. 26. 13:23

D-Link DSL-2740B routerem van. Az a problémám, hogy elfelejti a beállításokat, miután este kikapcsolom az UPS-t, ami ellátja árammal. Az nem megoldható, hogy mindig be legyen kapcsolva. A Quick Install CD-vel kell az Internet kapcsolatot beállítanom minden reggel. A http://192.168.1.1 címen található konfigurációs oldal is csak ritkán működik, akkor is csak Internet Explorerből.

konfiguráld fel, majd save-eld a configot. húzd ki a tápját, dugd vissza pár mp múlva, és kiderül, h menti-e a configot vagy sem.
ha nem menti, az érdekes, ez akár nvram hiba is lehet.

-C0pp3rM!n3-

[Echelon]

Most a konfig oldalhoz se tudok hozzáférni, de a CD-ről be tudom állítani. Emlékszem, amikor még működött a konfig, próbáltam a Backup Settings opciót, de csak egy üres .conf file-t mentett el.

[Coppermine]

Idézet: Echelon - Dátum: 2010. 07. 27. 12:56

Most a konfig oldalhoz se tudok hozzáférni, de a CD-ről be tudom állítani. Emlékszem, amikor még működött a konfig, próbáltam a Backup Settings opciót, de csak egy üres .conf file-t mentett el.

adál neki egy factory resetet, sokáig nyomva kell tartani a reset gombját, bár a kézikönyvében biztos le van írva, hogy hogyan kell ezt produkálni. talán attól felébred. elvileg az nullázza az nvram tartalmat teljesen, mindent töröl, csak a firmware marad meg rajta.

-C0pp3rM!n3-

[Echelon]

Reseteltem, de még mindig nem jó.

[Echelon]

Defaultra állítottam az Explorert, most már jó.

[Coppermine]

Idézet: Echelon - Dátum: 2010. 07. 30. 10:53

Defaultra állítottam az Explorert, most már jó.

na akkor a kexplorer volt a ludas

-C0pp3rM!n3-