mutt + UPC

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

Hello,

ma a munkahelyen a UPC szolgáltatást váltott (4MB/s bérel vonal -> 120MB/s Fiber Power), mindenki nagy örömére.
A váltás óta a legtöbb protokoll, ami hosszabb ideig használja a felépített kapcsolatot megszakad.Pl ssh, de ezt ki tudtam kerülni (ServerAliveInterval 5).

A levelezéshez mutt-ot használok IMAPS-en keresztül, a küldés is a külső kiszolgálón történik (SMTPS), de ha egy emailt hosszabb ideig fogalmazok, küldéskor a mutt "lefagy", nem lehet semmit csinálni (valszeg timeoutolna, de nem várom meg), így meg trükközni kell a már megírt levél megmentéséért.

Tcpdump-al figyelve az SMTPS kiszolgálóhoz ilyenkor egyáltalán nem jut el a csomag, de a tűzfalról még kimegy - gondolom a UPC valahol lebontotta a kapcsolatot (mondjuk nem értem h a mutt miért nem tud SMTP-n küldeni, ha mondjuk az IMAP session megszakad...).

Van valakinek ötlete, mit lehetne tenni?

Köszi:

a.

  • 2128 megtekintés

( errotan v | 2010. 09. 10., p – 18:57 )

UPC ügyfélszolgálat felhív -> probléma elmond.

( VaZso v | 2010. 09. 10., p – 19:12 )

Mihez csatlakozik a szolgáltató?

Nálam furcsa MTU érték okozott problémát, bizonytalanságot ill. szakadásokat egyes szolgáltatásokban... esetleg nézd meg.
Ha jól rémlik, 576 volt 1500 helyett.

Ezt nem értem: hogy-hogy mihez csatlakozik a szolgáltató?

Nem hiszem h MTU probléma lenne, minden kifogástalanul működik, az SSH elég determinisztikusan viselkedett azáltal, h bekapcsoltam a keep-alive-ot, és megszűnt az a session szakadás.

Nem a kapcsolat szakadozik, hanem a session. Maga a vonal szerintem rendben van.

köszi:

a.

Engem először egy Sipura VoIP-PSTN készüléknél kezdett zavarni a probléma (amikor váltottunk UPC-re).
Látszólag minden működött, de egyéb szolgáltatásokban is voltak fennakadások, szakadások.

A fenti telefon pedig időnként használhatatlanná vált, máskor működött.

Gondoltam, egy próbát megér, ha megnézed.

Nálam sem a kapcsolat szakadozott, az folyamatosan aktív volt, csak nem működtek rendesen a dolgok.

ADSL-ről váltottunk a 120-as csomagra, amivel együtt a routert is cseréltem Debianra.
Amíg nem derült ki a probléma, nagyjából minden működött... kivéve pár idegesítő problémát, pl. a fentit.

ADSL-ről mindig működött a beállított szolgáltató, UPC-ről rapszodikusan.
MTU értékének helyreállítása (ill. MTU lekérésének tiltása a dhcp kliensben) helyrehozta a dolgot, azóta semmi gond vele.

Csak tipp, de ha nálam jelentkezett, másnál is előfordulhat...

Köszi,

VoIP konkrétan megy (Ekiga-ról).

Minden más megy, 30 user (átlag user) használja, senkinek semmi gondja nem volt.

Egy bajom van: a mutt "kifagy", ha sokáig nem nézek mailt, de nyitva van.

Közben találtam egy ilyet:

man muttrc 


       timeout
              Type: number
              Default: 600

              When Mutt is waiting for user input either idleing in menus
              or in an interactive prompt, Mutt would block until input
              is present. Depending on the context, this would prevent
              certain  operations from working, like checking for new mail
              or keeping an IMAP connection alive.

ezt majd kipróbálom.

Egyébként fix IP-s a szolgáltatás, nincs DHCP.

Köszi:

a.

( bambano | 2010. 09. 10., p – 20:25 )

a 120 megás fiber power végén lehet, hogy filterezve van az smtp.

Bocs, ezek szerint nem derül ki a post-ból (mea culpa), de amúgy működik az SMTPS (nem sima SMTP).
A gond akkor van, ha a levelet mondjuk néhány percig fogalmazom. Ha gyorsan megírom :), akkor el tudom küldeni.

De az eredeti post küldése után volt olyan is, hogy elindítottam a mutt-ot, ott maradt egy ideig, és mire visszamentem arra a terminálra, már semmire nem reagált. A Ctrl-C/Z látszott egyedül a strace-ben, de semmit nem reagált. A kill segített, utána simán elindult és tudtam levelezni.

Köszi:

a.

( airween v | 2010. 09. 15., sze – 18:05 )

Nos, hátha másnak még jól jön: 

set imap_keepalive = 30
set timeout=15

Alapértelmezetten az imap_keepalive 900, valszeg ez okozta. A timeout értéke default 300, azt is lejjebb vettem.

( oykawa | 2010. 09. 15., sze – 18:14 )

Akkor lehet, hogy az FTP kapcsolat is emiatt a húzásuk miatt akadozik??

Oykawa Hirohito

( BandiG v | 2010. 09. 15., sze – 19:42 )

>UPC valahol lebontotta a kapcsolatot

Mivel az IP nem allapottarto protocol, ezert meg direkt sem tudna lebontani. Nincs mit. A "kapcsolodott allapot"-ot a ket oldal tartja, a kozbenso routerek nem. Csekkold a muttot, sajat hostot, tavoli servert.

Ha van natolos router valamelyik oldalon, akkor csekkold, hogy nem telik-e meg a conntrack tablaja (Igen, ez tarol allapotot, de csak mert a NAT egy "csunya hekk"...)

Persze mindez csak akkor igaz, ha nem kapsz par percenkent uj IP-t (gondolom nem) es nem vadolod oket direkt disconnect csomagok es tarsaik injektalasaval (nem tul realisztikus).

Mindez igaz a fentebbi FTP-s kollegara is.

Mivel az IP nem allapottarto protocol
Az IP nem, de a TCP igen (vagyis bizonyos TCP-t használó protokollok), és ezt ma az ÜFSZ is elismerte, hogy valóban ez így van, ahogy állítom, de nem tudnak mit csinálni.

Ha van natolos router valamelyik oldalon
Kb 5-6 évig volt a korábbi kapcsolat, azt egy Draytek router, majd egy Linux kezelte (utóbbi 1 évig). Soha nem volt semmi ilyen gond: az ssh nem szakadt meg, a mutt nem fagyott, az FTPFS (fuse) működött permanensen.

Mindez péntek óta jött elő, így kizárnám mind a tűzfal, mint a túloldal "hibáját".

Persze mindez csak akkor igaz, ha nem kapsz par percenkent uj IP-t
Jól gondolod, nem kapok percenként új IP-t, sőt, fix IP-s a szolgáltatás.

nem vadolod oket direkt disconnect csomagok es tarsaik injektalasaval
Eszembe sincs :), de a probléma fennáll(t).
Az SSH-t aznap sikerült megoldani, a mutt-ot és az FTP-s nyűgjeimet ma (a FUSE-n keresztül felcsatolt FTP mountokat x mp-ként listázom egy daemonnal), eléggé arra utal minden, hogy mégis van valami "bontás", még ha ez nem is explicit beavatkozás a szolgáltató részéról.

A technikus nem tudta elmondani az okot, annyit "bevallott", hogy a probléma ismert és fennáll, de oldjam meg magam.

a.

Ugyanez a helyzet nálam is következő képpen:

120 -s UPC -> Fiber Power mezei Motorola modem nagyon fasza, hónapok óta megy hibátlanul.

120 -s UPC -> Fiber Power fixip üzleti CISCO modem-router mittom milyen kombó:
Kb 20 naponta a modem szó szerint megőrül, csak UDP enged befele minden más megszünt.
Tegnap reseteltem ki utoljára, ha megint előadja ezt a bontásos játékot kihívom őket
és lecseréltetem Motorolára a modemet. Cisco nem tetszik, mivel leírása szerint ő router lenne
engem meg valami DMZ be rakna. Namost nemtudom te hogy vagy vele, de engem ne pakolgasson csak
DMZ be, ne legyen rajta WIFI, ne legyen rajta 2db RJ11, ne legyen rajta 4db RJ45.

További előnyök Motorolába betudsz bújni úgyis ha online, másikba nem.
A két modem ugyanazon a kábelen van, direktbe húzva az erősítőjüktől, de annak idejen ennyit
szivatott a régi modem is, stabilitásban az EPC és EPX széria között ég és föld volt a
különbség.

Nekünk Cisco kábelmodem volt fent otthon, 120-as vonalon.

Aztán jött egy vihar és kinyiffant a LAN portja. Rákötöttem a megosztó gépemre USB-én is kihívtam az UPC-seket, hogy félig döglött a szerkezet (na jó, előbb hívtam, aztán jöttem rá, hogy USB csatlakozásán még él).

Konstatálták, hogy valóban használhatatlan a LAN portja, majd cserélték Motorolára. Mondták, hogy elég sok baj van azzal a Cisco készülékkel (mondjuk én nem vettem észre semmit, pedig szoktam kívülről használni a gépem), a Motorolával viszont nem szokott gond lenni. /Épp' nem is volt náluk több belőle./

Ezen nincs USB, de teszi a dolgát. Öcsém szerint jobb is mint az előző, én nem tudom. Lehet, hogy gyorsabb lett a net, bár eleinte a másikkal is az volt.
~9,5 MB/s-ot átroutol a gép, az alap cat5-ös kábelt meg cserélni kell.

Egyelőre még gigabites sebességgel nem tudtam csatlakozni hozzá, de majd próbálkozom még. Lehet, a hálókártya is kapott egy pofont.
Ugyanis a modem LAN-ja elhasalt, megosztó gép kifagyott, WLAN router elsüketült, 10/100-as HUB üzemképtelenné vált.

Áramtalanítás után a HUB helyrejött, a WLAN router egy darabig üzemelt, de szépen lassan meghal és egy portja süket.
Gigabites switch úgy néz ki, túlélte, de az asztali gépem bővítőkártyája nem kommunikál már gigabiten (ahogy a megosztó gépé sem eddig, de azt nem teszteltem).

A switch két gigabites gép között üzemel szerencsére, legalábbis nem lassít a közvetlen kapcsolathoz képest... a notebookom viszont gyenge egy valós sebességteszthez.

Bocs, hogy ezt a sok hülyeséget ideírtam.

Hello,

nem hagyott nyugodni amit írtál, hátha mégis én bénázok, kipróbáltam ismét:
- elindítottam egy tcpdump-ot lokálhoszton, a tűzfalon és a szerveren
- felcsatoltam az FTP tárhelyet gvfs-el (a fuse-nál ue)
- 30mp-ként figyeltem a conntrack táblában ennek a kapcsolatnak az állapotát
- kb 10p után megpróbáltam kilistázni a tárhely tartalmát: 

$ ls -la .gvfs/ftp\ devel\ néven\ a\ következőn%3A\ ftp.kiszolgalo.hu/
^C^C^C^C^C^C


összesen 0
drwx------ 1 airween airween 0 1970-01-01 01:00 .

Ekkor a conntrack állapota: 

tcp      6 295 ESTABLISHED src=192.168.1.126 dst=1.2.3.4 sport=50863 dport=21 packets=22 bytes=1282 src=1.2.3.4 dst=5.6.7.8 sport=21 dport=50863 packets=14 bytes=1631 [ASSURED] mark=0 secmark=0 use=2

A szerveren a tcpdump-ban már semmi nem volt.

A tűzfalról kimentek a csomagok, de már mind retransmission volt.

Szal' szerintem nem a végpontok bontanak.

Csak hogy jol ertem-e:

A---x-y-...-w-z---B

A, x, z, B normalis, publikus (globalisan routolhato) IPv4 cimmel rendelkezo host (akar router, tuzfal). A es B (te gepeid) kuldozget egymasnak IP csomagokat x es z (szolgaltato(k) gepei) segitsegevel. A tobbi az "internet felho".

Az a problema, hogy egyes csomagok kimennek A-rol (x iranyaba) B-nek cimezve, de B-re mar nem erkeznek meg? (Mas csomagok viszont igen.)

Ez esetben tenyleg az x, y, ..., w, z -t uzemelteto szolgaltatok valamelyikenel van gubanc. (Ha a csomagok maguk rendben vannak.)

Viszont erre nem mondanam hogy az adott szolgaltato "bontja a kapcsolatot", ugy fogalmaznek, hogy "nem tovabbitja az IP csomagomat".
(Persze timeout utan maga a A es B bontja a TCP kapcsolatot.)

Jol sejtem, hogy csak szohasznalat beli kulonbseg van koztunk? 

A---x-y-...-w-z---B

A, x, z, B normalis, publikus

define Normális

Ez van:
192.168.1.126 --- 192.168.1.254:1.2.3.4 --- internet felhő --- 5.6.7.8

az 1.2.3.4 mondjuk a tűzfal publikus lába, az FTP szerver az 5.6.7.8.

Az a problema, hogy egyes csomagok kimennek A-rol (x iranyaba) B-nek cimezve, de B-re mar nem erkeznek meg? (Mas csomagok viszont igen.)
Pontosítok: egy ideig minden csomag megérkezik, bizonyos idő után viszont már nem, és ez nem az alkalmazás timeout miatt van, ill nem függ porttól, alkalmazástól.

Viszont erre nem mondanam hogy "bontja a kapcsolatot", ugy fogalmaznek, hogy "nem tovabbitja a csomagomat".

Jol sejtem, hogy csak szohasznalat beli kulonbseg van koztunk?
Igen, pontosan.

És mindez a váltás óta van csak.

Van ötleted, mi lehet a gond?

a.

> define Normális

A zarojelben levo "globalisan routolhato"-t szantam a normalis konkretizalasanak.

Ertelmes otletem igy hirtelen nincs, ezek jutnak eszembe:
- nekem volt mar olyan, hogy a felhoben volt egy elcseszett VPN, ami nyomtalanul lenyelte a nagyobb csomagokat (nem fragmentalt es gondolom valami okos tiltotta az ICMP-t, mert nem ment a pMTU discovery sem), lejjebb vettem a kuldo gepen az MTU-t es elmult a baj.
Mar egy FTP konyvtar lista is eleg nagy volt (nem ment), de pl egy pwd-re siman kiirta, h hol vagyok. Ezt kiprobalhatnad.

