UPC egyszálú letöltés lassú - a többszálú...

Web, mail, IRC, IM, hálózatok

Sziasztok!

Elvileg ~ 1200 kB/s sebességgel lehetne letöltenem a UPC előfizetőjeként. Ennek ellenére 100-200 kB/s körül vánszorog az esti órákban.
Egy szálon.
Vagyok abban a szerencsés helyzetben, hogy saját dedikált 100 Mb-es szerverről tudok letölteni, és onnan is lassan jön. Egy szálon. Próbáltam OpenVPN tunnel keresztül is a letöltést, akkor is vánszorgott.
Nos, egy huszárvágással a szerveren több kisebb darabra szedtem szét egy 700 MB-os tesztállományt, és egyszerre több szálon keresztül keresztül kezdtem el letölteni. A sebesség 1100-1250 kB/s-ra ugrott fel.
Számomra ez azt bizonyítja, hogy a UPC korlátozza a letöltést egy szálon. (Azt feltételezem, azért, mert a nagy többség nem tölt több szálon.)
Mi a véleményetek?

  • 5500 megtekintés

( salaud v | 2008. 10. 23., cs – 20:18 )

Nem tudom, mindent több szálon szoktam tölteni. De mindjárt kipróbálom.

Kipróbáltam, jön egy szálon is max-al.

---------------------------------------------------------------------------------
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!

( zumy | 2008. 10. 23., cs – 20:17 )

nos ez ezt nem bizonyítja...max azt, h valami gubanc van nálad

egyébként meg nem korlátoznak; kb. 5-6 helyen tötöttem le nagy filéket egy szálon az utóbbi időben és mind jött le maximummal;

( csardij v | 2008. 10. 23., cs – 20:49 )

nos, pár dolog hiányzik: milyen protokoll, hol vagy helyileg, mikor csinálja (esti órák mindenkinek más), a környéketeken másnál is van ilyen, vagy csak nálad?

( kt0m | 2008. 10. 23., cs – 20:59 )

Hello,

A UPC-nel nincs ilyen korlatozas, Nalad lehet valami problema.

Nincs ertelmezheto elonye a fizikai korlatozasnak, mivel azzal csak azt ernek el, hogy a technologialag nalad kevesbe fejlettek kijelentseg "szar lassu az egesz, lemondom".
Emellett igensok munkaval jarna.
Van viszont ertelmes korlatozasi lehetosege ennek, ez pedig magabol az igenybevevo technologiabol ered(het) (ie: docsis es az adott gyarto properitary extensionjei) ennek koze nincs az egy szal korlatozasahoz, annal tobb az egyenlohoz kozelito elosztas az azonos prioritasu kapcsolatoknal a meglevo szalak kozt.

A sok munka relatív fogalom egy multinál: "csináld meg fő munkaidőben" utasítás nem jár többlet kiadással a cégnek.
Az egyenlőhöz közeli eloszlás(tás) csak akkor járna sebességcsökkenéssel, ha az egész vezetékre, melynek a végpontján van X felhasználó, globálisan és radikálisan csökkentenék az igénybe vehető sávszélességet.
Vagyis ez számomra még mindig a UPC szándékosságát bizonyítja.
Van egy harmadik megközelítés is: a gazdasági.
A UPC exponenciálisan veszíti el ügyfeleit a városban, ezt te is tudod, willy. A konkurenciájuk 1/3 annyiért kínál 2x gyorsabb netet és a le- és feltöltés elméletben ugyanaz. Feltételezhetjük, hogy csökken a városi előfizetők száma, ezért a UPC a kieső bevételből eredő veszteséget a megvásárolt és kiosztott sávszélesség korlátozásával kompenzálja. Nem lepődnék meg azon, ha ezeken a településeken is jelentkezne a probléma. (Természetesen, ahol van UPC.) Ezzel persze a UPC a saját farkába harapna, de ezt tőlük el is lehet várni. Az említett konkurencia hatását úgy kezelték, hogy a meglévő előfizetők kedvezményesen 1 év húségnyilatkozat esetén akciósan eggyel olcsóbb TV csomagot fizethetnek, ám a hűség lejárta után a régi árat kell fizetni ismét. Arra persze nincs lehetőség, hogy a hűség ideje után újra akciósan kötelezze el magát pl. még egy évre. Ehhez várnia kellene a delikvensnek 3 hónapot. Vagyis eleve szar az üzletpolitikájuk, éppen ezért ettől a cégtől várhatóbb reakció a korlátozás sumák bevezetése.

