Hansenet: 24h-Disconnect wird nicht erkannt.

L

</Life>

Member
Tja... viel mehr gibts da nicht mehr zu schreiben...
... ich wähle mich mit ppp -ddial ein, alles läuft auch wunderbar, nur muss ich leider nach dem 24-Stunden-Disconnect manuell die Verbindung trennen und neu aufbauen, da dieser nicht erkannt wird.
Derzeit benutze ich FreeBSD-6.0-RELEASE für den amd64,davor hatte ich aber mit selbiger Version für die i386-Architektur genau dasselbe Problem.
Ist das Problem bekannt; wenn ja: Gibts dafür Lösungs- oder zumindest Debuggingansätze? (Ein Cron-Job käme maximal als letzte Notlösung in Frage, dürfte klar sein, oder? ;))

Code: 
default:
 set log Phase Chat LCP IPCP CCP tun command
 ident user-ppp VERSION (built COMPILATIONDATE)
 set timeout 180                        # 3 minute idle timer (the default)
 enable dns                             # request DNS info (for resolv.conf)

hansenet:
 set device PPPoE:xl0
 enable dns
 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
 add! default HISADDR                   # Add a (sticky) default route
 set authname [I]xxxxx[/I]
 set authkey [I]xxxxx[/I]
 set MTU 1492
 
ppp ist scheisse, wenns darum geht zu erkennen, ob die leitung getrennt wurde.

benutz die "suchen" funktion, und du wirst sehen, wieviele leute schon an diesem problem verzweifelt sind...
 
Ich bin überhaupt kein ppp.conf-Fachmann, aber mit zusätzlichen vier Optionen klappt das hier mit T-Online und Arcor einwandfrei:
Code: 
 set redial 0 0
 set crtscts off
 set speed sync
 accept lqr
 
Jede Linux-Distribution mit 2.4er oder 2.6er Kernel kommt mit der 24 stündigen Verbindungstrennung einwandfrei klar, nur unter manchen BSD-Installationen gibt es anscheinend Probleme. Wieso ist es so schwierig, mit FreeBSD einen DSL-Zugang zu nutzen und die Wiedereinwahl zu verpassen? Unter OpenBSD gibt es seit geraumer Zeit ebenfalls dieses Fiasko, das aber mit kernel-pppoe umgangen werden kann.
 
</Life> schrieb:
Danke, ich werds mal ausprobieren.
Morgen gibts dann nen Bericht. :P
Zum Vergrößern anklicken....
Ich bin jetzt wiederum nicht so genau der Fachmann für Zwangstrennungen, aber reicht es nicht aus, notfalls einfach die DSL-Kabelverbindung zu trennen, um sowas zu testen?
 
quantumleeks schrieb:
Jede Linux-Distribution mit 2.4er oder 2.6er Kernel kommt mit der 24 stündigen Verbindungstrennung einwandfrei klar, nur unter manchen BSD-Installationen gibt es anscheinend Probleme.
Zum Vergrößern anklicken....
Ich kann mich an ein furchtbares Rumgehühner mit Debian woody erinnern, bei dem ich dieses Problem damals schon hatte. Das war irgendwo in der Zeit, zu der ich auf FreeBSD umgestiegen bin.
 
Ich hatte auch mit Linux (Debian SID) Probleme, dass manchmal die Wiedereinwahl nicht geklappt hat bzw. eine Trennung seitens Hansenet nicht erkannt wurde. Da starb dann der pppd und das wars. Da musste ich manuell den pppd killen und neustarten.
Ich hab nun folgendes laufen, was problemlos funktioniert.
1. Cron Job, der nachts trennt und wiedereinwaehlt.
2. monit, der eine TCP Verbindung zu meinem root Server herstellt und bei Bedarf die ppp Verbindung restartet. (Ist zwar nicht optimal, aber behebt Probleme, falls Hansenet trennt und der pppd nix merkt.)

Momentan ist die "Migration" von Linux zu FreeBSD auf dem Server noch nicht abgeschlossen, aber unter FreeBSD sollte das so auch laufen. ;)

HTH
 
xbit schrieb:
1. Cron Job, der nachts trennt und wiedereinwaehlt.
Zum Vergrößern anklicken....
Das ist übrigens die Lösung, die ich für mein FreeBSD 4.11-STABLE auch gewählt habe, obwohl ich dort kein Problem mit der Wiedereinwahl habe. Das hat nämlich unter anderem den Vorteil, dass man den Zeitpunkt der Trennung sehr genau bestimmen kann. Früher dauerte ein Zyklus hier nämlich immer 24 Stunden und 2 bis 5 Minuten. Dadurch verschob sich der Reconnect kontinuierlich um ein paar Minuten pro Tag und kreiste dann über die Monate gesehen quer durch die Tagesstunden. Jetzt lasse ich in den sehr frühen Morgenstunden trennen und wiederaufbauen und alles funktioniert einwandfrei.
 
Genau das Problem hatte ich auch, dabei starb der ppp und konnte nicht per Sig TERM gekillt werden, es bedarf dann einem Sig KILL.

Das Log sah dann so aus:
Dec 2 09:25:27 bitrouter ppp[5828]: tun0: LCP: deflink: RecvEchoRequest(77) state = Opened
Oct 1 09:25:27 bitrouter ppp[5828]: tun0: LCP: deflink: SendEchoReply(77) state = Opened
Oct 1 09:26:27 bitrouter ppp[5828]: tun0: LCP: deflink: RecvEchoRequest(78) state = Opened
Oct 1 09:26:27 bitrouter ppp[5828]: tun0: LCP: deflink: SendEchoReply(78) state = Opened
Zum Vergrößern anklicken....

Nur leider antwortete der Peer nicht mehr -> aus die Maus.

Eine Zwangstrennung ist als 'TerminateReq' im Log zu erkennen:
Dec 2 09:50:27 bitrouter ppp[5828]: tun0: LCP: deflink: SendEchoReply(77) state = Opened
Dec 2 09:51:27 bitrouter ppp[5828]: tun0: LCP: deflink: RecvEchoRequest(78) state = Opened
Dec 2 09:51:27 bitrouter ppp[5828]: tun0: LCP: deflink: SendEchoReply(78) state = Opened
Dec 2 09:53:41 bitrouter ppp[5828]: tun0: LCP: deflink: RecvTerminateReq(79) state = Opened
Dec 2 09:53:41 bitrouter ppp[5828]: tun0: LCP: deflink: LayerDown
Dec 2 09:53:41 bitrouter ppp[5828]: tun0: LCP: deflink: SendTerminateAck(79) state = Opened
Dec 2 09:53:41 bitrouter ppp[5828]: tun0: LCP: deflink: State change Opened --> Stopping
Dec 2 09:53:41 bitrouter ppp[5828]: tun0: CCP: deflink: State change Stopped --> Closed
Dec 2 09:53:41 bitrouter ppp[5828]: tun0: CCP: deflink: State change Closed --> Initial
Zum Vergrößern anklicken....

Ich nutze jetzt auch die harte Methode per cron-Job. Alles andere ist mir zu unzuverlässig. Mal sehen, wie das nach dem Wechsel auf NetBSD läuft (NetBSD als Domain0 mit (Net|Free)BSD und Debian als Gastsysteme).
 
Gut... dann scheints wohl nciht anders zu gehen... es hat mit obigen ppp.conf-Einstellungen nämlich ebenfalls _nicht_ funktioniert. :/
 
Hi

Also die läuft bei mir und zwei Bekannten ohne Probleme

Code: 
default:
        set device PPPoE:fxp0
        set speed sync
        set mru 1492
        set mtu 1492
        set ctsrts off
        enable lqr
        log phase tun
        add default HISADDR
        enable dns
        set authname "blablabla@blablabla"
        set authkey "blablablabla"

2x T-Online FreeBSD 5.3 + 5.4
1x 1und1 5.4

Vieleicht hilft es euch ja
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben