MAIL / Hálózat hiba (kifogytam az ötletekből, vlki segítsen)
Hozzászólások
Hát egyelőre egyre kevesebb reményt látok, hogy ezt meg lehet rendesen csinálni, hogy működjön.
Azon gondolkozom, vajon megoldható-e a probléma egy Socks Proxy (mondjuk dante-server) felállítása segítségével.
Egyre kevésbé tetszik ez nekem... (és a főnököm is érthető okoból egyre csak nyúz mikor lessz megoldás a problémára, nem túl kénylemes és parktikus a webmail felületen keresztül intézni a céges levelezést).
Van egy ismerősöm az Axelerónál (pontosabbanm ismerősöm ismerőse), megkértem próbálja meg kideríteni, volt-e a múlt héten karbantartás, vagy rendszerátállítás az Axelerónál. Hátha csak valamit megkavartak, nekünk meg nem szóltak...
[quote:256b55feb3="gabor2"]
Az axelero smtp szervere level kuldes kozben kidob es az exim mond egy timeout-ot, ez persze nyilvanvaloan inkabb az lehet, hogy a tcp kapcsolat menet kozben megbomlik es az exim megall a level kuldesben.
.
Ha már úgy is exim-et használsz erre a problémára tudom javasolni, hogy ne relay-ezz az axeleros smtp szerverre, hanem szépen az eximmel közvetlenül kézbesíts. Könnyebb kézben tartani, megbízhatóbb, stb... (az egyetlen amire figyelni, kell, hogy olyan beállításokat kell adni a gépnek, hogy kívűlről, inet felöl láthatatlan legyen a 25-ös port, nehogy feketelistára kerülj, mint nyílt szabadon használható smtp relay. Ráadásul jobb, ha csak a belső hálórólk lehet igénybe venni, kívülről nem)
[quote:3b50df80c2="zither"][quote:3b50df80c2="gabor2"]
Az axelero smtp szervere level kuldes kozben kidob es az exim mond egy timeout-ot, ez persze nyilvanvaloan inkabb az lehet, hogy a tcp kapcsolat menet kozben megbomlik es az exim megall a level kuldesben.
.
Ha már úgy is exim-et használsz erre a problémára tudom javasolni, hogy ne relay-ezz az axeleros smtp szerverre, hanem szépen az eximmel közvetlenül kézbesíts. Könnyebb kézben tartani, megbízhatóbb, stb... (az egyetlen amire figyelni, kell, hogy olyan beállításokat kell adni a gépnek, hogy kívűlről, inet felöl láthatatlan legyen a 25-ös port, nehogy feketelistára kerülj, mint nyílt szabadon használható smtp relay. Ráadásul jobb, ha csak a belső hálórólk lehet igénybe venni, kívülről nem)
Ez igy is van csinalva pontosan ahogy mondod.
Tegnap egy haverommal szorakoztunk a problemaval. O hollandiabol UPC-s halobol buzgeralta a szervert. Sikerult annyira letisztitani a problemat, hogy ha van egy "gyors" TCP kapcsolatod, akkor az meg fog hallni es valoszinuleg ez a pop3-as problemadnak is oka. Probald ki a kovetkezot: scp-z, vagy ftp-z le egy nagy file-t pl a szerveredrol, ugy hogy kozben mas nem veszi el a savszelesseget egy nem determinisztikusan jelentkezik, de par probalkozas utan a kapcsolat megszakad. Termeszetesen a tobbi kapcsolat megmarad. Olyan mintha valaki/valami kiszurne/modositana a TCP kapcsolat bizonyos csomgjait mondjuk savkorlatozas vagy tudomis en milyen celbol. A tcpdump csak a kliens oldalrol mutat ujabb kapcsolat felveteli probalkozasokat a szerver oldal az suket.
Hibauzenet nuku.
Az iptables ACCEPT volt mindenre arrol a kliens oldali cimrol igy a tuzfal hiba valoszinuleg nem jatszik.
Ma felhivom az Axelero-t aztan megkerdezem mi van.
fixip cimetek van? ha igen milyen tartomanybol oszt ki? reverse? mas mailszerveren muxik? pl yahoo.com, vagy total mas. vipmail... egyeb.
total megoldas. a modemre ratolsz egy linuxos gepet direktbe es meglesed, utanna meglesed egy windowzzossal is. kiderul. esetleg masik linux disztribucioval, ami mashol jol mukodott... de szerintem a legjobb lenne, ha kikopiznad a logokat es elkuldened az ISP hd-s email cimere...
Nálam nincs ilyen. Pont ezért lett az egész egy Linuxos tűzfal-router/proxy megoldásra kihegyezve hálózati címfordítással (masquereding az iptables nat moduljának segítségével).
Beszéltem az ismerősömmel. Szerinte, az Axelero gerince rendben van (utána nézett), azt mondja szerinte a helyi alálommásnál van a hiba. Ezek után az a kérdés, hogy mi (akiknél a hiba befutott) helyileg egy körzetben vagyunk-e. Én speciál Budakalászon küzdök (26-os körzet). Többiek is innen, vagy más körzetből és más országrészből vannak (mert ha máshonnan, akkor ez kizárható)?
[quote:db5f5c132b="MGy"]Szerintem ez a tipikus ADSL mascarading hiba.
A rövid csomagok átmennek, de a hosszúak hibáznak. A következmény indeterminisztikusnak látszó viselkedés ==> haj kitépése.
Tedd a tűzfalad elejére:
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Nekem nem mukodik a fenti dolog. De most egy ujabb axelero-s emberrel sikerult beszelnem, aki ismet megigerte, hogy felhiv majd (72h belul). Idaig mar volt ketto masik, akik ezt nem tettek meg, remuljuk itt siker lesz. Vegre valahara egy tcpdump kimenetet kert, amit majd megvizsgalnak. Ha van valami akkor irok.
Nálam nincs ilyen. Pont ezért lett az egész egy Linuxos tűzfal-router/proxy megoldásra kihegyezve hálózati címfordítással (masquereding az iptables nat moduljának segítségével).
Beszéltem az ismerősömmel. Szerinte, az Axelero gerince rendben van (utána nézett), azt mondja szerinte a helyi alálommásnál van a hiba. Ezek után az a kérdés, hogy mi (akiknél a hiba befutott) helyileg egy körzetben vagyunk-e. Én speciál Budakalászon küzdök (26-os körzet). Többiek is innen, vagy más körzetből és más országrészből vannak (mert ha máshonnan, akkor ez kizárható)?
Azt nem tudom, hogy mi a korzetszam, de a helye az a Helsinki uton van. A HEV Torontál utcai megallojahosz kozel hazszam passz.
nálam is jelentkezik ilyesmi probléma:-(( megpróbáltam énis telnet-en elérni a leveleket és picit tovább jutottam: "This is a multi-part message in MIM" szoval csak úgy elveszett a vége..
a másik érdekesség amit tapasztaltam: ssh-znék be a koli hálózatába, inditom mc, és egy "szép" fekete kép fogad, és megáll a tudomány. viszont ha a serveremre megyek elöször és nézem, akkor onnan megy.
ez a server közvetlen kapcsolodik a netre.
a probléma nekem is április 21 körül keletkezett, mert akkor vittem el a gépemet, kicsit konfiguráltam át, és hazahozatal után nemvolt jo. ma derült ki, hogy nemcsak az én gépemen van ez, hanem apámén is..
a következő érdekesség, hogy a vnc-sem megy azóta:-(
gondoltam megosztom, hogy nálam is van ilyen probléma..
köszi!
Szerintem ez a tipikus ADSL mascarading hiba.
A rövid csomagok átmennek, de a hosszúak hibáznak. A következmény indeterminisztikusnak látszó viselkedés ==> haj kitépése.
Tedd a tűzfalad elejére:
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
[quote:486c16ed64="gabor2"]
Azt nem tudom, hogy mi a korzetszam, de a helye az a Helsinki uton van. A HEV Torontál utcai megallojahosz kozel hazszam passz.
Ez igen csak másik körzet. Budakalász nem is BP.-hez tartozik, hanem csupán az agromerációs körzethez (azt hiszem). Legközelebbi "ismert" város Szentedre (vagy a sokak által ismet Pomáz, bár szt.endre jobban ismert ). Azt hiszem elég nagy biztonsággal (miután viszont te délen vagy a Kis Duna melett) kimondhatjuk, hogy nem lokális jellegű probléma, nem lehet egy kis vicvac alközpont (legalábbis nem hiszem, hogy egész Pestet+környékét 1 alközponról hajtanák meg).
Jó lenne valami megoldást találni...
Csak azon csodálkozok, hogy miért csupán mi néhányan találkoztunk ezzel a hibával (csak ennyi LAN-on megosztott DSL kapcsolat lenne Linuxos tűzfallal/forgalomirányítóval :( ), és a többi érintett miért hallgat, mint a sír. Többen többre juthatnánk, akkkor is, ha az Axelerónál van a hiba. Ráadásul, ha többen vagyunk kevésbe foghatja rá az axel, hogy a hálózatunkban van a hiba, vagy a tefonközpontban, stb... , szóval hamarabb találnánk végleges (nem csupán tüneti kezelés alapú) megoldást. Mert ez így semmi képpen sem kóser...
[quote:2614d4d988="MGy"]Szerintem ez a tipikus ADSL mascarading hiba.
A rövid csomagok átmennek, de a hosszúak hibáznak. A következmény indeterminisztikusnak látszó viselkedés ==> haj kitépése.
Tedd a tűzfalad elejére:
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Hat lehet, hogy iliyen is van, de nekem kizarolag a szervertol kifele meno forgalomnal jelentkezik ahol masq nincsen.
Erdekessegkeppen : a szervert azota is vagy 10 ember hasznalja (net+mail) minden gond nelkul. Gond csak kifele meno kapcsolatoknal van.
[quote:4d66ce490c="zither"][quote:4d66ce490c="gabor2"]
Azt nem tudom, hogy mi a korzetszam, de a helye az a Helsinki uton van. A HEV Torontál utcai megallojahosz kozel hazszam passz.
Ez igen csak másik körzet. Budakalász nem is BP.-hez tartozik, hanem csupán az agromerációs körzethez (azt hiszem). Legközelebbi "ismert" város Szentedre (vagy a sokak által ismet Pomáz, bár szt.endre jobban ismert ). Azt hiszem elég nagy biztonsággal (miután viszont te délen vagy a Kis Duna melett) kimondhatjuk, hogy nem lokális jellegű probléma, nem lehet egy kis vicvac alközpont (legalábbis nem hiszem, hogy egész Pestet+környékét 1 alközponról hajtanák meg).
Jó lenne valami megoldást találni...
Csak azon csodálkozok, hogy miért csupán mi néhányan találkoztunk ezzel a hibával (csak ennyi LAN-on megosztott DSL kapcsolat lenne Linuxos tűzfallal/forgalomirányítóval :( ), és a többi érintett miért hallgat, mint a sír. Többen többre juthatnánk, akkkor is, ha az Axelerónál van a hiba. Ráadásul, ha többen vagyunk kevésbe foghatja rá az axel, hogy a hálózatunkban van a hiba, vagy a tefonközpontban, stb... , szóval hamarabb találnánk végleges (nem csupán tüneti kezelés alapú) megoldást. Mert ez így semmi képpen sem kóser...
Ja. Majd ma felhivom Oket aztan megkerdezem, hogy mi az abra. Nekem egyebbkent kb. 1.5 honapja jelentkezett eloszor a hiba, tehat nem most.
[quote:2130a7d6d1="MGy"]Szerintem ez a tipikus ADSL mascarading hiba.
A rövid csomagok átmennek, de a hosszúak hibáznak. A következmény indeterminisztikusnak látszó viselkedés ==> haj kitépése.
Tedd a tűzfalad elejére:
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Ez nekem bejött, valóban műxik (legalábbis egyenlőre). Ha hosszabb távon is működik, akkor beillesztem rendesen - nem az fw lánc elejére - hanem egy külön láncba, csak az elfogadott kapcsolatokhoz.
Köszönet mindenkinek... és remélem másoknak is használni fog ez a kis sorocska. :) :D
Most már csak arra az egyre lennék kiváncsi, hogy miért működött 1 éven kersztül, és most hirtelen mitől döglött ez ki. Főleg így, hogy mások is hasonló gondokkal küzdenek. (Talán az Axelero valamit változtatott a rendszerén, ez pedig egy nem kívánt mellékhatás). :?:
Hali, lenne egy igen érdekes problémám.
Egy helyi hálózaton van megosztva 1 db ADSL (üzleti) előfizetés. A dolog a következő képpen néz ki: ADSL modem (PPPoE) bekötve egy tűzfalnak kinevezett Linuxba, a tűzfal másik oldala pedig a helyi hálózat szerverére (szintúgy SuSE Linux 9.0 Pro). A tűzfalon a SuSE cuccai helyett egy egyedi iptables alapú netfilter dolgozik,+1 Proxy (squid 2.5) az inet sebességének növeléséhez, +sshd távoli karbantartáshoz (head-less, vagyis monitor+bill. nélküli gépről van szó).
Ami, a problémám: lassan fél év üzem után "megkergült" a rendszeren a levelezés. A hibajelenség a következő: minden internetes forgalom működik, csupán a levelezés nem, mégpedig oly módón, hogy a leveleket letölteni nem lehet. Ez alatt azt értem, hogy, felcsatlakozik a távoli levelező kiszolgálóra, belépteti az ügyfelet, lekéri a levelek listáját, aztán a levelek tényleges letöltésekor megáll az élet, csak egy nagy TimeOut jön ki belőle. (A kimenő levélforgalom viszont működik).
Beszéltem az ISP-nkkel, szerintük minden Ok. Ekkor gondoltam egyet, és a tűzfalról betelneteltem a levelező kiszolgálóra, és a letöltés működött. Ekkor arra gondoltam, hogy a mi hálózatunkban lehet a hiba, ezért elkezdtem a klienseken (hiba jelentkezett) és a LAN kiszolgálóján (hiba jelentkezett) is próbálkozni telnetre. Ekkora gyanúm eléggé a tűzfalra irányult, bár nem értem, hogy mitől romolhatott el beavatkozás nélkül (mi nem nyultunk a konfigjához az idő alatt, amikor a hibajelenség megjelent). Előszőr felraktam egy laptopot a Lan kiszolgáló helyére, hogy ellenőrizzem elméletemet, a hiba (a vártnak megfelelően) jelentkezett. Gondoltam megvan a hiba forrása. A konfigurációk és naplók nézegetése közben egy elég érdekes dolgot vettem észre: valaki szabvány nevekkel (admin, postmaster, stb.. +naptári kereszt nevek) megróbált belépni az SSH burokba az nap illetve előző nap, amikor megjelent a hibajelenség. Ekkor gondoltam eggyet, arra gondoltam, felnyomták a tűzflalat (bár a logok szerint nem tudodd bejelentkezni + RSA kulcs alapú hitelesítéssel lehet bejutni elvileg, de hát az ördög sose alszik), elmentettem a naplókat (tar.bz2-be későbbi elemzésre), aztán letöröltem a tűzfalat, újratelepít+konfigurál. Gondoltam ez megoldhatja a problémát.
Sajnos azonban a hibajelenség megmaradt. Most már nem nagyon tudok mire gondolni, ezért kérdeznélek titeket, van-e valakinek valami épkézláb ötlete, amin el lehet indulni. Egyáltalán elképzelhető-e, hogy nem is szoftver, hanem hardver hibával állunk szembe (bár erősen kétlem, hogy hardver hiba okozhat ilyen prezisztens (állandó jellegű) és specifikus (csak ebben az egy esetben van hiba, minden más teljes körűen működik)?
Még egy telnet kimenetet mindjárt berakok ide, hogy értsétek ponosan miről van szó, aztán még szívesen adok tájékoztatást, amire szükség lehet a hiba kikócolásához.
Ahogy ígértem, ide rakom, hogy miről is van szó. Ez egy telnet kapcsolat, amivel megpróbáltam POP3 protokollon keresztül megjeleníteni. A bejelentkezés és a levelek számának lekérdezése sikeresen végrehajtódik. Amikor azonban megkérem a retr paranccsal, hogy jelkenítse meg az üzenetet, akkor, noha az +OK választ megkapom (parancs elfogadva, üzenet megjeleníthető), az üzenet nem jelenek meg, a kapcsolat várakozó állásba kerül. Kb 5 perc után pedig a kapcsolat lezáródik. Azt hiszem ezt a jelenséget tekinthetjük klasszikus TimeOut-nak.
Tehát, ha valakinek van valami ötlete, merre nézzek még szét, szívesen venném...
Mekkora MTU/MRU érték van beállítva a tűzfal és a belső szerver közti szegmensen? Nem lehet, hogy a PPPOE header miatt fragmentálódó csomagok zavarják POP protokollt?
[quote:7d6dcd9649="Sallus"]ha a tuzfalat ideigelenesen all ACCEPTre allitod akkor mi tortenik?
ha a notebookot egyenesen az ADSL-re kotod akkor is jelentkezik a hiba?
S.
Nos, átkötögettem a laptopot is a DSL-re, ott minden működik.
Másik érdekesség: a mai nap folyamán a rendszer úgy döntött, hogy minden nem proxy-n (tűzfalon van egy Squid) keresztül történő kommunikáció kiöl. Érdekes módón ez akkor is így van, ha a tűzfalat kikapcsolom (csak egy parancsot hagyol a nat modulban masquerading-nek), iletve akkor is így van, ha a DSL-t átkötöm és átkonfigurálom a hálózati kiszolgálóra.
Egyre kevésbe értem mi történik erre felé...
(Talán időkorlátos lenne a Suse 9.0 Pro :wink: :D )
Na felhivtam az axelero-t. Egyik kollegajukkal vegig probagattunk minden dolgot es szerencsere a hibak siman kijottek. Megmutattam neki a topic-ot is, igy kepben van. Azt igerte majd felhivnak telefonon.
En is ezzel a problemaval kuzdok, sot van egy ismerosom, akinek (valoszinuleg) szinten ez a gondja.
A tuzfal-szabalyokat en is kiuritettem, minden accept: nem megy. Ha a tuzfalrol probalom (nem a belso geprol), akkor ok, mukodik a "retr". MTU a ppp0-an szinten 1492.
Az igazan erdekes az, hogy a pop3 szervernek kiadott "top 1 0" mukodik, de a "retr 1" nem.
Sot ami meg talan ennel is erdekesebb:
1. Bejelentezek egy tavoli gepre ssh-n keresztul
2. Onnan telnetelek a pop3-ra
3. user, pass, retr...
4. A retr igy is elhal, de nem a tavoli ssh-zott gepen, hanem az en routeremen.
Nekem azonban csak egy hete letezik a jelenseg.
Kernel: 2.4.20
ipchains-t hasznalok (lustasagbol nem alltam meg at iptablesre).
Abszolut tanacstalan vagyok... Talan a szolgaltato bosszuja a tobb gep miatt... ( Ez nem tul ertelmes tipp, de jobb nem jut eszembe )
Kernel: 2.4.20
ipchains-t hasznalok (lustasagbol nem alltam meg at iptablesre).
Abszolut tanacstalan vagyok... Talan a szolgaltato bosszuja a tobb gep miatt... ( Ez nem tul ertelmes tipp, de jobb nem jut eszembe )
Lehet, hogy nem írtam, de nálunk is csak Április 21.-ére virradó reggel jelentkezett a probléma, azelőtt pedig már egy éva stabilan működött. Vagyis nálunk is durván 1 hete jött be a probléma. Lehet, hogy valami spéci linuxra írt féreg? (bár ez sem értelmesebb a szolgáltató bosszújánál, sőt talán még gagyibb is.)
Nekünk egyébként üzleti ADSL csomagunk van, ahol (bár lehet, hogy rosszul) úgy tudom akárhány gép netezhet az adott IP alatt helyi hálózaton keresztül.
[quote:077739a7ce="arrabonus"]Mekkora MTU/MRU érték van beállítva a tűzfal és a belső szerver közti szegmensen? Nem lehet, hogy a PPPOE header miatt fragmentálódó csomagok zavarják POP protokollt?
Arrabonus
A ppp0 kapcsolaton az MTU=1492, az eth0-án MTU=1500.
Nem hinném, hogy ez lenne az oka, mert akkor a kezdetektől jelentkeznie kellett volna a porblémának.
Mindenesetre holnap megpróbálom lehúzni az ethernet MTU-ját a kapcsolat mértékére, aztán meglátjuk mi történik...
[quote:b4f823db44="Sallus"]ha a tuzfalat ideigelenesen all ACCEPTre allitod akkor mi tortenik?
ha a notebookot egyenesen az ADSL-re kotod akkor is jelentkezik a hiba?
S.
Sajnos a problémát nem oldja meg a tűzfal szabályok feloldása:
iptables -F
iptables --delete-chain
iptables -P OUTPUT ACCEPT
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
Kipróbálom a laptopot is, bár van egy olyan előérzetem, hogy ha a laptopra kötöm a DSL-t és felkonfigurálom, ott teljesen működni fog...
Ha az MTU-s magia nem segit, akkor esetleg probalj meg ki a tuzfal gepen valamilyen livecd-s disztrot, knoppix, vagy valami hasonlo, csak a legszuksegesebb konfiguraciokat ejtsd meg (halozati beallitasok, no tuzfal). Ha a problema jelentkezik kezdd el kicserelgetni a hardware elemeket, halokartya, kabel...
Lejjebb vettem a MTU-t a ppp0-an, de - ahogy vartam - nem gyogyult meg a dolog. Ha a metrikaval lenne a gond, akkor semmi sem mukodne jol, ez a gep pedig kisebb modositasokkal (sw frissetes, ventillator csere, stb...) mar evek ota gond nelkul uzemel 24/7-ben. Amikor a problema eloszor jelentkezett, mar hetek ota be sem jelentkeztem ra (log-okat nezni sem, khm :-)).
Egyre tobbet gondolkozom ezen, ugy tunik, hogy ennek a dolognak semmi koze a pop3-hoz (lasd az elozo hozzaszolasomat a tavoli ssh-s kiserlet miatt), hanem a bejovo csomag a tartalmaval lehet gaz. Pontosabban a tartalma miatt nyeli le a router.
De ennek valami igen specialis dolognak kell lennie, hiszen minden mas teljesen hibatlanul mukodik.
Na nem tudom, ez meghaladja a kepessegeimet, ide varazslo kell...
Az királyság. Ha valamire jutottatok, légyszi szóljál ide is. Sajnos nem sikerült a hibákat az ő oldalukon is meggenerálni, amikor az ügyfélszolgálattal beszéltem, és a műszaki táblázatunk is okés volt, úgyhogy itt megrekedt a dolog. Ekkor gondoltam arra, hogy a hiba biztos mégiscsak nálunk van. Örülök, hogy kezd úgy alakulni, hogy mégsem teljesen én hülyültem be :) .
Egyébként ki intézi? Esetleg megpróbálnám én is felvenni vele a kapcsolatot az Axeleró ügyfélszolgáltanál. (Nekünk egyszerűbb ha közvetlenül tárgyalunk vele, és talán nekik is kazdaságosabb egyben kezelni, nem pedig egy tucat operátorral megoldatni ugyan azt a problémát.)
Hasonlo hiba van nalunk is. A kulonbseg annyi, hogy fixip-s adsl-s(axelero) pop3 szerverre van kivulrol raengedve nehany tavoli kliens outlook-kal. kb 1 honapja all a levelezesuk, mert nem tudunk rajonni a hibara. A jelenseg ue, timeout. Elkezdi letolteni a leveleit, aztan egyszercsak az outlook azt mondja, hogy timeout. Gondoltunk hw hibara : halokartya csere, semmi. Raadasul semmi hibauzenet nincs a pop3 szerver logjaba. Azt mondja letoltott ennyi meg ennyi levelet, azt kesz. Erdekesseg. Kiprobaltam mashonnan(Interware, UPC halobol) mas kliensekkel(Sylpheed,Thunderbird) es ment, de amikor ott probaltunk egy masik levelezo klienst felrakni (thunderbird), akkor az lehalt. Nalunk az a megoldas, hogy ket het mulva bekoltoznek a kozpontba es nem lesz ilyen problemajuk, mert a belso halon nem jelentkezett idaig meg ez a hiba.
En az axelero-ra tippelek egyebbkent. Bevallom kisse elfogult vagyok ezzel a tarsasaggal. Legutobb azzal boldogitottak, hogy a fixip helyett egy masik cimet adtak, amivel osszeomlott a VPN-em. :)
En meg a kovetkezo hibajelensegeket tapasztaltam, ami lehet, hogy nem fugg ossze ezekkel a dolgokkal, de pontosan azota jelentkeznek miota a pop3 rosszalkodik.
Az axelero smtp szervere level kuldes kozben kidob es az exim mond egy timeout-ot, ez persze nyilvanvaloan inkabb az lehet, hogy a tcp kapcsolat menet kozben megbomlik es az exim megall a level kuldesben.
A masik egy meg erdekesebb hiba. Tavolrol hasznalom a szervert es gyakran nezem less-szel a logokat. Azt tapasztaltam, hogy amikor elkezdem "porgetni" gyorsan akkor egyszeruen meghal a kapcsolat. Ezt sok helyrol sikerult reprodukalnom. A hiba kb. 1.5 honapja van. Na itt aztan minden vegig neztem a screen-tol a tuzfalig, de semmi eredmeny.
A gep kb. 1.5 eve megy minden hiba nelkul valtoztatas semmi (csak neha upgrade).
Ma halo kartyakat csereltem es azota meg nem jelentkezett a hiba, de nem vagyok biztos benne, hogy ez megoldja a problemat, mert nem determinisztikusan jelentkezik.
A pop3 azonban amit a szerverunk biztosit a kulso outlook kliensek szamara az meg mindig rossz, hasonloan a temainditohoz csak visszafele.
[quote:2cd48d2cb6="zither"]Az királyság. Ha valamire jutottatok, légyszi szóljál ide is. Sajnos nem sikerült a hibákat az ő oldalukon is meggenerálni, amikor az ügyfélszolgálattal beszéltem, és a műszaki táblázatunk is okés volt, úgyhogy itt megrekedt a dolog. Ekkor gondoltam arra, hogy a hiba biztos mégiscsak nálunk van. Örülök, hogy kezd úgy alakulni, hogy mégsem teljesen én hülyültem be :) .
Egyébként ki intézi? Esetleg megpróbálnám én is felvenni vele a kapcsolatot az Axeleró ügyfélszolgáltanál. (Nekünk egyszerűbb ha közvetlenül tárgyalunk vele, és talán nekik is kazdaságosabb egyben kezelni, nem pedig egy tucat operátorral megoldatni ugyan azt a problémát.)
Azt nem tudom, hogy kiintezi. Azt igerte az a srac, hogy felhiv telefonon. En egyszeruen megkertem, hogy scp-vel szedjen le egy file-t, ami elakadt neki, meg megprobaltuk meg egy masik geprol is ott is hasonlo "sikerrel". Mivel megmutattam neki ezt a hup-os forumot ezert remelem olvassa is. Hagyj neki egy emilt, aztan lehet, hogy ir majd neked is.
Ha van valami akkor szolok.
Ez úton szeretném megkérni azt az operátort, aki az üggyel foglakozik, hogy vegye fel a kapcsolatot velem is (amennyiben megoldható) az automatik@weszta-t.hu e-mail címen.
Ujabb lepes tortent az ugyben. Az axelero atpasszolta a dolgot a matavnak, aki visszadobta a dolgot az axelero-nak, hogy minden rendben az ADSL modelnel.
Kozben talaltam egy erdekes howto-t ami egy adsl problemaval foglalkozik (upload, es eppen nalam ez a problema) es lehet, hogy ezzel kapcsolatban van ez a hiba is. Egy masik felvetes, hogy ez az egesz problema az axelero sebesseg novekedesevel van kapcsolatban. Persze csak tipp. :)
Hozzászólások
Hát egyelőre egyre kevesebb reményt látok, hogy ezt meg lehet rendesen csinálni, hogy működjön.
Azon gondolkozom, vajon megoldható-e a probléma egy Socks Proxy (mondjuk dante-server) felállítása segítségével.
Egyre kevésbé tetszik ez nekem... (és a főnököm is érthető okoból egyre csak nyúz mikor lessz megoldás a problémára, nem túl kénylemes és parktikus a webmail felületen keresztül intézni a céges levelezést).
Van egy ismerősöm az Axelerónál (pontosabbanm ismerősöm ismerőse), megkértem próbálja meg kideríteni, volt-e a múlt héten karbantartás, vagy rendszerátállítás az Axelerónál. Hátha csak valamit megkavartak, nekünk meg nem szóltak...
[quote:256b55feb3="gabor2"]
Az axelero smtp szervere level kuldes kozben kidob es az exim mond egy timeout-ot, ez persze nyilvanvaloan inkabb az lehet, hogy a tcp kapcsolat menet kozben megbomlik es az exim megall a level kuldesben.
.
Ha már úgy is exim-et használsz erre a problémára tudom javasolni, hogy ne relay-ezz az axeleros smtp szerverre, hanem szépen az eximmel közvetlenül kézbesíts. Könnyebb kézben tartani, megbízhatóbb, stb... (az egyetlen amire figyelni, kell, hogy olyan beállításokat kell adni a gépnek, hogy kívűlről, inet felöl láthatatlan legyen a 25-ös port, nehogy feketelistára kerülj, mint nyílt szabadon használható smtp relay. Ráadásul jobb, ha csak a belső hálórólk lehet igénybe venni, kívülről nem)
[quote:3b50df80c2="zither"][quote:3b50df80c2="gabor2"]
Az axelero smtp szervere level kuldes kozben kidob es az exim mond egy timeout-ot, ez persze nyilvanvaloan inkabb az lehet, hogy a tcp kapcsolat menet kozben megbomlik es az exim megall a level kuldesben.
.
Ha már úgy is exim-et használsz erre a problémára tudom javasolni, hogy ne relay-ezz az axeleros smtp szerverre, hanem szépen az eximmel közvetlenül kézbesíts. Könnyebb kézben tartani, megbízhatóbb, stb... (az egyetlen amire figyelni, kell, hogy olyan beállításokat kell adni a gépnek, hogy kívűlről, inet felöl láthatatlan legyen a 25-ös port, nehogy feketelistára kerülj, mint nyílt szabadon használható smtp relay. Ráadásul jobb, ha csak a belső hálórólk lehet igénybe venni, kívülről nem)
Ez igy is van csinalva pontosan ahogy mondod.
Tegnap egy haverommal szorakoztunk a problemaval. O hollandiabol UPC-s halobol buzgeralta a szervert. Sikerult annyira letisztitani a problemat, hogy ha van egy "gyors" TCP kapcsolatod, akkor az meg fog hallni es valoszinuleg ez a pop3-as problemadnak is oka. Probald ki a kovetkezot: scp-z, vagy ftp-z le egy nagy file-t pl a szerveredrol, ugy hogy kozben mas nem veszi el a savszelesseget egy nem determinisztikusan jelentkezik, de par probalkozas utan a kapcsolat megszakad. Termeszetesen a tobbi kapcsolat megmarad. Olyan mintha valaki/valami kiszurne/modositana a TCP kapcsolat bizonyos csomgjait mondjuk savkorlatozas vagy tudomis en milyen celbol. A tcpdump csak a kliens oldalrol mutat ujabb kapcsolat felveteli probalkozasokat a szerver oldal az suket.
Hibauzenet nuku.
Az iptables ACCEPT volt mindenre arrol a kliens oldali cimrol igy a tuzfal hiba valoszinuleg nem jatszik.
Ma felhivom az Axelero-t aztan megkerdezem mi van.
Nincs véletlenül egy DSL router is a folyamatban?
[quote:0446fc080d="Willow"]Nincs véletlenül egy DSL router is a folyamatban?
Ezt nem tudom, en sima ADSL-en kapcsolodom az Axelero halojara utana nem tudom min keresztul mennek a csomagok.
úgy gondoltam nálad(tok).
fixip cimetek van? ha igen milyen tartomanybol oszt ki? reverse? mas mailszerveren muxik? pl yahoo.com, vagy total mas. vipmail... egyeb.
total megoldas. a modemre ratolsz egy linuxos gepet direktbe es meglesed, utanna meglesed egy windowzzossal is. kiderul. esetleg masik linux disztribucioval, ami mashol jol mukodott... de szerintem a legjobb lenne, ha kikopiznad a logokat es elkuldened az ISP hd-s email cimere...
[quote:031a55b79b="Willow"]úgy gondoltam nálad(tok).
Nálam nincs ilyen. Pont ezért lett az egész egy Linuxos tűzfal-router/proxy megoldásra kihegyezve hálózati címfordítással (masquereding az iptables nat moduljának segítségével).
Beszéltem az ismerősömmel. Szerinte, az Axelero gerince rendben van (utána nézett), azt mondja szerinte a helyi alálommásnál van a hiba. Ezek után az a kérdés, hogy mi (akiknél a hiba befutott) helyileg egy körzetben vagyunk-e. Én speciál Budakalászon küzdök (26-os körzet). Többiek is innen, vagy más körzetből és más országrészből vannak (mert ha máshonnan, akkor ez kizárható)?
[quote:db5f5c132b="MGy"]Szerintem ez a tipikus ADSL mascarading hiba.
A rövid csomagok átmennek, de a hosszúak hibáznak. A következmény indeterminisztikusnak látszó viselkedés ==> haj kitépése.
Tedd a tűzfalad elejére:
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Nekem nem mukodik a fenti dolog. De most egy ujabb axelero-s emberrel sikerult beszelnem, aki ismet megigerte, hogy felhiv majd (72h belul). Idaig mar volt ketto masik, akik ezt nem tettek meg, remuljuk itt siker lesz. Vegre valahara egy tcpdump kimenetet kert, amit majd megvizsgalnak. Ha van valami akkor irok.
[quote:9c3187e517="zither"][quote:9c3187e517="Willow"]úgy gondoltam nálad(tok).
Nálam nincs ilyen. Pont ezért lett az egész egy Linuxos tűzfal-router/proxy megoldásra kihegyezve hálózati címfordítással (masquereding az iptables nat moduljának segítségével).
Beszéltem az ismerősömmel. Szerinte, az Axelero gerince rendben van (utána nézett), azt mondja szerinte a helyi alálommásnál van a hiba. Ezek után az a kérdés, hogy mi (akiknél a hiba befutott) helyileg egy körzetben vagyunk-e. Én speciál Budakalászon küzdök (26-os körzet). Többiek is innen, vagy más körzetből és más országrészből vannak (mert ha máshonnan, akkor ez kizárható)?
Azt nem tudom, hogy mi a korzetszam, de a helye az a Helsinki uton van. A HEV Torontál utcai megallojahosz kozel hazszam passz.
Hali!
nálam is jelentkezik ilyesmi probléma:-(( megpróbáltam énis telnet-en elérni a leveleket és picit tovább jutottam: "This is a multi-part message in MIM" szoval csak úgy elveszett a vége..
a másik érdekesség amit tapasztaltam: ssh-znék be a koli hálózatába, inditom mc, és egy "szép" fekete kép fogad, és megáll a tudomány. viszont ha a serveremre megyek elöször és nézem, akkor onnan megy.
ez a server közvetlen kapcsolodik a netre.
a probléma nekem is április 21 körül keletkezett, mert akkor vittem el a gépemet, kicsit konfiguráltam át, és hazahozatal után nemvolt jo. ma derült ki, hogy nemcsak az én gépemen van ez, hanem apámén is..
a következő érdekesség, hogy a vnc-sem megy azóta:-(
gondoltam megosztom, hogy nálam is van ilyen probléma..
köszi!
Maniac_
nekem a vpnem makkant meg egyik naprol a masikra (Axelero; xxx.szekesfehervar.matav.net)
Szerintem ez a tipikus ADSL mascarading hiba.
A rövid csomagok átmennek, de a hosszúak hibáznak. A következmény indeterminisztikusnak látszó viselkedés ==> haj kitépése.
Tedd a tűzfalad elejére:
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
[quote:486c16ed64="gabor2"]
Azt nem tudom, hogy mi a korzetszam, de a helye az a Helsinki uton van. A HEV Torontál utcai megallojahosz kozel hazszam passz.
Ez igen csak másik körzet. Budakalász nem is BP.-hez tartozik, hanem csupán az agromerációs körzethez (azt hiszem). Legközelebbi "ismert" város Szentedre (vagy a sokak által ismet Pomáz, bár szt.endre jobban ismert ). Azt hiszem elég nagy biztonsággal (miután viszont te délen vagy a Kis Duna melett) kimondhatjuk, hogy nem lokális jellegű probléma, nem lehet egy kis vicvac alközpont (legalábbis nem hiszem, hogy egész Pestet+környékét 1 alközponról hajtanák meg).
Jó lenne valami megoldást találni...
Csak azon csodálkozok, hogy miért csupán mi néhányan találkoztunk ezzel a hibával (csak ennyi LAN-on megosztott DSL kapcsolat lenne Linuxos tűzfallal/forgalomirányítóval :( ), és a többi érintett miért hallgat, mint a sír. Többen többre juthatnánk, akkkor is, ha az Axelerónál van a hiba. Ráadásul, ha többen vagyunk kevésbe foghatja rá az axel, hogy a hálózatunkban van a hiba, vagy a tefonközpontban, stb... , szóval hamarabb találnánk végleges (nem csupán tüneti kezelés alapú) megoldást. Mert ez így semmi képpen sem kóser...
[quote:2614d4d988="MGy"]Szerintem ez a tipikus ADSL mascarading hiba.
A rövid csomagok átmennek, de a hosszúak hibáznak. A következmény indeterminisztikusnak látszó viselkedés ==> haj kitépése.
Tedd a tűzfalad elejére:
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Hat lehet, hogy iliyen is van, de nekem kizarolag a szervertol kifele meno forgalomnal jelentkezik ahol masq nincsen.
Erdekessegkeppen : a szervert azota is vagy 10 ember hasznalja (net+mail) minden gond nelkul. Gond csak kifele meno kapcsolatoknal van.
g
[quote:4d66ce490c="zither"][quote:4d66ce490c="gabor2"]
Azt nem tudom, hogy mi a korzetszam, de a helye az a Helsinki uton van. A HEV Torontál utcai megallojahosz kozel hazszam passz.
Ez igen csak másik körzet. Budakalász nem is BP.-hez tartozik, hanem csupán az agromerációs körzethez (azt hiszem). Legközelebbi "ismert" város Szentedre (vagy a sokak által ismet Pomáz, bár szt.endre jobban ismert ). Azt hiszem elég nagy biztonsággal (miután viszont te délen vagy a Kis Duna melett) kimondhatjuk, hogy nem lokális jellegű probléma, nem lehet egy kis vicvac alközpont (legalábbis nem hiszem, hogy egész Pestet+környékét 1 alközponról hajtanák meg).
Jó lenne valami megoldást találni...
Csak azon csodálkozok, hogy miért csupán mi néhányan találkoztunk ezzel a hibával (csak ennyi LAN-on megosztott DSL kapcsolat lenne Linuxos tűzfallal/forgalomirányítóval :( ), és a többi érintett miért hallgat, mint a sír. Többen többre juthatnánk, akkkor is, ha az Axelerónál van a hiba. Ráadásul, ha többen vagyunk kevésbe foghatja rá az axel, hogy a hálózatunkban van a hiba, vagy a tefonközpontban, stb... , szóval hamarabb találnánk végleges (nem csupán tüneti kezelés alapú) megoldást. Mert ez így semmi képpen sem kóser...
Ja. Majd ma felhivom Oket aztan megkerdezem, hogy mi az abra. Nekem egyebbkent kb. 1.5 honapja jelentkezett eloszor a hiba, tehat nem most.
[quote:2130a7d6d1="MGy"]Szerintem ez a tipikus ADSL mascarading hiba.
A rövid csomagok átmennek, de a hosszúak hibáznak. A következmény indeterminisztikusnak látszó viselkedés ==> haj kitépése.
Tedd a tűzfalad elejére:
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Ez nekem bejött, valóban műxik (legalábbis egyenlőre). Ha hosszabb távon is működik, akkor beillesztem rendesen - nem az fw lánc elejére - hanem egy külön láncba, csak az elfogadott kapcsolatokhoz.
Köszönet mindenkinek... és remélem másoknak is használni fog ez a kis sorocska. :) :D
Most már csak arra az egyre lennék kiváncsi, hogy miért működött 1 éven kersztül, és most hirtelen mitől döglött ez ki. Főleg így, hogy mások is hasonló gondokkal küzdenek. (Talán az Axelero valamit változtatott a rendszerén, ez pedig egy nem kívánt mellékhatás). :?:
Hali, lenne egy igen érdekes problémám.
Egy helyi hálózaton van megosztva 1 db ADSL (üzleti) előfizetés. A dolog a következő képpen néz ki: ADSL modem (PPPoE) bekötve egy tűzfalnak kinevezett Linuxba, a tűzfal másik oldala pedig a helyi hálózat szerverére (szintúgy SuSE Linux 9.0 Pro). A tűzfalon a SuSE cuccai helyett egy egyedi iptables alapú netfilter dolgozik,+1 Proxy (squid 2.5) az inet sebességének növeléséhez, +sshd távoli karbantartáshoz (head-less, vagyis monitor+bill. nélküli gépről van szó).
Ami, a problémám: lassan fél év üzem után "megkergült" a rendszeren a levelezés. A hibajelenség a következő: minden internetes forgalom működik, csupán a levelezés nem, mégpedig oly módón, hogy a leveleket letölteni nem lehet. Ez alatt azt értem, hogy, felcsatlakozik a távoli levelező kiszolgálóra, belépteti az ügyfelet, lekéri a levelek listáját, aztán a levelek tényleges letöltésekor megáll az élet, csak egy nagy TimeOut jön ki belőle. (A kimenő levélforgalom viszont működik).
Beszéltem az ISP-nkkel, szerintük minden Ok. Ekkor gondoltam egyet, és a tűzfalról betelneteltem a levelező kiszolgálóra, és a letöltés működött. Ekkor arra gondoltam, hogy a mi hálózatunkban lehet a hiba, ezért elkezdtem a klienseken (hiba jelentkezett) és a LAN kiszolgálóján (hiba jelentkezett) is próbálkozni telnetre. Ekkora gyanúm eléggé a tűzfalra irányult, bár nem értem, hogy mitől romolhatott el beavatkozás nélkül (mi nem nyultunk a konfigjához az idő alatt, amikor a hibajelenség megjelent). Előszőr felraktam egy laptopot a Lan kiszolgáló helyére, hogy ellenőrizzem elméletemet, a hiba (a vártnak megfelelően) jelentkezett. Gondoltam megvan a hiba forrása. A konfigurációk és naplók nézegetése közben egy elég érdekes dolgot vettem észre: valaki szabvány nevekkel (admin, postmaster, stb.. +naptári kereszt nevek) megróbált belépni az SSH burokba az nap illetve előző nap, amikor megjelent a hibajelenség. Ekkor gondoltam eggyet, arra gondoltam, felnyomták a tűzflalat (bár a logok szerint nem tudodd bejelentkezni + RSA kulcs alapú hitelesítéssel lehet bejutni elvileg, de hát az ördög sose alszik), elmentettem a naplókat (tar.bz2-be későbbi elemzésre), aztán letöröltem a tűzfalat, újratelepít+konfigurál. Gondoltam ez megoldhatja a problémát.
Sajnos azonban a hibajelenség megmaradt. Most már nem nagyon tudok mire gondolni, ezért kérdeznélek titeket, van-e valakinek valami épkézláb ötlete, amin el lehet indulni. Egyáltalán elképzelhető-e, hogy nem is szoftver, hanem hardver hibával állunk szembe (bár erősen kétlem, hogy hardver hiba okozhat ilyen prezisztens (állandó jellegű) és specifikus (csak ebben az egy esetben van hiba, minden más teljes körűen működik)?
Még egy telnet kimenetet mindjárt berakok ide, hogy értsétek ponosan miről van szó, aztán még szívesen adok tájékoztatást, amire szükség lehet a hiba kikócolásához.
Előre is köszi mindenkinek.
Ahogy ígértem, ide rakom, hogy miről is van szó. Ez egy telnet kapcsolat, amivel megpróbáltam POP3 protokollon keresztül megjeleníteni. A bejelentkezés és a levelek számának lekérdezése sikeresen végrehajtódik. Amikor azonban megkérem a retr paranccsal, hogy jelkenítse meg az üzenetet, akkor, noha az +OK választ megkapom (parancs elfogadva, üzenet megjeleníthető), az üzenet nem jelenek meg, a kapcsolat várakozó állásba kerül. Kb 5 perc után pedig a kapcsolat lezáródik. Azt hiszem ezt a jelenséget tekinthetjük klasszikus TimeOut-nak.
Tehát, ha valakinek van valami ötlete, merre nézzek még szét, szívesen venném...
zither@szerver:~> telnet mail.adatpark.hu 110
Trying 195.228.240.10...
Connected to mail.adatpark.hu.
Escape character is '^]'.
+OK POP3 Ready mail.axelero.hu 00021374
user automatik@weszta-t.hu
+OK USER automatik@weszta-t.hu set, mate
pass *****************
+OK
list
+OK
1 5326
2 889197
3 10989
4 1333
5 4040
6 2917
7 4120
8 84534
9 76483
10 2202
11 4432
12 3946
13 47534
14 143591
15 133942
16 133946
.
retr 1
+OK 5326 octets
Connection closed by foreign host.
zither@szerver:~>
ha a tuzfalat ideigelenesen all ACCEPTre allitod akkor mi tortenik?
ha a notebookot egyenesen az ADSL-re kotod akkor is jelentkezik a hiba?
S.
Mekkora MTU/MRU érték van beállítva a tűzfal és a belső szerver közti szegmensen? Nem lehet, hogy a PPPOE header miatt fragmentálódó csomagok zavarják POP protokollt?
Arrabonus
[quote:7d6dcd9649="Sallus"]ha a tuzfalat ideigelenesen all ACCEPTre allitod akkor mi tortenik?
ha a notebookot egyenesen az ADSL-re kotod akkor is jelentkezik a hiba?
S.
Nos, átkötögettem a laptopot is a DSL-re, ott minden működik.
Másik érdekesség: a mai nap folyamán a rendszer úgy döntött, hogy minden nem proxy-n (tűzfalon van egy Squid) keresztül történő kommunikáció kiöl. Érdekes módón ez akkor is így van, ha a tűzfalat kikapcsolom (csak egy parancsot hagyol a nat modulban masquerading-nek), iletve akkor is így van, ha a DSL-t átkötöm és átkonfigurálom a hálózati kiszolgálóra.
Egyre kevésbe értem mi történik erre felé...
(Talán időkorlátos lenne a Suse 9.0 Pro :wink: :D )
Na felhivtam az axelero-t. Egyik kollegajukkal vegig probagattunk minden dolgot es szerencsere a hibak siman kijottek. Megmutattam neki a topic-ot is, igy kepben van. Azt igerte majd felhivnak telefonon.
Hello!
En is ezzel a problemaval kuzdok, sot van egy ismerosom, akinek (valoszinuleg) szinten ez a gondja.
A tuzfal-szabalyokat en is kiuritettem, minden accept: nem megy. Ha a tuzfalrol probalom (nem a belso geprol), akkor ok, mukodik a "retr". MTU a ppp0-an szinten 1492.
Az igazan erdekes az, hogy a pop3 szervernek kiadott "top 1 0" mukodik, de a "retr 1" nem.
Sot ami meg talan ennel is erdekesebb:
1. Bejelentezek egy tavoli gepre ssh-n keresztul
2. Onnan telnetelek a pop3-ra
3. user, pass, retr...
4. A retr igy is elhal, de nem a tavoli ssh-zott gepen, hanem az en routeremen.
Nekem azonban csak egy hete letezik a jelenseg.
Kernel: 2.4.20
ipchains-t hasznalok (lustasagbol nem alltam meg at iptablesre).
Abszolut tanacstalan vagyok... Talan a szolgaltato bosszuja a tobb gep miatt... ( Ez nem tul ertelmes tipp, de jobb nem jut eszembe )
udv!
[quote:246119ccf9="fafej"]
Nekem azonban csak egy hete letezik a jelenseg.
Kernel: 2.4.20
ipchains-t hasznalok (lustasagbol nem alltam meg at iptablesre).
Abszolut tanacstalan vagyok... Talan a szolgaltato bosszuja a tobb gep miatt... ( Ez nem tul ertelmes tipp, de jobb nem jut eszembe )
Lehet, hogy nem írtam, de nálunk is csak Április 21.-ére virradó reggel jelentkezett a probléma, azelőtt pedig már egy éva stabilan működött. Vagyis nálunk is durván 1 hete jött be a probléma. Lehet, hogy valami spéci linuxra írt féreg? (bár ez sem értelmesebb a szolgáltató bosszújánál, sőt talán még gagyibb is.)
Nekünk egyébként üzleti ADSL csomagunk van, ahol (bár lehet, hogy rosszul) úgy tudom akárhány gép netezhet az adott IP alatt helyi hálózaton keresztül.
[quote:077739a7ce="arrabonus"]Mekkora MTU/MRU érték van beállítva a tűzfal és a belső szerver közti szegmensen? Nem lehet, hogy a PPPOE header miatt fragmentálódó csomagok zavarják POP protokollt?
Arrabonus
A ppp0 kapcsolaton az MTU=1492, az eth0-án MTU=1500.
Nem hinném, hogy ez lenne az oka, mert akkor a kezdetektől jelentkeznie kellett volna a porblémának.
Mindenesetre holnap megpróbálom lehúzni az ethernet MTU-ját a kapcsolat mértékére, aztán meglátjuk mi történik...
[quote:b4f823db44="Sallus"]ha a tuzfalat ideigelenesen all ACCEPTre allitod akkor mi tortenik?
ha a notebookot egyenesen az ADSL-re kotod akkor is jelentkezik a hiba?
S.
Sajnos a problémát nem oldja meg a tűzfal szabályok feloldása:
iptables -F
iptables --delete-chain
iptables -P OUTPUT ACCEPT
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
Kipróbálom a laptopot is, bár van egy olyan előérzetem, hogy ha a laptopra kötöm a DSL-t és felkonfigurálom, ott teljesen működni fog...
probald meg ppp0 lejebb venni mtu, pl 1200ra es emeld addig amig nem jelentkezik a hiba, utana egyet vissza.
Ha az MTU-s magia nem segit, akkor esetleg probalj meg ki a tuzfal gepen valamilyen livecd-s disztrot, knoppix, vagy valami hasonlo, csak a legszuksegesebb konfiguraciokat ejtsd meg (halozati beallitasok, no tuzfal). Ha a problema jelentkezik kezdd el kicserelgetni a hardware elemeket, halokartya, kabel...
Udv!
Lejjebb vettem a MTU-t a ppp0-an, de - ahogy vartam - nem gyogyult meg a dolog. Ha a metrikaval lenne a gond, akkor semmi sem mukodne jol, ez a gep pedig kisebb modositasokkal (sw frissetes, ventillator csere, stb...) mar evek ota gond nelkul uzemel 24/7-ben. Amikor a problema eloszor jelentkezett, mar hetek ota be sem jelentkeztem ra (log-okat nezni sem, khm :-)).
Egyre tobbet gondolkozom ezen, ugy tunik, hogy ennek a dolognak semmi koze a pop3-hoz (lasd az elozo hozzaszolasomat a tavoli ssh-s kiserlet miatt), hanem a bejovo csomag a tartalmaval lehet gaz. Pontosabban a tartalma miatt nyeli le a router.
De ennek valami igen specialis dolognak kell lennie, hiszen minden mas teljesen hibatlanul mukodik.
Na nem tudom, ez meghaladja a kepessegeimet, ide varazslo kell...
Az királyság. Ha valamire jutottatok, légyszi szóljál ide is. Sajnos nem sikerült a hibákat az ő oldalukon is meggenerálni, amikor az ügyfélszolgálattal beszéltem, és a műszaki táblázatunk is okés volt, úgyhogy itt megrekedt a dolog. Ekkor gondoltam arra, hogy a hiba biztos mégiscsak nálunk van. Örülök, hogy kezd úgy alakulni, hogy mégsem teljesen én hülyültem be :) .
Egyébként ki intézi? Esetleg megpróbálnám én is felvenni vele a kapcsolatot az Axeleró ügyfélszolgáltanál. (Nekünk egyszerűbb ha közvetlenül tárgyalunk vele, és talán nekik is kazdaságosabb egyben kezelni, nem pedig egy tucat operátorral megoldatni ugyan azt a problémát.)
vizsgald meg erosen a tcpdump kimenetet
Hasonlo hiba van nalunk is. A kulonbseg annyi, hogy fixip-s adsl-s(axelero) pop3 szerverre van kivulrol raengedve nehany tavoli kliens outlook-kal. kb 1 honapja all a levelezesuk, mert nem tudunk rajonni a hibara. A jelenseg ue, timeout. Elkezdi letolteni a leveleit, aztan egyszercsak az outlook azt mondja, hogy timeout. Gondoltunk hw hibara : halokartya csere, semmi. Raadasul semmi hibauzenet nincs a pop3 szerver logjaba. Azt mondja letoltott ennyi meg ennyi levelet, azt kesz. Erdekesseg. Kiprobaltam mashonnan(Interware, UPC halobol) mas kliensekkel(Sylpheed,Thunderbird) es ment, de amikor ott probaltunk egy masik levelezo klienst felrakni (thunderbird), akkor az lehalt. Nalunk az a megoldas, hogy ket het mulva bekoltoznek a kozpontba es nem lesz ilyen problemajuk, mert a belso halon nem jelentkezett idaig meg ez a hiba.
En az axelero-ra tippelek egyebbkent. Bevallom kisse elfogult vagyok ezzel a tarsasaggal. Legutobb azzal boldogitottak, hogy a fixip helyett egy masik cimet adtak, amivel osszeomlott a VPN-em. :)
En meg a kovetkezo hibajelensegeket tapasztaltam, ami lehet, hogy nem fugg ossze ezekkel a dolgokkal, de pontosan azota jelentkeznek miota a pop3 rosszalkodik.
Az axelero smtp szervere level kuldes kozben kidob es az exim mond egy timeout-ot, ez persze nyilvanvaloan inkabb az lehet, hogy a tcp kapcsolat menet kozben megbomlik es az exim megall a level kuldesben.
A masik egy meg erdekesebb hiba. Tavolrol hasznalom a szervert es gyakran nezem less-szel a logokat. Azt tapasztaltam, hogy amikor elkezdem "porgetni" gyorsan akkor egyszeruen meghal a kapcsolat. Ezt sok helyrol sikerult reprodukalnom. A hiba kb. 1.5 honapja van. Na itt aztan minden vegig neztem a screen-tol a tuzfalig, de semmi eredmeny.
A gep kb. 1.5 eve megy minden hiba nelkul valtoztatas semmi (csak neha upgrade).
Ma halo kartyakat csereltem es azota meg nem jelentkezett a hiba, de nem vagyok biztos benne, hogy ez megoldja a problemat, mert nem determinisztikusan jelentkezik.
A pop3 azonban amit a szerverunk biztosit a kulso outlook kliensek szamara az meg mindig rossz, hasonloan a temainditohoz csak visszafele.
Debian (woody) 2.4.X.
[quote:2cd48d2cb6="zither"]Az királyság. Ha valamire jutottatok, légyszi szóljál ide is. Sajnos nem sikerült a hibákat az ő oldalukon is meggenerálni, amikor az ügyfélszolgálattal beszéltem, és a műszaki táblázatunk is okés volt, úgyhogy itt megrekedt a dolog. Ekkor gondoltam arra, hogy a hiba biztos mégiscsak nálunk van. Örülök, hogy kezd úgy alakulni, hogy mégsem teljesen én hülyültem be :) .
Egyébként ki intézi? Esetleg megpróbálnám én is felvenni vele a kapcsolatot az Axeleró ügyfélszolgáltanál. (Nekünk egyszerűbb ha közvetlenül tárgyalunk vele, és talán nekik is kazdaságosabb egyben kezelni, nem pedig egy tucat operátorral megoldatni ugyan azt a problémát.)
Azt nem tudom, hogy kiintezi. Azt igerte az a srac, hogy felhiv telefonon. En egyszeruen megkertem, hogy scp-vel szedjen le egy file-t, ami elakadt neki, meg megprobaltuk meg egy masik geprol is ott is hasonlo "sikerrel". Mivel megmutattam neki ezt a hup-os forumot ezert remelem olvassa is. Hagyj neki egy emilt, aztan lehet, hogy ir majd neked is.
Ha van valami akkor szolok.
Nos, akkor...
Ez úton szeretném megkérni azt az operátort, aki az üggyel foglakozik, hogy vegye fel a kapcsolatot velem is (amennyiben megoldható) az automatik@weszta-t.hu e-mail címen.
Előre is köszönet a közreműködésért.
Ujabb lepes tortent az ugyben. Az axelero atpasszolta a dolgot a matavnak, aki visszadobta a dolgot az axelero-nak, hogy minden rendben az ADSL modelnel.
Kozben talaltam egy erdekes howto-t ami egy adsl problemaval foglalkozik (upload, es eppen nalam ez a problema) es lehet, hogy ezzel kapcsolatban van ez a hiba is. Egy masik felvetes, hogy ez az egesz problema az axelero sebesseg novekedesevel van kapcsolatban. Persze csak tipp. :)
http://www.ibiblio.org/pub/Linux/docs/HOWTO/translations/hu/html_single/ADSL-Bandwidth-Management-HOWTO-hu.html