Én arra reagáltam, hogy rossz helyen keresed a problémát. Nem a te előfizetésed korlátos, hanem a nodecsoportra jutó fejállomás kevés , amit 2 perc alatt nem lehet megoldani.
Nekem volt már pár afférom a fent említett társasággal, nem épp az, hogy egy szálon nem jó a sebesség, és nagyjából tudom, hogy nem az ott dolgozó melósok körül van a baj(van ott is, de inkább az ismerethiány).
Ettől még (és tudod, hogy nem áll érdekemben):
1, általánosan elmondható, hogy a szolgáltatásuk jó
2, nincs érdekükben a fenti korlát bevezetése,
3, mindig van egyszerű magyarázat.

Nekem előfizetőként tv, illetve ügyintézés kapcsán több bajom van velük.

Amit a másikról el lehet mondani, hogy az utolsó kilóméter hozzáférés szép, és modern lesz. Viszonylag olcsón karbantartható és fejleszthető, és ez a jövő. 5 éve is ez volt a jövő. Nekik van pénzük rá. Ami inkább érdekes, az az, hogy az adott árért nem lehet fenntartani és kifizetni ezt, és itt profitvadászat zajlik.

A végeredmény az, hogy nálam romlott le a minőség. Az ÜSZ egyébként kategórikusan tagadta, hogy nodecsoportok befolyásolnák a sebességet. Aztán kiröhögtem, és korrigálta annyival, hogy "elméletben". Ezen megint jót derültem.
Azért egy valamit ne felejts el. Annó a Dunanet olyan - mai szemmel nézve - horribilis összegért kínálta a netet, hogy csodálkozom, hogy van még előfizetőjük. Vagy ott vannak a mobilszolgáltatók. Évekig leszedték az előfizetőiket, és még most is megéri nekik.
Kíváncsi lennék, hogy hol van az a természetes határ, amikor még megérné a UPC-nek a szolgáltatás.

Nem ertem az altalad feltetelezett elofizetoi szam csokkenes - ami egyebkent nem is fedi valosagot - es a savszelesseg korlatozas kozotti osszefuggest. Valamelyest "insider" vagyok, es biztosithatlak, hogy ilyen jellegu korlatozas nincs. Adatforgalom priorizacio van, mely szukseg eseten adatforgalmi csucsidoszakokban menedzselheti a forgalmat es ekkor esetleg bizonyos csomagok hatrebb szorulhatnak, ez nyilvan viragnyelven a p2p. Egyebkent ez sem jellemzo.

Hivd vissza az ugyfelszolgalatot, ha biztos vagy benne, hogy nem Nalad van a hiba, van lehetoseged tesztkiszallast kerned. Kimegy valaki egy notival, megnezi mit tapasztal, nyilvan ha igazad van, jelentkezni fog a problema. Ha meg minden rendben van, kifizeted az indokolatlan kiszallas dijat. Szerintem ez teljesen korrekt.

Remelem megoldodik a problemad.

Van előfizető csökkenés, és jelentős, csak te nem ismered a települést, és elsősorban nem internetes hanem ktv-s előfizetőszám csökkenésről van szó.
Nincs köze a fent említetthez, de van egy új szolgáltató amelyik jelenleg meglehetősen jó minőségben sokkal olcsóbban ad netet.
Az, hogy hogyan priorizaljatok a forgalmat, és hogy van e elég downstream az adott körzetben az más kérdés. Már ő is érti, hogy tévesen ítélte meg a problémát, de ugye downstream-enként nem 4 állandó előfizetővel számoltok?
Nevetséges letagadni a technológia korlátait.

Akkor mivel jellemeznéd, hogy órákig állnak sorba a személyes ÜSZ-nál az emberek, mert sorra lemondják az előfizetéseiket?
(A telefonos ÜSZ-i hölgy is azzal biztatott, hogy bizony jobban teszem, hogyha a Sugárba megyek (60-70 km), mert ott szinte nincs sor. Sicc!)
A notebookos kollégákról pedig annyit, hogy ők hétvégén, az esti órákban bizony nem szállnak ki. Napközben pedig nem reprodukálható a hiba, vagyis garantáltan fizetek.
A p2p-t nevezheted nevén, nem tilos. Az elméleti p2p prioritásról pedig elég legyen annyi, hogy titkosítatlanul max. 60-70 kB/s-kel jön még a leggyorsabbként ismert trackerről is az állomány. Titkosítás után pedig teljes draftal.

A probléma megoldása már a pincében jár műszerészálruhában.

Nincs hűségnyilatkozatom, így bármikor leléphetek. Érdekes, hogy az ügyfélmegtartási magatartási stratégiája is a béka segge alatt van a UPC-nél. Zsigerből kecsegtetni kellene engem valami hyper akcióval.
Van erre egy jó példám. Egy helyi középvállalkozásnál a havi telefonszámla 1 millió körül mozgott. Errefelé ügynököltek a T-com emberei, és olyan csomagot lebegtettek meg az említett cégnek, ami rögtön az 1/3-ára redukálta a számlájukat. A cég egyik alkalmazottja beballagott ahhoz a telefonszolgáltatóhoz, aki pillanatnyilag szolgáltatott nekik, és megmutatta a T-com ajánlatát. "Ilyet mi is tudunk" Volt a felet... És tudtak is.
A cég maradt a régi telefonszolgáltatójuknál. A UPC erre képtelen. Bár azt érzem, nem is erőltetik...

Te is elszállsz azért. Vigyázzál!
Nem épp a város 3 legnagyobb előfizetője közül vagy 1. És a számla végösszege sem annyi.
Az meg hogy jó szándékú kritikát fogalmazol meg a szolgáltató felé nem indikálja, hogy erre a sok hülye más panaszos mellett képesek reagálni.
Értem én, hogy az 5 forintos kínai cipő is jó, de ha véletlenül nem annyira divatos, akkor inkább kidobod nem visszamész kicserélni.

( Treck v | 2008. 10. 23., cs – 23:34 )

Kb. egy honapja ugyanezt tapasztalom en is a UPC halozaton @ Szombathely
Lehet, h megsem egyedi a problema es nem a felhasznalonal van a gond?

Látom elég öreg a topic, de nekem most jött elő ugyanez a probléma debrecenben. Váltottam a jelenleg legnagyobb 120-as csomagra, és a jelenség nálam is az, hogy egy szálon 25 mbit körül van a max lefele irányuló adatforgalom. Ha inditok 4-5 szálat, szépen tartja. a 20mbitet minden szál.
Az ügyfélszolgálat az operációs rendszer gyártójának felkeresését emlegeti :) Próbáltam vistan, osx-en, meg egy xp-n is. Közvetlen upt kabellel a modembe, de semmi változás.
Valaki talált már erre megoldást, vagy tud rá magyarázatot, hogy mitől lehet?

Köszi,
Somi

Nálam is, viszont nekem a feltöltésem lassú (30/3-as kapcsolaton átlag 1,5 megabit) és a pingem borzalmas (>200). Szintén esti órákban (tipikusan amikor enemy territoryznék). Traffic shaping-el próbálkozom, de mivel ingadozik a sávszél, ezért nem tudom fixre jól belőni.

--
http://csuhai.hu
http://sys-admin.hu

( bird v | 2008. 10. 24., p – 14:43 )

Nemrég csináltam egy tesztet. Két számítógépen, 4 böngészővel és vagy ötféle sebességmérő oldalon sem sikerült 2 Mbit-es sebességnél gyorsabban töltenie a hálónak.

IE-vel volt, hogy 4 Mbitet írt ki, de ez is édeskevés az ~1200KB/sec-es sebességhez képest.

A feltöltési sebességgel nem volt gond, általában 1800/1900 kbps-t jelzett.

Ugyanúgy UPC 10/2, @Rákoskeresztúr/Madárdomb
---
Powered by Áram

csomagpriorizálás van, ráadásul az összes sebességtesztet igyekeznek a max sávszéllel produkálni, nehogy feltűnjön nekünk.
példa:
msn-en keresztüli 2-3 megás file szaggatva ér át (ugyanez másik neten elő sem fordul)
www-n és ftp-n főműsoridőben gyatra a garantálthoz képest
p2p: még mindig nem kaptam választ (több mint egy év után), hogy az akkori 1MBit/128kBit-es kapcsolattal (most már 15/2) ha p2p-t űzök, akkor milyen gazdasági és technológiai szempontok késztetik a korlátozásra? értsd: előtte átlag 60 kByte/sec lefelé, utána 1-12 között.

egyelőre csak a megszokás és a lustaság nem késztet váltásra, meg a p2p forgalom drasztikus visszaesése (nincs időm rá).

--
Sony Vaio &

aMSN-t használok, azzal pedig nagyon gyorsan megy a file átvitel, nem ftp-zek, www mindig gyors, torrentet titkosítva használom, ha van elég seeder, maximális sebességgel jön az épp töltött ISO. Nézesd meg, megfelelő jelerősség van-e nálad, a modem megfelelően működik-e.

---------------------------------------------------------------------------------
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!

2-3 hónapja volt modemcsere, mert a régi feloszlott idegileg. a szervizes első körben végigmérte az utcát, a bejövő kábelemet, majd a házban található kábelhálózatot. felszerelt 2 szűrőt ahova kellett, egy F csatlakozót kiváltott (pedig nem lett volna kötelessége), majd az új modemet bekonfigolta.
azóta jelproblémám nincs.
az volt a kiborító, hogy csak arról kaptam értesítést, hogy változik az email cím domain-je, a priorizálásról pedig nem, holott az ászf-et változtatták, r-go az ügyfelet előre kellett volna tájékoztatni. az, hogy ezen információ a neten előbb elérhető volt hírforrásokból, számomra NEM mérvadó, mert a szolgáltatónak kötelessége írásban tájékoztatni az ügyfelét minden olyan változásról, mely az igénybe vett szolgáltatást érinti.
nos tehát akkor visszakanyarodhatunk a piszkossághoz: az adatforgalom zajlása nem "innét odamegy és kész" formában megy, hanem darabolják az átvitelt észrevehető módon. egy-egy "adatcsomag" kb 3-4 pihenővel jut el a célállomásig. látható egy egyszerű átviteli információban, mely ugye real-time számolja az átadott biteket, meg csíkot húz, itt vehető észre. azt meg ne mondja senki, hogy egy 100-200 kByte méretű png képet 4 darabba kell megkapnia a célszemélynek.
érdekesség, hogy a sötét éjszakában ezen jelenség nem tapasztalható.

sokkal kevesebb p2p forgalmat bonyolítok, mint anno az 1 megás kapcsolattal.
(fél év szünet után havi 1-2 letöltött mp3)

--
Sony Vaio &

számlán rajta volt mikor ezt bevezették (amúgy az ÁSZF-ben jóval előbb benne volt minthogy gyakorlatilag elkezdték volna használni, csinálni).

Az ÁSZF-ben benne van a fai use policy, szóval örülj, hogy nem az van, hogy lekapcsolják a neted mint ténél, hanem így mindenki jól jár. Ha van elég kapacitás megy ezerrel, ha nincs, akkor visszafogja, hogy a web meg a mindenki által használt dolgok menjenek.

A Fair pay policy elvárása alapján a Fair ISP behaviour policy elvárható. Ha nekem az tetszene, hogy egész nap csak töltsek mindenféle junkot, akkor a pénzemért elvárható lenne, hogy meg is tehessem. Kissé ferdített példával: csak akkor kapsz benzint, ha nem mész 130-nál gyorsabban, különben csak fél litert. Még jó, hogy a benzin pre-paid szolgáltatás, nem beszélve a konkurencia sokaságáról.
Egyébként a UPC nemes egyszerűséggel túlvállalta magát, csak nem vallja be. Amíg a 64 kB/s-os, 9900 Ft/hós Axelero és Invitel volt az ellenfél, addig produkálták a teljes sávszélességet, amint a piac domináns szereplőivé váltak, ott, azonmód a FUP üzemmódba kapcsolták a felhasználókat.
Itt, Dunaújvárosban, meg is *opták tisztességesen, mert a Digi elszippantja az ügyfeleiket. Felteszem, amint a Digi eléri a UPC lefedettségét, a FUP nem lesz mérvadó, vagy jelentéktelen szereplő lesz. Erre most fel mernék dobni 100 €-t.

Nézd meg alaposan, mi az a garantált szolgáltatás, amiért fizetsz. A szolgáltató hálózatán belül, megadott módon mérhető garantált sávszélességért, illetve a rendelkezésreálló kapacitások függvényében a bel- és külföldi irányok eléréséért. Ez úgy en bloc szolgáltatófüggetlenül van így, ugyanis maga a szolgáltatási infrastruktúra működik így.

Néhány észervétel:
Az UPC-t nem ismerem, de a T-Home a változásról úgy értesít írásban, hogy a számlalevélben jelzik, hogy változott az ÁSZF, és a változást a honlapon találom meg. Ha a változás a számla elküldése után történt, akkor a honlapon már az értesítés előtt is olvasható.
A TCP/IP legnagyobb csomagmérete 65515 byte, ami azt jelenti, hogy egy 200 kByte-os kép legalább 4 darabra vágva halad át a hálózaton. (A gyakorlatban -- a két gép közötti teljes hálózat konfigurációjától függően -- ennél több darab is lehet.) Az egyes darabok különböző útvonalon is haladhatnak, és az útvonalak sebessége jelentősen eltérhet. Ha a két gép közötti hálózatrész terheltsége kisebb, akkor nagyobb valószínűséggel haladnak ugyanazon az útvonalon.

-----
Dropbox tárhely igénylése: https://www.getdropbox.com/referrals/NTI2MzM2MjA5

nyilván a tcp/ip tulajdonságaiból adódó "szüneteket" nem érzékeled.
de amikor 1-2 másodperces szinte off állapot van, azt már észreveszed.
átmegy 70 kB, vár 1-2 másodpercet, addig is 0 az átviteli sebesség, majd újabb adag.
vicc kategória, pedig nem p2p-ről beszélek, egyszerű file átvitel.

--
Sony Vaio &

Nem a tcp csomagméretéről, hanem a TCP/IP csomagméretéről írtam. Igazad van, helyesebb lett volna azt írni, hogy a TCP/IP protokollkészlet csomagmérete. Vagy még pontosabb lett volna, ha azt írom, hogy a TCP/IP protokollkészlet IP rétegének csomagmérete.

A 6k-s korláthoz: "... egy 200 kByte-os kép legalább 4 darabra vágva halad át a hálózaton. (A gyakorlatban -- a két gép közötti teljes hálózat konfigurációjától függően -- ennél több darab is lehet.) ... ". Azért lehet több darab, mert lehet olyan hálózati szakasz, ahol az elvi maximumnál (65515) sokkal kisebb a megengedett méret. És mivel az volt a mondanivalóm lényege, hogy a kép több darabban jut el a célállomásra, így a te megjegyzésed csak megerősítette az én állításomat.
Köszönöm a megerősítést.

A "... ez nem tcp layer, hanem lentebbi, sokkal." pedig úgy lenne helyes, hogy "ez nem TCP réteg, hanem lentebbi (eggyel)". Ugyanis csomagokról csak az IP rétegben beszélhetünk, és az közvetlenül a TCP réteg alatt helyezkedik el.

-----
Dropbox tárhely igénylése: https://www.getdropbox.com/referrals/NTI2MzM2MjA5

az egy vaskos marhaság, hogy csomagról csak az ip rétegben beszélhetünk, helyesebb lenne azt mondani, hogy a tcp rétegen kívül mindenhol. Van ethernet, ip, udp csomag.

A 6k-s csomagméret korlátot nem általában mondtam, hanem ilyennel egy helyen lehet talákozni: az upc kábelmodemeiben. Máshol pont 6k-s csomagméret korlátot még nem láttam. És ez nem ip hanem inkább atm szintbeli korlát, tehát nem a tcp alatt eggyel, hanem sokkal lejjebb van (3 vagy 4, most nem számolok utána).

Jobb lenne, ha ezeknek egy kicsit utánanéznél.
Pl. az udp helye a TCP/IP protokoll készleten belül. Melyik rétegben beszélünk üzenetről és keretről?
ATM-nél csomag? Talán cella és sokkal kisebb méret (5 + 48 byte). De az ATM dolgairól a TCP/IP protokoll semmit nem tud.

-----
Dropbox tárhely igénylése: https://www.getdropbox.com/referrals/NTI2MzM2MjA5

( mn3monic v | 2009. 12. 21., h – 13:18 )

Szerintem érdemes megnézni, hogy mennyi is a garantált sávszélesség.

( zsirmo v | 2009. 12. 21., h – 17:06 )

ha van valahova ssh accod, ahol tudod hogy meg van a magyar(BIX) iranyba a megfelelo savszel
akkor ajanlom az iperf vagy wintalicskabinaris
progit tesztelni! tud egyszal, tobbszal tesztet, es nincs az hogy bongeszo, meg op.rendszer stb. blablalba

( SySERR | 2009. 12. 21., h – 18:54 )

Nem feltuno, de a pingek is nottek a priorizalas ota: 


root@syserrgw:~# ping index.hu
PING index.hu (217.20.130.97) 56(84) bytes of data.
64 bytes from sportgeza.hu (217.20.130.97): icmp_seq=1 ttl=60 time=46.8 ms
64 bytes from sportgeza.hu (217.20.130.97): icmp_seq=2 ttl=60 time=17.8 ms
64 bytes from sportgeza.hu (217.20.130.97): icmp_seq=3 ttl=60 time=15.2 ms
64 bytes from sportgeza.hu (217.20.130.97): icmp_seq=4 ttl=60 time=22.0 ms
64 bytes from sportgeza.hu (217.20.130.97): icmp_seq=5 ttl=60 time=17.1 ms
64 bytes from sportgeza.hu (217.20.130.97): icmp_seq=6 ttl=60 time=19.1 ms
64 bytes from sportgeza.hu (217.20.130.97): icmp_seq=7 ttl=60 time=15.7 ms
64 bytes from sportgeza.hu (217.20.130.97): icmp_seq=8 ttl=60 time=17.6 ms
64 bytes from sportgeza.hu (217.20.130.97): icmp_seq=9 ttl=60 time=19.3 ms
^C
--- index.hu ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8017ms
rtt min/avg/max/mdev = 15.207/21.231/46.873/9.271 ms
root@syserrgw:~#

A priorizalas elott 9-12 volt a pingem.
Az mar egy masik dolog hogy az Adatpark fele meg eleg erdekes a routing: 


 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. catv-80-99-119-254.catv.broadban  0.0%    17   23.1  13.5   8.5  23.9   4.9
 2. ???
 3. catv-80-98-55-41.catv.broadband.  0.0%    17   29.1  24.6  13.4  76.4  15.4
 4. 84.116.240.2                      0.0%    17   21.8  23.1  14.4  38.9   9.2
 5. de-fra01a-rd3-xe-4-1-0.aorta.net  0.0%    17   31.0  37.2  31.0  55.3   8.0
 6. de-fra01a-ri2-xe-2-2-0.aorta.net  0.0%    17   50.7  40.8  28.9  82.2  14.0
 7. 213.46.179.102.aorta.net          0.0%    17   39.1  47.1  35.3 109.4  20.6
 8. vlan69.csw1.Frankfurt1.Level3.ne  0.0%    17   38.7  49.8  38.7  84.7  11.5
 9. ae-61-61.ebr1.Frankfurt1.Level3.  0.0%    17   37.3  40.4  35.3  48.9   4.2
10. ae-1-12.bar1.Budapest1.Level3.ne  0.0%    17   54.7  62.7  50.6 111.2  17.9
11. ae-0-11.bar2.Budapest1.Level3.ne  0.0%    17   55.6  66.7  50.0 121.5  18.4
12. 212.162.26.134                    0.0%    17   32.1  36.7  29.3  50.0   5.7
13. 84.1.104.138                      0.0%    17   48.4  36.3  31.7  48.4   4.6
14. 84.2.225.246                      0.0%    17   43.0  39.3  29.8  78.1  12.3
15. 84.2.225.113                      0.0%    16   31.6  37.1  29.7  67.6   9.7
16. s3w.hu                            0.0%    16   29.6  39.6  29.6  69.0  11.3

vannak, akik gleccsereken síznek, vannak, akik búvárkodnak a cápák között és vannak, akik rootként csinálnak dolgokat:)

az igazi f.sza csávók soros portra dugott eszközökbe tolják bele a minicom init stringjét és megnézik, hogy mit borít meg:) (elindítod a minicomot, bejelentkezel szabályosan, utána kilépsz és visszalépsz úgy, hogy közben ott volt az admin konzol) izgalmas még ebben a számban cut&paste-zni valamit véletlenül root ablakba:)

( hg2ebh | 2009. 12. 22., k – 23:51 )

Ez ám a korrekt belföldi routing... Frankfurtból fordul a csomag...