Früher hatte ich eine virtuelle Hyper-V Maschine mit Ubuntu als Router. Nachts habe ich den Server runtergefahren. Ich wollte nun auch nachts Internet haben, damit mein Emailserver möglichst immer die Emails annehmen kann (über einen SMTP Proxy gelöst). Um das zu realisieren, habe ich mir einen Raspberry PI 2 Modell B bestellt und dort Raspian (Debian Wheezy) installiert. Funktionieren tut so weit alles.
Ich bin jetzt nur auf ein Problem gestoßen, wo ich absolut nicht weiter weiß.
Nachts, wenn der Server und mein PC ausgeschaltet sind, wird die Leitung auf Grund von LCP echo request timeouts getrennt. Das passiert im Schnitt alle 7 bis 15 Minuten. Das ist höchst merkwürdig. Ich konnte das Verhalten nachstellen, in dem ich am Switch den Server und meinen PC trenne, um so die Nichtaktivität zu simulieren. Nach gewisser Zeit ist dann der entsprechende Log-Eintrag zu sehen. Obwohl die Netzinaktivität eigentlich nicht das Problem sein kann, habe ich trotzdem versucht für Aktivität zu sorgen. Ich habe ein Script geschrieben, was 55x einen ping zu 8.8.8.8 startet ( ping -c 55 8.8.8.8 ). Dieses Script wird als Cronjob jede Minute ausgeführt. Mit diesem Script sind die Fehler erst mal nicht mehr aufgetreten - dachte ich. Also habe ich es so gelassen und war gespannt, was die Nacht bringt. Mit einem Trollface sprangen mir die Logeinträge über die timeouts wieder ins Gesicht. Mit diesem Dauerping wurde die Leitung alle 30 bis 50 Minuten getrennt.
Hier ist ein vollständiger Syslog-Auszug von einem dieser Vorfälle. Das meiste sind eigentlich Protokolleinträge für den Verbindungsaufbau und nicht weiter wichtig. Trotzdem habe ich sie der Vollständigkeit halber drin gelassen.
Die Einträge "(CRON) error (grandchild #n failed with exit status 1)" kommen vom ping-Befehl und zeigen, dass dort Fehler im Ping sind. Dass in diesem Fall die Fehler des pings vor dem No Response to 8 echo-requests kommen, zeigt, dass die Leitung wirklich getrennt/inaktiv (wie auch immer) ist.
Sehr großes Fragezeichen. Und wie gesagt: Ist der PC und der Server an, bleibt die Verbindung stabil. Wir gehen in diesem Fall einmal davon aus, dass bei der Telekomseite alles in Ordnung ist.
Ein Bild der DSL Statistiken vom VDSL Modem ALL-500VDSL2 Rev. B
Achso. Es handelt sich um einen VDSL IP Anschluss (Annex J). Das Modem ist natürlich Annex J fähig.
Die Fehler waren früher natürlich nicht da, da die virtuelle Maschine des Routers nie alleine lief und alle anderen Maschinen immer mit aktiv waren. Ich weiß also nicht, ob das Problem auch früher aufgetreten wäre.
Meine Idee wäre noch, um mir den Raspberry PI anzusehen, meinen Laptop zu nehmen und diesen so wie den PI zu installieren. Das hätte den Vorteil, dass ich ein ausgereiftes 100% unterstütztes System (Ubuntu) für x86 Architektur testen kann. Da habe ich zwar keinen Bock drauf, muss aber wohl sein. Mal abwarten, was Ihr so meint.
ANHANG
/etc/ppp/peers/dsl-provider:
/etc/ppp/options
Ich bin jetzt nur auf ein Problem gestoßen, wo ich absolut nicht weiter weiß.
Nachts, wenn der Server und mein PC ausgeschaltet sind, wird die Leitung auf Grund von LCP echo request timeouts getrennt. Das passiert im Schnitt alle 7 bis 15 Minuten. Das ist höchst merkwürdig. Ich konnte das Verhalten nachstellen, in dem ich am Switch den Server und meinen PC trenne, um so die Nichtaktivität zu simulieren. Nach gewisser Zeit ist dann der entsprechende Log-Eintrag zu sehen. Obwohl die Netzinaktivität eigentlich nicht das Problem sein kann, habe ich trotzdem versucht für Aktivität zu sorgen. Ich habe ein Script geschrieben, was 55x einen ping zu 8.8.8.8 startet ( ping -c 55 8.8.8.8 ). Dieses Script wird als Cronjob jede Minute ausgeführt. Mit diesem Script sind die Fehler erst mal nicht mehr aufgetreten - dachte ich. Also habe ich es so gelassen und war gespannt, was die Nacht bringt. Mit einem Trollface sprangen mir die Logeinträge über die timeouts wieder ins Gesicht. Mit diesem Dauerping wurde die Leitung alle 30 bis 50 Minuten getrennt.
Hier ist ein vollständiger Syslog-Auszug von einem dieser Vorfälle. Das meiste sind eigentlich Protokolleinträge für den Verbindungsaufbau und nicht weiter wichtig. Trotzdem habe ich sie der Vollständigkeit halber drin gelassen.
Die Einträge "(CRON) error (grandchild #n failed with exit status 1)" kommen vom ping-Befehl und zeigen, dass dort Fehler im Ping sind. Dass in diesem Fall die Fehler des pings vor dem No Response to 8 echo-requests kommen, zeigt, dass die Leitung wirklich getrennt/inaktiv (wie auch immer) ist.
Code:
Jun 25 08:37:05 s-rras-1 CRON[5586]: (CRON) error (grandchild #5587 failed with exit status 1)
Jun 25 08:38:05 s-rras-1 CRON[5590]: (CRON) error (grandchild #5591 failed with exit status 1)
Jun 25 08:38:22 s-rras-1 pppd[29520]: No response to 8 echo-requests
Jun 25 08:38:22 s-rras-1 pppd[29520]: Serial link appears to be disconnected.
Jun 25 08:38:22 s-rras-1 pppd[29520]: Connect time 56.4 minutes.
Jun 25 08:38:22 s-rras-1 pppd[29520]: Sent 469778 bytes, received 754584 bytes.
Jun 25 08:38:22 s-rras-1 pppd[29520]: Script /etc/ppp/ip-down started (pid 5598)
Jun 25 08:38:22 s-rras-1 radvd[5249]: attempting to reread config file
Jun 25 08:38:22 s-rras-1 pppd[29520]: Script /etc/ppp/ipv6-down started (pid 5601)
Jun 25 08:38:22 s-rras-1 pppd[29520]: sent [LCP TermReq id=0x13 "Peer not responding"]
Jun 25 08:38:22 s-rras-1 radvd[5249]: resuming normal operation
Jun 25 08:38:22 s-rras-1 pppd[29520]: Script /etc/ppp/ipv6-down finished (pid 5601), status = 0x0
Jun 25 08:38:22 s-rras-1 pppd[29520]: Script /etc/ppp/ip-down finished (pid 5598), status = 0x0
Jun 25 08:38:23 s-rras-1 radvd[5249]: attempting to reread config file
Jun 25 08:38:23 s-rras-1 radvd[5249]: resuming normal operation
Jun 25 08:38:25 s-rras-1 pppd[29520]: sent [LCP TermReq id=0x14 "Peer not responding"]
Jun 25 08:38:28 s-rras-1 pppd[29520]: Connection terminated.
Jun 25 08:38:28 s-rras-1 pppd[29520]: Connect time 56.4 minutes.
Jun 25 08:38:28 s-rras-1 pppd[29520]: Sent 469778 bytes, received 754584 bytes.
Jun 25 08:38:28 s-rras-1 radvd[5249]: attempting to reread config file
Jun 25 08:38:28 s-rras-1 radvd[5249]: resuming normal operation
Jun 25 08:38:28 s-rras-1 radvd[5249]: attempting to reread config file
Jun 25 08:38:28 s-rras-1 radvd[5249]: resuming normal operation
Jun 25 08:38:28 s-rras-1 pppd[29520]: Modem hangup
Jun 25 08:38:28 s-rras-1 ifplugd(ppp0)[5221]: Link beat lost.
Jun 25 08:38:28 s-rras-1 ifplugd(ppp0)[5221]: Exiting.
Jun 25 08:38:30 s-rras-1 vnstatd[2277]: Interface "ppp0" disabled.
Jun 25 08:38:58 s-rras-1 pppd[29520]: Send PPPOE Discovery V1T1 PADI session 0x0 length 12
Jun 25 08:38:58 s-rras-1 pppd[29520]: dst ff:ff:ff:ff:ff:ff src b8:27:eb:c7:b0:c9
Jun 25 08:38:58 s-rras-1 pppd[29520]: [service-name] [host-uniq 50 73 00 00]
Jun 25 08:38:58 s-rras-1 pppd[29520]: Recv PPPOE Discovery V1T1 PADO session 0x0 length 46
Jun 25 08:38:58 s-rras-1 pppd[29520]: dst b8:27:eb:c7:b0:c9 src f0:f7:55:19:e9:43
Jun 25 08:38:58 s-rras-1 pppd[29520]: [service-name] [host-uniq 50 73 00 00] [AC-name HNOA75-ths] [AC-cookie d1 15 64 83 75 96 64 93 f5 76 4a 30 42 37 7e f6]
Jun 25 08:38:58 s-rras-1 pppd[29520]: Send PPPOE Discovery V1T1 PADR session 0x0 length 32
Jun 25 08:38:58 s-rras-1 pppd[29520]: dst f0:f7:55:19:e9:43 src b8:27:eb:c7:b0:c9
Jun 25 08:38:58 s-rras-1 pppd[29520]: [service-name] [host-uniq 50 73 00 00] [AC-cookie d1 15 64 83 75 96 64 93 f5 76 4a 30 42 37 7e f6]
Jun 25 08:38:58 s-rras-1 pppd[29520]: Recv PPPOE Discovery V1T1 PADS session 0x2c2f length 32
Jun 25 08:38:58 s-rras-1 pppd[29520]: dst b8:27:eb:c7:b0:c9 src f0:f7:55:19:e9:43
Jun 25 08:38:58 s-rras-1 pppd[29520]: [service-name] [host-uniq 50 73 00 00] [AC-cookie d1 15 64 83 75 96 64 93 f5 76 4a 30 42 37 7e f6]
Jun 25 08:38:58 s-rras-1 pppd[29520]: PADS: Service-Name: ''
Jun 25 08:38:58 s-rras-1 pppd[29520]: PPP session is 11311
Jun 25 08:38:58 s-rras-1 pppd[29520]: Connected to f0:f7:55:19:e9:43 via interface eth0.7
Jun 25 08:38:58 s-rras-1 pppd[29520]: using channel 135
Jun 25 08:38:58 s-rras-1 radvd[5249]: attempting to reread config file
Jun 25 08:38:58 s-rras-1 pppd[29520]: Using interface ppp0
Jun 25 08:38:58 s-rras-1 pppd[29520]: Connect: ppp0 <--> eth0.7
Jun 25 08:38:58 s-rras-1 pppd[29520]: sent [LCP ConfReq id=0x15 <mru 1492> <magic 0x644873a0>]
Jun 25 08:38:58 s-rras-1 radvd[5249]: resuming normal operation
Jun 25 08:38:58 s-rras-1 pppd[29520]: rcvd [LCP ConfReq id=0x1 <mru 1492> <auth pap> <magic 0x832ce4d6>]
Jun 25 08:38:58 s-rras-1 pppd[29520]: sent [LCP ConfAck id=0x1 <mru 1492> <auth pap> <magic 0x832ce4d6>]
Jun 25 08:38:58 s-rras-1 pppd[29520]: rcvd [LCP ConfAck id=0x15 <mru 1492> <magic 0x644873a0>]
Jun 25 08:38:58 s-rras-1 radvd[5249]: attempting to reread config file
Jun 25 08:38:58 s-rras-1 pppd[29520]: sent [LCP EchoReq id=0x0 magic=0x644873a0]
Jun 25 08:38:58 s-rras-1 pppd[29520]: sent [PAP AuthReq id=0xb user="<hidden>" password=<hidden>]
Jun 25 08:38:58 s-rras-1 radvd[5249]: resuming normal operation
Jun 25 08:38:58 s-rras-1 radvd[5249]: attempting to reread config file
Jun 25 08:38:58 s-rras-1 radvd[5249]: resuming normal operation
Jun 25 08:38:58 s-rras-1 pppd[29520]: rcvd [LCP EchoRep id=0x0 magic=0x832ce4d6]
Jun 25 08:38:58 s-rras-1 ifplugd(ppp0)[5715]: ifplugd 0.28 initializing.
Jun 25 08:38:58 s-rras-1 radvd[5249]: attempting to reread config file
Jun 25 08:38:58 s-rras-1 ifplugd(ppp0)[5715]: Using interface ppp0/00:00:00:00:00:00
Jun 25 08:38:58 s-rras-1 radvd[5249]: resuming normal operation
Jun 25 08:38:58 s-rras-1 ifplugd(ppp0)[5715]: Using detection mode: IFF_RUNNING
Jun 25 08:38:58 s-rras-1 ifplugd(ppp0)[5715]: Initialization complete, link beat detected.
Jun 25 08:38:58 s-rras-1 pppd[29520]: rcvd [PAP AuthAck id=0xb ""]
Jun 25 08:38:58 s-rras-1 pppd[29520]: PAP authentication succeeded
Jun 25 08:38:58 s-rras-1 pppd[29520]: peer from calling number F0:F7:55:19:E9:43 authorized
Jun 25 08:38:58 s-rras-1 pppd[29520]: sent [IPCP ConfReq id=0x15 <addr 0.0.0.0>]
Jun 25 08:38:58 s-rras-1 pppd[29520]: sent [IPV6CP ConfReq id=0xb <addr fe80::008e:4dc5:40a0:3a1d>]
Jun 25 08:38:58 s-rras-1 pppd[29520]: rcvd [IPCP ConfReq id=0x1 <addr 217.0.118.64>]
Jun 25 08:38:58 s-rras-1 pppd[29520]: sent [IPCP ConfAck id=0x1 <addr 217.0.118.64>]
Jun 25 08:38:58 s-rras-1 pppd[29520]: rcvd [IPCP ConfNak id=0x15 <addr 87.158.222.173>]
Jun 25 08:38:58 s-rras-1 pppd[29520]: sent [IPCP ConfReq id=0x16 <addr 87.158.222.173>]
Jun 25 08:38:58 s-rras-1 pppd[29520]: rcvd [IPV6CP ConfReq id=0x1 <addr fe80::f2f7:55ff:fe19:e900>]
Jun 25 08:38:58 s-rras-1 pppd[29520]: sent [IPV6CP ConfAck id=0x1 <addr fe80::f2f7:55ff:fe19:e900>]
Jun 25 08:38:58 s-rras-1 pppd[29520]: rcvd [IPV6CP ConfAck id=0xb <addr fe80::008e:4dc5:40a0:3a1d>]
Jun 25 08:38:58 s-rras-1 pppd[29520]: local LL address fe80::008e:4dc5:40a0:3a1d
Jun 25 08:38:58 s-rras-1 pppd[29520]: remote LL address fe80::f2f7:55ff:fe19:e900
Jun 25 08:38:58 s-rras-1 pppd[29520]: Script /etc/ppp/ipv6-up started (pid 5716)
Jun 25 08:38:58 s-rras-1 pppd[29520]: Script /etc/ppp/ipv6-up finished (pid 5716), status = 0x0
Jun 25 08:38:58 s-rras-1 pppd[29520]: rcvd [IPCP ConfAck id=0x16 <addr 87.158.222.173>]
Jun 25 08:38:58 s-rras-1 pppd[29520]: local IP address 87.158.222.173
Jun 25 08:38:58 s-rras-1 pppd[29520]: remote IP address 217.0.118.64
Jun 25 08:38:58 s-rras-1 pppd[29520]: Script /etc/ppp/ip-up started (pid 5718)
Jun 25 08:38:58 s-rras-1 ifplugd(ppp0)[5715]: Executing '/etc/ifplugd/ifplugd.action ppp0 up'.
Jun 25 08:38:58 s-rras-1 ifplugd(ppp0)[5715]: client: Ignoring unknown interface ppp0=ppp0.
Jun 25 08:38:58 s-rras-1 ifplugd(ppp0)[5715]: Program executed successfully.
Jun 25 08:39:00 s-rras-1 vnstatd[2277]: Interface "ppp0" enabled.
Jun 25 08:39:05 s-rras-1 CRON[5594]: (CRON) error (grandchild #5595 failed with exit status 1)
Jun 25 08:39:13 s-rras-1 radvd[5249]: Exiting, sigterm or sigint received.
Jun 25 08:39:13 s-rras-1 radvd[5249]: sending stop adverts
Jun 25 08:39:13 s-rras-1 radvd[5249]: removing /var/run/radvd.pid
Jun 25 08:39:23 s-rras-1 radvd[5741]: version 1.9.1 started
Jun 25 08:39:48 s-rras-1 pppd[29520]: Script /etc/ppp/ip-up finished (pid 5718), status = 0x0Sehr großes Fragezeichen. Und wie gesagt: Ist der PC und der Server an, bleibt die Verbindung stabil. Wir gehen in diesem Fall einmal davon aus, dass bei der Telekomseite alles in Ordnung ist.
Ein Bild der DSL Statistiken vom VDSL Modem ALL-500VDSL2 Rev. B
Achso. Es handelt sich um einen VDSL IP Anschluss (Annex J). Das Modem ist natürlich Annex J fähig.
Die Fehler waren früher natürlich nicht da, da die virtuelle Maschine des Routers nie alleine lief und alle anderen Maschinen immer mit aktiv waren. Ich weiß also nicht, ob das Problem auch früher aufgetreten wäre.
Meine Idee wäre noch, um mir den Raspberry PI anzusehen, meinen Laptop zu nehmen und diesen so wie den PI zu installieren. Das hätte den Vorteil, dass ich ein ausgereiftes 100% unterstütztes System (Ubuntu) für x86 Architektur testen kann. Da habe ich zwar keinen Bock drauf, muss aber wohl sein. Mal abwarten, was Ihr so meint.
ANHANG
/etc/ppp/peers/dsl-provider:
Code:
noipdefault
hide-password
lcp-echo-interval 20
lcp-echo-failure 8
connect /bin/true
noauth
persist
mtu 1492
noaccomp
default-asyncmap
plugin rp-pppoe.so eth0.7
user "..."/etc/ppp/options
Code:
asyncmap 0
crtscts
lock
hide-password
modem
passive
debug
lcp-echo-interval 30
lcp-echo-failure 8
noipx
maxfail 0
+ipv6 ipv6cp-use-ipaddr
persist
Zuletzt bearbeitet:
