Megszűnik a 24 órás (A)DSL bontás a T-Online-nál

Bejelentés

Megszűnik a 24 órás kötelező PPP(oE) bontás a T-Online ADSL-es ügyfeleinél.

A session timer egy ideig még csak körülbelül egy hétre változik, majd ha minden vonatkozó műszaki fejlesztés elkészül, megszűnik (vagy hosszú -években mérhető- lesz). A T-Online-nál eddig csak a statikus IP címmel rendelkezők ADSL kapcsolata maradt állandóan online, a session timer megnövelésével azonban minden (dinamikus, poolos IP címet kapó) ügyfél sessionje is hosszú ideig érintetlen marad.

A session idő megnövelése a címkiosztási algoritmuson nem változtat, azaz a bontás után valószínűleg új IP címet kap az ügyfél (viszont a kisebb fluktuációnak köszönhetően annak a valószínűsége, hogy ugyanaz az IP cím kerüljön kiosztásra akár nőhet is).

Annak, aki -akármilyen okból kifolyólag- számít a 24 órás bontásra, érdemes felkészülnie a változásra.

( tr1719 | 2008. 06. 13., p – 23:28 )

Régen interware- nél nem volt bontás, vagy több, mint 2 hetente, aztán néhány éve van 24 órás bontás. Nem lenne rossz, ha visszaállnának arra, hogy megint nem bontanak.

( BaT | 2008. 06. 13., p – 23:32 )

Höhh, mindjárt törlöm a dyndns accom. :)

A router automatikusan csak akkor csatlakozik, ha belülről internetezem. Ha nem bontanék és újracsatlakoznék automatikusan, akkor miután a T-Online ledob, kívülről nem lehetne elérni a szerveremet addig, amíg belülről nem kezdek kapcsolatot. (Amúgy OpenWRT van a routeren, azon megy a cronjob.)

Pláne, ha no-ip.org-os dinamikus domain-t használsz, mert az process-ként futva percenként ellenőrzi az IP-t és összehasonlítja a no-ip.org-on regisztrálttal. :-)
Nekem azért marad a bont-csatlakozik-IP-címet frissít cron még egy darabig, már csak megszokásból is, bár 3 féle regisztrált dinamikus domain-em van. (no-ip.org, dyndns, myip)

( ssa2 v | 2008. 06. 13., p – 23:43 )

Kábelen a T-online se bontogat. Ha egyszer megaptam az ip-t és nem bontok, akkor meg is marad.
Minek volt eddig az ASDL-en ez a bontogatási mizéria?

AFAIK a kábel net általában statikus IP-t ad.. de nem is a kábelről volt szó..
nálam nem bontogatna, bár nem tudom ez mennyire t-online, mert internet-előfizetés a tv-networknél van, de hát adsl budapesten t-online-on keresztül megy.. egyébként statikus IP-m van, úgyhogy jó hogy nem bontogatják (tvnetworknél ez alapból jár(t))

I hate myself, because I'm not open-source.

( nagy_peter v | 2008. 06. 14., szo – 00:02 )

Ugyan nem T-online-os vagyok, de nálam elvileg hetente van IP címcsere... 2 és fél év most kaptam meg a harmadikat, az eddigi kettőt fejből tudtam. De most már azért van dynDNS-is, biztos ami biztos :D

---
Nagy Péter

( DirtY_iCE | 2008. 06. 14., szo – 00:23 )

bocs, de ez egy kicsit off lessz:
azt tudom, hogy sok szolgáltatónál a korlátlan net azért nem korlátlan, mert a szolgáltató adatátvitel alapján veszi a netet mittudoménkitől. de ez a dinamikus ip cím miért jó, azon kivűl hogy nhány rosszindulaú vandált ne lehessen IP cím alapján bannolni. gondolom az IP címek vásárlása pénzbe kerül, de így elég sokkal kevesebb IP címet venniük? mert más esetben szerintem nem lenne értelme. de akkor itt csak azokra építhetnek, akik nincsenek egész nap kapcsolódva; mert akik 24 órát vannak fönt folyamatosan, azokon nem igazán tudnak IP címet spórolni.. ja és mi van, ha mindenki egy időpontban szeretne internetre csatlakozva lenni? :) kifogynak az IP címből?

ja egy másik: az miért jó, hogy egyes szolgáltatók az ip címekhez subdomaint rendelnek (pl. xxx.pool.invitel.hu)? ennek az értelmét nem igazán látom..

I hate myself, because I'm not open-source.

"gondolom az IP címek vásárlása pénzbe kerül, de így elég sokkal kevesebb IP címet venniük"
Lehet hogy hülyeséget gondolok de az IP cím a RIPE tagoknak ingyen van. Gondolom a nagyobb szolgáltatók RIPE tagok, és nem veszik az IP-ket sem. Gondolom annyi IP-t igényelnek amennyi felhasználót képesek kiszolgálni. És azt is gondolom a rendszerüket nem a végtelenre bővítik, hanem a jó kihasználtsági szint fölé valamivel. Biztosan elemzik a forgalmat folyamatosan.

"az miért jó, hogy egyes szolgáltatók az ip címekhez subdomaint rendelnek (pl. xxx.pool.invitel.hu)?"
Gondolom jó ha van reverse is megadva. Például hogy földrajzi statisztikák készüljenek a látogatottsági statisztikákba. :)

"Maradjunk a hulyeseget mondasznal. (publikusan elerheto informaciokrol van szo)"

Nekem lőttél? Borzasztóan hálás tudnék lenni, ha alá is támasztanád 1-2 mondatban az véleményedet, mert én sem vagyok rendszergazda és esetleg tanulhatnék belőle. Guglizni meg nem fogok, de ha ide információt írsz be akkor azt elolvasom. :)

Windows is NOT a virus. Viruses DO something.

( hg2ebh | 2008. 06. 14., szo – 00:59 )

RIPE tagoknak is van ecceri kőccsége... ;)

( csko | 2008. 06. 14., szo – 04:27 )

T-online kábelnet(nem ADSL ugye), "dinamikus" IP cím kiosztás. De valójában meg nem tudom mondani mióta ugyan ez az IP-m, és nem egyszer bontott már kapcsolatot, nem 24óra miatt, hanem a szolgáltatás általános minősége miatt. Inkább lenne fele ennyi sávszélesség és egy kicsi stabilabb kapcsolat. 20+ párhuzamos TCP kapcsolat után fél percre megáll az adatátvitel, más tapasztalt már ilyet bárhol?
Meg aludni sem tudok... :)

( LiRul | 2008. 06. 14., szo – 09:36 )

Trey, hol van a cikkbol a hivatkozas? Nem szoktal link nelkul kitenni semmit.

Ebből következik, hogy nem én tettem ki a cikket :)

A forrásról pedig... Mivel a "postmaster" user aláírása a következő:

"Magyar Telekom NyRt.
T-Online postmaster"

Elfogadhatjuk hiteles forrásnak, insider infónak :) Ilyen esetben nincs szükség egyéb forrásra.

--
trey @ gépház

Ha azt mondod, hogy a regisztráció @telekom.hu vagy @t-online.co.hu címről érkezett, akkor nem szóltam semmit. :)

Nekem az is fura az egészben, hogy olyan kifejezéseket használ, amiról egy PR-os vagy marketinges azt se tudja, hogy eszik, vagy iszzák és ha igen, akkor miért nem. Ha pedig tényleg akkor cukorral vagy sóval és citrommal.

Igazából, nekem is az azonosítással pontosabban annak hiányával van problémám. Mert ha tegyük fel "bra" nickkel írja le ugyanezt valaki, akkor már majdnem el is hiszem. Hiszen az ő jelszavát is ellophatják. viszont ha a bevitt szöveg szilisztikai elemzése során tipikus vonásokra bukkanok (irónia, humor, és a többi), akkor már nmegint egy lépéssel közelebb vagyok ahhoz, hogy valósnak tekintsem az információt. :)

