ADSL reconnect

Nekem is ez a problémám, hogy naponta egyszer levágja a kapcsolatot.
Én csináltam egy scriptet, ami a cron segedelmével figyeli, hogy él-e a kapcsolat.

Kipróbáltam az itt elhangzott javaslatokat, de nekem nem működik ezekkel. Pedig igazán jó volna, ha nem a scripptel kéne zabáltatni az erőforrást.

Megnéztem a DSL Howtot is, de nem ír igazán semmi konkrétat erre a problémára.

Vagy van még valami más is?

a demand opciót engedélyezd a konfig file-jában (/etc/ppp/peers/dsl-provider).

[quote:387f327c3a="Henrik"]Hello !

Tudna valaki segiteni hogy ha a DSL leesik hogyan tudnam a Debian-t ravenni, hogy automatikusan inditsa ujra a pppoe-t.

Kosz elore is .

Henrik

maxfail 0
persist

A /etc/ppp/peers/dsl-provider -be

ahol a dsl-provider a szolgaltatod neve (amit megadtal a konfiguralaskor).

Sziasztok!

Lehet, hogy újra hasonló hiba van a Sarge-ban?

Van itthon egy folyamatos üzemű, naponta frissített Sarge szerver, évek óta gond nélkül működő ADSL kapcsolattal. A szolgáltató 24 óránként bontja a kapcsolatot és ilyenkor a szerver automatikusan újra kapcsolódik. (kapcsolódott) :(

25.-én tartós áramszünet volt, az UPS leállította, majd később újraindította a gépet.

Ettől kezdve a 24 óránkénti bontás után nem tud újra kapcsolódni.

A /var/log/syslog:
[code:1:be5cae00b7]Apr 30 18:08:00 server pppd[835]: LCP terminated by peer
Apr 30 18:08:00 server pppd[835]: Connect time 1440.0 minutes.
Apr 30 18:08:00 server pppd[835]: Sent 16179194 bytes, received 398347310 bytes.
Apr 30 18:08:00 server pppoe[839]: Session 58159 terminated -- received PADT from peer
Apr 30 18:08:00 server pppoe[839]: Sent PADT
Apr 30 18:08:03 server pppd[835]: Connection terminated.
Apr 30 18:08:03 server pppd[835]: tcflush failed: Input/output error
Apr 30 18:08:03 server pppd[835]: Serial connection established.
Apr 30 18:08:03 server pppd[835]: Using interface ppp0
Apr 30 18:08:03 server pppd[835]: Connect: ppp0 <--> /dev/pts/1
Apr 30 18:08:03 server pppoe[15817]: PADS: Service-Name: ''
Apr 30 18:08:03 server pppoe[15817]: PPP session is 11233
Apr 30 18:08:23 server pppoe[15817]: Session 11233 terminated -- received PADT from peer
Apr 30 18:08:23 server pppoe[15817]: Sent PADT
Apr 30 18:09:03 server pppd[835]: LCP: timeout sending Config-Requests
Apr 30 18:09:03 server pppd[835]: Connection terminated.
Apr 30 18:09:03 server pppd[835]: tcflush failed: Bad file descriptor
Apr 30 18:09:03 server pppd[835]: Serial connection established.
Apr 30 18:09:03 server pppd[835]: Using interface ppp0
Apr 30 18:09:03 server pppd[835]: Connect: ppp0 <--> /dev/pts/2
Apr 30 18:09:03 server pppoe[15838]: PADS: Service-Name: ''
Apr 30 18:09:03 server pppoe[15838]: PPP session is 11258
Apr 30 18:09:23 server pppoe[15838]: Session 11258 terminated -- received PADT from peer
Apr 30 18:09:23 server pppoe[15838]: Sent PADT
...
[/code:1:be5cae00b7]

Az első csatlakozási kísérletre "tcflush failed: Input/output error", majd végtelen ciklusban "tcflush failed: Bad file descriptor".

Kézzel leállítva, újraindítva a ppp tökéletesen működik újabb 24 óráig.

Mi történt? Hogyan tudnám tartós működésre bírni.

Köszi a segítséget!

Arrabonus

Debian alatt nekem lazán ment, apt-get install pppoe pppoeconf; pppoeconf --mergkérdezte hogy elinduljon-e induláskor a kapcsolat, igen, azt is megkérdezte hogy most elindítsa-e, igen, és ment lazán napokig, a /var/log/syslog -ban lehet látni hogy megszakadt a kapcsolat, de magától egy-két másodpercen belül újraépült. stable, testing alatt is. Axeleros vagyok, 24 óránként kapok új IP-címet, 24 óránként újraindul a kapcsolat.

[quote:9cb445e371="Jedite"]Nekem is ez a problémám, hogy naponta egyszer levágja a kapcsolatot.
Én csináltam egy scriptet, ami a cron segedelmével figyeli, hogy él-e a kapcsolat.

Kipróbáltam az itt elhangzott javaslatokat, de nekem nem működik ezekkel. Pedig igazán jó volna, ha nem a scripptel kéne zabáltatni az erőforrást.

Megnéztem a DSL Howtot is, de nem ír igazán semmi konkrétat erre a problémára.

Vagy van még valami más is?

A persist, es a maxfail 0 boven elegendo. Mukodnie kell, mert nekem akar 12 oran keresztul is probalkozik, ha esetleg megszakad a kapcsolat.

PS: maximalis avatar meret 32x32. legyszi alakitsd at olyanra. ha kesz feltoltom a hup-ra, hogy mindig elerheto legyen, es ne lassitsa kulso link az oldalt.

hello

vagy masik lehetoseg nemtom lehet e olyat hogy nodetach es akkor scriptbe berakod vegtelen ciklusba. aztan inditasnal kap egy & ilyet a vegere.

ez csak az elso eset, nemtom hogy muxene e
vagy masik ami biztos hogy ha debian od van akkor
w3.uw.hu/adsl.deb aztan ha felrakod akkor adsl-setup al alitod be
ha esetleg nem allitana be magat inditasnal. Nekem ez mindig recoonectel es mivel invitel t hasznalok igy most extra.irc.hu n mar
11:31:36 **** signed on 3wks 6days 1hr 14mins 40secs ago
de most epp elsplittelt extra igy nemtom megmarad e
tehat sztem hasznald debian eseten
http://w3.uw.hu/adsl.deb ezt....

macskas

Nekem is van egy disconnectalas problemam, de nekem nem a szolgaltato bontja a kapcsolatot. naponta tobbszor is elofordul hogy szakad az ADSL!
Megneztem ilyenkor mi kerul a logba, de nem ertem meg belole a problemat.

[code:1:61b722113a]
# Sikeresen felcsatlakozik
Jul 2 04:41:34 titan pppd[3451]: PAP authentication succeeded
Jul 2 04:41:34 titan pppd[3451]: peer from calling number 00:0F:F8:32:7C:1A authorized
Jul 2 04:41:34 titan pppd[3451]: local IP address 84.0.147.165
Jul 2 04:41:34 titan pppd[3451]: remote IP address 145.236.238.134
Jul 2 04:41:34 titan pppd[3451]: primary DNS address 195.228.240.249
Jul 2 04:41:34 titan pppd[3451]: secondary DNS address 195.228.242.180

# Itt bedig bontja a kapcsolatot
Jul 2 04:50:34 titan pppd[3451]: No response to 3 echo-requests
Jul 2 04:50:34 titan pppd[3451]: Serial link appears to be disconnected.
Jul 2 04:50:34 titan pppd[3451]: Connect time 9.0 minutes.
Jul 2 04:50:34 titan pppd[3451]: Sent 8975351 bytes, received 39467987 bytes.
Jul 2 04:50:34 titan pppd[3451]: Couldn't increase MTU to 1500
Jul 2 04:50:34 titan pppd[3451]: Couldn't increase MRU to 1500
Jul 2 04:50:34 titan pppd[3451]: Connection terminated.
[/code:1:61b722113a]

Van hogy elmegy majdnem egesz nap, van hogy fel orara a csatlakozas utan megszakad. Automatan visszacsatlakozik, de azert megis idegesito, ha naponta tobbszor elofordul. raadasul az ok hiba eredetu valoszinu, szal szeretnem kideriteni mi a baj.
Van valakinek otlete?
Az oprendszer amugy Debian 3.1 Sarge

Hali! Nekem a woodyban lévő 2.41ppp-t le kellett cserélni 2.4.2-re, hogy működjön a reconect(így működik több linux serverem), itthon(mielőtt nem fríssítettem fel(én őrült) addig frankó volt) viszont már egy komplet sarge distribem van, akárhogy variálgattam eddig a 2.4.2-el is rossz, 2.4.3-al is rossz a reconect funkció! Valami máshol lehet a hiba,gondolom! De hol??

Jedite:
Hogy van ez nálad? Bootoláskor felépül az ADSL kapcsolat és egyszer aztán valamikor megszakad. Ilyenkor a hiába van kifelé irányuló forgalom, akkor se épül fel újra a kapcsolat? A pon (ill. pon dsl-provider) hatására viszont igen?

slack alatt adsl-start-tal lehet indítani. ha nem teszed bele kézzel, akkor soha nem fog magától indulni induláskor :wink:

Debian alatt az /etc/ppp/ppp_on_boot szkript fut le.

[quote:4b3ce4995d="begin"]Debian alatt az /etc/ppp/ppp_on_boot szkript fut le.

imho az avatarjáról ordít, h slack alá keres megoldást :wink:

Igazad van. Az eredeti kérdésből maradt meg bennem a Debian... :)