- mondjuk ha az ssh is lehal akkor ez nem valoszinu.

- azt mondod egy ido utan nem erkeznek meg B-be a csomik. Mitol javul ez meg? mutt ujrainditas? Mert ennek nincs koze az IP reteghez...

- igy hogy up tartjuk a temat majd az okosok adnak otleteket. :)

nekem volt mar olyan, hogy a felhoben volt egy elcseszett VPN, ami nyomtalanul lenyelte a nagyobb csomagokat (nem fragmentalt es gondolom valami okos tiltotta az ICMP-t, mert nem ment a pMTU discovery sem), lejjebb vettem a kuldo gepen az MTU-t es elmult a baj.
ezt lehet h kipróbálom, idő és kedv kérdése :), napközben nem igazán lehet ilyenekkel "játszani", panasz meg az átlagusereknél nincs.

mondjuk ha az ssh is lehal akkor ez nem valoszinu.
ahogy írtam a ServerAliveInterval oldotta meg, ez a beállított mp-ként küld valami alive üzenetet, és nem hal le az ssh

azt mondod egy ido utan nem erkeznek meg B-be a csomik. Mitol javul ez meg? mutt ujrainditas?
a mutt újraindítás megoldja, de ezt írtam itt valahol, h ide is állítottam be egy imap_keepalive-ot 30-as értékkel, és ez megoldotta. Az FTP-t másképp nem tudom (gvfs, curlftpfs nem tud keepalive-ot), csak hogy egy processz X mp-ként kiad egy ls-t a könyvtárra.

Tehát ha valahogy elérem, hogy az adott felépített csatornán folyjon kommunikáció, akkor nincs gond.

Mert ennek nincs koze az IP reteghez...
de szerintem ezt nem is írtam...

Köszi:

a.

Nagyon úgy tűnik mintha valahol egy hatalmas NAT lenne a rendszerben, és szerintem ezt a szolgáltató csinlja!

Saját eset:

Az IP cím drága dolog, de az 1-1 publikus IPcímet megkövetelik a userek. Mit csinál a szolgáltató? Egy publikus ip-t kiad több usernek EGYSZERRE. Ezek után valahogy MAC adress, vagy alhálózat vagy valami alapján azonosítja hogy melyik gép melyik, és "NAT-olja" őket (ugyanazon IP mögé mint amit azt hisznek hogy megkaptak) Az internet felől úgy néz ki mintha nem lenne NAT, hiszen az internet IP = kapott ip.

Amíg viszonylag folyamatos az adatfolyam addig működik is (jönnek befelé is a csomagok) viszont ha elérsz valamilyen időtúllépést akkortól kezdve kikerülsz a listából (mint a NAT kapcsolat táblában) és valamilyen trükkös úton módon próbálkozik a szolgáltató. Elküldi a csomagot mindenkinek akinek ez az IP-je broadcastként, vagy hasonló. Na a legtöbb router pl broadcast csomagot nem NAT-ol be, nehogy valami végtelen ciklust csináljon => kapcsolat megszakadt. Akkor is gáz van ha 2 gép ugyanazt a portot akarja megnyitni befelé, hiszen akkor...

Igen az egész egy hatalmas nagyon csúnya gányolás, és mégis nehezen észrevehető, max a csomagok részletes elemzése alapján, és ott is szerencsével lehet kiszúrni a módszert, máshogy nem nagyon, inkább csak sejteni lehet pl nálad is.

Velünk amikor kiderült hogy ez a probléma okozója (és végül a szolgáltató egyik technikusa is beismerte, amikor a privát telefonján hívtuk) azonnal váltottunk, mert úgy gondoljuk ez nonszensz.

( gUHU | 2010. 09. 16., cs – 07:29 )

A volt melóhelyemen mikrón keresztül jött a cucc és szaggatott. Onnan vettem észre, hogy a skype hülyén viselkedett és a youtube se volt az igazi.

-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --

( traktor | 2010. 09. 16., cs – 21:28 )

Nem a tcp_keepalive_time-ot kellene kisebbre venni? Kb mennyi ido tetlenseg utan halnak meg a kapcsolatok? 

 echo 300 > /proc/sys/net/ipv4/tcp_keepalive_time

Lehet hogy hosztonként megoldás lenne, de próbálom kideríteni, hogy globálisan (a teljes LAN-t tekintve) megoldást keressek. (Ill csak én használok Linuxot, mindenhol Windows-ok vannak - gondolom ott is van hasonló paraméter, de nem az a cél h egyesével registry-t állítok, ahol előjön ez a gond.)