Seit zwei Monaten fällt mein Internetanschluss mehrmals täglich aus. Ich kann dann keine Webseiten aufrufen und bestehende Verbindungen hängen sich auf. Es passiert immer häufiger. Nun starte ich den vierten Versuch, diese Zeiten zu erfassen um sie nachzuweisen. Aber immer wenn das Testprogramm läuft (egal welches) verschwindet das Problem wie von Geisterhand. Beende ich den Testlauf, kommt das Problem umgehend zurück. Auch ist mir aufgefallen, daß sämtliche Speed Test Webseiten IMMER ein perfektes oder fast perfektes Ergebnis melden. Ich habe das starke Gefühl, dass dort irgendeine Abschalteinrichtung aktiv wird, sobald ich teste. Kann das sein? Kennt jemand ein gutes Programm, dass ich wochenlang laufen lassen kann, um Ausfallzeiten zu erfassen? Die Übertragungsrate ist mir weniger wichtig.
Welcher Internetanschluss, (A/V)DSL? Was sagt die Fritzbox/der Router in diesem Moment? Ggf. mit dem Telefon als Video aufnehmen? Dann eben ein kleines Python- oder C-Programm (ESP8266?), dass gelegentlich eine Webseite abruft. Das müsstest Du doch schnell(?) realisieren können(?)
> Aber immer wenn das Testprogramm läuft (egal welches) verschwindet das > Problem wie von Geisterhand. Beende ich den Testlauf, kommt das Problem > umgehend zurück. > Kennt jemand ein gutes Programm, dass ich wochenlang laufen lassen kann, > um Ausfallzeiten zu erfassen? Die Übertragungsrate ist mir weniger > wichtig. DEIN Programm erfüllt offenbar den Zweck die Leitung und deine Verbindungen "voll da" zu halten. Also lasse es wochenlang durchrödeln. Profit$$$ Ev. nimmst ein Bandbreitemanagement vor: Dein Programm etwas drosseln zu Gunsten von Webbrowser, Email, etc.pp. Idealerweise dynamisch & automagisch.
TV Kabelanschluss. Die Fritzbox zeigt dazu nichts an Einen Logger mit WLAN würde niemand ernst nehmen. Ein Logfile von einer Ping Schleife ist schwierig auszuwerten und sagt micht viel aus solange nicht mehrere Server gleichzeitig angepingt werden. Abgesehen davon ist mein Hauptproblem ja, dass diese Ping Schleifen zu 99,99% fehlerfrei durch laufen und ich während dessen auch manuell ein einwandfreies Surf-Erlebnis habe. Doch sobald ich den Testlauf beende fängt der Internetzugang an zu stocken. Und zwar auf allem Geräten gleichzeitig: Smartphones und Konsolen der Kids, meine Playstation, mein Laptop, det Rechner meiner Frau und das WLAN Küchenradio. Dabei sind die Computwr und Konsolen verkabelt, nur das Küchenradio und die Smartphones nutzen WLAN.
Es muß nicht zwingend der Anschluss sein. Es ist ebenfalls möglich, das der Router, bzw. dessen Netzteil in den letzten Zügen liegt. Hatte ich beides bereits.
Dein Script/Programm müsste natürlich auch gelegentlich Webseiten abrufen und nicht ständig pingen. Was jemand ernst nimmt, das wird noch eine Frage sein. Ggf Raspberry direkt an Fritzbox-LAN-Anschluss?
Nun, dann schreib' Dir ein Programm, das das Verhalten des Testprogramms nachbildet (vielleicht etwas weniger bandbreitenfressend) und lass' das dauerhaft auf einem Deiner PCs laufen. Solange, bis Du Dir einen funktionierenden Internetanbieter ausgesucht hast, ist das vielleicht eine Lösung.
Den habe ich in den letzen 4 Monaten bereits 2x erneuert. Inzwischen auch mal mehr als 20 Euro dafür ausgegeben (Fritz Box).
Rufus Τ. F. schrieb: > Nun, dann schreib' Dir ein Programm, das das Verhalten des Testprogramms > nachbildet (vielleicht etwas weniger bandbreitenfressend) und lass' das > dauerhaft auf einem Deiner PCs laufen. Soll ich mein bash Einzeiler posten, der im konfigurierbaren & zufallsvariablen Zeitabstand ein zufällig gewürfelter uC.net-Thread abruft?
Stefan U. schrieb: > Rufus, meinst du das ernst? Was denn sonst? Wenn Dein ISP ein Drecksprovider ist, der das beschriebene Verhalten aufweist, was soll man mit dem sonst machen, als sich von ihm zu trennen?
könnte auch ein Problem auf höherer ebene sein. DNS vielleicht? die speedtests laufen dann per IP und nicht per hostname und das problem ist nicht aufspürbar.
Simon S. schrieb: > DNS vielleicht? Wäre auch mein erster Versuch. DNS auf der Fritzbox auf openDNS oder googleDNS wechseln. Muss man nicht mögen, taugt aber ggf.für einen Test.
Stefan U. schrieb: > Doch sobald ich den Testlauf beende fängt der Internetzugang an zu > stocken. Und zwar auf allem Geräten gleichzeitig: Smartphones und > Konsolen der Kids, meine Playstation, mein Laptop, det Rechner meiner > Frau und das WLAN Küchenradio. Das passt nicht zu DNS-Problemen. DNS-Anfragen gibt's beim Verbindungsaufbau, danach aber nicht mehr (wozu auch, die Adresse ist ja bekannt). Natürlich kann man probeweise einen anderen Nameserver im Router eintragen (oder den jeweiligen PC einen anderen verwenden lassen), für derartige Experimente eignet sich der böse Google-Server mit der Adresse 8.8.8.8.
Was für einen Router hast du eigentlich? Eine Fritzbox las ich oben, am Kabelanschluß, also eine 6490? Wieviel Zeit vergeht von einem Reboot deines Kabelmodems bis der Fehler auftritt?
Stefan U. schrieb: > Aber immer wenn das Testprogramm läuft (egal welches) verschwindet das > Problem wie von Geisterhand. Beende ich den Testlauf, kommt das Problem > umgehend zurück. Könnte auf das löschen eines Cache-Eintrages nach einer bestimmten Inaktivitätszeit hindeuten. ARP-Cache bei Routern oder auch MAC-Adress-Tabellen von Switches sind oft gesehene Kandidaten. Wenn Du von Deiner Seite aus die Verbindung "aktiv" halten kannst, dann versuche es doch mal mit einem "dauerping" vom Internet aus. Eventuell fällt der ja irgendwann zusammen...
Das funktioniert:
1 | #!/bin/sh
|
2 | |
3 | echo "monitoring $1 ..." |
4 | |
5 | while true; do |
6 | while true; do |
7 | wget -O - $1 > /dev/null 2>&1 |
8 | if [ $? -ne 0 ]; then |
9 | echo "$1 went down at `date -R`" |
10 | break
|
11 | fi |
12 | sleep 1 |
13 | done
|
14 | |
15 | while true; do |
16 | wget -O - $1 > /dev/null 2>&1 |
17 | if [ $? -eq 0 ]; then |
18 | echo "$1 went up at `date -R`" |
19 | break
|
20 | fi |
21 | sleep 1 |
22 | done
|
23 | done
|
Ausgabe:
1 | $ ./monitorconnection.sh www.mikrocontroller.net |
2 | monitoring www.mikrocontroller.net ... |
<Netzwerkkabel abgezogen>
1 | www.mikrocontroller.net went down at Mon, 05 Feb 2018 23:07:45 +0100 |
<Netzwerkkabel wieder eingesteckt>
1 | www.mikrocontroller.net went up at Mon, 05 Feb 2018 23:07:56 +0100 |
2 | ^C |
Stefan U. schrieb: > Ich habe das starke Gefühl, dass dort irgendeine Abschalteinrichtung > aktiv wird, sobald ich teste. Kann das sein? Dynamische Bandbreite wäre vorstellbar, also temporär hochgefahrene Bandbreiten-Priorität bei Testseite(n). Habe ich beim Mobilfunk erleben können. Aber den Kunden vorsätzlich dynamisch abzuschalten? Bei DSlite solltest du evtl. mal checken, ob nur IPv4 ausfällt, IPv6 aber weiterhin funktioniert.
:
Bearbeitet durch User
Hallo, TV-Kabel ist Docsys. Docsys weist die verfügbaren Kanäle generell dynamisch zu, wenn der Traffik es erfordert. meine 64MBit sind recht stabile 60-62MBit wenn ein großer download läuft. Gestartet wird aber meist irgendwo bei 2-3MBit wenn vorhaer nichts los war und es dauert etliche Sekunden, bis die 60MBit dann erreicht werden. Allerdings fürht das normalerweise nicht zu einem echten Ausfall. Abbrüche waren bei mir bisher immer Routingprobleme meines Kabelanbietern. Da hatte Google oder Heise plötzlich Paketverluste und Ping-Laufzeiten im Sekundenbereich... Gruß aus Berlin Michael
> Soll ich mein bash Einzeiler posten Danke nicht nötig. Ich habe mir inzwischen ein kleines Cygwin Script geschrieben, dass drei Server regelmäßig anpingt und das Ergebnis dokumentiert. Siehe Anhang. Vielleicht besorge ich mir wirklich einen Raspbery, damit das rund um die Uhr nebenbei laufen kann, um "Beweismittel" zu sammeln. > Was für einen Router hast du eigentlich? Modell 4020 an einem Motorla Kabel-Modem > Wieviel Zeit vergeht von einem Reboot deines Kabelmodems > bis der Fehler auftritt? Darauf habe ich noch nicht geachtet. Ich schalte die Geräte jede Nacht aus. Also kann ich schon einmal sagen, dass der Fehler nach weniger als 24 Stunden auftritt. Warum fragst du danach? Frage zu DNS: Hängt der Ping Befehl vom DNS Server ab? Der Vorschlag mit dem wget kommt meinem Wifi Monitor nahe. Das ist ein kleines Kästchen mit ESP8266 und Ampel-Anzeige. Es testet die Erreichbarkeit meiner Homepage (bei Hosteurope) und zeigt an: - grün = Connect dauerte weniger als 100ms - blau = Connect dauerte 100ms bis 10s - rot = Connect timeout (>10s) - aus = Keine Verbindung zum AP (Fritz Box) Immer wenn der Internet Zugang hängt, sehe ich blaues Licht. Das Ding läuft schon seit viele Monaten zuverlässig, aber zunehmend oft mit blauem Licht. > Bei DSlite solltest du evtl. mal checken, ob nur IPv4 ausfällt, > IPv6 aber weiterhin funktioniert Mein Anschluss hat nur IPv4. Im Angehängten Log Auszug seht ihr so einen Ausfall um 28:28:07 Uhr. Ein Ping war sehr langsam und einer hatte sogar einen Timeout (>1000ms). Das passiert mittlerweile mehrmals pro Stunde. Aber jetzt wo der Test läuft natürlich wieder nicht -> Vorführeffekt.
> > Im Angehängten Log Auszug seht ihr so einen Ausfall um 28:28:07 Uhr. Also nur freitags...
>> Im Angehängten Log Auszug seht ihr so einen Ausfall um 28:28:07 Uhr. > Also nur freitags... Haha Ich meinte natürlich 18:28:07 Gerade war wieder ein Aussetzer:
1 | Unitymedia Stefanfrings Google |
2 | 06.02.2018 19:00:42 13ms 17ms 15ms |
3 | 06.02.2018 19:00:53 13ms 18ms 15ms |
4 | 06.02.2018 19:01:03 12ms 18ms 15ms |
5 | 06.02.2018 19:01:13 12ms 18ms 14ms |
6 | 06.02.2018 19:01:24 14ms 19ms 14ms |
7 | 06.02.2018 19:01:36 84ms |
8 | 06.02.2018 19:01:48 20ms |
9 | 06.02.2018 19:02:00 17ms |
10 | 06.02.2018 19:02:11 27ms 17ms |
11 | 06.02.2018 19:02:22 9ms 27ms 22ms |
12 | 06.02.2018 19:02:33 29ms 15ms |
13 | 06.02.2018 19:02:44 53ms 24ms |
14 | 06.02.2018 19:02:55 12ms 17ms 13ms |
15 | 06.02.2018 19:03:05 12ms 17ms 13ms |
16 | 06.02.2018 19:03:16 12ms 20ms 13ms |
17 | 06.02.2018 19:03:26 12ms 17ms 15ms |
Stefan U. schrieb: > Frage zu DNS: Hängt der Ping Befehl vom DNS Server ab? Nur wenn als Argument ein Name und keine IP-Adresse angegeben wurde, und dann auch nur einmal. Üblicherweise landen DNS-Abfragen in einem vom OS verwalteten Cache, so daß selbst mehrfache Anfragen der gleichen Adresse nur einen tatsächlichen Zugriff auf den Nameserver zur Folge haben. Die Adresse wird nach Ablauf ihrer Gültigkeit aus dem Cache gelöscht; die Gültigkeitsdauer (TTL = time to live) wird vom Nameserver mitgeteilt. Adressen, die z.B. für DynDNS-Dienste verwendet werden, haben naturgemäß eine ziemlich kurze Gültigkeitsdauer. Der DNS-Cache kann auch manuell gelöscht werden, diese geschieht unter Windows mit ipconfig -flushdns bzw. einem Neustart des ncds Daemons unter Linux.
> Danke nicht nötig. Ich habe mir inzwischen ein kleines Cygwin Script > geschrieben, dass drei Server regelmäßig anpingt und das Ergebnis > dokumentiert. Siehe Anhang. > Frage zu DNS: Hängt der Ping Befehl vom DNS Server ab? Genau genommen ping selbst nicht, ist im übrigen weder TCP noch UDP sondern ICMP Damit also klar anderen Traffic als normaler Datenverkehr (Websurfen, mailen, ...) DNS wird vor dem eigentlichen ping Protokoll verwendet, um die textuelle Zieladresse z.B. "stefanfrings.de" in eine numerische IP Adresse aufzulösen.
Ich hab mal nach Problemen IPv6 deaktiviert, dann ging es wieder einwandfrei.
Peter D. schrieb: > Ich hab mal nach Problemen IPv6 deaktiviert, dann ging es wieder > einwandfrei. Da hier gar kein IPv6 vorhanden sein soll, wird es schwierig, das zu deaktivieren.
Lerne auch noch traceroute Ergänze dein Script noch um die innere und die aussere (*) IP Adresse deines Routers. Dies um auch in den Blick zu bekommen ob zumindest die Geräte bei dir richtig funktionieren. (* wird wohl dynamisch sein, also bei jedem Modem/Router Reset/Neustart anders: es gilt ein Kniff zu finden um diese zu ermitteln...) --- Tip:
1 | date --iso=s |
ist kürzer & schneller geschrieben als der Formatsermon. Harmoniert auch einfacher mit sort
Fritz Box und Modem sind immer erreichbar, das weiß ich bereits mit Sicherheit. Ich habe meine eigene öffentliche IP-Adresse und die des Gateways hinzugefügt. Mal sehen, ob das neue Erkenntnisse bringt.
Rufus Τ. F. schrieb: > Da hier gar kein IPv6 vorhanden sein soll, wird es schwierig, das zu > deaktivieren. Ich meinte in den Netzwerkadaptereinstellungen der Geräte (W10-PC). Warum IPv6 plötzlich Probleme machte, habe ich nicht weiter untersucht. Ich vermute mal, ein Providerproblem (Telekom), da nicht alle Webseiten betroffen waren. Wenigstens konnte mich Google noch zu einer Hilfeseite lotsen, wo der Tip mit der IPv6-Abschaltung stand.
> Ich meinte in den Netzwerkadaptereinstellungen der Geräte (W10-PC)
Bei mir nicht nur Windows PC betroffen, sondern auch Spielkonsolen und
Smartphones (gleichzeitig).
Local Area Notwork schrieb: > (* wird wohl dynamisch sein, also bei jedem Modem/Router Reset/Neustart > anders: es gilt ein Kniff zu finden um diese zu ermitteln...) Im Kabel sind wechselnde IPs seit jeher unüblich.
> Im Kabel sind wechselnde IPs seit jeher unüblich.
Das werde ich spätestens morgen merken
Ich habe mir gerade einen Raspberry Pi bestellt. Weiß jemand zufällig, ob es dem Gerät (bzw. der SD Karte in der Standard Konfiguration) schadet, wenn man Abends einfach die Stromzufuhr unterbricht?
A. K. schrieb: > Local Area Notwork schrieb: >> (* wird wohl dynamisch sein, also bei jedem Modem/Router Reset/Neustart >> anders: es gilt ein Kniff zu finden um diese zu ermitteln...) > > Im Kabel sind wechselnde IPs seit jeher unüblich. Mein Kabelanschluss ist jetzt schon über ein Jahrzehnt her (damals, mit WinME :), aber halten die IPs da wirklich auch über einen Neustart hinweg? Kanns nicht mehr genau sagen.
Stefan U. schrieb: >> Was für einen Router hast du eigentlich? > Modell 4020 an einem Motorla Kabel-Modem Was passiert, wenn du einen anderen Router oder gar den Computer direkt ans Modem hängst?
Reinhard S. schrieb: > Mein Kabelanschluss ist jetzt schon über ein Jahrzehnt her (damals, mit > WinME :), aber halten die IPs da wirklich auch über einen Neustart > hinweg? Kanns nicht mehr genau sagen. Technisch gesehen wird dabei gewöhnliches DHCP verwendet. So lange die Lease des DHCP-Servers bestehen bleibt, kriegt man also immer die gleiche Adresse.
:
Bearbeitet durch User
Reinhard S. schrieb: > Was passiert, wenn du einen anderen Router oder gar den Computer direkt > ans Modem hängst? Dann gibts eine andere IP-Adresse.
Es könnte ein banales Kabelmodem-Problem dahinter stecken ich hatte hiervor 2-3 Jahren etwas ähnliches mit DSL-Modem diese verlor immer wieder. Die PLL Synchronisation des Carriers rastete regelmäßig aus, eskalierend. Das war nur durch Neustart des Modems zu fixen. Ich bekam dann als Bussines-Kunde einen neuen Routermit internem Modem. Das besserte die Situation, aber endgültig gelöst wurde es als der OVK auf Glasfaser umgestellt wurde. Allerdings bekomme ich keinen Zugang zu den Routerdaten, weshalb ich darauf bestanden habe diesen transparent zu stellen und Fernwartung und WLAN zu deaktivieren. Meinen dahinter liegenden eigenen Router verwalte ich selbst und nutze den A1-Router nur als WAN-Gate. Namaste
> Was passiert, wenn du einen anderen Router oder gar den Computer > direkt ans Modem hängst? Das hatte ich im Dezember mal ausprobiert - läuft nicht besser.
Startet irgend ein Client einen großen Download? Nachdem die Server immer schneller wurden kam es bei meinem 16er DSL immer häufiger dazu das große Downloads (Windows und Spiele Updates, Softwareinstaller) die komplette Bandbreite belegten und an anderen Geräten absolut nichts mehr ging, nichtmal DNS-Auflösung. Geholfen hat nur ein Upgrade auf 50er DSL.
Edit Es könnte ein banales Kabelmodem-Problem dahinter stecken ich hatte hiervor 2-3 Jahren etwas ähnliches mit DSL-Modem. Dieses verlor immer wieder die PLL Synchronisation des Carriers und rastete regelmäßig aus, eskalierend. ... Namaste
:
Bearbeitet durch User
Reinhard S. schrieb: > Was passiert, wenn du einen anderen Router oder gar den Computer direkt > ans Modem hängst? An der Stelle sollte man nur basteln, wenn man nicht dringend aufs Netz angewiesen ist. Bei einem Business(!)-Kabelanschluss mit reinem Modem am Anschluss habe ich die im Business-Kontext doch etwas irritierende Erfahrung gemacht, dass öfter wechselnde Geräte bis zum nächsten Tag geblockt werden.
Winfried J. schrieb: > Es könnte ein banales Kabelmodem-Problem dahinter stecken ich hatte > hiervor 2-3 Jahren etwas ähnliches mit DSL-Modem. Dieses verlor immer > wieder die PLL Synchronisation des Carriers und rastete regelmäßig aus, > eskalierend. ... Bring das mal mit dem "Vorführeffekt" in Einklang. ;-) Müsste man beim Modem eigentlich sehen. Im Webzugang, so vorhanden, oder ganz banal an den LEDs.
:
Bearbeitet durch User
Stefan U. schrieb: > Weiß jemand zufällig, ob es dem Gerät (bzw. der SD Karte in der Standard > Konfiguration) schadet, wenn man Abends einfach die Stromzufuhr > unterbricht? Es gibt sicherlich eine Möglichkeit, den RasPi mit readonly Filesystem zu betreiben. Dann ist es risikolos.
A. K. schrieb: > Bring das mal mit dem "Vorführeffekt" in Einklang. ;-) du das war bei mir ähnlich, das Aufhängen geschah immer in Inaktivitätsphasen nie solange alle paar min Traffic lief. Aber Zum mittag in die Küche wiederkommen, --> Neustart Modem. Namaste
A. K. schrieb: > Es gibt sicherlich eine Möglichkeit, den RasPi mit readonly Filesystem > zu betreiben. Dann ist es risikolos. und das logfile? Namaste
Winfried J. schrieb: > und das logfile? Landet im RAM. In Linux verwendet man häufig "RAM-Disks" für Filesysteme, die nicht persistent sein müssen (Typ tmpfs).
ich meinte das wolle er sichern? Namaste
Winfried J. schrieb: > und das logfile? Ich hatte mal mit einer Server-Reihe zu tun, deren Netzteile nach vielen vielen Jahren serienweise schwache Spannung auf 5V lieferten. Da die 5V nur im I/O-System genutzt wurden, führte das zu gelegentlichen I/O-Fehlern und einem Linux, das sicherheitshalber automatisch auf r/o umschwenkte. Die Kisten haben seelenruhig weitergearbeitet und schön brav alle Überwachungsanfragen positiv quittiert. Erst wenn man sich drauf einloggte und zu schreiben versuchte, wurde es deutlich.
Winfried J. schrieb: > ich meinte das wolle er sichern? Würde ich in dem Fall auf ein separates Medium, z.B. einen USB-Stick, der als einziges Filesystem r/w gemountet ist. Weniger Risiko fürs Bootmedium. Hart ausschalten geht zwar meistens gut, aber mit der Häufigkeit steigt eben die Wahrscheinlichkeit, dass man doch mal ein Problem kriegt.
Gerade gab es wieder einen Aussetzer:
1 | Unitymedia StefanFrings Google Gateway MyPublic IP |
2 | 06.02.2018 21:16:39 11ms 17ms 13ms 7ms 1ms |
3 | 06.02.2018 21:16:49 12ms 17ms 14ms 7ms 1ms |
4 | 06.02.2018 21:17:00 11ms 17ms 14ms 8ms 1ms |
5 | 06.02.2018 21:17:10 12ms 16ms 14ms 7ms 1ms |
6 | 06.02.2018 21:17:21 11ms 17ms 14ms 8ms 1ms |
7 | 06.02.2018 21:17:32 11ms 18ms 14ms 8ms 1ms |
8 | 06.02.2018 21:17:42 13ms 18ms 16ms 7ms 1ms |
9 | 06.02.2018 21:17:53 12ms 18ms 14ms 9ms 1ms |
10 | 06.02.2018 21:18:06 17ms 1ms |
11 | 06.02.2018 21:18:18 17ms 14ms 1ms |
12 | 06.02.2018 21:18:32 1ms |
13 | 06.02.2018 21:18:43 12ms 18ms 7ms 1ms |
14 | 06.02.2018 21:18:54 12ms 18ms 13ms 8ms 1ms |
15 | 06.02.2018 21:19:05 12ms 17ms 14ms 7ms 1ms |
16 | 06.02.2018 21:19:15 22ms 17ms 13ms 17ms 1ms |
17 | 06.02.2018 21:19:26 13ms 17ms 24ms 9ms 2ms |
18 | 06.02.2018 21:19:36 11ms 17ms 13ms 8ms 1ms |
19 | 06.02.2018 21:19:47 12ms 19ms 14ms 7ms 1ms |
Ich finde hier auffällig, dass meine eigene öffentliche IP Adresse durchgängig erreichbar war. Mal sehen, ob sie das Szenario so wiederholt. > Bring das mal mit dem "Vorführeffekt" in Einklang. Der kann auch Einbildung sein. Wenn man auf ein relativ seltenes Ereignis (die Störung), kommt einem (also mir) die Zeit besonders lang vor. Deswegen denke ich, dass die Erstellung dieses Protokolls besser ist, als gefühlte Häufigkeiten zu melden. > Es gibt sicherlich eine Möglichkeit, den RasPi mit > readonly Filesystem zu betreiben. Aber das Logfile soll er schon schreiben. Ich könnte allerdings damit leben, wenn beim Abschalten ein paar Sekunden vom Protokoll verloren gehen. >> und das logfile? > Landet im RAM. Das ist doch nicht Sinn der Sache. Ich will ein Langzeit-Protokoll erstellen, um es Unitymedia vorzulegen. Was nützt mir eine RAM Disk, wenn die abends verworfen wird, wenn meine Frau oder Kinder den Internet Anschluss (samt Raspberry Pi) wie gewohnt an der Steckdosenleiste abschalten?
Stefan U. schrieb: > Das ist doch nicht Sinn der Sache. Ich hatte das zunächst auf die üblichen Verdächtigen in Linux bezogen: Auf Logfiles à la /var/log. Das Logfile deiner Überwachung geht so natürlich nicht, aber - wie gesagt - das kann ja woanders hin. Anderes Filesystem auf der µSD ist übrigens keine Lösung. Aufgrund der Arbeitsweise von Flash-Medien sind Filesysteme nicht so gut entkoppelt, wie man das gerne hätte.
:
Bearbeitet durch User
> Startet irgend ein Client einen großen Download? Nein. Die Aussetzer treten sowohl bei hoher Auslastung als auch bei geringer Auslastung auf. Von den maximal möglichen 64Mbit (die ich bei Tests auch fast immer erreiche) nutzen wir nur selten mehr als 10Mbit. > Das Logfile deiner Überwachung ... kann ja woanders hin. Ähh, nein. Das muss schon der Raspberry Pi auf seine SD Karte speichern, dafür habe ich ihn ja gekauft.
Stefan U. schrieb: > Ähh, nein. Das muss schon der Raspberry Pi auf seine SD Karte speichern, > dafür habe ich ihn ja gekauft. Du weisst was ein USB-Stick ist? Je nun, du hattest gefragt. Pack das File auf die µSD, schalte täglich hart ab, und berichte. Wahrscheinlich gehts. Aber vielleicht irgendwann...
:
Bearbeitet durch User
> Du weisst was ein USB-Stick ist?
Gewinne ich damit irgend etwas, im Vergleich zur SD Karte? Wenn der
Rechner beim Stromausfall die SD Karte schrottet, dann dürfte der USB
Stick ebenso gefährdet sein, oder nicht?
Notfalls lasse ich ihn einfach 24h durch laufen. Nur habe ich dann
leider auch die gewollten "Ausfallzeiten" mit im Logfile, wenn wir
Nachts den Internetanschluss abschalten. Obwohl ... ich kann das
vielleicht im Script abfangen. Nur protokollieren, wenn der AP
erreichbar ist, oder so.
Stefan U. schrieb: > Ich finde hier auffällig, dass meine eigene öffentliche IP Adresse > durchgängig erreichbar war. Das kann direkt von Deinem Router kommen, das würde ich nicht überbewerten.
Stefan U. schrieb: > Gewinne ich damit irgend etwas, im Vergleich zur SD Karte? Stimmt eigentlich. In dem Fall macht es nichts aus, im Falle eines Falles die µSD vom RasPi komplett neu zu erzeugen, ohne vom vorherigen Inhalt etwas zu benötigen.
Stefan U. schrieb: > Nur habe ich dann > leider auch die gewollten "Ausfallzeiten" mit im Logfile, wenn wir > Nachts den Internetanschluss abschalten. Obwohl ... ich kann das > vielleicht im Script abfangen. Nur protokollieren, wenn der AP > erreichbar ist, oder so. Wenn Du Dir von dem Log einen Wert erhoffst, so würde ich nach Möglichkeit den Internetzugang nicht abschalten.
:
Bearbeitet durch User
Rufus Τ. F. schrieb: > Das kann direkt von Deinem Router kommen, das würde ich nicht > überbewerten. s/kann/wird/, bei echtem IPv4. Das Problem liegt recht wahrscheinlich im Kabelanschluss oder jenseits davon, nicht auf der inneren Seite vom Modem.
:
Bearbeitet durch User
Das Szenario hat sich wiederholt. Wieder war sogar das Gateway zeitweise nicht erreichbar, meine eigene IP aber schon
1 | Unitymedia StefanFrings Google Gateway MyPublicIp |
2 | 06.02.2018 22:04:54 11ms 17ms 14ms 6ms 1ms |
3 | 06.02.2018 22:05:04 12ms 17ms 13ms 18ms 1ms |
4 | 06.02.2018 22:05:15 13ms 18ms 14ms 9ms 2ms |
5 | 06.02.2018 22:05:25 12ms 17ms 13ms 7ms 1ms |
6 | 06.02.2018 22:05:36 13ms 17ms 15ms 18ms 2ms |
7 | 06.02.2018 22:05:47 11ms 20ms 14ms 7ms 1ms |
8 | 06.02.2018 22:05:59 14ms 13ms 1ms |
9 | 06.02.2018 22:06:12 11ms 17ms 1ms |
10 | 06.02.2018 22:06:23 27ms 13ms 7ms 1ms |
11 | 06.02.2018 22:06:35 35ms 18ms 2ms |
12 | 06.02.2018 22:06:47 33ms 9ms 1ms |
13 | 06.02.2018 22:07:00 12ms 38ms 1ms |
14 | 06.02.2018 22:07:11 17ms 13ms 7ms 1ms |
15 | 06.02.2018 22:07:22 29ms 17ms 13ms 8ms 1ms |
16 | 06.02.2018 22:07:32 12ms 18ms 13ms 8ms 1ms |
17 | 06.02.2018 22:07:43 12ms 16ms 13ms 7ms 2ms |
18 | 06.02.2018 22:07:54 13ms 17ms 13ms 6ms 1ms |
19 | 06.02.2018 22:08:04 13ms 17ms 13ms 7ms 1ms |
20 | 06.02.2018 22:08:15 17ms 18ms 14ms 9ms 2ms |
21 | 06.02.2018 22:08:26 14ms 17ms 14ms 8ms 2ms |
22 | 06.02.2018 22:08:36 13ms 18ms 14ms 9ms 2ms |
23 | 06.02.2018 22:08:47 12ms 29ms 13ms 8ms 2ms |
Was meint ihr, stelle ich mich empfindlich an, oder kann man sagen, das 1-2 solcher Ausfälle pro Stunde inakzeptabel sind?
Stefan U. schrieb: > Was meint ihr, stelle ich mich empfindlich an, oder kann man sagen, das > 1-2 solcher Ausfälle pro Stunde inakzeptabel sind? Nachrechnen. In den AGB von Kabel-BW stand ehedem: "Die mittlere Verfügbarkeit des Kabelanschlusses und der TV Produkte liegt im Jahresdurchschnitt bei mindestens 97,5 %."
A. K. schrieb: > Nachrechnen. In den AGB von Kabel-BW stand ehedem: "Die mittlere > Verfügbarkeit des Kabelanschlusses und der TV Produkte liegt im > Jahresdurchschnitt bei mindestens 97,5 %." Das heißt der darf 9 komplette Tage im Jahr ausfallen. Selbst 99,9% sind noch 8 h 47 min und als Privatkunde wirst du so einen Vertrag weder bekommen noch bezahlen wollen.
Stefan U. schrieb: > Was meint ihr, stelle ich mich empfindlich an, oder kann man sagen, das > 1-2 solcher Ausfälle pro Stunde inakzeptabel sind? Dafür würde ich nicht die vertraglich zugesicherte Verfügbarkeit zu Grunde legen, sondern die Erfahrungen anderer. Wärest Du der einzige mit dem Phänomen, so fände ich das an Deiner Stelle keinesfalls akzeptabel. Dh, vergleichen mit anderen Kunden und anderen Anbietern.
A. K. schrieb: > Stefan U. schrieb: >> Was meint ihr, stelle ich mich empfindlich an, oder kann man sagen, das >> 1-2 solcher Ausfälle pro Stunde inakzeptabel sind? > > Nachrechnen. In den AGB von Kabel-BW stand ehedem: "Die mittlere > Verfügbarkeit des Kabelanschlusses und der TV Produkte liegt im > Jahresdurchschnitt bei mindestens 97,5 %." "Welcome to the World of Packet Switched Networks" (e.g. TCP/IP) ließ "da bleibt mal ab und an ein Krümmel auf der Strecke". Die Zeit der "Circuit Switched Networks" (leitungsgebundene Dienste) welche konzeptbedingt "verlustfrei" sind, wurde leider abgeschafft. Grund: man wollte das nicht mehr bezahlen... BTDT.
> Das Problem liegt recht wahrscheinlich im > Kabelanschluss oder jenseits davon, nicht auf der inneren Seite vom > Modem. Bei "shared media" (alle Teilnehmer auf dermselben Kabel) muss es nichtmal böse Absicht oder "rogue participant" sein: eine kleine Imperfektion an beliebiger Stelle wirkt sich da weitreichend aus. Ich sehe Parallelen zu den damaligen Thick- & Thinwire Ethernetverkabelungen (Coaxkabel , BNC Verbinder, Vampire taps, 10Mbit zum teilen für ganze Stockwerke!). Bei frischer Installation der Kabel und Anschlussdosen funktionierte es; mit der Zeit schlichen sich "ausnudelungen" aller Arten ein und der Durchsatz degradierte allmählich auf unbrauchbar zu... (solange ich mir die Wahl leisten kann, nehme ich freiwillig keine CaTV-Netzwerkanbindung...)
Damit ein RasPI hart abschaltbar ist braucht es SD Karte und USB Stick. Auf der SD Karte ist nur die FAT32 Bootpartition drauf. In der cmdline.txt wird dann der USB Stick als Bootmedium angegeben. Auf dem USB Stick ist dann das rootFS drauf. So ein USB Stick hat noch ein paar mehr KOndensatoren wie eine SD Karte und somit kann der letzte Schreibvorgang noch abgeschlossen werden. Funktioniert so bestens bei der 150W LED Uhr mit RasPI, da wird nur hart per Netzschalter abgeschalten seid 3? Jahren. Wobei ich mal gehört habe, dass die neuen rasPIs nicht mehr so die SD Karte fressen bei Stromausfall?
Local Area Notwork schrieb: > "Welcome to the World of Packet Switched Networks" (e.g. TCP/IP) ließ > "da bleibt mal ab und an ein Krümmel auf der Strecke". Krümmel wurde glücklicherweise bereits vor Jahren abgeschaltet.
Lars R. schrieb: > Stefan U. schrieb: >> Was meint ihr, stelle ich mich empfindlich an, oder kann man sagen, das >> 1-2 solcher Ausfälle pro Stunde inakzeptabel sind? > > Dafür würde ich nicht die vertraglich zugesicherte Verfügbarkeit zu > Grunde legen, sondern die Erfahrungen anderer. Klar. Ich wäre darüber auch nicht glücklich, mein Kabelabschluss funktioniert recht ordentlich. Ich hatte gelegentlich DNS Probleme, weshalb ich dazu überging, das zwecks Umgehung des CGNAT möglichst per IPv6 abzuwickeln, aber darum geht es hier ja nicht. Aber so lange man im per AGB zulässigen Bereich bleibt, sitzen die am längeren Hebel, weshalb man beim Support freundlich bleiben sollte.
:
Bearbeitet durch User
Hallo Stefan, ich möchte mal zurück auf den DSLITe kommen. Hast Du einen oder nicht ? Unitymedia hat nach meiner Information IPV6 und leitet IPV4 über einen Proxy, der bei Bedarf eine beliebige IP für den Zugriff nutzt. Diese IP siehst Du aber nicht in Deinem Router bzw. Kabelmodem. In diesem Fall wäre es evtl. sinnvoll, alle lokalen Geräte auf IPV6 umzustellen. Bei W10 ist das normalerweise der Fall und selbst mein RPI-Cluster ist komplett IPV6-fähig out of the box. Gruß, Michael
Michael A. schrieb: > Hallo Stefan, > > ich möchte mal zurück auf den DSLITe kommen. Hast Du einen oder nicht ? Laut Stefan hat er nur IPv4.
Hallo, möglicherweise nicht, wenn er bei Unitymedia ist. Er denkt, dass es IPV4 ist, weil sein lokales Netz so gestrickt ist. Aber das Modem tunnelt alle IPV4 Verbindungen über IPV6 zu einem Proxy. Bei mir war das (allerdings mit Kabel Deutschland) auch so. Gruß, Michael
> ich möchte mal zurück auf den DSLITe kommen. Hast Du einen oder nicht ? Habe ich nicht, nur IPv4. Das liegt vielleicht daran, dass mein Vertrag über 10 Jahre alt ist und lediglich die Bitrate zweimal erhöht wurde. Deswegen habe ich auch ein Modem bekommen, keinen Router. Die Fritz-Box gehört mir. Ich habe einen 1-Play Anschluss, den gibt es gar nicht mehr. > Er denkt, dass es IPV4 ist, weil sein lokales Netz so gestrickt ist. Ich denke das, weil die Fritz Box es so anzeigt und in der Anleitung des Motorola Modems ipv6 nicht erwähnt wird.
Hallo Stefan, dann könnte es z. B. auch so sein, dass Du mit Deinem alten Anschluss irgendwie in die Unitymedia-Architektur implantiert bist und alle bekannten Standards nicht anwendbar sind. Bei mir hat's 4 Wochen gebraucht, bis Vodafone mich auf ne vollwertige IPV4 zusätzlich zur IPV6 umgestellt hat. Bis dahin hatte ich täglich mehrmals Resets der Fritzbox, danach stabile Verbindung über Monate. Viel Glück und Geduld, Michael
Michael A. schrieb: > Bei mir hat's 4 Wochen gebraucht, bis Vodafone mich auf ne vollwertige > IPV4 zusätzlich zur IPV6 umgestellt hat. Bis dahin hatte ich täglich > mehrmals Resets der Fritzbox, danach stabile Verbindung über Monate. Wie hasten das geschafft? Vor 3 Jahren hatte ich erst nur IPv4, dann wurde auf DSlite umgestellt (halbes Internet kaputt) und nachm bösen Anruf hammses wieder auf IPv4 only gestellt.
Der Vorführeffekt ist weg. Mein Ping Script dokumentiert jeden Ausfall, den wir auch manuell bemerken. Wenn der Raspi da ist, lasse ich das mal eine Woche lang 24h durch laufen und schicke es Unitymedia.
Stefan U. schrieb: > Der Vorführeffekt ist weg. Das bedeutet, daß jetzt der Download-Speed-Test nicht mehr ohne Probleme läuft?
@Stefan: Schon mal angerufen hast Du aber? Was haben die gesagt?
>> Der Vorführeffekt ist weg. > Das bedeutet, daß jetzt der Download-Speed-Test nicht mehr > ohne Probleme läuft? Der Ping Test zeigt die Aussetzer immer Zeitgleich, wenn wir auch in anderen Anwendungen Hänger bemerken. Er eignet sich also, die Zeiten zu dokumentieren. Ich habe nach gestern Abend keinen Speed Test mehr durchgeführt, da die Geschwindigkeit (abgesehen von den kurzzeitigen Totalausfällen) zufriedenstellen ist.
Mw E. schrieb: > Michael A. schrieb: >> Bei mir hat's 4 Wochen gebraucht, bis Vodafone mich auf ne vollwertige >> IPV4 zusätzlich zur IPV6 umgestellt hat. Bis dahin hatte ich täglich >> mehrmals Resets der Fritzbox, danach stabile Verbindung über Monate. > > Wie hasten das geschafft? Bei mir ging vpn nach dem Wechsel auf Kabel/VF nicht mehr, ist manchmal für mich beruflich sinnvoll. Und MyFritz ging auch nicht mehr. Irgendwann habe ich mich dann in das Thema eingelesen, bis klar war, dass vpn eine während einer VPN-Sitzung konstante IPV4 benötigt. Vodafone hat erstmal alle auf IPV6 und den IPV4-Proxy umgestellt, als die IPV4-Adressen von VF knapp wurden. Bei Bedarf und auf erheblichen und wiederholten Druck erhalten Kunden dann den vollen Dual Stack und damit zusätzlich zur V6 eine V4-dynamische Adresse. Wobei mein seit Monaten dynamisch die gleiche ist ;-) Jetzt habe ich intern und extern beides. Wegen der Prio auf V6 unterhalten sich die Hosts in meinem Netz vorzugsweise mit V6. Und die FB 6490 ist auch zufrieden damit. Gruß, Michael
Michael A. schrieb: > Bei Bedarf und auf erheblichen > und wiederholten Druck erhalten Kunden dann den vollen Dual Stack und > damit zusätzlich zur V6 eine V4-dynamische Adresse. Das klappt bei Unitymedia m.W. nicht. Für statische IPs gibts den Business-Anschluss. Und auch da sind sie mit Adressen so knapp, dass sie die einzeln vertickern. > Bei mir ging vpn nach dem Wechsel auf Kabel/VF nicht mehr, ist manchmal > für mich beruflich sinnvoll. Und MyFritz ging auch nicht mehr. > Irgendwann habe ich mich dann in das Thema eingelesen, bis klar war, > dass vpn eine während einer VPN-Sitzung konstante IPV4 benötigt. Innerhalb der Sitzung wechselnde IPv4-Adressen habe ich nicht erlebt, aber die Adresse funktioniert nicht eingehend, weshalb allenfalls VPNs funktionieren, die von dem Kabelanschluss ausgehend aufgebaut werden. Zudem läuft die VPN über NAT, was auch nicht jede VPN-Technik verkraftet. Eingehende VPNs funktionieren nicht. > und den IPV4-Proxy umgestellt, Recht übersichtliche Erklärung: https://www.elektronik-kompendium.de/sites/net/2010211.htm
:
Bearbeitet durch User
Hallo, wenn ich Stefan richtig verstanden habe hat er ja einen alten IPV4-Anschluss, der noch kein Upgrade zur aktuellen Technik hatte. Ich rate (vermuten wäre zuviel gesagt) mal, dass er auf ein anderes Gateway geht als die normalen Unitymedia-Benutzer. Man könnte ja mal die Adressen benachbarter Anschlüsse vergleichen. Gruß, Michael
Michael A. schrieb: > Jetzt habe ich intern und extern beides. Wegen der Prio auf V6 > unterhalten sich die Hosts in meinem Netz vorzugsweise mit V6. Und die > FB 6490 ist auch zufrieden damit. Die 6490 verbindet sich aber nicht per IPv6 mit dem VPN, oder?
Heute war der Anschluss zwischen einige Aussetzern einmal kurz langsam:
1 | Unitymedia StefanFrings Google Gateway MyPublicIp |
2 | 08.02.2018 14:42:27 13ms 18ms 14ms 8ms 2ms |
3 | 08.02.2018 14:42:38 12ms 17ms 14ms 8ms 2ms |
4 | 08.02.2018 14:42:49 12ms 19ms 14ms 8ms 2ms |
5 | 08.02.2018 14:42:59 12ms 19ms 13ms 9ms 2ms |
6 | 08.02.2018 14:43:12 576ms 665ms 700ms 553ms 2ms |
7 | 08.02.2018 14:43:24 628ms 346ms 103ms 2ms |
8 | 08.02.2018 14:43:35 12ms 18ms 14ms 8ms 2ms |
9 | 08.02.2018 14:43:45 12ms 18ms 13ms 8ms 2ms |
10 | 08.02.2018 14:43:56 12ms 18ms 13ms 7ms 1ms |
11 | 08.02.2018 14:44:07 13ms 18ms 14ms 9ms 2ms |
Unitymedia wird einen Techniker schicken. Mein Protokoll hat wohl schon verhindert, dass sie sich doof stellen.
> Unitymedia wird einen Techniker schicken. Mein Protokoll hat wohl schon > verhindert, dass sie sich doof stellen. Ich gratuliere zum sauberen Vorgehen und gelungenen Einstieg. Der Fall steht damit beim Provider zwar erst am Anfang und Dauer+Ausgang noch ungewiss, Jedoch in diesem Forum ein Vorzeigebeispiel gegen die beklagte vermeintliche "Anfängerfeindlichkeit". (beide Schnittstellen: TE zu anderen Forumsuser / TE zu Provider)
Local Area Notwort schrieb: > gegen die beklagte > vermeintliche "Anfängerfeindlichkeit". Inwiefern das? https://www.mikrocontroller.net/user/show/stefanus Namaste
Stefan U. schrieb: > Unitymedia wird einen Techniker schicken. Mein Protokoll hat wohl schon > verhindert, dass sie sich doof stellen. Da bin ich auf das Resultat und die noch zu ermittelnde Ursache gespannt. Namaste
Gerald B. schrieb: > Es muß nicht zwingend der Anschluss sein. Es ist ebenfalls möglich, das > der Router, bzw. dessen Netzteil in den letzten Zügen liegt. Hatte ich > beides bereits. Das ist doch Schwachsinn. Jedenfalls wenn man den Beobachtungen des TO glauben mag. Denn: Natürlich kann desolate Hardware beliebig katastrophale Perfomance-Einbrüche verursachen. Aber keinesfalls derart selektive. Dazu ist der blöde Zufall einfach nicht intelligent genug...
Wenn meine Verkabelung, der Switch, die Fritz-Box oder das Modem defekt wäre, dann müsste meine eigene öffentlich IP-Adresse zu den Ausfallzeiten ebenfalls nicht erreichbar sein.
Deine Öffentliche IP zu pingen benötigt es des Kabelmodems imho nicht, die fände der Router auch ohne das Modem zu belästigen. Aber die StatusLED des Modems sollte "mimi" machen wenn da was faul wäre, wie A.K.schon anmerkte. Namaste
> Deine Öffentliche IP zu pingen benötigt es des Kabelmodems imho nicht
Das sieht bei mir anders aus.
Wenn ich das Netzwerkkabel zwischen Fritz-Box und Modem unterbreche,
kann ich meine öffentliche IP sofort nicht mehr anpingen. Wenn ich es
danach wieder anstecke, ist sie etwa 2 Sekunden später wieder
erreichbar.
Das Modem ist übrigens doch nicht von Motorola, sondern ein "Cisco
EPC3208 EuroDocsis 3.0". Ich habe inzwischen Zugang zu dessen logs
gefunden. Dort konnte ich jedoch keine Einträge finden, die zeitlich zu
den Ausfällen passen.
Stefan U. schrieb: > Das Modem ist übrigens doch nicht von Motorola, sondern ein "Cisco > EPC3208 EuroDocsis 3.0". Haben wir so am Business-Anschluss. Reines Kabelmodem, echtes IPv4. Was am Modem hängt, ob Router oder nicht, kriegt eine offizielle IP per DHCP. Kommt ab und zu vor, dass der Anschluss nicht funktioniert. Ein Power-Cycle vom Cisco-Modem hilft dann.
:
Bearbeitet durch User
Stefan U. schrieb: > 08.02.2018 14:42:27 13ms 18ms 14ms 8ms 2ms Ping hat einige Optionen. Mit z.B. ping -t -l 444 8.8.8.8 sind die Pakete etwas länger und es fallen manche Fehler früher auf.
Reinhard S. schrieb: > > Die 6490 verbindet sich aber nicht per IPv6 mit dem VPN, oder? Nein, soll sie auch nicht, weil die VPN-Software nur IPV4 kann. Meine Firma ist noch bei W7 und S2008 sowie IPV4 steckengeblieben. Aber das ergibt sich ganz einfach über die Namensauflösung: der VPN-Provider wird nur als IPV4 aufgelöst. Aber mir gefällt, dass jetzt alles mit Prio über IPV6 abläuft und nur im Notfall IPV4 werwendet wird. Ginge mein Mobilnetz über IPV6 bräuchte ich auch kein MyFritz mehr, weil die IPV6 eine feste IP wäre. Gruß, Michael
Stefan U. schrieb: > Wenn meine Verkabelung, der Switch, die Fritz-Box oder das Modem defekt > wäre, dann müsste meine eigene öffentlich IP-Adresse zu den > Ausfallzeiten ebenfalls nicht erreichbar sein. Das kannst Du von Deinem Standort aus nicht prüfen, Dein Router macht da einen "Kurzschluss". Du müsstest also einen Pingtest auf Deine öffentliche Adresse /von außen/ laufen lassen, d.h. von einem irgendwo anders ans Netz angebundenen Rechner aus.
A. K. schrieb: > Technisch gesehen wird dabei gewöhnliches DHCP verwendet. So lange die > Lease des DHCP-Servers bestehen bleibt, kriegt man also immer die > gleiche Adresse. Bei mir (Vodafone/Kabel) 1 jährig. Kenne das bei kabel auch nicht anders.
Heute hatten wir zwei Ausfälle von etwa 30 Minuten, wo gar nichts mehr ging. Ich habe den Raspberry Pi heute bekommen. Ihn einzurichten war kinderleicht. Jetzt liegt die Kiste hinter dem Fernseher in der Ecke und protokolliert fleißig alles mit (bis die SD Karte voll oder kaputt ist). Von den 1GB Ram habe ich noch 850MB frei. Was mache ich bloß damit? :-)
Irgendwann ist der Job erledigt,dann wartet der Nächste. Nach dem Problem ist vor dem Problem. Sorge dich nicht, bastle. Ein erfüllter Wunsch, zieht hundert neue Wünsche nach sich. Namaste
Der Techniker war da und hat mein Protokoll mit anderen verglichen, die er mitgebracht hat. Seiner Meinung nach liegt der Defekt am anderen Ende des Kabels außerhalb unseres Hauses. Darum wird sie jemand anderes kümmern - hoffen wir es.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.