Megint visszatértem sajna a témára. :cry:

Na az alábbi üzit dobja, mikor megszakad a kapcsolat:

pppd: LCP terminated by peer
pppd: ioctl(PPPIOCSASYNCMAP): Inappropriate ioctl for device(25)
pppd: tcflush failed: Input/output error
pppd: exit.

Mondanom sem kell, hogy nem hajlandó még mindig visszacsinálni a kapcsolatot a szakítás után.
Igérem ez az utolsó zaklatás e téren.

Még annyi a kérdés, hogy milyen porton és milyen csomagot küld a kiszolgáló a modemre, hogy az lekapcsolja a kapcsolatot?

Van egy érzésem, hogy ezen a nyomon kell haladni.

Köszönöm türelmetek!
Jedite

Ezzel en is talalkoztam. A woodyban levo ppp az oka (ppp 2.4.1.uus-4). A 2.4.2-vel nekem megszunt a problema.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=114423&archive=yes

/etc/apt/sources.list -be:
deb http://www.backports.org/debian stable ppp

apt-get update
apt-get install ppp

A dsl-provider fileba:
persist
maxfail 0

Sziasztok!

Szösszennék a témához, mert én is hasonló problémával küszködöm 1 hete. 2 szerverem is van, ugyanannál a szolgáltatónál az eggyik woody a másik Sargre.