Hm... így a végére lassan egész jó kis összesküvés-elméletet gyártok egy mezei hírből. :)

( prygme | 2008. 06. 14., szo – 13:24 )

bár az EUban jelenleg nincs egységes jogrendszer sem, nemhogy országok közötti precedensjog, az viszont több mint jelzésértékű, hogy nemrég egy filecserélős perben a német bíróság elvetette a dinamikus IP cím bizonyítékként való kezelését.
lehet, nem is olyan nagy hátrány, a rendszeresen változó dinamikus IP. sok problémát eddig sem jelentett a 24 órás bontás.
magyarul itt lehet olvasni az esetről.

azert a tisztanlatas kedveert megjegyeznem, hogy nem az ip cim bizonyitek jelleget vetette el, hanem az ip kiadasanak torvenyes voltat kerdojelezte meg a biro, es mint torvenytelen eszkozzel szerzett bizonyitekot nem vette figyelembe.

ez analog azzal, hogy ha elozoleges tajekoztatas nelkul rogzitik a telefonbeszelgetest, akkor az kesobb nem hasznalhato fel a birosagon, leven titkosszolgalati eszkozzel engedely nelkul vagyis torvenytelenul szerzett bizonyitek.

vagyis ebben az esetben a hangsuly nem a dinamikuson van, hanem hogy torvenytelenul kerult kiadasra az ip cim, lett legyen az statikus vagy dinamikus.

Ez itt nem jatszik, ugyanis (politikamentesen) rejtett kamerával, engedély nélkül készült felvételeket bármikor figyelembe vesz a magyar igazságszolgáltatás. Van egy tvadó, amelyik hetente nyomatja az ilyen anyagokat.
Kéretik ezt nem politikai felhangként értékelni!

kötöjelkötöjel
//:wladek's world

"Van egy tvadó, amelyik hetente nyomatja az ilyen anyagokat. "

Nyilván jogot nem sért, mert kitakarják az arcokat, megváltoztatják a hangot, egyszerűen közterületen veszik fel stb. Nyilván egy jogi eljárásban nem fogja egyetlen ügyvéd sem nemmegtámadni a felvételt, ha bizonyítékként fogják felhasználni.

Más: elvileg a rögzített telefonbeszélgetéséekkel kapcsolatban, a jog szerint biztosítania kellene azt is hogy a felek bármelyike ne járuljon hozzá pl. a telefon beszélgetés rögzitéséhez. Ezidáig mindösszesen egy bank telefonos ügyfélszolgálatán találkoztam azzal, hogy megkérdezték hogy hozzá járulok -e a beszélgetés rögzitéséhez? Gondolom ellenpéldával már ti is találkoztatok.

Windows is NOT a virus. Viruses DO something.

ilyen esetekben a valasztasi jogod kimerul abban, hogy leteszed a telefont, vagy beleegyezel a beszelgetes rogzitesebe. sajnos az eletben ez sokszor valoban vicc kategoria, de ezt a reszet a jog eszkozeivel mar nem nagyon lehet kezelni... ahogy mondani szokas: minden telefon melle nem lehet rendort allitani.

Ez ugyanaz, mint az 1-2 éve nagy port kavart ügy a személyi igazolvány fénymásolásával. Ha jól emlékszem, a bankoknál csak úgy kötöttek veled szerződést, ha lefénymásolhatták az igazolványod. Ez törvénytelen, és az adatvédelmi biztos is nyilatkozott róla. Valami bankos fószer (talán a Bankszövetség elnöke) meg nagyjából a következőt válaszolta rá a tv-seknek "blablabla blabla bla blabla leszarom blabla ...".

( ricsip v | 2008. 06. 14., szo – 17:15 )

Hmm, lőttek a rapidshare-s multipart cuccok gyors töltögetésnek? Hiába reconnectelek, ha nagy vsz-el ugyanazt az IP-t fogom visszakapni.

Ezt sosem ertettem. aki warezol es eselyes hogy egyszercsak megjeleni nala fakabat elvtars bsa elvtarssal karoltve, az miert nem hasznal legalabb egy truecryptet a kenyes cuccok tarolasara? oszt onnantol foglalhatjak, haver cegetol berel egy gepet aranyaron amig vizsgalgatjak, aztan kifizetteti a cehhet a zsarukkal.

( saabi v | 2008. 06. 15., v – 10:17 )

< offtopic >
Biztos akadna jobb hely is a kérdésem feltevésére és biztos ki is leszek erről okosítva.

Szeretnék választ kapni arra az egyszerű kérdésre, hogy a T-Online (T-Com?) képes-e 8-10 megabit/secundum sebességű ADSL szolgáltatást nyújtani a lakóhelyemen. Az ügyfélszolgálatuk erre az egyszerű kérdésre sajnos nem képes válaszolni, csak azt hajtogatják, hogy rendeljem meg és akkor meglátjuk. Úgy érzem hülyének néznek.

Kérdésem, hogy kit lehetne megkeresni, aki képes értelmezni a kérdésem és többé-kevésbé releváns választ adni?
< /offtopic >

Ave, Saabi.

Csak nekünk a ház aljába üveg jön. A probléma ott merül föl, hogy van-e megfelelő sebességű konverter a pincében? Tavaly decemberben - az akkori próbahónapom alatt, miután reklamáltam hogy én 8Mb-et rendeltem de csak egyet kaptam - felhívtak a helyi központból és biztosítottak arról, hogy nem is lesz gyorsabb. De idén nyáron cserélik az ADSL kártyákat. Ennek időpontját szerettem volna kihúzni az ügyfélszolgálatból. Lehet, konkrétabban kellett volna fogalmaznom?
Csak nem akartam túl sok olyan szót használni, amit jó eséllyel nem ismernek...

Ave, Saabi.

( mogorva v | 2008. 07. 23., sze – 09:01 )

Hi,

Azt nem állítanám, hogy minden nap, de elég sűrűn előfordul, hogy 03:30-kor lehal az ADSL egy T-Online-os irodai szerveren és a logokban ez van:

Jul 23 03:31:19 myserver pppd[2088]: LCP terminated by peer
Jul 23 03:31:19 myserver pppd[2088]: Connect time 1189.5 minutes.
Jul 23 03:31:19 myserver pppd[2088]: Sent 20267968 bytes, received 136399461 bytes.
Jul 23 03:31:19 myserver pppd[2088]: Couldn't increase MTU to 1500
Jul 23 03:31:19 myserver pppd[2088]: Couldn't increase MRU to 1500
Jul 23 03:31:22 myserver pppd[2088]: Connection terminated.
Jul 23 03:31:22 myserver pppd[2088]: Modem hangup
Jul 23 03:31:22 myserver pppd[2088]: PPP session is 43777
Jul 23 03:31:22 myserver pppd[2088]: Using interface ppp0
Jul 23 03:31:22 myserver pppd[2088]: Connect: ppp0 <--> eth1
Jul 23 03:31:22 myserver pppd[2088]: Couldn't increase MTU to 1500
Jul 23 03:31:22 myserver pppd[2088]: Couldn't increase MRU to 1500
Jul 23 03:31:22 myserver pppd[2088]: Connection terminated.
Jul 23 03:31:22 myserver pppd[2088]: write: Bad file descriptor (9)
Jul 23 03:31:25 myserver pppd[2088]: write: Bad file descriptor (9)
Jul 23 03:31:28 myserver pppd[2088]: Connection terminated.
Jul 23 03:31:28 myserver pppd[2088]: write: Bad file descriptor (9)
Jul 23 03:31:34 myserver pppd[2088]: Connection terminated.
Jul 23 03:31:34 myserver pppd[2088]: write: Bad file descriptor (9)
Jul 23 03:31:40 myserver pppd[2088]: Connection terminated.
Jul 23 03:31:40 myserver pppd[2088]: write: Bad file descriptor (9)
Jul 23 03:31:40 myserver pppd[2088]: write: Bad file descriptor (9)
Jul 23 03:31:43 myserver pppd[2088]: write: Bad file descriptor (9)
Jul 23 03:31:46 myserver pppd[2088]: Connection terminated.
Jul 23 03:31:46 myserver pppd[2088]: write: Bad file descriptor (9)
Jul 23 03:31:52 myserver pppd[2088]: Connection terminated.
Jul 23 03:31:52 myserver pppd[2088]: Modem hangup
Jul 23 03:31:52 myserver pppd[2088]: PPP session is 43783
Jul 23 03:31:52 myserver pppd[2088]: Using interface ppp0
Jul 23 03:31:52 myserver pppd[2088]: Connect: ppp0 <--> eth1
Jul 23 03:31:52 myserver pppd[2088]: Couldn't increase MTU to 1500
Jul 23 03:31:52 myserver pppd[2088]: Couldn't increase MRU to 1500
Jul 23 03:31:52 myserver pppd[2088]: Connection terminated.
Jul 23 03:31:52 myserver pppd[2088]: write: Bad file descriptor (9)
Jul 23 03:31:55 myserver pppd[2088]: write: Bad file descriptor (9)
Jul 23 03:31:58 myserver pppd[2088]: Connection terminated.
Jul 23 03:31:58 myserver pppd[2088]: Modem hangup
Jul 23 03:31:58 myserver pppd[2088]: PPP session is 43783
Jul 23 03:31:58 myserver pppd[2088]: Using interface ppp0
Jul 23 03:31:58 myserver pppd[2088]: Connect: ppp0 <--> eth1
Jul 23 03:31:58 myserver pppd[2088]: Couldn't increase MTU to 1500
Jul 23 03:31:58 myserver pppd[2088]: Couldn't increase MRU to 1500
Jul 23 03:31:58 myserver pppd[2088]: Connection terminated.
Jul 23 03:31:58 myserver pppd[2088]: write: Bad file descriptor (9)
Jul 23 03:32:01 myserver pppd[2088]: write: Bad file descriptor (9)
Jul 23 03:32:04 myserver pppd[2088]: Connection terminated.
Jul 23 03:32:04 myserver pppd[2088]: Modem hangup
Jul 23 03:32:42 myserver pppd[2088]: Timeout waiting for PADO packets
Jul 23 03:32:42 myserver pppd[2088]: Unable to complete PPPoE Discovery
Jul 23 03:33:17 myserver pppd[2088]: Timeout waiting for PADO packets
Jul 23 03:33:17 myserver pppd[2088]: Unable to complete PPPoE Discovery
Jul 23 03:33:52 myserver pppd[2088]: Timeout waiting for PADO packets
Jul 23 03:33:52 myserver pppd[2088]: Unable to complete PPPoE Discovery
Jul 23 03:34:27 myserver pppd[2088]: Timeout waiting for PADO packets
Jul 23 03:34:27 myserver pppd[2088]: Unable to complete PPPoE Discovery
Jul 23 03:34:27 myserver pppd[2088]: Exit.

Megoldani úgy szokták (titkár nénik), hogy egy web-es felületről kiadnak egy reboot-ot, a gép újra indul és van net. Namost ez nyilván nem megoldás, de egyelőre nincs ötletem, mi lehet a probléma oka.

A cron-okat megnéztem, sehol semmi utalás arra, hogy ebben az időszakban a PPP kapcsolattal bármit is csinálni kellene.

Mi lehet a gond?