Internet neu verbinden (FritzBox), wenn Störung vorliegt

dantist · 07 Juni 2016, 22:22:41

Hallo zusammen,

ich habe seit einigen Monaten ein lästiges Problem mit meinem O2 Internet-Zugang, und da der Anbieter sich außerstande sieht, zu helfen, muss eine Lösung über FHEM her.

Situation: In etwa drei von vier Fällen funktionieren nach dem Aufbau einer DSL-Verbindung viele Dienste nicht. Ich konnte das Problem so weit eingrenzen, als dass Requests mit langen URLs nicht funktionieren, endlos warten und keine Antwort bekommen. Scheint irgendwas mit der MTU-Size zu sein, aber das ist zu hoch für den O2-Support und deren Störungsstelle.

Idee: Ein kleines Script schreiben, das eine beliebige Seite mit sehr langem Parameter aufruft. Wenn eine Antwort kommt, "true" ausgeben, wenn es nicht klappt, nach einem definierten Timeout "false" ausgeben. Wenn false zurückkommt, über FHEM einen Reconnect der FritzBox auslösen. Wiederholen, bis eine gute DSL-Verbindung zustande kommt.

Das Perl-Script habe ich schon fertig, funktioniert soweit gut. Den Timeout kann ich scheinbar nicht beeinflussen, der liegt fest bei 180 (?) Sekunden. Aber wie mache ich nun weiter? Kann ich FHEM dazu bringen, ein Script aufzurufen, bis zu drei Minuten zu warten und je nach Antwort eine Aktion auszulösen?

Update #1: Ich habe das Script testweise in die 99_myUtils.pm eingebaut. Allerdings hängt sich FHEM komplett auf, wenn der Testrequest nicht abgeschickt werden kann. Wenn sich das umgehen ließe, hätte ich schon einen funktionierenden Workaround.

Danke & Gruß

KölnSolar · 07 Juni 2016, 23:11:00

geht viel einfacher: Stichwort: presence mit lan-ping. Mach ich auch, weil meine Fritte manchmal nach nächtlichem disconnect keine funktionsfähigen DNS-Server mehr kennt.
und das notify für restart der WAN-Verbindung:

Code Auswählen

define act_on_FB_Inet_check FB_Inet_check:absent get Fritzbox tr064Command WANIPConnection:1 wanipconnection1 ForceTermination

Grüße, Markus

dantist · 07 Juni 2016, 23:18:45

Aber lan-ping ist doch, wie der Name sagt, für lokale Geräte? Der lässt auch nur die IP zu und keine zusätzlichen Parameter. Das Problem bei meiner Verbindung nach einem Reconnect sieht so aus:

Geht:
http://www.google.com/

Geht nicht:
http://www.google.com/?ewigLangerParameterMitEtwa1500Zeichen

Ich würde also gerne den Reconnect auslösen, wenn sich der lange Link nicht öffnen lässt.

KölnSolar · 08 Juni 2016, 00:47:14

Nö, z.B.
lan-ping google.de oder eben auch mit einem x-beliebigen langen URL.

Welche Parameter ?

dantist · 08 Juni 2016, 07:50:53

Das funktioniert nicht - ein Ping geht auf eine Domain und damit IP, und nicht auf eine URL. Das ist auch beim presence-Modul so. google.de funktioniert, google.de?123 nicht

Da es keine Domain gibt, die 1500 Zeichen lang ist, muss ich den Funktionstest mit einem entsprechend langen Parameter durchführen.

marvin78 · 08 Juni 2016, 08:00:01

Das dürfte mit httpmod machbar sein. Das kann allerdings blockieren, wenn keine DNS Auflösung stattfinden kann.

dev0 · 08 Juni 2016, 09:09:28

@dantist: Wenn es wirklich ein Problem mit der MTU Size ist, dann könntest Du auch versuchen die MTU size anzupassen. Falls es Dein eigener Router ist und er managebar ist, dann könntest Du auf dem ausgehenden Interface die MTU size fest auf einen Wert einstellen, der ausreichend klein ist und dem internen Interface eine MSS mitgeben, damit die internen Systeme die MTU size direkt anpassen. Alternativ kann man auch den internen Rechnern eine MTU direkt vorgeben (ifconfig ethX mtu 1234 up). Die MTU kannst Du ermitteln in dem Du mit verschiedenen Paketgrößen und gesetzten DF flag ein System im Internet anpingst (siehe "man ping"). Hier findest Du noch ein paar Erklärungen dazu und ein ping Beispiel für Windows Systeme: http://www.nwlab.net/art/mtu/mtu.html

