Hallo Liste,
leider wieder eine Frage statt einer Antwort. Ich versuche gerade in IPv6 einzusteigen und bekomme mittels SIXXS auch alles geregelt. Was mich "nervt" ist, dass der Tunnel nach einem reboot nicht automatisch "steht". Ein '/etc/init.d/aiccu restart' und alles tut, wie es soll. Nur wie finde ich jetzt die Ursache, warum es beim booten nicht klappt? Ich vermute pppoe steht noch nicht, wenn aiccu startet (ist im rc2.d aber drin), aber sicher bin ich mir da nicht. Ideen oder Erfahrungen?
Mit freundlichen Grüßen / Kind regards Ronny Seffner
On Fri, Aug 05, 2011 at 07:00:17PM +0200, Ronny Seffner wrote:
leider wieder eine Frage statt einer Antwort. Ich versuche gerade in IPv6 einzusteigen und bekomme mittels SIXXS auch alles geregelt. Was mich "nervt" ist, dass der Tunnel nach einem reboot nicht automatisch "steht". Ein '/etc/init.d/aiccu restart' und alles tut, wie es soll. Nur wie finde ich jetzt die Ursache, warum es beim booten nicht klappt? Ich vermute pppoe steht noch nicht, wenn aiccu startet (ist im rc2.d aber drin), aber sicher bin ich mir da nicht. Ideen oder Erfahrungen?
Ich starte aiccu nicht über das Init-Skript sondern über folgendes in der /etc/network/interfaces:
iface eth1 inet static address 192.168.178.200 netmask 255.255.255.0 network 192.168.178.0 broadcast 192.168.178.255 gateway 192.168.178.1 post-up aiccu start pre-down aiccu stop
etwas ähnliches sollte sich auch mit pppoe-Interfaces hinbekommen lassen.
Viele Grüße Jan
Hallo IPv6'ler,
Ich habe hier nur Stabilität reinbekommen, indem ich 'aiccu' über /etc/ppp/ip-down.d abschalten und in ip-up.d als letztes script um 10 Sekunden verzögert wieder starte. Alle genannten Schräubchen an den pppoe Parametern waren fruchtlos.
Mit freundlichen Grüßen / Kind regards Ronny Seffner
Hi,
On Friday 05 August 2011, Ronny Seffner wrote:
leider wieder eine Frage statt einer Antwort. Ich versuche gerade in IPv6 einzusteigen und bekomme mittels SIXXS auch alles geregelt. Was mich "nervt" ist, dass der Tunnel nach einem reboot nicht automatisch "steht". Ein '/etc/init.d/aiccu restart' und alles tut, wie es soll. Nur wie finde ich jetzt die Ursache, warum es beim booten nicht klappt?
Schau mal in /etc/default/aiccu - dort muss ein Flag gesetzt werden damit es beim Start hochkommt.
Ich vermute pppoe steht noch nicht, wenn aiccu startet (ist im rc2.d aber drin), aber sicher bin ich mir da nicht. Ideen oder Erfahrungen?
Das stört nicht. Aiccu detektiert automagisch wenn PPP hoch oder runter fährt.
Konrad
On Sat, Aug 06, 2011 at 11:27:17AM +0200, Konrad Rosenbaum wrote:
Hi,
On Friday 05 August 2011, Ronny Seffner wrote:
leider wieder eine Frage statt einer Antwort. Ich versuche gerade in IPv6 einzusteigen und bekomme mittels SIXXS auch alles geregelt. Was mich "nervt" ist, dass der Tunnel nach einem reboot nicht automatisch "steht". Ein '/etc/init.d/aiccu restart' und alles tut, wie es soll. Nur wie finde ich jetzt die Ursache, warum es beim booten nicht klappt?
Schau mal in /etc/default/aiccu - dort muss ein Flag gesetzt werden damit es beim Start hochkommt.
Wenn das nicht gesetzt ist, startet es nie, nicht nur nicht beim Booten.
Ich vermute pppoe steht noch nicht, wenn aiccu startet (ist im rc2.d aber drin), aber sicher bin ich mir da nicht. Ideen oder Erfahrungen?
Das stört nicht. Aiccu detektiert automagisch wenn PPP hoch oder runter fährt.
Ach ja, seit welcher in Debian gepackten Version? Ich habe das Problem, das Aiccu nicht hinter einer NAT sitzt, sondern direkt auf dem Gateway ohne NAT. Da Aiccu das unterbrochene ppp0-Interface nicht mitbekommt hängt es sich danach sofort auf, und kann keine UDP-Pakete nach draußen schicken. Allein ein restart von aiccu kann das beheben. Seitdem ich das Setup so habe, und den Fehler kenne starte ich aiccu präventiv beim DNS-Update durch.
Für die Interessierten ein kleiner Auszug aus dem Syslog:
Aug 7 02:12:06 hive aiccu[31430]: [AYIYA-beat] : Error (-1) while sending 44 bytes sent to network: Invalid argument (22) Aug 7 02:13:06 hive aiccu[31430]: [AYIYA-beat] : Error (-1) while sending 44 bytes sent to network: Invalid argument (22) Aug 7 02:13:08 hive aiccu[31430]: [AYIYA-tundev->tun] : Error (-1) while sending 146 bytes to network: Invalid argument (22) Aug 7 02:13:09 hive aiccu[31430]: [AYIYA-tundev->tun] : Error (-1) while sending 146 bytes to network: Invalid argument (22) Aug 7 02:13:10 hive aiccu[31430]: [AYIYA-tundev->tun] : Error (-1) while sending 136 bytes to network: Invalid argument (22) Aug 7 02:13:17 hive aiccu[31430]: [AYIYA-tundev->tun] : Error (-1) while sending 140 bytes to network: Invalid argument (22) Aug 7 02:13:39 hive aiccu[31430]: [AYIYA-tundev->tun] : Error (-1) while sending 135 bytes to network: Invalid argument (22) Aug 7 02:13:39 hive aiccu[31430]: [AYIYA-tundev->tun] : Error (-1) while sending 135 bytes to network: Invalid argument (22) Aug 7 02:13:39 hive aiccu[31430]: [AYIYA-tundev->tun] : Error (-1) while sending 135 bytes to network: Invalid argument (22) Aug 7 02:13:39 hive aiccu[31430]: [AYIYA-tundev->tun] : Error (-1) while sending 135 bytes to network: Invalid argument (22) Aug 7 02:14:06 hive aiccu[31430]: [AYIYA-beat] : Error (-1) while sending 44 bytes sent to network: Invalid argument (22) Aug 7 02:15:05 hive aiccu[5772]: Successfully retrieved tunnel information for T1 Aug 7 02:15:05 hive aiccu[5874]: AICCU running as PID 5874 Aug 7 02:15:05 hive aiccu[5874]: [AYIYA-start] : Anything in Anything (draft-02) Aug 7 02:15:05 hive aiccu[5874]: [AYIYA-tun->tundev] : (Socket to TUN) started
Wenn jemand eine Idee hat, wie man das fixt: gerne, her damit..
Ich würde wahrscheinlich das aiccu-init-script so modifizieren, dass es einfach ein wenig wartet oder ein paar Scriptchen für /etc/network/if-up.d schreiben.
Gruß, Andre
On Sun, Aug 07, 2011 at 03:20:28AM +0200, Andre Klärner wrote:
On Sat, Aug 06, 2011 at 11:27:17AM +0200, Konrad Rosenbaum wrote:
Hi,
On Friday 05 August 2011, Ronny Seffner wrote:
leider wieder eine Frage statt einer Antwort. Ich versuche gerade in IPv6 einzusteigen und bekomme mittels SIXXS auch alles geregelt. Was mich "nervt" ist, dass der Tunnel nach einem reboot nicht automatisch "steht". Ein '/etc/init.d/aiccu restart' und alles tut, wie es soll. Nur wie finde ich jetzt die Ursache, warum es beim booten nicht klappt?
Schau mal in /etc/default/aiccu - dort muss ein Flag gesetzt werden damit es beim Start hochkommt.
Wenn das nicht gesetzt ist, startet es nie, nicht nur nicht beim Booten.
Das ist nicht korrekt, bei mir steht in der /etc/default/aiccu (Kommentare lass ich mal weg):
DAEMON_ARGS="" AICCU_ENABLED=No
Das stört nicht. Aiccu detektiert automagisch wenn PPP hoch oder runter fährt.
Ach ja, seit welcher in Debian gepackten Version?
Bei mir ist das aiccu 20070115-14 (die Version ist in Squeeze, testing und unstable identisch)
Ich habe das Problem, das Aiccu nicht hinter einer NAT sitzt, sondern direkt auf dem Gateway ohne NAT. Da Aiccu das unterbrochene ppp0-Interface nicht mitbekommt hängt es sich danach sofort auf, und kann keine UDP-Pakete nach draußen schicken. Allein ein restart von aiccu kann das beheben. Seitdem ich das Setup so habe, und den Fehler kenne starte ich aiccu präventiv beim DNS-Update durch.
Wenn das ppp-Interface per ifupdown (also /etc/network/interfaces) gestartet wird, sollten die beiden Zeilen aus meiner vorigen Mail bei dem ppp-Interface-Block helfen, also:
post-up aiccu start pre-down aiccu stop
Wenn jemand eine Idee hat, wie man das fixt: gerne, her damit..
Ich würde wahrscheinlich das aiccu-init-script so modifizieren, dass es einfach ein wenig wartet oder ein paar Scriptchen für /etc/network/if-up.d schreiben.
Das brauchst du wahrscheinlich nicht, siehe oben.
Viele Grüße Jan
-- Jan Dittberner - Debian Developer GPG-key: 4096R/558FB8DD 2009-05-10 B2FF 1D95 CE8F 7A22 DF4C F09B A73E 0055 558F B8DD http://www.dittberner.info/
On Sun, Aug 07, 2011 at 11:13:07AM +0200, Jan Dittberner wrote:
On Sun, Aug 07, 2011 at 03:20:28AM +0200, Andre Klärner wrote:
On Sat, Aug 06, 2011 at 11:27:17AM +0200, Konrad Rosenbaum wrote:
Schau mal in /etc/default/aiccu - dort muss ein Flag gesetzt werden damit es beim Start hochkommt.
Wenn das nicht gesetzt ist, startet es nie, nicht nur nicht beim Booten.
Das ist nicht korrekt, bei mir steht in der /etc/default/aiccu (Kommentare lass ich mal weg):
DAEMON_ARGS="" AICCU_ENABLED=No
Also heißt ein "AICCU_ENABLED=Yes" das aiccu beim Booten startet, und ein "AICCU_ENABLED=No" dass aiccu beim Booten startet?
Ein kleiner Auszug aus /etc/init.d/aiccu:
# Is aiccu enabled? case "$AICCU_ENABLED" in [Nn]*) exit 0 ;; esac
Damit beendet sich das aiccu-initscript sobald der Inhalt der AICCU_ENABLED-Variable mit N beginnt. Klingt nach keiner Unterscheidung ob beim Booten oder nicht.
Das stört nicht. Aiccu detektiert automagisch wenn PPP hoch oder runter fährt.
Ach ja, seit welcher in Debian gepackten Version?
Bei mir ist das aiccu 20070115-14 (die Version ist in Squeeze, testing und unstable identisch)
Okay, die habe ich installiert. Trotzdem hängt sich der Aiccu-Tunnel auf, sobald die Zwangstrennung des Providers kommt.
Ich habe das Problem, das Aiccu nicht hinter einer NAT sitzt, sondern direkt auf dem Gateway ohne NAT. Da Aiccu das unterbrochene ppp0-Interface nicht mitbekommt hängt es sich danach sofort auf, und kann keine UDP-Pakete nach draußen schicken. Allein ein restart von aiccu kann das beheben. Seitdem ich das Setup so habe, und den Fehler kenne starte ich aiccu präventiv beim DNS-Update durch.
Wenn das ppp-Interface per ifupdown (also /etc/network/interfaces) gestartet wird, sollten die beiden Zeilen aus meiner vorigen Mail bei dem ppp-Interface-Block helfen, also:
post-up aiccu start pre-down aiccu stopWenn jemand eine Idee hat, wie man das fixt: gerne, her damit..
Das hilft leider bei der Zwangstrennung nicht, denn der PPPoE-Daemon trennt das Interface, löscht das ppp0 (womit das Handle auf das Netzwerk-Interface in Aiccu ungültig wird) und startet danach ein neues ppp0-Interface mit dann neuen Handles. Aiccu bekommt das nicht mit, und verwendet keinen neuen sauberen Socket, sondern noch immer den alten. Laut Bugtracker ist das Problem seit 2008 gefunden und gefixt, aber kein gefixtes Release für Linux existiert. In der Versionshistorie habe ich es schon gefunden:
"Don't use a connected UDP socket for AYIYA and heartbeat traffic"
Ich hoffe du verstehst jetzt besser was ich meinte.
Gruß, Andre
post-up aiccu start pre-down aiccu stopWenn jemand eine Idee hat, wie man das fixt: gerne, her damit..
Das hilft leider bei der Zwangstrennung nicht, denn der PPPoE-Daemon trennt das Interface, löscht das ppp0 (womit das Handle auf das Netzwerk-Interface in Aiccu ungültig wird) und startet danach ein neues ppp0-Interface mit dann neuen Handles. Aiccu bekommt das nicht mit, und verwendet keinen neuen sauberen Socket, sondern noch immer den alten. Laut Bugtracker ist das Problem seit 2008 gefunden und gefixt, aber kein gefixtes Release für Linux existiert. In der Versionshistorie habe ich es schon gefunden:
"Don't use a connected UDP socket for AYIYA and heartbeat traffic"
Kleiner Link noch dazu: https://www.sixxs.net/tools/aiccu/changelog
Change from connected UDP socket to unconnected UDP socket for AYIYA tunnels This avoids cases where the local address changes and the socket is still being used. This goes unnoticed when one is behind a NAT as then the local address mostly remains the same.
Gruß, Andre
Hi Andre,
On Mon, Aug 08, 2011 at 02:29:48 +0200, Andre Kl?rner wrote:
[...]
Das hilft leider bei der Zwangstrennung nicht, denn der PPPoE-Daemon trennt das Interface, loescht das ppp0 (womit das Handle auf das Netzwerk-Interface in Aiccu ungueltig wird) und startet danach ein neues ppp0-Interface mit dann neuen Handles. Aiccu bekommt das nicht mit, und verwendet keinen neuen sauberen Socket, sondern noch immer den alten. Laut Bugtracker ist das
Wuerde es helfen, pppd/pppoe mit der "demand"-Option zu starten? In dem Fall fliegt das ppp0-Interface bei einer Zwangstrennung nicht weg, es wechselt nur die IP-Adresse bei der naechsten Einwahl. Die Einwahl wird durch Traffic ueber das ppp0-Interface getriggert.
Gruss, Chris
On Mon, August 8, 2011 09:22, Christian Perle wrote:
Wuerde es helfen, pppd/pppoe mit der "demand"-Option zu starten? In dem Fall fliegt das ppp0-Interface bei einer Zwangstrennung nicht weg, es wechselt nur die IP-Adresse bei der naechsten Einwahl. Die Einwahl wird durch Traffic ueber das ppp0-Interface getriggert.
Das ist nicht zuverlaessig. Ab und zu ist die Zwangstrennung zu brutal oder zu lang und pppd verabschiedet sich doch.
Das Problem scheint zu sein dass AYIYA (IPv6 over UDP) benutzt wird - es kann sein dass aiccu sich da anders verhaelt. Ich wuerde fuer den Fall einfach ein Script in /etc/ppp/ip-up.d legen was einfach nur ein /etc/init.d/aiccu restart macht. Nicht sehr schoen, aber sollte funktionieren.
Konrad
Hi Konrad,
On Mon, Aug 08, 2011 at 10:27:33 +0200, Konrad Rosenbaum wrote:
Wuerde es helfen, pppd/pppoe mit der "demand"-Option zu starten? In dem Fall fliegt das ppp0-Interface bei einer Zwangstrennung nicht weg, es wechselt nur die IP-Adresse bei der naechsten Einwahl. Die Einwahl wird durch Traffic ueber das ppp0-Interface getriggert.
Das ist nicht zuverlaessig. Ab und zu ist die Zwangstrennung zu brutal oder zu lang und pppd verabschiedet sich doch.
Mit den pppd-Optionen "demand" und "maxfail 0" sollte das nicht passieren.
Es kann vorkommen, dass pppd/pppoe die harte Trennung nicht mitbekommt, weil kein explizites PADT vom Peer gesendet wird. Fuer diesen Fall kann man eine lcp-basierte Erkennung durch die Optionen "lcp-echo-interval 60" und "lcp-echo-failure 3" benutzen.
Gruss, Chris
lug-dd@mailman.schlittermann.de
-
Andre Klärner -
Christian Perle -
Jan Dittberner -
Konrad Rosenbaum -
Ronny Seffner