A woodys szerveren a szolgáltató 24 óránként bont és szépen vissza is csatlakozik (pppd 2.4.1)

Jul 31 19:58:14 fw pppd[107]: LCP terminated by peer
Jul 31 19:58:14 fw pppd[107]: Modem hangup
Jul 31 19:58:14 fw pppd[107]: Connection terminated.
Jul 31 19:58:14 fw pppd[107]: Connect time 1440.1 minutes.
Jul 31 19:58:14 fw pppd[107]: Sent 606014466 bytes, received 198800661 bytes.
Jul 31 19:58:44 fw pppd[107]: Serial connection established.
Jul 31 19:58:44 fw pppd[107]: Using interface ppp0
Jul 31 19:58:44 fw pppd[107]: Connect: ppp0 <--> /dev/pts/0
Jul 31 19:58:46 fw pppd[107]: local IP address 81.183.10.112
Jul 31 19:58:46 fw pppd[107]: remote IP address 145.236.238.96

A Sarge szervernél (pppd 2.4.3) már a telepitésnél gondok voltak a ppp vel, eléggé "furcsa" dolgokat müvelt, (bizonyos oldalak nem jöttek le) de viszont a kapcsolat szakadás után ujra felépítődött.

Jul 20 15:47:29 server pppd[1670]: LCP terminated by peer
Jul 20 15:47:29 server pppd[1670]: Connect time 1440.0 minutes.
Jul 20 15:47:29 server pppd[1670]: Sent 2306866 bytes, received 21559944 bytes.
Jul 20 15:47:29 server pppd[1670]: Couldn't increase MTU to 1500
Jul 20 15:47:29 server pppd[1670]: Couldn't increase MRU to 1500
Jul 20 15:47:32 server pppd[1670]: Connection terminated.
Jul 20 15:47:32 server pppd[1670]: Modem hangup
Jul 20 15:47:32 server pppd[1670]: PPP session is 59865
Jul 20 15:47:32 server pppd[1670]: Using interface ppp0
Jul 20 15:47:32 server pppd[1670]: Connect: ppp0 <--> eth0
Jul 20 15:47:32 server pppd[1670]: Couldn't increase MTU to 1500
Jul 20 15:47:32 server pppd[1670]: Couldn't increase MRU to 1500
Jul 20 15:47:32 server pppd[1670]: Connection terminated.
Jul 20 15:47:56 server last message repeated 4 times

ezekután egyeztettem a két rendszer konfigfiléjét, és bemásoltam 1:1 be woody konfigot. Nos ezekután már a szokásos dolog:

ug 3 09:38:57 server pppd[1658]: LCP terminated by peer
Aug 3 09:38:57 server pppd[1658]: Connect time 1440.0 minutes.
Aug 3 09:38:57 server pppd[1658]: Sent 10528864 bytes, received 50435766 bytes.
Aug 3 09:39:00 server pppd[1658]: Connection terminated.
Aug 3 09:39:00 server pppd[1658]: tcflush failed: Input/output error
Aug 3 09:39:00 server pppd[1658]: Serial connection established.
Aug 3 09:39:00 server pppd[1658]: Using interface ppp0
Aug 3 09:39:00 server pppd[1658]: Connect: ppp0 <--> /dev/pts/1
Aug 3 09:40:00 server pppd[1658]: LCP: timeout sending Config-Requests
Aug 3 09:40:00 server pppd[1658]: Connection terminated.
Aug 3 09:40:00 server pppd[1658]: tcflush failed: Bad file descriptor
Aug 3 09:40:00 server pppd[1658]: Serial connection established.
Aug 3 09:40:00 server pppd[1658]: Using interface ppp0
Aug 3 09:40:00 server pppd[1658]: Connect: ppp0 <--> /dev/pts/2
Aug 3 09:41:00 server pppd[1658]: LCP: timeout sending Config-Requests
Aug 3 09:41:00 server pppd[1658]: Connection terminated.
Aug 3 09:41:00 server pppd[1658]: tcflush failed: Bad file descriptor
Aug 3 09:41:00 server pppd[1658]: Serial connection established.
Aug 3 09:41:00 server pppd[1658]: Using interface ppp0
Aug 3 09:41:00 server pppd[1658]: Connect: ppp0 <--> /dev/pts/3

ami az előző konfighoz képest változott hogy az első esetben a PAP filébe turkált, mostmár a CHAP ba. valamint a Sarge pppoeconf ja rengeteg helyre beirkált ugyan olyan adatokat (pl az usepeerdns szerepelt az optionsba és a dsl-providerbe is stb)

az eltérések:
dsl-provider
régiben pty #"/usr/sbin/pppoe -I eth0 -T 80 -m1452 sor ez -# most
valamint van egy plusz sor : plugin rp-pppoe.so eth0 sor amit most # eltem

valamint peers ben
mostani:
connect "/usr/sbin/chat -v -f /etc/chatscripts/provider"
régi:
connect "/usr/sbin/chat -v -f /etc/chatscripts/pap -T ********"

valamint az lcp_echo_interval -t megnöveltem 60 al, ennek még nem látom az eredményét.

és van egy options.ttyXX file ami az új rendszerben nincs

jah és demand és maxfail nincs benne a müködö woodys konfigba (szolgáltató ugyanaz)

most csak elméleti szinten foglalkozom a problémával, nem akarom nagyon megbojgatni a konfigokat, mert előfordulhat hogy nem müxik, aztán sokat kellen utazgatnom :) ezekután esetleg tipp? addigis szorgosan rebútolgatok

Az avataram már nem a régi :-(

De nem is az a fontos, mert bent a melóhelyen van a tűzfalam ami deb alapú.
Úgyhogy, akik a debes tanácsokat adják azók jól teszik :lol:

Egyébként meg tényleg Nagy Slacki fan vagyok, de ha szerverről van szó, akkor kicsit jobban hajlok a fafejű Woody felé.

Arra is gondoltam, hogy talán az a hiba:

pon parancs kiadása után a plog utasításra azt írja az utolsó sorban, hogy nem tudja determinálni a Proxy ARP valamit. Bár e nélkül is megy a net.

Nem vagyok még nagy guru a hálózatok terén, ezért felvilágosítana valaki, hogy az mi és mire jó.

Gondolom a kapcsolat nekem is azért szakad meg napi egy alkalommal, hogy új ipcímet adjanak, mert sajna nem fix (bár majd szeretném).

És benne van dsl-provider fileban a persist, meg a maxfail 0, de le se bagózza.
Nem éleszti újra a kapcsolatot.

trey! Az avatarról meg gondoskodom, majd csak hirtelen ez a megoldás volt a leggyorsabb. :wink:

[quote:d7e946cb70="Jedite"]És benne van dsl-provider fileban a persist, meg a maxfail 0, de le se bagózza.

Ez OK, de a demand is benne van? Mert ennek hatására figyeli a kifelé irányuló kéréseket. Ha ilyen érkezik és nem online, akkor csatlakozik.

Én anno írtam egy kétsoros scriptet, ami 8:00-kor disconnectelt, 8:01-kor újracsatlakozott. rc-dbe berakni napi futásra és kész. Az egy per kihagyás nem nagyon zavart, és lehet máskorra is időzíteni..

[quote:706e3fbc0d="begin"][quote:706e3fbc0d="Jedite"]És benne van dsl-provider fileban a persist, meg a maxfail 0, de le se bagózza.

Ez OK, de a demand is benne van? Mert ennek hatására figyeli a kifelé irányuló kéréseket. Ha ilyen érkezik és nem online, akkor csatlakozik.

Jaja benne van!
Úgyhogy már nem értem a problémát.

Én akkor is erre a Proxy ARP dologra tippelek.
Vagy lehet hogy az iptables configom zavar be neki? (bár ezt én kétlem)
De hát ki tudja?! :?: :?: :?: :?: :?:

[quote:c2fe89114c="dikki"]Én anno írtam egy kétsoros scriptet, ami 8:00-kor disconnectelt, 8:01-kor újracsatlakozott. rc-dbe berakni napi futásra és kész. Az egy per kihagyás nem nagyon zavart, és lehet máskorra is időzíteni..

jó ilyet én is csináltam, de cronnal. Csak úgy gondolom, hogy minek fusson egy fölös process, ha ezt a dsl-provider is tudja elviekben és sok linux gurunak 8) működik. Csak nekem nem. :cry:

tkpppoe nevű kis kliens azonnal reconnectel minden beállítás nélkül.

az elobb en voltam. :oops:

Az ip-t nem figyelem, mert nem volna sok értelme.
Hanem magát a csatoloót a ppp0-t.

Én inkább arra gondoltam esetlegesen, hogy az INPUT és a FOPRWARD táblákat alapból DENY-ra állítottam és csak a szükséges kapcsolatokat engedéjeztem. Az OUTPUT az ACCEPT-en maradt. Én arra gondolok, hogy esetlegesen nem kapom meg azt a csomit a ppp0-ra, ami szól, hogy levágja a netet a szolgáltató és ezért a pppoe nem is tudja feléleszteni, mert nem is kapott soha arról hírt, hogy le lesz vágva, hanem egyszercsak megtörtént.

Kissé parasztos a fogalmazás, de valami ilyesmi :lol:

Csak már az a kérdés, hogy milyen porton küldi azt a csomit, hogy engedélyezni tudjam az elfogadását. Valakinek valami ötlet?

Miért jó az neked hogy a FORWARD alapból DENY-n van? Szerintem az nem biztonságtalan/praktikátlan/rossz úgy ha ACCEPT-en van.

[quote:f5a6e2bf94="lacipac"]Miért jó az neked hogy a FORWARD alapból DENY-n van? Szerintem az nem biztonságtalan/praktikátlan/rossz úgy ha ACCEPT-en van.

Talán a forwardnál tényleg nem sokat dob a dolgon, de input felöl sztem fontos. Azért jó, mert melyiket egyszerűbb megcsinálni?
Pl.:

Van 10 dolog amit engedélyezni akarok.

1. megoldás:
Minden ACCEPT és le be kell tennem egy halomnyi láncot, hogy mindent ami nem kell megakadájozzak a bejutástól.

2. megoldás:
Minden DENY és csak azt engedélyezem ami kell.

Tanulság:
kevesebb chainrule, letisztultabb és átláthatóbb. Sokkal flekszibilisebb, mert ha valami kell csak engedélyezed.

No meg a könyvek is ezt ajánlják, hogy az első dolog mindent tiltani, majd azt ami kell átengedni és nem többet.

Szerintem ez teljesen logikus.

tipikusan a "mindent szabad, ami nem tiltott"/"csak azt szabad ami engedélyezett" problematika. ha biztonságos rendszert akarsz, akkor az utóbbit kell választani :wink: