Debian Lenny + UPC Fiber Power

Linux-haladó

Sziasztok!

Akadt egy kis beállításbeli problémám, amit nem tudok mire vélni.

Adott egy UPC Fiber Power 120-as net a hozzá tartozó kábelmodemmel.
Ha ezt rákötöm a Mandriva 2010-es rendszerre, szó nélkül kap IP-címet (IPv4 és IPv6 is), tökéletesen látom a netet, eddig 30/6 megabit körül mértem, de elvileg lesz még nagyobb a sávszélesség...

...viszont ha a Debian Lenny rendszerre kötöm rá és kérek IP-ét, kapok ugyan (igaz, csak IPv4-et), de a net nem megy rendesen. Ezt valahogy úgy kell érteni, hogy sebességtesztben kb. 0.5 megabit letöltés és 6 megabit feltöltés, ami működik.
Ping olykor megy, máskor megáll. Letöltés olykor nem indul el, máskor kb. 16 kbyte/s sebességgel megy.

Magyarul valami nagyon nem jó.

Ezt a rendszert szeretném használni a net megosztására, mivel amúgyis állandóan megy és legfeljebb egy gigabites kártyát teszek még bele.

Jelenleg egy 10/100-as és egy gigabites vezérlőkártya van a gépben, mindkettő Realtek chipsetes és amúgy működik.
Próbáltam mindkettő kártyán, azonos eredménnyel úgy is, hogy a másik kártyát ifdown-nal lelőttem és csak az UPC-és élt.

Mi lehet ennek a viselkedésnek az oka?

Hogy tudnám Debian alatt is megkérni az IPv6-os címet?

Hogy lenne célszerű beállítani a rendszert, hogy a kábel bedugásakor automatikusan megkérje az IP-ét, kihúzásakor elengedje és így tovább? ...illetve szeretném, hogy a szolgáltató eseteges IP-változása azonnal érvényre kerüljön a rendszeren... vagy ezt rendes DHCP timeout-nál csinálhatják meg?

Elég sürgős lenne számomra megcsinálni a net megosztását rajt és teljesen tanácstalan vagyok, hol keressem a nem működésének okát.

Remélem, van valakinek ötlete.

  • 3029 megtekintés

( gbor | 2009. 12. 05., szo – 09:12 )

"mtr bix.hu" mit mond a két esetben?

--
Írj egy e-mailt, ha itt bármi hibát találsz. ^ ^

A Debianos gépről:

Host
1. ???
2. ???
3. catv-80-....catv.broadband.hu Packet loss ~4.3% Ping avg 20.5 best 11.8 wrst 87.0 stdev 12.4
4. 193.188.137.7 Packet loss 6.7% Ping avg 20.0 best 15.2 worst 52.3 stdev 4.5
5. www.bix.hu Packet loss 6% Ping avg 18.8 best 13.8 worst 54.0 stdev 4.8

Olyan 320 elküldött csomag után.

Felül még kaptam egy ilyen üzenetet is: Resolver: Received error response 2. (server failure)

Mandrivás gép:

Kb. ugyanez mint fent (a best, worst, stb. értékeket kevésbé figyeltem, egyébként 100% ugyanaz), viszont 0% Packet loss

Ami feltűnt még, hogy Mandriva esetén a resolv.conf

nameserver 213.46.246.53
nameserver 213.46.246.54
search chello.hu

Debiannál

domain chello.hu
search chello.hu
nameserver 213.46.246.53
nameserver 213.46.246.54

Mi tévő legyek? :((

Szerk.: Kernel 2.6.26-2-686
Van értelme újat fordítani? Hol lehet a gubanc?

A kártya adatai között megjelent, de nem próbálkoztam vele, lehet, csak a rendszer rendelte hozzá valamiért...

Az viszont őrületbe kerget, hogy Debian alatt használhatatlan a netem. Nem értem miért és engem fognak piszkálni, ha nem kezdek vele valamit... egyelőre tanácstalan vagyok.

( uid_2030 | 2009. 12. 05., szo – 11:10 )

Nálam MTU gond volt a Fiber+ Debian felállásnál, egy /etc/network/interfaces-be elhelyezett post-up megoldotta a problémát, esetleg nézd meg, hátha segít!

> BERUS
Motor: openSUSE Linux 11.2

Hopsz, MTU-ra nem gondoltam, de esélyes és reményt adott hirtelen. :)
Most kernelt fordítok, de leállítom rögtön, ha ez megoldja...

Ezt a post-upot még nem értem egészen, de rögtön utánanézek.
Esetleg le tudod írni részletesebben?

Köszi a tippet, bizakodó vagyok, jogosnak tűnik egy ilyen probléma.

Egyelőre ugyanúgy elhagyja a csomagokat, ha ifconfig-gal 1492-re állítom az MTU-t.
1500-on az előbb pingre sem válaszolt.
/A letöltési sebesség ~30 kbyte/s/

Megnézem, a Mandrivás gépen milyen értéket ad meg.

Szerk.: Egyelőre elakadtam :(
Mandriván MTU 1500, file letöltés ~4.5Mbyte/s

Debianon
ifup eth1
ifconfig eth1 mtu 1500

MTU ifconfig szerint is 1500-on van, pingre kapok választ, bár néha kiesik... letöltésem nem indult...

Resolving www.kernel.org... 199.6.1.164
Connecting to www.kernel.org|199.6.1.164|:80... connected.
HTTP request sent, awaiting response...

...és itt áll

Kicsit tovább jutottam (mármint a Debiannal).

Fent írtam, hogy egy 10/100-as és egy gigabites LAN kártya van a gépben.

Előbbi csak tartalékként volt bent, a gigabites volt használva a gépben (a 10/100-asat pedig cserélni akarom szintén gigabitesre).

Úgy fest, hogy a gigabites kártyára kötve a kábelmodemet és az MTU-t helyreállítva 8-9Mbyte/s sebességet érek el és nincs packet loss.

10/100-assal ugyanezt elvégezve kihagy, letöltés lassú vagy nincs.

Ugyanez történik, ha netet hagyom a gigáson és LAN-t rákötöm a másikra. Elkezd vacakolni a net kapcsolat is.

Szerintem hibás lehet ez a kártya vagy valami interrupt-ütközésféle lehet.

Keresek egy másikat, kicserélem és folytatom a próbát.

Szerintem is az MTU mérettel lehet gond! Ezt állítsd át!

Nézd meg, hogy a mandriva mekkora mtu mérettel dolgozott!

Mintha a tofflineos optikai nethez winXP-re telepítő cd-t adnának, hogy teljes sávszélességgel mehessen a dolog; ami annyit csinál, hogy az mtu méretet piszkálja...

tisztázzuk már ezeket a hülyeségeket egyszer és mindenkorra:
- ha közvetlenül ethernet kártyához van kötve a net és dhcp-zel, akkor NEM KELL MTU-t állítanod.
- ha pppoe-t kell használnod, akkor a pppoe fejlécek miatt javasolt az mtu állítás.

A fiberpower (nagyon helyesen) NEM HASZNÁL pppoe-t, ezért nem kell mtu-t állítani.

A UPC-c fiberpower az nem az aminek mondják!!!!
Ha valódi lenne, akkor lakásba üvegszálon jönne be és nem koaxon.
Miért van az hogy xp-n csak egy program telepítése után megy
a névleges teljesítmény közelében?
Miért kap dhcp-n a linuxos kliens 576 byte-os MTU -t a szervertől?
Valami nem OK ebben a szolgáltatásban.

Miért, minek mondják? Mondják FTTH-nak? Szerintem nem. A fiberpower kifejezés egyrészt egy marketing maszlag, amit reklámozási céllal nyomatnak, másrészt üvegszál erőt jelenet, máshol sem kapsz 120 megát üvegszálon se, és ez a cucc 300-ig jó. Ugye általában nem szoktad elhinni a reklámokat? Na jóreggelt.

Például lehet, hogy azért, mert az xp-nek a tcp window scaling implementációja rossz. Ezt sima etherneten is ki lehet mérni, ezt nem árt javítani. De millió meg egy egyéb oka is lehet, akár a megengedett tcp kapcsolatok darabszámának feljebbállítása, akár ezer más.

Nem tudom, miért kap 576-os mtu-t, semmi szüksége rá. Ha kisebbek a csomagok, jobban lehet sávszélességet szétosztani meg jobban működhet a csatorna bonding, de ettől még nincs rá szüksége. Főleg, hogy a központ 3k meg 6k-s burstokat kezel alapértelmezésben...

Az 576 a legkisebb általánosan használt mtu érték, az 1500 az ethernet hálózatok standardja. Ha engem kérdezel, egy ilyen sebességű kapcsolatnál az 1500 a jó érték, lejjebb venni csak akkor érdemes, ha gondjaid vannak bizonyos hálózati helyek elérésével, és akkor sem 576-ra. A legviccesebb, hogy nálam disztró függő, pl. Mandriva és CentOS esetén 1500, Debian és SUSE esetén 576-ra állítódik alapból.

> BERUS
Motor: openSUSE Linux 11.2

( VaZso v | 2009. 12. 05., szo – 15:44 )

Most ott tartok, hogy kicseréltem a gépben a hálózati kártyát. (Rosszul emlékeztem, 3com volt benne.)
Mot egy VIA 10/100-ason van épp' a net.

Működik már a routolás is a másik kártyára.

Az MTU-val kapcsolatban még nem tudom, mi legyen... 576-ot kap a Debian és működik, 1500-on is működik.
/Ha jól sejtem, azért az elérhető sebesség szempotjából nem lenne egészen mindegy, hogy mekkora adatmennyiséget kéne egyszerre továbbítania... ki kéne derítenem, a szolgáltató szerint mit kéne beállítanom.../

Holnap ill. este folytatom. :)
Most legalább működik már.

windows alatt ment szépen, linux alatt is jódarabig, aztán egyszer csak gondolt egyet és lement 10Mbit /half duplex módba. A gép samba kiszolgáló volt és napokig nem értettem, miért akadoznak a filmek, ha arról a gépről nézem (eldobálta a hálót, stbstb...)
Aztán a tcpnuts megmondta, hogy a kispajti szabira ment...
nagyon nem tesztelgettem utána, lehet hogy jó, de nem ér annyit hogy nézegessem...

Egyelőre egy 16-portos 10/100-as HUB-on van, az sem mai darab...

Az a helyzet, hogy így visszagondolva volt már előzménye a dolognak... egy darabig nem volt semmi gondom, aztán elkezdett olykor TFTP boot alatt hol Mbyte/s, hol pár száz Kb/s sebességgel döcögni a sebesség...
...akkor betudtam annak, hogy vacak, régi UTP kábelen megy (szemmel látni rajta, hogy vacak minőségű, szimplán cat 5-ös) és valami miatt összeszedi a zavarokat.

Meg is lepődtem rajt, hogy amikor beletettem a gigabites kártyát a gépbe, megtáltosodott sebesség ügyében... nagyon nem foglalkoztam vele. A kábel azért erre a HUB-ra megy, mivel vélhetően a 4+ér valamelyike nem érintkezik (valamelyik aljzatban), gigabites switch-cel nem értik meg egymást, kényszeríteni nem próbáltam.
Nem igazán foglalkoztam vele, mert az egész kábelezést cserélni fogom a gigabites háló miatt, csak még a vezeték beszerzése késik.
Ráadásul épp' tegnap, net bekötés alkalmával sikerült (szó szerint) elfúrni ezt a nyamvadt vezetéket, ezért eléggé elítélhető módon összeforrasztottam a két szabadon maradt véget. - Mondjuk meglepő módon utána sima filemásolással "lemérve" 8Mbyte/s-ot vitt folyamatosan, szóval kihúzza a komplett kábelcseréig...

Kártyát majd még próbálom, de ebben a gépben nem lesz többé... a VIA viszont vitt már file letöltésnél 11.2 Mbyte/s-ot is.
A 8Mbyte/s-ot pedig át is routolja a gép, tehát adott feltételek mellett rendben érzi magát. :)

