UPC-ről tudunk valamit?

 ( kumgabor | 2013. november 2., szombat - 13:07 )

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Pont eleget ahhoz, hogy messzire elkerüljem őket! :D
Sajnos a többi szolgáltató is kezd felzárkózni hozzá. :-(
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

engem most hívtak pár perce hogy + 710 hufért dupláznák a netet, meg adnának még pár csatornát :D

+1

Viszont a Digi eddig jó, nemrég cseréltem az ő optikaijukra ADSL-ről
De az ADSL is megbízható volt de csak 4Mbites le, ~512 fel

Kidobva a UPC-s DNS szervereket, jónak tűnik:
dhcp-option=6,8.26.56.26,8.20.247.20,8.8.8.8,8.8.4.4
----------
rohamkocka

Sajnos úgy sem bár javul a helyzet de akkor sem tökéletes! :-S

Külföldről továbbra sem érem el a UPC-s gépeimet, ez pedig nem névszerver probléma.

--
Kum G.
Linux pólók HUP pólók Linux tanga

Jahm, érdekes, pl az ncore-t rendben feloldja (erre hivatkoznak sokan, hogy nem érik el), de a weboldalt mégsem hozza be.

----------
rohamkocka

$ traceroute 89.135.209.**
traceroute to 89.135.209.** (89.135.209.**), 30 hops max, 60 byte packets
1 192.168.2.1 (192.168.2.1) 0.419 ms 0.363 ms 0.377 ms
2 * * *
3 10.76.178.25 (10.76.178.25) 80.311 ms 80.528 ms 89.992 ms
4 10.78.248.74 (10.78.248.74) 99.942 ms 109.849 ms 110.253 ms
5 * * *
6 * * *
7 * * *
8 * * *
9 78.25.80.93 (78.25.80.93) 145.921 ms 145.957 ms 145.992 ms
10 78.25.80.92 (78.25.80.92) 155.425 ms 155.504 ms 156.005 ms
11 * * 10.222.255.78 (10.222.255.78) 180.351 ms
12 te-3-4.border2.lon.docler.net (195.66.224.210) 270.085 ms 269.246 ms 269.291 ms
13 TE-3-1.border0.ams2.dditservices.com (5.159.218.41) 179.295 ms 179.091 ms 170.777 ms
14 TE-2-2.core2.dp.bud.docler.net (80.77.112.158) 171.385 ms 170.875 ms 139.931 ms
15 TE-Po1-10.core0.dhq.bud.docler.net (80.77.112.237) 149.655 ms 169.275 ms 169.034 ms
16 TE-9-2.core1.vh.bud.docler.net (80.77.112.194) 169.155 ms 169.074 ms 149.750 ms
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

--
Kum G.
Linux pólók HUP pólók Linux tanga

ja, én is lecseréltem saját NS-re, akkor nekem minden jó lett (legalábbis amiket én nézek).

Szerintem nézz meg más oldalakat is, pl. hetzner.de

Hmm, érdekes:

hetzner.de [213.133.107.227] pingelése - 32 bájtnyi adattal:
Válasz 213.133.107.227: bájt=32 idő=29 ms TTL=63
Válasz 213.133.107.227: bájt=32 idő=29 ms TTL=63
Válasz 213.133.107.227: bájt=32 idő=28 ms TTL=63
Válasz 213.133.107.227: bájt=32 idő=30 ms TTL=63

És a weboldal mégsem jön be ...

----------
rohamkocka

Hmm, ezt nem is néztem - érdekes.
Ezek a csomagok nálam is megjönnek, a weboldal viszont nem. Utóbbi ugyanakkor működik, mert VPS-en átpasszírozva bejön az oldal is.

Bekapcsolták a tartalomszűrést -- csak még nincsen beállítva "Az amennyiben ez az oldal a munkádhoz szükséges, vedd föl a kapcsolatot a Helpdeskkel" :) :)

----------
rohamkocka

Ok, akkor ezentúl csak munkára lehet használni az internetet? Akkor a többség számára az 1 Mb/s-os sebesség is túlzás.

-----
(&%;_98\<|{3W10Tut,P0/on&Jkj"Fg}|B/!~}|{z(8qv55sr1C/n--k**;gfe$$5a!BB]\.-

AZ valóban nem megy.

De éljenek a proxy-k, így amíg belföldi forgalom van nem számít :D

Nagyobb a gond, ugyanis a hetzernel levo gepeket se erem el upc-on keresztul.

Így van - Hetznert, és angol VPS-t sem érek el, ugyanakkor egy amerikait igen...

Ezen felül még korábban nem tudtam, miért nem elérhető egy oldal, amiről letölteni szerettem volna - azt hittem, áll a szerverük.
...hát nem náluk volt a baj...

Nekem ott a monitoring gép, pontban 0:00-kor jöttek a nagiostól a mailok az összes UPC-s figyelt végpontra, azóta sem megy...
--
The Community ENTerprise Operating System

Pontban 0:00-kor nem nagyon szoktak véletlen dolgok történni

--
Kum G.
Linux pólók HUP pólók Linux tanga

Ez is egy nagy igazság :) Megy is aláírásba.

-----------
"640GB sokmindenre elég"

Ha munkát keresel, akkor kezdd az elején: írj CV-t.

Híres leszek?

--
Kum G.
Linux pólók HUP pólók Linux tanga

Úgy fest :)

-----------
"Pontban 0:00-kor nem nagyon szoktak véletlen dolgok történni"

Lehet hogy hülyeség de nem lehet hogy összefügg a szökőmásodperccel?

http://hup.hu/szavazasok/20150701/a_2015-os_szokomasodperc_nalunk_okozott

Mondjuk az 30-ról elsejére virradóra volt

Off

Elfogyott a Linux tanga:)

necro! 2013

---
Referrall https://goo.gl/7S2vlp (koding) | https://goo.gl/muWzKz (digitalocean)

"az amszterdami központtal közösen dolgoznak a megoldáson, még nem tudják, mi okozza pontosan a problémát"
A UPC már teljes mértékben beköltözött a holland felhőbe. :)
--
zsebHUP-ot használok!

A UPC saját nemzetközi hálózatát (aorta.net) használja külföldi adatcserélésre, aminek a központja van hollandiában (illetve a upc szolgáltatások zöme is ott foglal helyet). Valószínűleg ott van valami gebasz, mert infók alapján csak a külföldi eléréseket érinti a hiba


// Happy debugging, suckers
#define true (rand() > 10)

Subscrible. Amúgy nem csak a UPC hülyéskedik, a T- se 100-as, akadnak apróbb fennakadások tegnap ~23 óta.

Eh, eltűntet az NSA pár transzparens bridge-et, erre fél Európa leáll :D

Ez kész! :D

azért az jó, hogy elég a hup-ra feljönni és rögtön látom tényleg globális a probléma. jobb a hup mint a upc helpdesk :D

Ezért is kérdeztem itt. A T rendszeres lehalásáról itt lehet a legtöbb információt kapni.

--
Kum G.
Linux pólók HUP pólók Linux tanga

most köti be az NSA a lehallgatókészüléket a magyar internetbe!!!!!!

pont minket akarna lehallgatni! :))))

--- Jaj ne, már megint én! :D ---

liberty ?

Pár perce rendesen működik minden. Kíváncsi leszek a hiba okára.

--
Kum G.
Linux pólók HUP pólók Linux tanga

Meddig?! :)

bár a grafikonok szépek a bix-en, de szerintem ez még nem 100-as....

Mivel döntően minden hír arról szólt, hogy a külföldükkel van/volt gond, az meg értelem szerűen nem igazán látszik a BIX forgalmán, így..

"Az UPC-ről tud valaki valamit?"

Én eleget tudok, hogy Hétfőn az legyen az első dolgom, hogy bontom a szerződést a gecibe...

--
openSUSE 12.2 x86_64

Én sem kedvelem őket mostanában, de nem találtam sokkal kevésbé idegesítő alternatívát.

Én igazából egy olyan szolgáltatót sem tudok mondani, amelyikkel maradéktalanul elégedett lettem volna. Igaz még csak hármat "fogyasztottam el". Jelenleg UPC van, de nem tudom mennyire javulna a helyzet, ha most hirtelen felindulásból szerződést bontanék (hűségidő már nem köt), és mennék egy másikhoz. A digi az érdekelne (azt is akartam eredetileg), de az nálunk nincs.

Invitel ADSL-em volt korábban, 4-5 év alatt leállás nélkül. Pedig küldtek néha e-mait, hogy kiesés lehet 10-15 percre a "társszolgáltató munkái" miatt, de soha nem volt a logok alapján.
Persze a kínált sebességeket nem érdemes egymás mellé tenni.

--
Kum G.
Linux pólók HUP pólók Linux tanga

Én nem emlékszem, hogy 5 éven belül lett volna ilyesmi. 5 évente meg egy belefér, a többi szolgáltatónál se jobb.

Nálam nem fér bele. Naponta küzdök az kiadott szar eszközeikkel. állandó net szakadozás, lassúság, szar dns szerverek miatt sajátot kell konfigurálnom stb...
Szóval váltok Digire. Volt már vele dolgom, és nem volt annyi gond, mint ezzel a szarral. Csak köröket kell futnom a tulajjal...

--
openSUSE 12.2 x86_64

hát hajrá, a digi az catv-s vagy utp-s?

Itt UTP-st szoktak kötni. De ahogy hallottam, van ahol optikát adnak.

--
openSUSE 12.2 x86_64

8.8.8.8 és 8.8.4.4 dns miért nem jó?

http://hup.hu/node/127969

--
openSUSE 12.2 x86_64

Felénk a hálózatot rendberakták az elmúlt években, előtte folyamatosan voltak gondok a UPC-vel. Ami zavar, az a szinte folyamatos DNS-probléma.

--
Kum G.
Linux pólók HUP pólók Linux tanga

ez miért zavar? OK, értem én, hogy jó volna, ha menne, de használhatsz google DNS-t, ill sok egyebet.

Persze, Józsibácsinak ez kevésbé jó megoldás, de Te azért csak meg tudod oldani...

Google DNS-t használok, de jobban örülnék, ha inkább a szolgáltatómét használhatnám. A "sok egyéb" alatt konkrétan mikre gondolsz?

--
Kum G.
Linux pólók HUP pólók Linux tanga

valószínűleg nem blokkolja a szolgáltatód a root DNS-ek használatát, így akár telepíthetsz saját (caching only) nameservert is. Használhatod a munkahelyed DNS szerverét (ha távolról beengednek). Megkéred a haverodat, h engedjen hozzáférni a DNS-éhez, etc.

Én világ életemben saját resolvert használtam - a problémát se értem a "nem megy a szolgáltató resolvere" c. történetben...

Jó ötlet, köszönöm.

--
Kum G.
Linux pólók HUP pólók Linux tanga

akkor itt is jeleznem, hogy letezik ez a projekt - ha valaki nem ismerne. peldaul a "sok egyeb" kozul ez az egyik. jelenleg 63 ns szerver alkotja, van mibol valogatni.

Meg majd váltogatni, ha elkezdenek szaporodni a TLD-k az internetes névtérben. :)
--
zsebHUP-ot használok!

Ez érdekes, köszönöm!

--
Kum G.
Linux pólók HUP pólók Linux tanga

Nem nagyon, az utóbbi kb. fél évben marha sok leállás volt... Azelőtt nem is emlékszek még csak kimaradásra sem errefele, most fél éven belül a sokadik. Ráadásul olyan, ami mindenkit érint, a business előfizetőket is, mert most ugye arról beszélek.
Nem tudom mi van, felvettek valami magát "network engineer"-nak valló szakbarbárt, vagy beszereztek valami szuper új eszközt, de kezdi verni a t-nek a minőségét a szolgáltatásuk.
--
The Community ENTerprise Operating System

Ugye a hírek alapján az UPC tök vétlen ebben az esetben.

Valahogy nehezen tudom elhinni, hogy egy tök más cég rosszul beállított cucca okozta. Ennyi erővel, fogom és beállítom a Google tartományát az itthoni routeremen és leállítom félnapra komplett Google cuccot. Kicsit kamun hangzik.

--
openSUSE 12.2 x86_64

Tessék tanulmányozni a BGP mûködését. Elvileg csak azon prefixeket (értsd IP blokkokat) szabadna elfogadni a hirdetôtôl ami igazoltan hozzá köthetô.
Mivel a kérdéses cég elég komoly nemzetközi infrastruktúrával is bír -és tranzitál is forgalmat- akár még jogos is lehetne, h átmegy rajta a forgalom. Valószínûleg sokadik route kéne, h legyen - de vmiért preferrált lett.
(Szerintem)

Lehet, h rosszul gondolom, de eleg sokrétû nek tûnik a probléma. Ja, és simán lehte, h a Te csomagod kimegy a UPC hálózatól de vissza - fentiek miatt- már nem talál. Ez pedig már kevésbé a UPC hatásköre...

Olyan is volt, hogy Pakisztán le akarta tiltani a youtube-ot országon belül és rosszul módosították a konfigurációt. A rossz információt nagyon gyorsan tovább adták egymásnak az eszközök tier 1 szinten és emiatt az egész világon órákig nem volt youtube.

Semmi közöm az UPC-hez, de ilyen létezik.
http://www.renesys.com/2008/02/pakistan-hijacks-youtube-1/

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Ok. Ha 3-an is találtatok ilyet, akkor elhiszem, hogy van ilyen. Csak akkor nem értem, miért nincs ebből állandó probléma?.. (hisz annyi gyökér van ezen a bolygón, hogy már csak puszta élvezetből szopatnák a népet...)

--
openSUSE 12.2 x86_64

Általában a triviális dolgok ellen védekeznek. Az alapvetõ emberi hülyeség csodákat kêpes produkálni. Ha egy ilyen eset elôfordul, akkor kidolgozzák rá a védekezést is. Szerintem a paki trükköt sem lehet beadni újra.

+1
gyanítom, van otthon egy fiber powered ötezeré, és mész inkább a másik szolgáltatóhoz.
tedd azt, és nézd meg, hogy ott boldogabb leszel-e. nem leszel.

ha tutira mész, veszel két - egymástól amennyire csak lehet - független hozzáférést.
ha erőlködsz egy kicsit, tudsz közöttük balance-olni (főleg tőled indított forgalmat),
de az az igazi nyereség, hogyha az egyik leszakad, még ott a másik.
Ja, hogy kétszer annyiba kerül? hát, a rendelkezésre állásnak ára van!

Fiber jah. Régen Digim volt, és jóval elégedettebb voltam azzal. Csak sajnos itt ez volt és el kellett fogadni vagy még be nem kötik. Ugyanannyi a digi, mint ez és 80/25-t ad, 60/3 helyett...

Failovernek meg ott a mobilnet. Igaz nem automatikus, de legalább van.

--
openSUSE 12.2 x86_64

Volt ilyenem itthon, egy Dunaweb mikros meg egy Fibernet kabelteves, amig mindkettot meg nem vette az Invitel :-)

Hasonló sztori: üf.-nek csak úgy lehetet netet csiholni, hogy volt benne egy mikrós szakasz. 2x2Mbit-es mikró felrak, üf. megkapja az egyik csatornát, másik netszolgáltató meg rácsap a másikra, mondván, hogy neki nagyon kell ott egy ilyen összeköttetés.
Jött a karbantartási igény, üf. (meg a másik netszolgáltató is) megkapta a ticketet a szolgáltatótól, hogy a mikrós átvitel karbantartás miatt állni fog x időpontban. Üf. örül, hiszen vett egy másik szolgáltatótól tartalék vonalat... A kellemetlen az volt, amikor a tartalék szolgáltatótól megkapta a levelet, hogy rajtuk kívülálló okok miatt x időpontban a szolgáltatásukat szüneteltetni fogják...

Ennél csak az volt a durvább, amikor a két 64k-s bérelt vonal, ami egymás tartalékja volt, ugyanazon az érpáron közlekedett... Igaz, itt a cég saját magának kiépített vonalairól volt szó...

No és ahhoz mit szólsz, amikor 16db redundanciát biztosító vonalból 9 ment ki, mert ugyarra az eldurrant kártyára csatlakoztak. Pont akkor, amikor az adatbázis inaktív lett. És akkor még nem a + csinálta ospf volt, így el kellett kezdeni a dolgozók berendeléset reggelre a másik telephelyen.

Csaxólok, hogy az a 2x64k adta a cég ... szolgáltatását biztosító három telephely egyikének a szerverek felé a kapcsolatot. Ennek a leszakadása a pécsi telephely és az ott lévő kb. 80 munkahely (a nagyjából 300-ból) kiesését jelentette volna. Az egész rendszer úgy lett tervezve, hogy SPOF ne legyen. A kivitelezésbe viszont itt-ott belecsúsztak ilyen hibák... Egy ilyen leszakadásnál nem másnapra, hanem "azonnal" kellett volna kezelőket előteremteni a másik két telephelyen - szerencsére tartalék (üres) munkahelyek azért mindenütt volt, ha nem is sok.

már benne van, nyugodt lehetsz.

Lehetséges, hogy egyes debian mirrorok is érintettek?
Pl. ftp.hu.debian.org?


Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

"a cég kommunikációs igazgatója azt mondta, hogy egy hazai internetes cég konfigurálta félre a UPC IP-címtartományait, ezzel pedig elterelték a cég felhasználóit." via

Szűcs úr (a pletykák szerint) egy időben jelen volt az index fórumán. Amennyire emlékszem, nem szokott hülyeségeket beszélni.


Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

lol

Valaki a nagyok közül megint nem szűrte a BGP prefixeket?

Normális esetben Pistike bt hiába trombitál, hogy a 11.12.13.0/24 az övé ha az upstream másképp gondolja.

lehet, hogy én tudom rosszul, de elvileg csak olyan prefixet fogadnak el tőled, ami hozzád tartozik (vagy rajtad keresztül elérhető). Mindkettő RIPE adatbázisban nyilván van tartva,
ami alapján dolgoznak a route filterek.
(bár ezt lehet, h sokan nem használják)

https://stat.ripe.net/widget/bgplay#w.resource=89.134.0.0/15

itt meg lehet nézni, h mi történt ill. történik éppen a világban.

Nekem úgy tűnik, hogy az egyik jelentős hazai _tartalom_ szolgáltató hálózatán át érhető el a UPC (valószínűleg hibás konfiguráció miatt).

Hahh, ez marha mókás kis eszköz. Pár óra alatt szépen magukra húztak elég sokmindent.

ha jol ertelmezem, akkor dacosan magukkal vittek az internetet is brusszelbe?

--
NetBSD - Simplicity is prerequisite for reliability

http://index.hu/tech/2013/11/11/a_pornokiraly_cege_akasztotta_meg_a_upc-t/

az, hogy miért fogadták el a UPC tartományára a hírdetést tőlük, és miért kellett ennyi idő a javításra, az még mindíg nem tiszta.

biztos fog mostanaban meguresedni pozicio, jelentkezz, es megtudhatod. :)
--
zsebHUP-ot használok!

Ők is felajánlhatnának pár filmet ingyen. Biztos vannak akik élveznék a szopás után.

:)

Jók a hozzászólások:
user1: "jé? ilyet lehet? ez ilyen egyszerű?"
user2: "Nem ilyen egyszerü csak lefordították a hozzád hasonló egyszerü emberek nyelvére"

Ha U2 tudná, hogy milyen egyszerű. :)
--
zsebHUP-ot használok!

Asszem nemrég Kínán ment keresztül a fél világ egy hasonló nyomor miatt.

...no és akkor ki hirdetett milyen AS szám alól milyen IP tartományt? :D
http://www.origo.hu/techbazis/20131102-eltereltek-a-upc-forgalmat.html

Szerintem itt a válasz :) http://hup.hu/node/128012?comments_per_page=9999#comment-1660299

Mintha tegnap délután kettőkor állt volna helyre a rend.

én inkább tegnap éjjelt (vagy késő estét) mondanék. azért a hivatalos kommunikációra nagyon kíváncsi leszek.

Hát, nekem reggel, délelőtt volt észrevehető nyomorom az FB képekkel (akamai vagy mi elérése), délután már nem tűnt fel.

Meg most...

Nekem este het korul. Reggel neztem, nem ment, aztan Allatkertbe mentem a gyerekkel es mikor negy korul megjottem, nem ment.

Egy ugyfelunk proxyjat hasznaltam arra a par infora, ami kellett (vmi ADSL kapcsolatuk van)
Aztan ugy este het korul rendbejott.

--
http://www.micros~1

X. keruletben fel oraja semmi nyoma azinternetnek. nalatok minden ok?

XIV.-ben szuperjó

Igaz ez tök függetlenül a tegnapi hibától, de itt ma megint volt egy több mint 1 órás leállás...
--
The Community ENTerprise Operating System

Megint kezdődik valami lassulás, packet loss, timeout... Nálatok is, vagy csak én látok már rémeket? :)
Kezd besárgulni a nagios a upc-s végpontokra.
--
The Community ENTerprise Operating System

Ez van FB-n.

Kedves Előfizetőink!

Jelenleg nem működnek a szolgáltatásaink, ha áramszünet vagy áramtalanítás után újraindítjátok a modemet. A probléma okát jelenleg kutatjuk, azonnal tájékoztatunk mindenkit, amit többet tudunk arról, hogy ezt a hibát mikorra tudjuk elhárítani. Köszönjük a türelmeteket!

még jó, hogy UPC független mobilon is lehet nézni a facebookot :-)

Remek, kösz. Azóta amúgy helyreállt minden....
--
The Community ENTerprise Operating System

Ma nem láttam, de tegnap véglegesen begőzöltem, és "újraálmodtam" a komplett bekötést. Volt a bejövő kábelen egy elosztó, és 2 szűrő. Egy EZHP 88/65/50 036 és egy EMN-224.25 025 jelölésű. Előbbi a(z amúgy nem bekötött) TV-felé érkező kimeneten volt, utóbbi a netfelé jövő. Az EZHP-st felismerem, az a TV felől kell szűrje a cuccot, de ezt a másikat nem ismerem és sehol sem találtam semmi infót erről. Tudja valaki mi ez a második? Mondjuk mióta nincs bent, azóta nincs annyi net szaggatás.

--
openSUSE 12.2 x86_64

Én ilyesmit nem láttam, de egy ismerősömhöz (legalábbis ezt mesélte) kijött az UPC, mértek valamit, azt mondták, hogy túl erős a jel, betettek egy csillapítót és elmentek... nem ő hívta őket, a nettel pedig sem előtte, sem utána nem volt gondja.

Ez most konkrétan nem minősítése semminek, csak érdekesség... nem tudom, mi lehetett ez nálad, de lehetett akár hasonló céllal is bent.

mi is jártunk már így. A bekötésnél még más volt a jelszint, aztán a közelben felraktak egy erősítőt. Gyanítom, ez azon helyeken, ahol előtte is már nagyon jó jel volt jeltorzuláshoz vezethez.

Gondolom, ilyesmi lehetett - és a rendszerükben látták emiatt a hibákat.

Másfelől fordított esetben (régen kellett, ma nem feltétlen) nem tudom, mennyire jönnének maguktól, ill. mennyire jutna eszükbe ezt ellenőrizni pl...

nyilvan van naluk is "zajkommando" csoport. ennek az eremnek a masik oldala az, amikor lemondod, de az analog tv meg megy fel evig tovabb, mert csak akkor jutnak el idoben hozzad, hogy lehuzzanak.

-

Apa kezdődik!!!
Megint valami.... Ti mit láttok?
--
The Community ENTerprise Operating System

FUNOFF:

Kiderült, nem bírtak magukkal az emberek és a pornóigényükkel összedöntötték a fél netet :D

Egyelőre minden megy, de a pingidők megint megnőttek minden UPC végpont felé...
szerk: már nem megy... tracerouteok alapján megint valami routing issuenak néz ki.
--
The Community ENTerprise Operating System

+1
Megint sz@r...
Hónapok óta fos az egész. Mehetnek kapálni.

valami konkrétumot is írnátok? nekem működőnek tűnik...

Pl nalunk a nagios del ota kb 170 email kuldott…

ssh belépés egy külső szerverre 7sec...
traceroute zéró
ping elérés egy másik szerver felé tózse
Nem arról van szó, hogy nem tudom megnézni a youtubes videót...
Dolgozni szerettem volna.

ezen információk nagyon hasznosak, jelentősen segítik a probléma behatárolását. köszönjük.

http://kepfeltoltes.hu/view/131118/dns_www.kepfeltoltes.hu_.gif

Ehhez a dns szerverek: 151.236.10.135, 8.8.4.4, 213.46.246.53, 129.250.35.250
DNS forwarder lekérdezési stratégia: párhuzamos.

Hát mint külsős ennél több infót nehezen tudunk mondani. Packet loss, össze-vissza routolt csomagok, akadozó elérés. Ennyit látunk/láttunk.

Egyébként igazán subscribeolhatna a UPC is erre a threadre, ha már nekik nincs nagiosuk :).
--
The Community ENTerprise Operating System

nézd, ha legalább 2 hostot (v prefixet) megadnál, akkor más is ki tudná próbálni.
Te - mint (talán) hozzáértő - a megadott infók alapján mihez kezdenél?
Én addig dobnám vissza a munkalapot amíg MINDEN szükséges infó nincsen benne.

89.134-es tartomány, debrecen, upc business előfizetők.
80.99 budapest, szintén business előfizetők.
--
The Community ENTerprise Operating System

Remélem azért ezeket a tartományokat nem a hupon keresztül monitorozzák.

Digi akadozik. Nem kicsit.

Nálunk soha nem akadozott, pedig több helyen is használjuk elég durva adatforgalommal.

No kéremszépen. az utolsó csepp...

# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 40 byte packets using UDP
1 * * *
2 * * *
3 * * *
Unable to look up 89.135.220.62: Átmeneti névfeloldási hiba
4 89.135.220.62 1592.216 ms 1632.322 ms 1678.301 ms
Unable to look up 84.116.240.1: Átmeneti névfeloldási hiba
5 84.116.240.1 1715.837 ms 1759.700 ms 1799.291 ms
Unable to look up 72.14.217.146: Átmeneti névfeloldási hiba
6 72.14.217.146 1840.658 ms 1885.000 ms 1926.631 ms
Unable to look up 209.85.243.119: Átmeneti névfeloldási hiba
7 * 209.85.243.119 2039.975 ms *
Unable to look up 209.85.241.212: Átmeneti névfeloldási hiba
Unable to look up 72.14.234.11: Átmeneti névfeloldási hiba
8 209.85.241.212 2107.398 ms 2164.724 ms 72.14.234.11 2192.790 ms
Unable to look up 209.85.254.114: Átmeneti névfeloldási hiba
9 209.85.254.114 1217.501 msUnable to look up 209.85.254.118: Átmeneti névfeloldási hiba
209.85.254.118 8882.160 msUnable to look up 209.85.254.112: Átmeneti névfeloldási hiba
209.85.254.112 831.258 ms
10 * * *
Unable to look up 8.8.8.8: Átmeneti névfeloldási hiba
11 8.8.8.8 1178.775 ms 1139.827 ms 1214.032 ms

--
openSUSE 12.2 x86_64

nálam szuperül megy

Útvonal követése a következőhöz: google-public-dns-a.google.com [8.8.8.8]
legfeljebb 30 ugrással:

1 <1 ms <1 ms <1 ms 192.168.1.1
2 40 ms 27 ms 19 ms catv-188-142-197-254.catv.broadband.hu [188.142.197.254]
3 7 ms 10 ms 7 ms catv-89-135-217-94.catv.broadband.hu [89.135.217.94]
4 10 ms 7 ms 7 ms 72.14.217.146
5 * 9 ms 11 ms 209.85.243.121
6 26 ms 22 ms 24 ms 72.14.234.11
7 23 ms 25 ms 25 ms 209.85.254.118
8 * * * A kérésre nem érkezett válasz a határidőn belül.
9 23 ms 22 ms 25 ms google-public-dns-a.google.com [8.8.8.8]

Az útvonalkövetés elkészült.

Dettó.

fisher@ap:~$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  catv-89-134-207-254.catv.broadband.hu (89.134.207.254)  8.113 ms  8.294 ms  8.957 ms
 2  catv-89-135-220-46.catv.broadband.hu (89.135.220.46)  7.900 ms  9.374 ms  9.342 ms
 3  84.116.240.1 (84.116.240.1)  9.303 ms  9.268 ms  9.232 ms
 4  72.14.217.146 (72.14.217.146)  9.508 ms  10.247 ms  10.214 ms
 5  * 209.85.243.119 (209.85.243.119)  9.749 ms *
 6  209.85.241.212 (209.85.241.212)  25.641 ms 72.14.234.11 (72.14.234.11)  26.319 ms  26.537 ms
 7  209.85.254.114 (209.85.254.114)  30.649 ms 209.85.254.112 (209.85.254.112)  26.181 ms 209.85.254.114 (209.85.254.114)  25.473 ms
 8  * * *
 9  google-public-dns-a.google.com (8.8.8.8)  25.257 ms  26.179 ms  24.097 ms
fisher@ap:~$

Azért ez odabasz. Komolyan mind a ketten magyar nyelvű traceroute-ot használtok...?

pont ez volt az elso gondolatom nekem is.

a masodik meg az, hogy mi a franc van a nettel?

(itthon upc, teljesen halott.)

Anettel? :-D

Miért, mi a baj vele?

Az, hogy kereshetetlen, magyar nyelvű hibaüzeneteket kapsz. Próbáld meg kiguglizni, hogy mi a hiba, ha a világ 99.9%-a más szöveggel kapja meg ugyanazt a hibaüzenetet. És az hibás válasz, hogy de legalább magyarul van, és így megértheted, mert a hibaüzenetek szövegezése sose olyan, hogy abból megérthesd, mi a pontos hiba. Annyi hely egyszerűen nincs a hibaüzenet számára.

Régi, szép emlékeket idézel ezzel.
Valaha volt egy Operációs Rendszer, amit VMS-nek hívtak.
Annak az üzenetei egy pár karakteres kóddal kezdődtek. Ha nem volt elég amit kiírt, a legtöbb kódhoz volt fél-egy oldalas magyarázat a helpben. De mintha az AIX is rendelkezne valami hasonlóval.


Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Az IBM is tudta ugyanezt, gondolom AIX-on is ugyanez van: OS/2 alatt minden hibaüzenetnek volt azonosítója: pl. SYS4672-blablabla. Sajnos ők ezt túlzásba vitték, és pl. egy oprendszer nélküli floppy boot blokkja csak annyit mondott, ha rábootoltál, hogy SYS5643! SYS4716! Vagy valami hasonlót. Azért belefért volna még az 512 byte-ba annyi melléjük, hogy "Missing operating system"...

Ezt is lehet fokozni. Egyszer kigugliztam, bölcsen bólintottam, ÉS bedugtam a diszket a helyére.

Az IBM-et nem kell szidni. Kipróbáltam:
Lekapcsoltam a külső streamert. Goto hibaelhárítási kézikönyv. Az 5. őszinte válasz után közölte: Kapcsold be a streamert! Ezt vö. a Windows hibaelhárítási varázslójával.

Amikor én ezzel találkoztam, a gugli még nem is létezett... ;-)

Amúgy a Windowst meg azért ne keverjük ide, ott már koncepcionálisan el van baszva az egész, a hibaüzenetek méltó módon illeszkednek a koncepcióba...

Anno volt az a mondás, hogy a dokumentáció mennyiségét méterben mérjük :-) (mennyi polc kell hozzá...)

-

>Az, hogy kereshetetlen, magyar nyelvű hibaüzeneteket kapsz.
Nem nagy kunszt angolra fordítani. :3
Meg amúgy is, az esetek többségében úgyis le kell fordítani/egyszerűsíteni a kereső számára a kulcsszavakat, amit keresel.
Továbbá, ha van hibakód, azt úgyse fordítják le.

>És az hibás válasz, hogy de legalább magyarul van, és így megértheted, mert a hibaüzenetek szövegezése sose olyan, hogy abból megérthesd, mi a pontos hiba.
internet gyűlölet gépezet <3

>Annyi hely egyszerűen nincs a hibaüzenet számára.
Szabványosítva van, hogy hány sorban/karakterben válaszolhat/írhat a képernyőre egy program? :O

Nem nagy kunszt angolra fordítani. :3

Nem. Csak pont a lényeg veszik el (a pontos stringre keresés lehetősége).

Meg amúgy is, az esetek többségében úgyis le kell fordítani/egyszerűsíteni a kereső számára a kulcsszavakat, amit keresel.

Hibaüzenetet idézőjellel keresünk. Mert azt keresed, ahol pont ugyanaz a hibaüzenet jött ki. Nem kb. valami hasonlóról szeretnél olvasgatni.

Szabványosítva van, hogy hány sorban/karakterben válaszolhat/írhat a képernyőre egy program? :O

Nyilván minden programozó hülye, és csak a hülyeségük miatt használnak ilyen rövid hibaüzeneteket...

magyar Windows licenc > magyar Windows > magyar nyelvű a cmd-s toolok.

Hát ez a baj. A Windows-os megfelelője a tracert a 8.3 miatt.
És csak hasonló a parancs, így a traceroute viselkedésével nem mindig lehet összehasonlítani.

Azért magyar, mert átveszi a lokalizációt ha sudo-zok. Ha rootként jelentkezek be, akkor angol a komplett... A névfeloldási hiba azért mert félórás pingek miatt timeoutolt a dns..
Am még mindig ugyanez a helyzet, de legalább dns már van...

Szerk: amúgy ezt is legalább 10 percbe telt posztolni. a upc oldala egyáltalán nem jön be, egyéb más oldal is alig-alig. Azóta 2x lett újraindítva az a szutyok doboz amit routernek csúfolnak, de semmi. 8 ill. 5 perc alatt kért egyáltalán IP-t a szolgáltatótól, szóval...

--
openSUSE 12.2 x86_64

Megint nőnek a pingidők...
--
The Community ENTerprise Operating System

Nekem úgy tűnik mintha a peeringjük lenne sebesült. Vagy a GTS peeringje :D

Mókás :D

upc.hu : xmt/rcv/%loss = 10/10/0%, min/avg/max = 32.0/33.4/34.3
bme.hu : xmt/rcv/%loss = 10/10/0%, min/avg/max = 7.88/9.64/15.0

Persze upc-s kábelnetről.

ha nézel egy traceroute-t akkor látszik, h előbbi Hollandiában van (vagy csak tőlem?)

Eddig az osztrákoknál volt!

De akkor megvan miért lassult be!

http://whatismyipaddress.com/ip/213.46.242.70

Oykawa Hirohito

veszprémi upc megint kezdi.. 19:20 óta nagios szép piros majdnem állandóan
--
>'The time has come,' the Walrus said<

Vasárnap vagy hétfőn Nyíregyházán is gond volt. Hirtelen nem töltött be semmilyen oldalt és nslookup google.com nem oldotta fel.
Átírtam DNS szervert, probléma megszűnt.

Én újabban beállítottam egy bind-et DNS-feloldáshoz - azóta UPC DNS-problémái nem érintenek. :)
Meguntam... alternatív szolgáltatókat viszont nem akartam beállítani.

nekem helyi cache a dns már régóta, a nagios check meg a upc 1-es bix node-ját pingeli, és elég durva packet lossokat rajzolt nekem
--
>'The time has come,' the Walrus said<

Azt ugye tudod, hogy a legtöbb router az ICMP echót control plane-ből válaszolja meg, ezért az értelemes adminisztrátorok rate limitálják (vagy egyenesen tiltják) a válaszokat?
Magyarul egy router pingelése sem válaszidőben, sem packet lossban nem feltétlenül mérvadó.
--
zsebHUP-ot használok!

akkor, mit pingeljek, ami mérvadó?
--
>'The time has come,' the Walrus said<

Attól függ hogy mire vagy kíváncsi. Nekem az index.hu és a bme.hu két, merőben eltérő pinget szokott dobni, mert az index az kerül egy marha nagyot.

Ha (viszonylag) tutira akarsz menni akkor saját gépet pingess :D

hup.hu-ról meg ne is beszéljünk!

Ping nuku! Traceroute 120 hop után se ér oda! a 6. után meg azt se tudja merre jár!

Oykawa Hirohito

Csak akarni kell :D

fisher@zsebi:~$ tcptraceroute.mt hup.hu
Selected device eth0, address 10.34.32.21, port 55497 for outgoing packets
Tracing the path to hup.hu (195.228.252.138) on TCP port 80 (http), 30 hops max
 1  10.34.32.1  0.407 ms  0.301 ms  0.300 ms
 2  109-74-45-252.acetelecom.hu (109.74.45.252)  1.024 ms  0.892 ms  0.866 ms
 3  ten4-1.osr1-vhugo.net.telekom.hu (193.188.137.139)  1.233 ms  1.099 ms  1.160 ms
 4  xe-3-0-0.ic0-ip3.net.telekom.hu (81.183.0.154)  2.587 ms  1.413 ms  1.330 ms
 5  xe-0-0-2.ic1-dplex.net.telekom.hu (81.183.0.215)  1.607 ms  1.498 ms  1.454 ms
 6  81.183.2.210  1.515 ms  1.715 ms  1.567 ms
 7  portal.fsn.hu (195.228.252.138) [open]  1.688 ms  1.439 ms  1.964 ms

IPv6 -on pinglik :P

Ha jól sejtem, azon illik is neki. :)

Az biztos, úgyhogy nem is mondtam hülyeséget! ;) :)

nekem pesten (8.kerület) nem volt olyan fél 11-1:30-ig (voltam fent) net.. szerencsére a mobil net is elfogyott, szeretem igazán a upct.

Érdekes, mindenki rossz helyen lakik hozzám képest?
Nov 26 01:53:30 apinger: alarm canceled: GW_WAN(80.99.46.254) *** delay ***
Nov 26 01:52:02 apinger: ALARM: GW_WAN(80.99.46.254) *** delay ***
Nov 21 22:17:53 apinger: alarm canceled: GW_WAN(80.99.46.254) *** delay ***
Nov 21 22:17:16 apinger: ALARM: GW_WAN(80.99.46.254) *** delay ***
Ez meg 7.ker.

Bah, bárcsak lenne UPC-m itthon... :-(

Mazochista! Elképzeltem, ahogy bőrcuccba ostoroz a UPC, te meg ordibálsz, hogy "még, még ezaz!"

--
openSUSE 12.2 x86_64

Az egyetlen elérhető net a lakásomban a T-Home ADSL vonala, névleg 10 Mbites, gyakorlatilag egy ISDN-nel vetekedő sebességen. Ennél a UPC sokkal jobb lenne :-)

Próbáld ki a mobilnetjüket, a UPC a telenorral van szerződve ez ügyben. A telenor a UPC-hez hasonló kritikán aluli szolgáltatást nyúlt..

--
openSUSE 12.2 x86_64

+1
Itt felénk nem tudom mi van, ha telenorossal beszélek, sistergések, pukkanások vannak folyamatosan, és néha rettenetes a hangminőség is...
--
The Community ENTerprise Operating System

Az "itt felénk" mit takr helyileg? Nálam Bp-t jelenti, és itt is szar. pedig ez a főváros...

--
openSUSE 12.2 x86_64

Debrecen. Semmiben nem más a főváros...
--
The Community ENTerprise Operating System

Debrecen? az nem egy falu?... haha...

A lényeg nem pont az volt, hogy ez a főváros, és minden más csak "vidék", csak az, hogy arra szokták magukat verni, hogy "ez a főváros, itt minden jó".

--
openSUSE 12.2 x86_64

Az lenne a HD minőség? :D

Úgy tűnik, most éppen össze vannak omolva. Ami nem ritka az utóbbi napokban.
--
ulysses.co.hu

nem értek egyet. sem a BIX grafikonon nem látszik törés, sem az általam monitorozott kb 10 host nem jelez gondot.
valamint az általad küldött post nem hordoz hasznos információt, csak a puffogásod kivetülése.

Nem működik a net, nem működik az ugyanazon a kábelen jövő tv. Továbbá a hibabejelentő vonalon azt mondják, hogy jelenleg rendkívül foglaltak, és hívjam őket máskor. Mostanában már többedszer fordul elő ez. Ezek volnának az infók, akár hasznosak, akár nem. Tényleg nem biztos, hogy össze vannak omolva. Lehet, hogy minden a legfaszább. Szolgáltatás az viszont már 4+ órája (reggel 8 óta) nincs.
--
ulysses.co.hu

Nem tartom kizártnak hogy csak a te városodban/kerületedben van ez a probléma :D

http://kepfeltoltes.hu/view/131203/bme_mini_www.kepfeltoltes.hu_.png

+1
sőt, lehet,h csak a helyi erősítő állt meg. Információértéke akkor lett volna a bejelentésnek, ha
1) odaírod, hogy MINDEN szolgáltatás megállt
2) címet is írsz hozzá, legalább város-városrész

Nálunk hibátlan (UPC Business XIII-ker), szóval egyedi gond lehet felétek.

Helyreállt a szolgáltatás (14 óra).
--
ulysses.co.hu

Ha már net:
Az MX szervereik rendszeresen spam blacklisten vannak... A dolog onnan jutott eszembe, hogy épp megint kivételeket kellett hozzáadnom a mail szerverhez mielőtt megláttam a topic címét...
--
The Community ENTerprise Operating System

Mivel Business előfizetők vagyunk, egy szép panaszlevélben felsoroltam az utóbbi hónapok, napok eseményeit, azonnali reagálást kérve.

A hibák:
- Spamcop RBL lista.
- A levelek többszörösen érkeznek meg, akár 4-5 másolatban.
- A levélküldő szerver nem elérhető, vagy hibaüzenettel eldobja a kérést.

A reagálás telefonon:

Az RBL-ről tudnak, viszont nehéz tárgyalni a feketelista szolgáltatókkal, ezért elhúzódik a hibamegoldás. (KB 1 hónapja észleltük először. Ennyire nehéz?)

A másik két hibajelenséget, gyakorlatilag user hibára szerette volna kenni.

Szóval Kb. semmi hasznos.

Az RBL rendszeres probléma, nem most először jött elő.
--
The Community ENTerprise Operating System

Mi most tapasztaltuk 1 hónapja először.
Valószínűleg el fogjuk felejteni ezt az opciót és sajátot építek, de olyan kényelmes volt ez eddig...

> RBL lista.

Gyakran.

> - A levelek többszörösen érkeznek meg, akár 4-5 másolatban.

Tegnap volt 11 szeres is. Kerdeztek a kollegak, hogy ideges voltam-e?

> - A levélküldő szerver nem elérhető, vagy hibaüzenettel eldobja a kérést.

Gyakran.

ej-ejj... :(

"A másik két hibajelenséget, gyakorlatilag user hibára szerette volna kenni."

Há' mer nem értesz hozzá!!44!négy! Beezzeg a zügyfélszolgálatos mindenhez ért. Te az vagy? nem? szóval nem tudsz elküldeni egy levelet 1 példányban, monyjá'le!!!!négy! :D

Kb. hasonlóan hasznos infókat kaptam mikor jelentgettem a dolgokat, már leszarom. felhúzni sem érdemes magam rajta.. Benyomom a gépet, nincs net? töknyóc, kajálok, kv-zok stb. elkészülök, van net. oszt naponta 2x legalább lekapcsolódik a modem a netről..

--
openSUSE 12.2 x86_64

"Mivel Business előfizetők vagyunk"
Tökmindegy. Kerestem, nem találtam olyan ÁSZF pontot, hogy a mail szolgáltatásnak mennie kellene.

Az RBL döntés kérdése, nem magától jön. A probléma gyökere az, hogy a UPC a kimenő leveleknél a saját előfizetőit is szűri. Vajon erről kivel és mit is tárgyalnak??

Ez utóbbira azt a megoldást alkalmaztam, hogy más szerveren kersztül küldöm a levelet.

ez egy mai:

Recipient:
Reason: "JunkMail rejected - fep28.mx.upcmail.net [62.179.121.48]:64053 is in an RBL, see Blocked - see http://www.spamcop..net/bl.shtml?62.179.121.48"

Annyira bosszantó, az ügyfél nálam reklamál, hogy nem kapja meg a leveleket. És ez nem az első eset sajnos...

a 7. kerületben most lehalt. az üfsz. már úgy jelkezik hogy fennakadások vannak a szolgáltatásban...

14. kerületből rendszeresen nem lehet elérni a DNS szervereiket. Most is döglött mindkettő.

Valamit igazán csinálhatnának mert mobilnetről nem olyan vicces dolgozni.

--
maszili

11.kerben is lehalt.draga lesz a mobilnet

1.ker
eddig akadozott, most már azt sem

Debrecenben most jött vissza, kb 9:20 körül mehetett el. Párszor próbáltam hívni őket, de a telefon hálózat foglalt-at jelzett...

+1
DNS problémám volt, átírtam, jó lett. Bár egy kicsit akadozott is.

Budapest, 1. kerület. Órák óta hibátlan. Mivel folyamatosan online voltam, 1 másodperc kiesést is észrevettem volna.

Kelenföldön perpill visszajött, de az üfsz. elérhetetlen. ("Hálózat foglalt")

----------
rohamkocka

update: megy. de hogy meddig... egy negyed órán keresztül ki-kihagyott
még szerencse hogy ép nem deathmatcheltem :)

a dns megint lehalt, aki már váltott nem UPC dns-re az nem veszi észre...

213. 46.246. 54 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0,007 | 0,034 | 0,197 | 0,051 | 100,0 |
- Uncached Name | 0,014 | 0,091 | 0,356 | 0,092 | 95,6 |
- DotCom Lookup | 0,035 | 0,043 | 0,051 | 0,004 | 95,3 |
---<-------->---+-------+-------+-------+-------+-------+
hu-bud02a-dns04.chello.hu
LGI-UPC Liberty Global Operations B.V.

213. 46.246. 53 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0,006 | 0,052 | 0,346 | 0,090 | 100,0 |
- Uncached Name | 0,017 | 0,126 | 0,974 | 0,199 | 100,0 |
- DotCom Lookup | 0,032 | 0,052 | 0,192 | 0,039 | 100,0 |
---<-------->---+-------+-------+-------+-------+-------+
hu-bud02a-dns03.chello.hu
LGI-UPC Liberty Global Operations B.V.

Nekem se ment, pár perce éledt fel (Bp., I. kerület). Amúgy észre se vettem, mert már rég nem ezeket használom :D

hmm mostmár megy kb 20 perce rendesen...

Nalam eppen most kezdett el szorakozni megint. (Veszprem) Eddig semmi problemat nem ereztem kb 3 hete. Elotte viszont 2 honapig szakadozott. magyarazat szerint fejallomastol hozzam jo minden, csak valakinek a sz*r tv- je visszadolgozik a halozatra ezert szakadozik nalam. Meg turelmes vagyok. :(

Debrecenbe 2-3 ember is megkeresett, hogy nem megy. DNSt átírva ment. Ugyanitt ping loss 0%
--
Kristof

ba/be kontra ban/ben
Grammarnáci OFF

Halihóóó Emberek,

Ubuntu Linux - on hol kell átírni, hogy a Google DNS szerverét használhassam? dnsmasq - ot használok dns és dhcp szervernek.

Én nem így csinálnám :D

Ha van /etc/dnsmasq.d könyvtárad, akkor abba hozz létre egy fájlt, mondjuk home.conf néven és abba, ha nincs, akkor a /etc/dnsmasq.conf-ba írd bele, hogy:

no-resolv
server=8.8.8.8
server=8.8.4.4

Ezzel azt éred el, hogy a dnsmasq mindenképpen ezeket a szervereket fogja használni. A /etc/resolv.conf-ba a 127.0.0.1-et írd. Ha - mint nálam - a resolv.conf-ot felülírja a dhclient, akkor írd be a /etc/dhcp/dhclient.conf-ba hogy:

supersede domain-name-servers 127.0.0.1;

A fenti beállításokkal minden DHCP-s gép a dnsmasq-ot fogja kérdezni, aki megkérdezni a google (vagy amit a 8.8.8.8 helyére írsz) névszervereit, és a TTL-nek megfelelően meg is jegyzi a választ.

Ha minden igaz, és az Ubuntu nem akarja nagyon másképp csinálni az ilyesmit. :D

Az indexnek szerintem ez a topic a hírforrás :)
--
The Community ENTerprise Operating System

LOL b+...

"Apa kezdődiik!"

Nah szóval, 2 oldal jön be össz. A hup és a google. Bár a google most németül jön be. Youtube baszott lassan, mondhatni inkább nem. ami látszik, az szintúgy németül van. Fasza...

szerk: rájöttem. Az IPv6 miatt lett német. De az is fura, hogy csak a 6-on is elérhető oldalak jönnek be nagyjából. Bár egy sima tunnel. bár lehet nincs összefüggés, csak simán szar megint...

--
openSUSE 12.2 x86_64

Csak a szokásos ...

Kelenföld
UPC döglődik ismét (DHCP szerver nem elérhető, "no offer")
üfsz.: "Hálózat foglalt"

----------
rohamkocka

7 kerület körút mellett szintén mint párnapja...

XIII. ker. DNS probléma Google DNS-re átállva megjavult.

Detto. :(

Nálam is ez van - pechemre épp' babrálom azt a gépet, ami a megosztást csinálja /vagyis most épp' nem az csinálja/ és eltakarná ezt a problémát... :S

7. ker ugyanaz, de DHCP sincs

Eddig a héten minden este ez volt. Eleinte megjavult dns cserével, aztán 7 körül jött a packet loss... mint ma is :)

76 packets transmitted, 41 packets received, 46.1% packet loss
round-trip min/avg/max/stddev = 10.269/2866.527/9024.638/2193.413 ms

IX. kerület, tegnap este nem ment már semmi - és pár napja össze-vissza megy - google dns-re átállva a probléma megoldódott..

Itt Szombathelyen semmi!
Még fel sem talál a modem a hálózatra...

Oykawa Hirohito

VIII. ker, ugyanaz. A nagy semmi.

Két utcával arrébb tökéletes, mióta a pr0nkirály átroutolta magán, azóta nem volt probléma :D
Igaz nem csak az upc dns szerverei vannak beállítva.

Állítólag:

http://index.hu/tech/2013/12/05/meghackeltek_a_upc-t/

De ha a DNS áll le, miért rántja magával a DHCP-t is? Vagy egy szerveren lenne a két szerepkör?

----------
rohamkocka

Ez nagyon rossz duma! Meghackelték. Jó. De évek óta?!

Helyreállt.
213.46.246.53 jónak tűnik - csa az auszrtiai gyorsabb nála.
213.46.246.54 leglassabb

Nekem mindkettő 7-10 msec között van.

Én elhiszem :) Csak ugye jól látszik, hogy az UPC-nél egyrészt a DNS-ek amik betegeskednek, ezt könnyű kivédeni, másrészt pedig általában elszigetelt hálózati problémáik vannak, ami amúgy van máshol is, igaz lehet hogy nem ennyi.

És most meg nálam van az, hogy az FB képei nem töltődnek be, ez most megint ki tudja hogy mitől van.

Klassz képek. Milyen program csinálta?

Klassz képek. Milyen program csinálta?
Bocs a duplázásért, csuklott a böngésző.

https://www.grc.com/dns/benchmark.htm

Megy Wine alatt is!

Itt a fórumban találtam egy értelmes linket - amikor a google DNS is lassult.
Azóta jól megvagyok.
Először érdemes elengedni a programot
- remove all
- add default
- aztán hozzáadni a szolgáltató szervereit
- teszt után eldobni a lassúakat
- hozzámazsolázni innen: http://www.opennicproject.org/configure-your-dns/
- új teszt -> az eredményekből ésszel! kiválasztani a legjobbakat

Ezeket használom párhuzamos algoritmussal: 151.236.10.135, 8.8.4.4, 213.46.246.53, 129.250.35.250

(jelenleg az AT es DE az ami ajanlott itthonrol, es amint lesz megfelelo hely neki, lesz itthon hostolt T2 is.)

--
http://www.opennicproject.org/

Találtam ilyet is: http://code.google.com/p/namebench/

Még fut :D

Nyaron hoztak vmi torvenyt, hogy az online szerencsejatek szolgaltatast nyujto cegeket magyar licensz hianyaban a hirkozlesi szolgaltatoknak blokkolniuk kell 2014 jan 2.tol, es ebben technikailag az allam is "segit".
Nincs itt vmi osszefugges ezzel?

Egyet nem értek. Ha a DNS-t befelé olyan szerver szolgáltatja, amihez kívülről nem jut el kérés, azt csak belülről lehet dosolni. Akkor lehet nagyon mérgesen nézni az illető felhasználókra, vagy csak őket kib@szni a hálózatból. Ha meg nem így van szervezve a szolgáltatás, hanem befelé és kifelé ugyanaz a szerver szolgáltat, akkor el kellene gondolkozni, hogy vajon már egy kisvállalati rendszernél is miért szokták ezt máshogy megoldani (talán pont ezért...).

Szerintem keves szolgaltatonak van olyan infrastrukturaja, amin end to end hamisithatatlan ip cimes vpnben lehet csak elerni a rekurziv ns-eit, illetve azok kerdezo labait visszafele is olyan tuzfalakkal vedenek, amelyeket lehetetlen dosolni.
Bonyolitva meg ezt azzal, hogy a upc nem is magyarorszagrol szolgaltat, bar ez ebben a tortenetben mar nem akkora gond.
Ami mukodik egy kisvallalatban, nem biztos, hogy uzletileg elfogadhato egy multinal.
--
zsebHUP-ot használok!

Talán ezt azért nem, de abban a megjegyzésben van valami, hogy vajon miért elérhető a belső hálózatukban is használt DNS-feloldó szerverük bármely más hálózatból is (már ha fizikailag ugyanaz a gép szolgálja ki persze).

Ami azt illeti, Németországból, az USA-ból és Angliából is válaszolnak ezek a címek DNS-kérésekre pl., és úgy tűnik, mindig valahova az UPC Austria-hoz fut be az egész.
Így azért könnyebben DoS-olhatónak tűnik a szolgáltatás.
Azt persze nem tudom, hogy a magyarországi forgalmat korlátozzák-e le valami miatt, vagy már Ausztriában (és akár máshol) is fellép a probléma - azért ennyire csak nem általános...

Valaszol? Melyik cimek? Kivancsisagbol en is megneztem mult heten, de amit akkor talaltam (nincs upc szolgaltatasom), az nekem nem valaszolt.
--
zsebHUP-ot használok!

Én ezeket próbáltam (ezt adja át az UPC): 213.46.246.53, 213.46.246.54

Szerintem ezeket neztem en is, es korabban sem valaszoltak mas halozatbol. Igaz, hazaibol probaltam. Kulfoldrol tenyleg megy?
--
zsebHUP-ot használok!

Hmm - megnéztem újra, és most nem megy külföldről.
Elbizonytalanodtam - lehet, félrenéztem valamit...

Az előbb néztem magyarországi Digi-s hálózatból, és kaptam választ mindkét címet megszólítva, pl.:

root@janus:~# time nslookup ftp.fsn.hu 213.46.246.53
Server:    213.46.246.53
Address 1: 213.46.246.53 hu-bud02a-dns03.chello.hu

Name:      ftp.fsn.hu
Address 1: 2001:4c48:2:a33e::11
Address 2: 195.228.252.133 ftp.freepark.org
real    0m 0.07s
user    0m 0.01s
sys     0m 0.01s
root@janus:~#

Erre csakis az lehet a magyarazat, hogy az osztrakok/hollandok elrontottak az adatgyujtest, es veletlenul mas halozat is bekerult az engedelyezettek koze. :)
Egyebkent tetszik a hostneved. ;)
http://people.fsn.hu/~bra/pix/Screen_07-Dec-13_20-21-59.png
--
zsebHUP-ot használok!

:-D A janus elég régi standard neve nálam a tűzfal(ak)nak, a zsebhup méretkorlátairól nem tehetek :)

Ez a screenshot milyen telefonon készült?

köszi :)

Bocs, hogy itt írok, de van most egy ilyen telefonom.
SIM jelenleg nincs benne, mivel nem szabdaltam szét eddig a telefonkártyámat mikro méretűre - eddig VoIP-on telefonáltam csak.

Egy zavaró hibát sikerült találnom: ha én hívok, a "keypad" hangjai nem mennek át a túloldalra - ergo IVR menüt nem tudok hívni (random ügyfélszolgálat).
N900-zal, ugyanezen a hálózaton működik, sőt, az N9-et hívva is jó (tehát csak akkor jön elő a hiba, ha róla kezdeményezem a hívást; GSM hálózaton nem volt lehetőségem még tesztelni). Legfrissebb sw van rajta.

Te tudsz IVR menüpontok között választani híváskor?

Igen, igaz nem voippal.

Köszönöm.

Valószínűleg akkor GSM hálózaton működik, bár jó volna VoIP-on is megoldani... úgy tűnik, itt maradt egy bug a szoftverben. :S
(Az N9-en hallom egyébként ilyenkor is elég hangosan, a másik készüléken viszont egyáltalán nem - mintha rossz "csatornába" generálná a hangot.)

hm. nem lehet, h csak beallitas kerdese? milyen kodek es dtmf modot hasznalsz?

A codec iLBC, DTMF mód pedig rfc2833.

iLBC a sávszélesség-kímélés és minőség egyensúlya miatt van beállítva.
...de N900 és N9 között próbáltam - ha N900 hívta az N9-et, mindkét irányban ment a DTMF; ha N9 hívta az N900-at, akkor csak az N900 felől ment át a DTMF, N9 felől nem (viszont hangosabban hallom a "saját fülemben").

Előzmény egy ügyfélszolgálat felhívása volt N9-cel, ahol nem tudtam választani a menüpontok között. Az N900 kliensével, azonos beállítások mellett ez tökéletesen működik.

VoIP gateway-en is átmegy a DTMF hívás esetén, igaz, az viszont ulaw codec-en kapcsolódik.

T- smobilnetről - vélhetőleg helyesen - nem műx.

Nem arrol probaltam, bar telekom halozat. Azt mondod, hogy nem engedelyeznek, hanem tiltanak? :)
--
zsebHUP-ot használok!

Szinte bármi lehet, gondolom, neked sem kell bemutatni azt, hogy internet-szolgáltatók hálózatában mik vannak :)

Mesélj. :)
--
zsebHUP-ot használok!

:-P

Te látod a multit közelről, de szerintem a fenti probléma _kívülről_ és ismerethiányban szenvedve (azaz csak találgatva) tervezési hibának látszik. Erről beszélve bármilyen nagy multi, szvsz célszerű lenne legalább access hálózatát a management hálózatát és tranzit hálózatát külön választania, valamint ennek tekintetében adhatna rekurzív dns-t csak az access hálózatra. Sőt a hálózatot simán particionálhatná akár 10x kisebb egységekre, akár forwarderek beillesztésével.

Lehet, hogy a upc ez utobbit csinalja, csak a kisebb egyseg mondjuk fel europa. :)
--
zsebHUP-ot használok!

Azert szivesen elolvasnam, hogy valojaban mi tortent/tortenik, bar gyanitom erre nem fog sor kerulni. :(
Meg az is lehet, hogy a magyarok nem is tudjak, ok is csak az osztrak/holland call centert hivogatjak, hogy mi van mar...
--
zsebHUP-ot használok!

Én is ettől tartok...

Kicsit régóta húzódik már ez a probléma a DNS-ükkel - furcsa, hogy ennyi idő alatt még nem volt alkalmuk megbízható megoldást találni rá.

Nem találnak, mer leszarják. Mit foglalkozzanak egy kis ország sírásával, mikor máshol többet kaszálnak...

--
openSUSE 12.2 x86_64

Lehet, hoyg az osztrak UPC is szarakodik.
Most probaljuk eldonteni, hoyg a tuzfal, a modem vagy szimplan az UPC.

--
http://www.micros~1

Mi a fasz van megint? IPv4 only siteok alig akarnak bejönni, töknyóc, hogy magyar, vagy külföldi..

Az az érdekes, hogy a IPv6-om is v4-en jön, tunnelen, a v6-os siteok, pl. hup kiválóan működik, míg más baszik bejönni. sőt a nyomorék upc.hu is csak vár-vár-vár-vár de mire?

--
openSUSE 13.1 x86_64

nem éreztem belőle semmit. mi nem ment?
nameservert váltottál már?

DNS-t már rég váltottam sajátra. Nem is a DNS-sel volt baj. és úgy konkrétan semmi nem ment. Se magyar, se külföldi. (bár ezzel kezdtem a dühöngést :D)
Jah és olyan 10-20 perccel az írásom után konkrétan beállt minden mint a szeg, ahogy már a tunnel szervert sem sikerült elérni, az is megállt ami v6-on ment...

Most viszont (lekopogom) elég tűrhető az egész..

--
openSUSE 13.1 x86_64

azért kértem konkrét példát, hogy ha esetleg legközelebb hasonlóba futsz rá tudjak tesztelni neked. amúgy honnan próbálkoztál?

Konkrét példa: index.hu. BP 4. kerből próbálkoztam.

Most már egy ideje "jó" minden, szóval úgylátszik valami helyi gond volt.

--
openSUSE 13.1 x86_64

Mintha újabb nameserverek jelentek volna meg. Jól látom?

Mármint a root szerverek közt, vagy a UPC-nél ? Előbbi listáját frissítettem, viszont nem néztem, hogy van-e újabb. Utóbbit abszolút nem használom.

--
openSUSE 13.1 x86_64

Én igen! Tesztelni szoktam. :)

Vasárnap délután, Kelenföldön ismét összedőlt a ravatal.

(Még szerencse, hogy van mobilnet és nem tőlük. :) )

----------
rohamkocka

Semmi problemam nincs kelenfoldon.

---
Apple iMac 27"
áéíóöőúüű

Melyik része a kerületnek? Én Lágymányos.

----------
rohamkocka

Fehervari uti kocsiszin

---
Apple iMac 27"
áéíóöőúüű

Beszéltem velük, úgy néz ki, csak a kerület egyes részeit érinti a probléma.

----------
rohamkocka

Csupán érdeklődöm hogy a FB a nyomorék vagy az UPC-nél megint nem kerek valami, esetleg mindkettő? :D
(Bp. I. ker.)

Upc ügyfélszolgálat közölte, hogy központi hiba van. Várható elhárítás akár holnap délelőttig is elarthat... se net se telefon se tv. Bp. 4. Kerület..,

Engem épp ma győzködött az ügyfélszolgálatuk, hogy mennyivel jobb lenne, ha júpíszíre váltanék.
Egy pillanatra elgondolkodtam, hogy elküldöm a hupra :D

Mint a blogodban írtam, ezért nem kell tv és telefon. Az internet meg megy ebben a pillanatban a 7. és 4. kerületben is.

Itt épp a net miatt reklamáltak ketten is :))

Erre biztosan megállapítod, hogy nagy az arcom. :)
Folyamatleírás:
- "UPC-ről tudunk valamit?" blog frissült, sőt 4. ker.
- Átssházok a fiam gépére a 4. kerbe., működik.
- Igaz, azt nem tudtam ellenőrizni, hogy nálam működik-e a 7. kerben. :)
Ez legalább olyan pontos információ, mint a nincs net.
Üzemeltetőként is szerettem az olyan hibákat: valami szar.

Ha belegondolsz, a "seholsincsupc" híreket is általában itt olvasom a blogon. :)))
Kiegészítés: UPC előfizetésem van.

nem "valami szar" volt, hanem egyszerűen nem volt meg a kapcsolat a fejállomás és a modem között. Most nincs előttem a modem,. és nem tudom, hogy milyen sorrendben vannak rajta a ledek, de vagy a downstream-et vagy az upstream-et nem találta hosszú órákon és többszöri újraindítás után sem. Ebből következően sem a net, sem a voip alapú telefon nem működik. Az ügyfélszolgálat pedig természetesen a hibáról nem adott tájékoztatást "Mi sem tudjuk mi a probléma, mert a műszaktól nem kaptunk információt, de az ilyen jellegű hiba esetén a hiba elhárítása holnap délelőttig is eltarthat" Szóval még hazudni se tanítják meg a droidot rendesen... Ha nem tudják, hogy mi a hiba, akkor honnan tudja, hogy az ilyen jellegű hiba esetén 8-12 óra is lehet a hibaelhárítás?

"Ha nem tudják, hogy mi a hiba, akkor honnan tudja, hogy az ilyen jellegű hiba esetén 8-12 óra is lehet a hibaelhárítás?" Esetleg tapasztalat...? :-P

Kérdésedre a választ mindjárt az első oldalon megtalálod.

Vagy a fejállomás, vagy a lépcsőházban az erősítő. Abból, hogy "központi hiba van" nem derül ki minden. Általában a központi hiba sem érint teljes kerületet, de kevés az ügyfélszolgálat, ezért rögtön hangbemondásra kapcsolnak.
A modemre meg rá lehet nézni a 192.168.100.1 címen. (Hátha újat mondok.)

A "központi hiba" duma nyilván a kiadott fedősztori, ami az ügyfélszolgálatnak nyomnia kell. Nem fogják megmondani, a valós okot. És ha nem dolgozol a cégnél, vagy nincs bennfentes ismerős, a valós okot jó eséllyel soha az életben nem fogod megtudni.
Az ügyfélszolgálatosnak meg egyébként fogalma nincs róla, mi az a fejállomás, jó esetben modemet talán látott a kéthetes gyorstalpalón, mielőtt bevágták rendszerbe hívást venni. Tehát az ő szintjén a "központi hiba" tájékoztatástól többet nem is lehet várni.
Azt meg nem mondtam, hogy az egész kerületben nem megy, hanem azt, hogy nekem a 4. kerületben nem ment. Mint utóbb kiderült, a kollégának az utca másik végén simán működött. De ez engem cseppet sem vigasztal, ha nálam nem megy.
Pont nem érdekel, hogy mi az, ami miatt nem megy. Tök mindegy, hogy a ház erősítő döglött meg, vagy porig égett a UPC, vagy csak az az RF kártya döglött meg, amire az én modemem felmászna.. A végeredmény számomra minden esetben ugyanaz. Nincs net, nem tudok dolgozni távolról.
Attól nekem nem lesz jobb, ha tudom, hogy mondjuk eldurrant a modemem és majd 3 napon belül cserélik, vagy más nagyobb területet érintő hiba van. A végeredmény ugyanaz. Éjjel, riasztás esetén ülhetek autóba, és mehetek be a munkahelyemre. Holott egy normális minőségű szolgáltatás esetén elég lenne csak átbotorkálni a dolgozóba, és belépni vpn-en.
Nem mondtál újat, 10 év telkó munkaviszonnyal és egy végigjárt szamárlétrával a hátam mögött van róla némi fogalmam, hogy hogyan működik egy telkó cég és hogyan működnek az egyes internetszolgáltatások.

amilyen mélyrepülést a UPC produkált december-januárban Bp. I. kerületben, arra az utóbbi 5-8 évben nem volt példa. sűrű és hosszú kiesések illetve instabil működés, folyamatosan újrainduló modem. elérhetetlen ügyfélszolgálat, legjobb esetben géphang, "az ön körzetében szolgáltatáskiesés tapasztalható, a hiba elhárításán dolgozunk".

lehet szépíteni, hogy éppen hol nem működik és mennyire, és eközben hol máshol mennyire megy, de aki fizet érte, aztán dolgozna, de fél-1 napig nem tud, teljes tehetetlenség és informálatlanság, azt se lehet tudni, érdemes-e várni egy órát, vagy menjen inkább kirándulni az ember, aztán visszajön a net, végre elkezded bepótolni a lemaradást, de 20 perc után megint lerohad az egész, és csak az US led villog kétségbeesetten, szóval ebben a helyzetben hidd el, baromira nem érdekel, hogy máshol működik.

azt sem gondolom, hogy nekem kellene megfejtenem, mi nem működik és annak mi lehet az oka. egy bérelt szolgáltatással szemben jogos kritika az, hogy nem működik rendeltetésszerűen, azaz szar.

Igen, mindenképpen jobb lenne. a UPC-nek. Neked már nem annyira biztos... Az utóbbi 3-4 hónapban teljesen normálisnak tekinthető havonta legalább egy, többórás leállás... Nem is igazán érdekelne, ha hobbinetető lennék, de ahogy nagyon sokaknak, nekem is a munkámhoz kell a net elsősorban. Nem annyira vicces, mikor az éjszaka közepén jön mondjuk egy riasztás, amit VPN-en meg tudnék nézni, de nem tudom, mert nincs net. Így üljek kocsiba, menjek be a munkahelyemre (kb. fél óra), nézzem meg, majd ha megnéztem újabb fél óra haza. Azt a kb. 3-4 liter gázolajat senki nem fogja nekem kifizetni, amiből a havi netem fele kijönne...
Mobilnet meg nem játszik, mert a nagy 4G háborúban valahogy a telkók elfelejtik, hogy még mindig van olyan terület Bp.-n is, ahol jó ha EDGE van...

vegyél egy ADSL-t _is_ ha már ennyire kritikus...

Nálam most kivételesen "jó" 4. ker... Bár a szokásos akadozás most is megvan, de hát attól "szokásos", hogy mindig van.

--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64

A IX. kerületi József Attila lakótelepen tegnap ~19 óra után se kép se hang. A modem webes felületére ránézve not synchronized felirat.
Ez 23 óráig sem állt helyre. Eddig nem futottam bele, úgy tűnik ide is elért a "fejlődés".

Nálam tegnap este ugyanitt jó volt a net tegnap este. Viszont észrevettem ,hogy a facebook nagyon lassan jön le. Minden más tök jó :)

:) Erről Bruce Willis jutott eszembe a Die Hard 3-ban. "Reggel észrevettem, hogy pirososdik a lábujjam között és rohadtul viszket. Először azt hitem..."

Nálam úgy november óta áll fenn egy olyan érdekes helyzet, hogy kb .15-20 percenként egy 20-30 másodpercre teljesen "kihagy" a kapcsolat. Amikor ez történik, akkor a modemen semmi hoba nem látszik, a ledek ugyan úgy villognak, (illetve csak egy), mint máskor. Bejelentettem, múlt héten voltak modemet cserélni. Az ürge aki kijött, azt mondta, hogy valami jelerősség az 100%, szal az nem lehet hiba oka. 2-3 óráig jó volt, aztán megint csinálja.

Grafikonon kb. így néz ki a dolog: http://tinyurl.com/payrajg

Az én gépem kábellel csatlakozik a modemre, de barátnőm laptopja ami wifin van, az is szakad ilyenkor.
Belső hálón fix ip-t állítottam be a gépnek, ezek a DNS szerverek:
213.46.246.54
213.46.246.53
213.46.246.52
213.46.246.51

Álljak át a google félére?
----------------------------------------------------------
"One should strive to achieve; not sit in bitter regret."
www.xonotic.org

A modemet a 192.168.100.1 címen tudod megnézni.
A (nekem) optimális beállítás - az első kettőt a dhcp adja hozzá:
213.46.246.54
213.46.246.53
8.8.8.8
8.8.4.4
129.250.35.250

Ez csak egy érzés: inkább a router lehet a ludas. Az is van és milyen?

Nincs router, én közvetlenül a modemre csatlakozok.

--------------------------------------------------------
"One should strive to achieve; not sit in bitter regret."
www.xonotic.org

Nem, ilyenem:
http://ugyfelszolgalat.upc.hu/app/answers/detail/a_id/461/~/technicolor-tc7200-modem-inform%C3%A1ci%C3%B3k

Viszont most beírtam azokat a DNS szervereket, amiket te írtál, és frissítettem a cache-t is:

akion@quadra:~ > sudo /etc/init.d/dns-clean start
 * Restoring resolver state...
[ OK ] 
akion@quadra:~ > 

Érzésre most sokkal fürgébb minden, tehát 1-1 oldal is gyorsabban töltődik be. Kíváncsi vagyok, hogy szakadni fog-e még.
----------------------------------------------------------
"One should strive to achieve; not sit in bitter regret."
www.xonotic.org

Ezel szoktam dns-t válogatni: https://www.grc.com/dns/benchmark.htm
Érdekes módon az egyszerű http letöltés is lassul, ha bizonytalanok a dns szerverek. Annak ellenére, hogy pfsense routerem van, és párhuzamosan kérdezi az összes szervert.
A 7. kerületben ez a helyzet.

Linuxon namebench

No, csak a teljesség kedvéért, eddig úgy néz ki, nálam (egyelőre, kopp kopp kopp) megoldódott a helyzet. Az ok: Linux powaaa 2014...
Adott ez a hw:

04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 02)

Amihez az istenadta kernel az r8169 drivert szállítja és tölti is be. Persze, nem működik úgy, ahogy kell.
A megoldás drámaian egyszerű, fel kell tenni az r8168-dkms csomagot, kicserélni a drivereket, és blacklistbe tenni az r8169-et.

----------------------------------------------------------
"One should strive to achieve; not sit in bitter regret."
www.xonotic.org

Ez a kontroller maga a megtestesült sz..ívás. Nekem ~fél évente drivert kell váltani. Hol r8168 hol r8169 megy vele csomagvesztés nélkül. Bár lehet a bugos AMD lapkészletnek is van köze hozzá..