Pppoe

reconnect script

#!/bin/sh
#
### INFO ###
#
# Aufbau, Trennen und Wiederherstellen der DSL-Verbindung.
# Usage: /etc/init.d/dsl connect | disconnect | reconnect
#
### INFO ###

case "$1" in
  connect)
    # Bestehende DSL-Verbindung pruefen
      if ps ax | grep "dsl-provider" | grep -v "grep";
        then
          echo "Error: Connection seems to be up already, see above."
      else
        # DSL-Verbindung aufbauen
          /usr/bin/pon dsl-provider
          sleep 5
          if ifconfig ppp0;
            then
              echo "Connection established, interface ppp0 is up."
          else
            echo "Error: Could not find interface ppp0."
          fi
      fi
      ;;
  disconnect)
    # Bestehende DSL-Verbindung pruefen
      if ! ps ax | grep "dsl-provider" | grep -v "grep" 1> /dev/null;
        then
          echo "Error: There is no connection to disconnect."
      else
      # DSL-Verbindung trennen
        /usr/bin/poff dsl-provider
        sleep 5
        if ! ifconfig ppp0 1> /dev/null 2> /dev/null;
          then
            echo "Connection disconnected, interface ppp0 is gone."
        else
          echo "Error: Interface ppp0 still seems to be there."
        fi
      fi
      ;;
  reconnect)
    # DSL-Verbindung Trennen & Wiederherstellen
      /usr/bin/poff dsl-provider
      sleep 5
      /usr/bin/pon dsl-provider
      ;;
  *)
    # Startparameter des Scripts
      echo "Usage: $0 connect | disconnect | reconnect"
      ;;
esac
exit 0

Plagiat

contribute to http://layer9.wordpress.com/2010/02/09/dsl-verbindung-mit-t-dsl-business-pppoe-und-debian-lenny/

Die Anbindung kleinerer Standorte mittels günstigem DSL-Anschluss wie T-DSL-Business kann in mancherlei Hinsicht für eine kleine Herausforderung sorgen. Neben der Beschränkung auf lediglich eine offizielle IP-Adresse bieten die Provider oft nur Endgeräte an, die nicht in die vorhandene Infrastruktur passen und deren Konfiguration sich maßgeblich von der bestehender Systeme unterscheidet. Insbesondere wer für Netzwerkdienste wie Proxy und VPN normalerweise eigene Linuxsysteme einsetzt, muss bei der Verwendung eines entsprechenden Routers oder einer Appliance erst mal umdenken.

Glücklicherweise lässt sich Linux via PPPoE aber auch direkt hinter einem xDSL Modem betreiben und kann so ohne störendes NAT als Server für die erforderlichen Netzwerkdienste verwendet werden.

Im Fall von Debian Lenny werden dafür die Pakete pppoe und pppoeconf benötigt. Abhängigkeiten zu anderen Paketen werden durch die Installation mittels apt-get automatisch aufgelöst:

gw:~# apt-get install pppoe pppoeconf

Nach der Installation wird die DSL-Verbindung mittels des semigrafischen Konfigurationstools pppoeconf konfiguriert. Die Schritte sind selbsterklärend.

Im Hintergrund werden dabei zunächst die Dateien /etc/ppp/chap-secrets und /etc/ppp/pap-secrets um den Benutzernamen und das Passwort des Internetzugangs ergänzt:

# OUTBOUND connections

"feste-ip9/123456789@t-online-com.de" * "123456"

Zusätzlich wird in der Datei /etc/network/interfaces die Definition für das logische Interface ppp0 hinzugefügt. Durch auto dsl-provider wird die DSL-Verbindung beim Booten des Rechners automatisch gestartet:

auto dsl-provider
iface dsl-provider inet ppp
pre-up /sbin/ifconfig eth1 up # line maintained by pppoeconf
provider dsl-provider

Darüber hinaus werden in der Datei /etc/ppp/peers/dsl-provider verbindungsspezifische Einstellungen für den pppd vorgenommen, von denen folgende Parameter im Nachhinein angepasst bzw. hinzugefügt werden sollten:

# pppd nach Abbruch der Verbindung nicht beenden, sondern versuchen die
# Verbindung wiederherzustellen.
persist

# Versuche die Wiederherstellung der Verbindung bis in alle Ewigkeit.
maxfail 0

# Prüfe alle zwei Sekunden mit einem LCP echo request, ob die Verbindung
# noch steht.
lcp-echo-interval 2

# Verbindung nach drei LCP echo timeouts (6 Sekunden) trennen (wird im
# Anschluss durch persist versucht wiederherzustellen).
lcp-echo-failure 3

# Fünf Sekunden warten, bevor die Verbindung nach einem Abbruch erneut
# hergestellt wird.
holdoff 5

# Deaktiviere Proxy ARP.
noproxyarp

Eine umfassende Beschreibung aller Optionen findet sich in der manpage von pppd. Nach Abschluss der Konfiguration kann die DSL-Verbindung mit pon dsl-provider hergestellt werden. Klappt alles, sollte anschließend das logische Interface ppp0 verfügbar sein und eine IP-Adresse haben:

gw:~# pon dsl-provider
Plugin rp-pppoe.so loaded.
gw:~# ifconfig ppp0
ppp0  Link encap:Point-to-Point Protocol
      inet addr:209.85.13.105  P-t-P:209.85.13.106 Mask:255.255.255.255
      UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
      RX packets:5 errors:0 dropped:0 overruns:0 frame:0
      TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:3
      RX bytes:174 (174.0 B)  TX bytes:174 (174.0 B)

Der Verbindungsaufbau wird in der Logdatei /var/log/syslog protokolliert:

gw:~# grep "pppd" /var/log/syslog
10:44:11 gw pppd[2958]: Plugin rp-pppoe.so loaded.
10:44:11 gw pppd[2959]: pppd 2.4.4 started by root, uid 0
10:44:11 gw pppd[2959]: PPP session is 7801
10:44:11 gw pppd[2959]: Using interface ppp0
10:44:11 gw pppd[2959]: Connect: ppp0  eth1
10:44:12 gw pppd[2959]: PAP authentication succeeded
10:44:12 gw pppd[2959]: peer from calling number 00:90:[...] authorized
10:44:12 gw pppd[2959]: local  IP address 209.85.13.105
10:44:12 gw pppd[2959]: remote IP address 209.85.13.106
10:44:12 gw pppd[2959]: primary   DNS address 209.85.13.99
10:44:12 gw pppd[2959]: secondary DNS address 209.85.13.103

Mittels poff dsl-provider wird die Verbindung wieder getrennt und das Interface ppp0 verschwindet:

gw:~# poff dsl-provider
gw:~# ifconfig ppp0
ppp0: error fetching interface information: Device not found

Analog zum Verbindungsaufbau dazu der Auszug aus /var/log/syslog:

gw:~# grep "pppd" /var/log/syslog
11:06:12 gw pppd[2959]: Terminating on signal 15
11:06:12 gw pppd[2959]: Connect time 22.0 minutes.
11:06:12 gw pppd[2959]: Sent 6202 bytes, received 6406 bytes.
11:06:12 gw pppd[2959]: Connection terminated.
11:06:12 gw pppd[2959]: Exit.

Da die Verbindungsherstellung mittels pon dsl-provider während einer bestehenden Verbindung einfach einen zweiten (ungewollten) Prozess des pppd startet und die Rückmeldungen auch im Allgemeinen etwas dürftig ist, habe ich zur Handhabung der Verbindung ein kleines Script erstellt, das vor dem Auf/Abbbau der Verbindung auf evtl. bestehende Prozesse des pppd prüft und etwas mehr Feedback gibt:

#!/bin/sh
#
### INFO ###
#
# Aufbau, Trennen und Wiederherstellen der DSL-Verbindung.
# Usage: /etc/init.d/dsl connect | disconnect | reconnect
# Author: layer9 at gmx.de
#
### INFO ###

case "$1" in
  connect)
    # Bestehende DSL-Verbindung pruefen
      if ps ax | grep "dsl-provider" | grep -v "grep";
        then
          echo "Error: Connection seems to be up already, see above."
      else
        # DSL-Verbindung aufbauen
          /usr/bin/pon dsl-provider
          sleep 5
          if ifconfig ppp0;
            then
              echo "Connection established, interface ppp0 is up."
          else
            echo "Error: Could not find interface ppp0."
          fi
      fi
      ;;
  disconnect)
    # Bestehende DSL-Verbindung pruefen
      if ! ps ax | grep "dsl-provider" | grep -v "grep" 1> /dev/null;
        then
          echo "Error: There is no connection to disconnect."
      else
      # DSL-Verbindung trennen
        /usr/bin/poff dsl-provider
        sleep 5
        if ! ifconfig ppp0 1> /dev/null 2> /dev/null;
          then
            echo "Connection disconnected, interface ppp0 is gone."
        else
          echo "Error: Interface ppp0 still seems to be there."
        fi
      fi
      ;;
  reconnect)
    # DSL-Verbindung Trennen & Wiederherstellen
      $0 disconnect
      $0 connect
      ;;
  *)
    # Startparameter des Scripts
      echo "Usage: $0 connect | disconnect | reconnect"
      ;;
esac
exit 0

Soweit, so gut. Bei der Recherche zum Thema finden sich im Internet eine Reihe älterer Beiträge zum Thema Zwangstrennung und damit verbundener Probleme bei der Wiedereinwahl. Bei den von mir durchgeführten Tests mit

    Debian Lenny (5.04 2.6.26-2-686)
    pppd 2.4.4 (ppp 2.4.4rel-10.1)
    Roaring Penguin PPPoE Version 3.8
    T-DSL Business ADSL2
    ADSL Modem Speedport 201

gab es diesbzgl. allerdings keinerlei Probleme – die Wiedereinwahl nach erfolgter Zwangstrennung seitens der Telekom klappte völlig problemlos und innerhalb der durch lcp-echo-interval, lcp-echo-failure und holdoff definierten Zeitspanne:

gw:~# grep "pppd" /var/log/syslog
18:13:03 gw pppd[4600]: No response to 3 echo-requests
18:13:03 gw pppd[4600]: Serial link appears to be disconnected.
18:13:03 gw pppd[4600]: Connect time 1440.4 minutes.
18:13:03 gw pppd[4600]: Sent 5584059 bytes, received 5597591 bytes.
18:13:09 gw pppd[4600]: Connection terminated.
18:13:09 gw pppd[4600]: Modem hangup
18:13:14 gw pppd[4600]: PPP session is 6417
18:13:14 gw pppd[4600]: Using interface ppp0
18:13:14 gw pppd[4600]: Connect: ppp0  eth1
18:13:15 gw pppd[4600]: PAP authentication succeeded
18:13:15 gw pppd[4600]: peer from calling number 00:90:[...] authorized
18:13:15 gw pppd[4600]: Cannot determine ethernet address for proxy ARP
18:13:15 gw pppd[4600]: local  IP address 209.85.13.105
18:13:15 gw pppd[4600]: remote IP address 209.85.13.106
18:13:15 gw pppd[4600]: primary   DNS address 209.85.13.99
18:13:15 gw pppd[4600]: secondary DNS address 209.85.13.103

Auch die Wiedereinwahl nach Verlust und Wiederherstellung des DSL-Signals funktioniert – wobei hier die Zeitspanne zwischen Modem hangup und Timeout waiting for PADS packets nicht dem mittels holdoff konfigurierten Wert von 5 Sekunden entspricht (warum weiß ich momentan auch noch nicht):

gw:~# grep "pppd" /var/log/syslog
17:32:07 gw pppd[4292]: No response to 3 echo-requests
17:32:07 gw pppd[4292]: Serial link appears to be disconnected.
17:32:07 gw pppd[4292]: Connect time 1.1 minutes.
17:32:07 gw pppd[4292]: Sent 3120 bytes, received 3144 bytes.
17:32:13 gw pppd[4292]: Connection terminated.
17:32:13 gw pppd[4292]: Modem hangup
17:32:56 gw pppd[4292]: Timeout waiting for PADS packets
17:32:56 gw pppd[4292]: Unable to complete PPPoE Discovery
17:33:34 gw pppd[4292]: Timeout waiting for PADS packets
17:33:34 gw pppd[4292]: Unable to complete PPPoE Discovery
17:34:23 gw pppd[4292]: Timeout waiting for PADS packets
17:34:23 gw pppd[4292]: Unable to complete PPPoE Discovery
17:34:26 gw pppd[4292]: PPP session is 7920
17:34:26 gw pppd[4292]: Using interface ppp0
17:34:26 gw pppd[4292]: Connect: ppp0  eth1
17:34:26 gw pppd[4292]: PAP authentication succeeded
17:34:26 gw pppd[4292]: peer from calling number 00:90:[...] authorized
17:34:26 gw pppd[4292]: Cannot determine ethernet address for proxy ARP
17:34:26 gw pppd[4292]: local  IP address 209.85.13.105
17:34:26 gw pppd[4292]: remote IP address 209.85.13.106
17:34:26 gw pppd[4292]: primary   DNS address 209.85.13.99
17:34:26 gw pppd[4292]: secondary DNS address 209.85.13.103

Auch wenn die Downtime nur wenige Sekunden beträgt, ist sie ärgerlich und für ein Business-Produkt eigentlich unangemessen. So kann sich die Trennung z.B. durch Ausfall des DSL-Signals und damit verbundener Trennung/Wiedereinwahl beliebig verschieben. Fällt die DSL-Verbindung beispielsweise mittags um 11:00 Uhr aus, wird die 24h Zwangtrennung am nächsten Tag zur selben Zeit für eine kurze Trennung sorgen – während der Bürozeit nicht unbedingt wünschenswert.

Man sollte also versuchen, den Zeitpunkt der Zwangstrennung in ein weniger kritisches Zeitfenster zu legen – beispielsweise indem man die Verbindung nachts um 3:30 trennt und fünf Sekunden später wieder aufbaut.

Da das kleinste Zeitintervall bei Cronjobs jedoch nur eine Minute beträgt, muss man an dieser Stelle mit einem Script arbeiten. Theoretisch könnte man dazu einfach das oben aufgeführten Script verwenden und folgenden Eintrag in der /etc/crontab erstellen:

# m h dom mon dow user  command

30 3   * * *   root    /etc/init.d/dsl reconnect

In meinem Fall führte das allerdings zu einem Problem, wenn während der Ausführung des Scripts die DSL-Verbindung unterbrochen und der pppd wie in folgendem Beispiel mit der Wiederherstellung beschäftigt war:

gw:~# grep "pppd" /var/log/syslog
13:00:32 gw pppd[3117]: Timeout waiting for PADO packets
13:00:32 gw pppd[3117]: Unable to complete PPPoE Discovery

Wird der pppd während dieser Phase beendet, dauert es bis zum tatsächlichen Schließen des Prozesses bis zu 30 Sekunden. Da das Script aber schon nach fünf Sekunden eine neue Verbindung aufbauen möchte und zuvor auf bestehende Prozesse prüft, bricht das Script ab und der pppd wird nicht neu gestartet.

Natürlich existieren verschiedene Möglichkeiten, das Script anzupassen. Effektiv und schnell ist z.B. einfach den Part

  reconnect)
    # DSL-Verbindung Trennen & Wiederherstellen
      $0 disconnect
      $0 connect

durch

  reconnect)
    # DSL-Verbindung Trennen & Wiederherstellen
      /usr/bin/poff dsl-provider
      sleep 5
      /usr/bin/pon dsl-provider

zu ersetzen. So wird in jedem Fall ein neuer Prozess (hier: PID 3166) gestartet, der die Wiedereinwahl fortsetzt. Der alte Prozess (PID 3117) wird wie zuvor beschrieben nach einigen Sekunden beendet:

13:00:32 gw pppd[3117]: Timeout waiting for PADO packets
13:00:32 gw pppd[3117]: Unable to complete PPPoE Discovery
13:00:48 gw pppd[3165]: Plugin rp-pppoe.so loaded.
13:00:48 gw pppd[3166]: pppd 2.4.4 started by root, uid 0
13:01:12 gw pppd[3117]: Timeout waiting for PADO packets
13:01:12 gw pppd[3117]: Unable to complete PPPoE Discovery
13:01:12 gw pppd[3117]: Terminating on signal 15
13:01:12 gw pppd[3117]: Exit.
13:01:23 gw pppd[3166]: Timeout waiting for PADO packets
13:01:23 gw pppd[3166]: Unable to complete PPPoE Discovery

Theoretisch könnte man das alles noch weiter ausbauen, z.B. indem man den pppd regelmäßig kontrolliert und im Fehlerfall neu startet. Prinzipiell funktioniert die Verbindung aber auch so schon sehr gut und kann ohne weiteres produktiv eingesetzt werden.