( VaZso v | 2009. 12. 07., h – 21:01 )

Nem egészen a fenti kérdéshez kapcsolódik, de felmerült még néhány problémám.

Elvileg routol most a gép, látszólag megy minden, normális sebességgel.

Ugyanezen a gépen fut egy Apache szerver, egy külön IP-hez rendelve.
A gép megkapta most az eddigi router IP-jét és a régi cím eth0:1-ként van felhúzva, a net eth1-en érkezik.

Beállítottam, hogy a 80, ill. 443-mas portra érkező kérések az eth0:1 címére továbbítódjanak.
Külső hálózatból látom is a fent lévő weboldalt, ám belső hálóról csak not found üzenet jön be. Tehát valahogyan eljut a kérés a gépre, de nem tudja a VirtualHost alapján beazonosítani azt.
Ha beleteszem akár a szerveren lévő hosts fileba a konkrét címet, akkor belső hálóról is bejön az oldal.

A DNS szolgáltatást a dnsmasq csinálja.

Mivel lehetne megoldani, hogy ne kelljen ezzel külön szórakozni, ahogyan az eddigi router is tudta, hová kell irányítani a kérést?

----------

Másik, komolyabb problémám, hogy a beállított Sipura eszközöm nem képes felcsatlakozni a SIP hálózatra.

Még él a régi kapcsolatom, ha azt adom meg átjárónak, tökéletesen működik (a DNS kérés bármelyik netemmel megy).
Amint átírom az átjárót az új gépre, hibát jelez.
Úgy tűnik, a saját gépemről sem tudok SIP hívást kezdeményezni.

Ez mi a szösz lehet?
Próbálkoztam az ip_conntrack_sip modul betöltésével, nem történt változás.

Én konfiguráltam el valamit? Mit kéne beállítanom, hogy elérjem a Neophone/Megaphone/VoipDiscount szolgáltatásaimat?
STUN szerver be van állítva.

Hirtelen megfordult a fejemben, de nyugtassatok meg, ugye nem tiltja az UPC ezt a típusú forgalmat? (Tekintettel arra, hogy nekik is van ilyen jellegű szolgáltatásuk, bár eddig ez eszembe sem jutott, hogy ez lenne a gond.)

Mit ajánlotok?

Szerk.:
Hopsz, utóbbi probléma megoldva... megfeledkeztem fixálni az MTU értékét, így újfent 576 volt.
Most beraktam az if-up.d könyvtárba, hogy mindig érvényre jusson az 1500-as érték.
Ez utóbbival ugyanis működik a SIP, előbbivel nem.

Szóval nálam nem stimmelt a dolog.

...azért mégsem ilyen egyszerű a dolog... A notiról, Megafonról tudok hívni és működik is. A Sipura viszont továbbra sem megy valamiért, habár az előbb azt hittem, igen... (lehet, mégsem ment át a másik routerre és félrevezetett?)... most nem jó.

Az első kérdésre viszont érdekelne, hogy lehetne megoldást találni.

Szerk2.:
Mégegy furcsaság... öcsémnek lassan reagál az IRC.
Ez vajon mitől lehet?

Kapcsolódik, csak lomha az egész.

( VaZso v | 2009. 12. 10., cs – 13:44 )

Továbbra is van némi problémám az MTU-val.

Az if-up.d könyvtárban beállítom az MTU értékét és bekapcsoláskor jó is (mármint az interface felhúzásakor), ám időnként visszáll 576-ra. Gondolom, a DHCP-vel kapott cím megújításakor áll vissza.

Hogy tudnám megoldani, hogy ilyenkor is maradjon 1500-on?

Elég nagy baj, hogy 576-os MTU-val dolgozik, ugyanis állandóan kiakaszt, hogy nem megy a Sipura telefonom, holott csak az MTU állt vissza (mire rájöttem, hogy már megint miért nem megy...) :(

Szóval hogy tudnám elérni, hogy a DHCP-vel kapott cím megújításakor újra lefusson az MTU-beállításom vagy egyszerűen ne vegye figyelembe az attól kapott értéket?

-------

IRC-nél sikerült elérnem, hogy olyan 600 msec válaszidővel dolgozik. Hogy lehetne ezt lecsökkenteni?
Az ADSL kapcsolattal gyors volt, ahhoz képest még ez is nagyon lassú... Vajon miért?

Szerk.:
Van egy ilyen file, hogy /etc/dhcp3/dhclient.conf

Szerintem itt kéne kicsit "ügyeskednem".
Először is látok olyat benne, hogy

reguest subnet-mask, broadcast address, ..... interface-mtu, .....

Arra gondoltam, ez utóbbit vagy megpróbálom kiszedni innen (csak legvégső esetben), vagy megpróbálok rájönni (nyilván ez lenne jobb), hogy miket fogad el lease { interface stb... címszó alatt (egyelőre azt látom, a fenti értékeket meg tudom ott adni neki).

Úgy látom, itt fixálni tudok egyes értékeket, remélem, boldogul azzal és elfogadja, ha csak az interface-mtu értéket adom meg neki. Még gondolkozom, hogy távolról megpróbálom-e beállítani. :)

Szerk2.:
Arra jutottam, hogy valamilyen oknál fogva nem találtam megoldást az MTU interface-hez rendelésére, így kivettem a DHCP kérések közül, hogy ne zavarjon be az UPC által adott érték.
...most fix 1500-on van. Így hagyom, ha nem lesz ennél jobb ötlet.