Schlechte Erreichbarkeit laut Übersichtsseite

langhaarschneider · 18. Juli 2016 um 19:48

Hallo,

ich habe vor rund 10 Tagen eine Ubiquiti Nanostation Loco M2 mit der 4.2.2 Firmware bespielt und als Knoten 1122 in Betrieb genommen. Die Station läuft, die Verbindung ist gut und die Reichweite überragend.
Nur: Die Verfügbarkeit ist laut http://www.freifunk-dresden.de/hotspots.html mieserabel.
Davor hab ich am selben Standort schon einen TP-Link TL-WR841ND betrieben, bei dem ich nie Probleme damit hatte. Ein Neustart des Routers hat die angezeigte Verfügbarkeit nicht verbessert.
Lokal habe ich aber keine Probleme, komme auf die Nodes-Seite (http://10.200.4.103.freifunk-dresden.de/nodes.cgi) und sehe dort folgendes:

Direkte Nachbarn

Node Ip           Device    IP          RTQ  vom Nachbarn (RQ) zum Nachbarn (TQ)
2    10.200.0.3   tbb_fastd 10.201.0.3    13  50  26
102  10.200.0.103 tbb_fastd 10.201.0.103  86  64 100
111  10.200.0.112 tbb_fastd 10.201.0.112 100 100 100
120  10.200.0.121 tbb_fastd 10.201.0.121 100 100 100
Anzahl: 4

Meine Frage: Verursacht die schlechte Verbindungsqualität zu den Knoten 2 und 102 die schlechte Verfügbarkeit lauf Übersicht? Wenn ja, wie kann ich die Konnektivität verbessern?

Ich habe vor am Samstag beim Freifunkgrillen vorbei zu schauen - vielleicht ist es dort gemeinsam per VPN zugriff auf den Router einfacher zu lösen als aus der Ferne…

LG,

Jonathan

PS: Ist die Frage eigentlich hier gut aufgehoben oder wäre die Mailingliste der bessere Ort gewesen?

Emploi · 18. Juli 2016 um 21:10

Grüß dich. Die „Erreichbarkeit“ steigt nur wirklich sehr langsam an, 100% erreicht man erst nach einem Monat oder später. Lass nun mal schauen wie es am Wochenende aussieht und lass dich nicht durch die rote Farbe beeindrucken.
Was ich auf dem ersten Blick sehe ist, dass kaum Pakete verloren werden, die Pings sind oaky. Allerdings läuft der interne Speedtest nicht sauber durch. Manchmal sind die Antwortzeiten auch sehr lang:

|------------------------------------------------------------------------------------------|

| WinMTR statistics |

|------------------------------------------------|------|------|------|------|------|------|

| 192.168.1.1 - 0 | 1319 | 1319 | 0 | 0 | 5 | 0 |

| 10.200.200.4 - 1 | 1315 | 1314 | 1 | 31 | 309 | 27 |

| 10.200.4.63 - 1 | 1275 | 1265 | 28 | 70 | 4361 | 55 |

| 10.200.0.121 - 1 | 1282 | 1274 | 58 | 106 | 4494 | 134 |

| 10.200.4.103 - 1 | 1294 | 1289 | 70 | 129 | 4551 | 141 |

|____________|||||||

WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

Aber das muss nicht an deiner Nano liegen.

PS. Hier ist vollkommen okay, wie auch Facebook, g+, Twitter benutzt wird. Die aktiven Nutzer der Mailingliste kann man glaube ich an einer Hand abzählen.

langhaarschneider · 19. Juli 2016 um 06:18

Hallo,

Dass die Erreichbarkeit erst nach einem Monat bei 100% liegt und nur langsam steigt ist mir bewusst. Allerdings war sie schon bei 6% und ist jetzt wieder bei 1%… Naja, dann warte ich mal erstmal ab bis zum Wochenende.

LG,

Jonathan

ddmesh · 19. Juli 2016 um 20:43

Hi,

ich sehe zwei möglichkeiten. vom server aus gesehen, der die daten
einsammelt,
wird manchmal übere einen anderen router geroutet. das kommt dann
zustande, wenn
der server (auf dem auch vpn1 läuft) keine günstige verbindung hat.
du kannst mal den vpn3 durch vpn1 ersetzen.
der vpn3 ist überlastet und könnte zu so ein fehlerbild führen.

wenn das nicht reicht, könnte es sein dass das trafficshaping etwas zu
klein
konfiguriert ist. ich bin mir nicht sichere ob dieses exact funtioniert.
sollte
es eigentlich. Generell ist es aber nicht nötig, da der internet verkehr
eh maximal 5-10 mbit kann und somit die eigene leitung meisten nicht
auslastet.
das wäre der zweite punkt, den du versuchen könntest. stelle das traffic
shaping einfach auf ganz hohe werte, und beobachte es bitte nochmal.

viele grüße
stephan

langhaarschneider · 22. Juli 2016 um 06:54

Hallo @ddmesh, vielen Dank für deine Hilfe.

Ich habe das trafficshaping jetzt auf 10 MBit up/down eingestellt (wobei ich nur 1 MBit up habe, aber egal) und den Router neu gestartet (ist zwar nicht notwendig, schadet aber vermutlich ja auch nicht.

Aktuell scheine ich bessere Ereichbarkeitswerte zu haben:
(Via http://10.200.4.103.freifunk-dresden.de/sysinfo-json.cgi)

{„node“:„2“, „ip“:„10.200.0.3“, „rtq“:„97“, „rq“:„69“, „tq“:„100“},
{„node“:„102“, „ip“:„10.200.0.103“, „rtq“:„99“, „rq“:„65“, „tq“:„100“},

In der Übersichtsseite bin ich auch wieder bei 2%. Mal schaun ob das bis Morgen noch wieter steigt

LG,

Jonathan

Emploi · 22. Juli 2016 um 19:07

vpn3 läuft wieder wie eine 1. Er ist letzte Nacht vom ispOne auf ein servDiscount Blech umgezogen. Allein der vpn Tunnel schwächelt manchmal.

langhaarschneider · 3. Dezember 2016 um 21:46

Die Lösung des Problems brachte nicht die Änderung am Trafficshaping konnte mit @ddmesh beim Freifunk-Grillen gedunden werden:
Ich habe den Server VPN1 der die Übersicht erzeugt im Router direkt als Backbone-Verbindung eingetragen. Das lief dann einige Monate gut - aber jetzt bin ich angeblich laut übersichtsseite wieder nicht erreichbar. vom Zeitraum könnte das mit dem Ausfall/Umtausch meiner FritzBox zusammenhängen - aber eigentlich sehe ich da keinen technischen Grund für einen zusammenhang…
Der knoten 1122 läuft meiner Ansicht nach perfekt - aber laut der übersichtsseite bin ich offline.
Wenn ich aber auf den direkt verbundenen VPN-Servern nach der Verbindungsqualität zu mir suche - bin ich überall bei über 95% - http://vpn1.freifunk-dresden.de/nodes.cgi, http://vpn2.freifunk-dresden.de/nodes.cgi, http://vpn3.freifunk-dresden.de/nodes.cgi, http://vpn10.freifunk-dresden.de/nodes.cgi
Hab den Router schon mehrfach neu gestartet - ohne dass eine Verbesserung eintritt. Hat wer noch eine Idee?

ddmesh · 6. Dezember 2016 um 19:34

Hi,
Kannst du über deinen Router auf andere Knoten zugreifen? Geht Internet trotzdem? Geht der Speedtest zu andern Routern?

Vielleicht gibt es einen IP Konflikt. Und dadurch werden die Knoten ignoriert.
Hattest du schon mal Werkseinstellung gemacht, so dass du einen andere freie Knoten Nummer bekommst?
Probiere das bitte mal.
Vg Stephan

langhaarschneider · 7. Dezember 2016 um 19:37

Hallo,

ich komme über meinen Router über die lokale Adresse (192.168.178.XXX) auf den Freifunk-Router. Internet über den Freifunk-Router geht auch. Dann mach ich mal den Werkseinstellungsreset…

langhaarschneider · 14. Dezember 2016 um 16:07

So. gestern Abend hab ich den Router neu aufgesetzt ist jetzt Knoten 1233. Nach 20h bin ich in der Hotspot-Übersichtsseite immer noch bei 0%
Die Linkqualität der „direkten Nachbarn“ ist unterschiedlich: Node 2, 111 und 120 gut - 102 unterirdisch. Werde 102 mal löschen und schaun ob sich dann was tut…

{„node“:„2“, „ip“:„10.200.0.3“, „rtq“:„97“, „rq“:„100“, „tq“:„97“},
{„node“:„102“, „ip“:„10.200.0.103“, „rtq“:„17“, „rq“:„41“, „tq“:„41“},
{„node“:„111“, „ip“:„10.200.0.112“, „rtq“:„100“, „rq“:„100“, „tq“:„100“},
{„node“:„120“, „ip“:„10.200.0.121“, „rtq“:„100“, „rq“:„100“, „tq“:„100“}

ddmesh · 14. Dezember 2016 um 20:12

Hi
kurz zur Info, die Hotspot Liste aktualisiert sich alle 30 min bis 1h.
Du kannst aber die aktuelle Qualität der Verbindung über vpn1.freifunk-dresden.de einsehen.
Bitte gib mir Bescheid, wenn es sich gebessert hat oder auch nicht.
Vg Stephan

langhaarschneider · 15. Dezember 2016 um 13:08

Hallo,
in der Hotspot-Liste bin ich weiterhin bei 0 - auf VPN1 bei 97…

ddmesh · 20. Dezember 2016 um 17:16

Hi,

hat sich irgendwas an deinem Internetanschluss verändert? denn so wie es aussieht scheint es ein MTU Problem
zu sein. wenn ich ein „ping -s 1289 10.200.4.214“ mache, so funktioniert es noch. alles was grösser ist, kommt bei dir nicht mehr an.

Ich bin dabei in der neuen firmware die MTU zu den servern von 1426 auf 1200 zu reduzieren. das geht aber nicht so schnell, da die server dabei aktualisert werden müssen und die vorhandenen knoten aber trotzdem mit der alten mtu arbeiten.

Testweise kannst du folgendes probieren. aktuell laufen auf vpn1.freifunk-dresden.de und vpn2.freifunk-dresden.de
auf port 5002 eine zweite fastd instance (Backbone-Tunnel), der mit der mtu 1200 arbeitet.

Du musst dazu in der Firmware Oberfläche in den Backbone einstellungen diese beiden Server eingetragen haben und auch die Portnummer angepassen.
du must dich via ssh auf deinen router einloggen und in /etc/config/ddmesh den wert mesh_mtu von 1426 auf 1200
ändern und ebenfalls das gleiche in /usr/lib/ddmesh/ddmesh-bootconfig.sh
(suche einfach nach mesh_mtu).
Hoffe du kennst dich mit dem „vi“ aus

Ich habe bei mir eine verbindung über WLAN Hotspot von Kabeldeutschland. diese ist aber nicht stabil. es scheint, dass
hier oft UDP pakete nicht weitergleietet werden. Die IP ändert sich ständig. Mal gibt es welche, die funktionieren und mal nicht. ich vermute aber, dass es sich auf die WLAN Hotspot Infratruktur von kabeldeutschland beschränkt.

Wenn du die mesh_mtu änderst, dann kannst du dich NUR mit vpn2 und vpn1 verbinden. wäre aber ein guter test, ob
es stabil läuft.

vg
stephan

langhaarschneider · 20. Dezember 2016 um 21:20

Hallo Stephan,

erstmal vielen Dank für deine Hilfe. Ja - an meinem Anschluss hat sich was geändert. Da die von Kabel Deutschland gemietete FritzBox abgeraucht ist bekam ich außer der neuen Fritzbox zur steigerung der Kundenzufriedenheit auch für ein halbes Jahr ein 100Mbit/s upgrade - da hab ich nicht nein gesagt

Ich habe jetzt vpn1/2 im Backbone auf Port 5002 eingetragen und via SSH die anderen änderungen durchgeführt. (Bisher hatte ich nur mit vim Erfahrung - aber dank Google konnte ich dann auch mit vi speichern…)

Laut der Nodes-Seite ist die Verbindung zu VPN1/2 auch mit den neuen EInstellungen stabil. Morgen schau ich mal was meine Verfügbarkeit auf der Hotspor-Liste macht…

Liebe Grüße,

Jonathan

ddmesh · 21. Dezember 2016 um 02:12

Irgendwie ist da immer noch ein Problem.
Kannst du mal schauen, Welche mtu br-lan auf deinem Gerät eingestellt ist?
Könnte sein, das da was falsches berechnet wurde. Die mtu wird vom Interface des privaten VPN, Welches auch mit fastd aufgebaut werden kann, abgeleitet.
Da gibt es noch einen Fehler. Du kannst ja mal schauen ob du das priv Interface aus der bridge br-lan mit brctl entfernen kannst und dann schauen ob du via 10.200.4.214.freifunk-dresden.de auf deinen Router kommst. Das geht via Proxy.
Komisch ist es aber, da andere Nano nicht solche Probleme zeigen. Am Gerät selber wird es auch nicht liegen. Hast du noch einen tp-link zum testen? Den könntest du via LAN genauso anschließen und konfigurieren , wie die Nano.
Vg Stephan

langhaarschneider · 21. Dezember 2016 um 22:11

Hi,
danke für deine schnelle antwort - ich komm nicht so schnell hinterher. Hier erstmal alle MTUs aller Interfaces die ifconfig ausspuckt:

Ubiquiti Nanostation M @ r1233:~# ifconfig
bat0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:169.254.14.1  P-t-P:169.254.14.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1171  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

bmx_prime Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.200.4.214  P-t-P:10.200.4.214  Mask:255.255.0.0
          UP POINTOPOINT NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

br-lan    Link encap:Ethernet  HWaddr 68:72:51:51:44:41  
          inet addr:192.168.178.210  Bcast:192.168.178.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1134  Metric:1
          RX packets:3153743 errors:0 dropped:5403 overruns:0 frame:0
          TX packets:2251966 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:739010966 (704.7 MiB)  TX bytes:674129236 (642.8 MiB)

br-wifi2  Link encap:Ethernet  HWaddr 6A:72:51:50:44:41  
          inet addr:192.168.252.1  Bcast:192.168.255.255  Mask:255.255.252.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4926 errors:0 dropped:35 overruns:0 frame:0
          TX packets:7499 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:863754 (843.5 KiB)  TX bytes:7025676 (6.7 MiB)

eth0      Link encap:Ethernet  HWaddr 68:72:51:51:44:41  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3154951 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2251967 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:783624459 (747.3 MiB)  TX bytes:674129282 (642.8 MiB)
          Interrupt:4 

eth1      Link encap:Ethernet  HWaddr 6A:72:51:51:44:41  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:5 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:112 errors:0 dropped:0 overruns:0 frame:0
          TX packets:112 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:10637 (10.3 KiB)  TX bytes:10637 (10.3 KiB)

priv      Link encap:Ethernet  HWaddr 1A:6E:95:12:01:03  
          UP BROADCAST RUNNING  MTU:1134  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6426 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:0 (0.0 B)  TX bytes:2273628 (2.1 MiB)

tbb_fastd Link encap:Ethernet  HWaddr 32:E1:12:69:5A:BF  
          inet addr:10.201.4.214  Bcast:10.255.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING  MTU:1200  Metric:1
          RX packets:3141992 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1129206 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:645384770 (615.4 MiB)  TX bytes:297743454 (283.9 MiB)

wlan0     Link encap:Ethernet  HWaddr 68:72:51:50:44:41  
          inet addr:10.201.4.214  Bcast:10.255.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1426  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1925631 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:575939652 (549.2 MiB)

wlan0-1   Link encap:Ethernet  HWaddr 6A:72:51:50:44:41  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4924 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8212 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:933142 (911.2 KiB)  TX bytes:7206290 (6.8 MiB)

br-lan scheint erstmal korrekt zu sein da < 1200 - oder?

Hab keinen physikalischen Zugriff auf einen tp-link - kann aber via Netzwerk auf welche zugreifen (leider nicht auf alle die ich eingerichtet hab wegen vergessenem Passwort - sonst hätten auch alle die aktuelle Firmware (shameOnMe)) Das bringt aber wohl nichts - da ich direkt an meinem Anschluss testen sollte da hier das MTU-Problem auftritt - oder?

ddmesh · 22. Dezember 2016 um 07:56

Die Idee mit den anderen TP-Link routern, wäre nur interessant, wenn du diesen an deinem Anschluss testen könntest.

Du einfach mal das Private Vpn abschalten. dadurch wird in die br-lan (bridge) das interface priv nicht mehr
eingehängt. dieses „reisst“ die MTU von br-lan von 1500 mit runter. was eigentlich falsch ist. denn der gegenüberliegende Router, kennt diese MTU nicht und schickt weiterhin pakete mit 1500 bytes. Der Freifunk Router aber, würde diese Pakete evt. verwerfen. Für einen Link (Verbindung zwischen zwei geräten) gibt es nur eine MTU, welche auf beiden Seiten gleich sein muss.

Trage dazu einfach mal ein „exit 0“ ganz oben in das script /usr/lib/ddmesh/ddmesh-privnet.sh ein, so dass dieses einfach
nichts macht und starte den router neu.
das könnte damit dann schon funktionieren. wenn das so ist, würde es meine Korregtur für die neue Firmware bestätigen.
VG
Stephan

langhaarschneider · 22. Dezember 2016 um 09:39

Hallo,

hab das skript angepasst und rebootet- jetzt sieht die Ausgabe von ifconfig so aus:

Ubiquiti Nanostation M @ r1233:~# ifconfig
bmx_prime Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.200.4.214  P-t-P:10.200.4.214  Mask:255.255.0.0
          UP POINTOPOINT NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

br-lan    Link encap:Ethernet  HWaddr 68:72:51:51:44:41  
          inet addr:192.168.178.210  Bcast:192.168.178.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:585 errors:0 dropped:0 overruns:0 frame:0
          TX packets:54 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:122362 (119.4 KiB)  TX bytes:10046 (9.8 KiB)

br-wifi2  Link encap:Ethernet  HWaddr 6A:72:51:50:44:41  
          inet addr:192.168.252.1  Bcast:192.168.255.255  Mask:255.255.252.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth0      Link encap:Ethernet  HWaddr 68:72:51:51:44:41  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:604 errors:0 dropped:0 overruns:0 frame:0
          TX packets:55 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:134882 (131.7 KiB)  TX bytes:10092 (9.8 KiB)
          Interrupt:4 

eth1      Link encap:Ethernet  HWaddr 6A:72:51:51:44:41  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:5 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:708 (708.0 B)  TX bytes:708 (708.0 B)

tbb_fastd Link encap:Ethernet  HWaddr 86:5D:48:33:EA:8F  
          inet addr:10.201.4.214  Bcast:10.255.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING  MTU:1200  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:0 (0.0 B)  TX bytes:992 (992.0 B)

wlan0     Link encap:Ethernet  HWaddr 68:72:51:50:44:41  
          inet addr:10.201.4.214  Bcast:10.255.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1426  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:18 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:1728 (1.6 KiB)

wlan0-1   Link encap:Ethernet  HWaddr 6A:72:51:50:44:41  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:64 (64.0 B)

ddmesh · 22. Dezember 2016 um 13:09

… und schon geht es

Danke auch fuer deine Tests.

VG
Stephan

langhaarschneider · 22. Dezember 2016 um 17:08

Hurra
Soll ich die AutoUpdate-Funktion für die Firmware deaktivieren - oder wird das nächste Update das mögliche MTU-Problem sowieso beheben?
Danke für deine Hilfe!