dantist · 08 Juni 2016, 09:30:32

Zitat von: dev0 am 08 Juni 2016, 09:09:28
@dantist: Wenn es wirklich ein Problem mit der MTU Size ist, dann könntest Du auch versuchen die MTU size anzupassen.

Leider lässt sich die MTU-Size bei der FritzBox nicht anpassen. Bei einigen Clients, z.B. an einem Windows-Rechner, habe ich es testweise gemacht, das hat dort auch alle Probleme gelöst. Allerdings ist das keine wirkliche Lösung, da der Großteil der Endgeräte keine MTU-Anpassung erlaubt.

Ich werde heute Abend mal schauen, ob sich mit marvins httpmod-Vorschlag ein entsprechender Test umsetzen lässt.

Wernieman · 08 Juni 2016, 11:24:45

DHCP kennt eigentlich auch einen Parameter, der die MTU-Größe per dhcp verteilen kann.

Wenn dieses die Fritte nicht erlaubt, auf dem FHEm-Server noch einen dhcp-Server einsetzen. Macht von der Belastung nichts aus

Edit:
Es gibt übrigens noch einen "Trick":
Wenn Du ipv6 Aktivierst, kannst Du dort die MTU einstellen. Laut "I-Net" wird dieses auch für ipv4 übernommen (Angabe ohne Garantie)

dev0 · 08 Juni 2016, 11:38:32

Sehr gute Idee, an DHCP Optionen hatte ich gar nicht degacht. Die FW der Fritte ist auf dem aktuellen Stand?

dantist · 08 Juni 2016, 11:47:23

Interessant - dass der DHCP das mitteilen kann, wusste ich gar nicht. Auf dem RPi, der FHEM beherbergt, läuft nämlich auch ein DHCP-Server (ISC DHCP). Werde mich mal schlau machen, ob das damit funktioniert.

Den Trick über die IPv6-Einstellungen habe ich bereits getestet, das hatte leider keine Auswirkung. Liegt vielleicht daran, dass O2 noch kein IPv6 unterstützt. FritzOS ist aktuell (6.51).

Den eigenen DHCP habe ich übrigens vor einiger Zeit schon als Übeltäter ausgeschlossen. Die Probleme bestehen auch mit dem Fritzbox DHCP.

Wernieman · 08 Juni 2016, 12:46:05

Du weist, das es "nur einen" DHCP-Server geben darf?

Code Auswählen

option interface-mtu 9000;
Siehe (über google-Schnellsuche):
http://www.microhowto.info/howto/change_the_mtu_of_a_network_interface_using_dhcp.html

dantist · 08 Juni 2016, 16:53:05

So, ich habe folgendes in die ISC DHCP-Config eingetragen und den Service neugestartet:

Code Auswählen

option interface-mtu 1466;

Leider ohne Erfolg. Ein aktuelles Android zeigt weiterhin eine MTU von 1500, auch nach Löschen und Neuverbinden des WLANs und einem Neustart des Geräts.

Edit: Scheint ein bekannter Bug ab Android 5 zu sein: https://code.google.com/p/android/issues/detail?id=152819

Wernieman · 08 Juni 2016, 18:42:53

.. hätte da eher bei Windows auf Probleme getippt ...

Sorry aber mehr weiß ich auch nicht ....

StefanD · 12 Juni 2016, 11:36:34

Ein DHCP-Server kann viele Optionen mitgeben, entscheidend ist, welche der DHCP-Client letztlich auch umsetzt. Einen Versuch ist so ein Weg immer wert, jedoch leider keine Garantie, dass es mit allen Gerätschaften funktioniert.

Das Blöde an PPPoE ist, dass es keine einheitliche MTU Size gibt. Rein funktional sollten halbwegs aktuelle Router damit keine Problema haben. Für bestmöglichen Durchsatz kann nach wie vor eine Anpassung am Endgerät erforderlich sein.

Eine Url mit derart vielen Parametern ist aber auch sicherlich kein Regelfall. Muss eine solchlange Url von jedem internetfähigem Gerät im Heimnetz aus aufgerufen werden? Wenn ja, wäre wohl ggf. Auch der Wechsel zu einem anderen Provider mit größerer MTU als die derzeitige zu prüfen/überlegenswert.

Mit dem Tool MTU Path http://www.iea-software.com/products/mtupath.cfm lässt sich recht gut prüfen, welche Größe gegeben ist.

VG Stefan