WR1043N v5, Clients bekommen kein Internet und andere Probleme

[michi84]

Hallo,
hatte mir vor etwa einem halben Jahr ein WR1043N v5 gekauft und dort eine experimental Version drauf gemacht. War glaub ich eine 2016 oder 2017. Lief im Prinzip auch, ab und zu wurde der Router unter https://mesh.freifunknord.de/ als offline angezeigt, war aber nicht wirklich der Fall war.

Vor paar Tagen hab ich unter folgender Adresse einen Release-Candidate 2018.2 gefunden https://freifunk.in-kiel.de/nord-firmware/release-candidate/2018.2/

Runtergeladen, den Router in den Configmode gesetzt, die neue Firmware ausgewählt. Sicherheitshalber habe ich den Haken bei Einstellungen beibehalten weggemacht, damits auch sauber drauf kommt…

Ich kam dann aber erstmal nicht mehr auf den Router, auch nach aktivieren das Configmodes nicht.
In Chrome kam immer eine Fehlermeldung, siehe Screenshot. Na einiger Zeit habe ich dann gemerkt das es mit Internet Explorer geht…

Dann alles eingerichtet, den Namen des Knoten, Standort eingetragen, PPA Haken rein gemacht, Mailadresse eingetragen.
Diesen Code am Ende (weiß grad nicht genau wie der heißt) per Mail an FF Nord geschickt zum eintragen.
Es bekam aber kein Client Internet über den Knoten.
Hatte dann eine etwas ältere Version aufgespielt, wieder alles eingerichtet… Dann ging erst immer noch kein Internet, dann mal kurz, dann wieder nicht.

Habe dann wieder den RC 2018.2 drauf gemacht, den aktuellen Code wieder per Mail geschickt.
1 Tag später geht mit dem RC 2018.2 bei den Clients noch immer kein Internet

In der Config ist die Offline SSID aktiviert, aber es wird die normale SSID angezeigt. Also ist der Knoten ja theoretisch online?! Die Clients bekommen auch eine 10.x.x.x Freifunk IP zugewiesen, aber halt kein Internet…

Am selben Anschluss lief der Router vorher mit der alten Firmware, jaja never change ja running System…

Aber dachte Release Candidate ist besser als Experimental. Hat aber nicht so geklappt.

Momentan habe ich die Kiste erstmal abgeschaltet, da es für die User ja frustrierend ist wenn sie sich einloggen aber dann kein Internet haben…

Kann mir da irgendjemand helfen?

[alladin]

Erstmal: zwischen der alten luci basierten webgui und der neuen web-admin-Oberfläche haben sich die URLs geändert - wenn Du den Browser Cache löscht, sollte es mit jedem Browser gehen.

Du hast geschrieben, dass die Clients eine ipv4 aus dem 10er Netz kriegen - also steht der Tunnel zur Supernode und die dhcp-Anfrage des Clients wurde beantwortet.
Bleibt also die Frage, ob die Ipv4-Pakete auch geroutet werden.

nslookup www.irgendeine-domain.de
traceroute www.irgendeine-domain.de (wenn keine erfolgreiche dns
-Auflösung vorher, dann IP einsetzen)
ifconfig unter Linux oder ipconfig /all sollte die Netzparameter anzeigen:
Gateway-Eintrag vorhanden?
Nameserver?

sollte möglich sein, die gateway-IP zu pingen (ping <hostname/ip>)

Für die meisten Communities sollte eine stable-Version auf Lede-Basis (v2018.1.x) vorhanden sein - ggf. zurückflashen ohne Beibehalten der Settings.

my 2 cents

[michi84]

C:\WINDOWS\system32>nslookup www.google.de
Server:  UnKnown
Address:  fd42:eb49:c0b5:4242::fd20

Nicht autorisierende Antwort:
Name:    www.google.de
Addresses:  2a00:1450:4005:80a::2003
          172.217.16.131

C:\WINDOWS\system32>tracert 172.217.16.131

Routenverfolgung zu fra15s46-in-f3.1e100.net [172.217.16.131]
über maximal 30 Hops:

  1  Übertragungsfehler: Fehlercode 1232.

Ablaufverfolgung beendet.

C:\WINDOWS\system32>tracert 2a00:1450:4005:80a::2003

Routenverfolgung zu ham04s01-in-x03.1e100.net [2a00:1450:4005:80a::2003]
über maximal 30 Hops:

  1  Übertragungsfehler: Fehlercode 1231.

Ablaufverfolgung beendet.

Und

Drahtlos-LAN-Adapter WLAN:

   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Intel(R) Centrino(R) Advanced-N 6205
   Physische Adresse . . . . . . . . : 08-11-96-1D-93-F0
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   IPv6-Adresse. . . . . . . . . . . : fd42:eb49:c0b5:4242:a547:52ba:1605:86bb(Bevorzugt)
   Temporäre IPv6-Adresse. . . . . . : fd42:eb49:c0b5:4242:6032:e271:6e4b:c36c(Bevorzugt)
   Verbindungslokale IPv6-Adresse  . : fe80::a547:52ba:1605:86bb%10(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 10.187.221.160(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.0.0
   Lease erhalten. . . . . . . . . . : Sonntag, 13. Januar 2019 14:12:44
   Lease läuft ab. . . . . . . . . . : Sonntag, 13. Januar 2019 14:22:44
   Standardgateway . . . . . . . . . :
   DHCP-Server . . . . . . . . . . . : 10.187.127.254
   DHCPv6-IAID . . . . . . . . . . . : 50860438
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-1F-C7-35-57-B8-70-F4-F1-B0-D6
   DNS-Server  . . . . . . . . . . . : fd42:eb49:c0b5:4242::fd20
                                       fd42:eb49:c0b5:4242::fd01
                                       fd42:eb49:c0b5:4242::ffff
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

[alladin]

@michi84

Standardgateway . . . . . . . . . :

der fehlt - ohne den läuft nix nach draussen.

[michi84]

Das muss aber eine Freifunk GW IP sein oder?
Oder der Gateqay aus meinem LAN?

[alladin]

der gateway des 10er Netzes, aus dem Du die IP bezogen hast

[michi84]

Komisch sollte er aber doch normal automatisch bekommen.

[alladin]

@michi84

10.187.127.254

jepp, sollte er neben ip/netzmaske und nameservern bekommen vom ```
dhcp-server auf der 10.187.127.254

wenn das die supernode ist, könnte das auch der Gateway für den Tunnel sein :smiley:

route add default gw ... :D

[rubo77]

Ich baue gerade noch mal eine neue firmeare 2018.2.0.1, lade ich morgen hoch.

@anon68922371 hatte auch noch eine Idee, aber der ist nicht mehr online. mal morgen sehen im webchat: https://riot.eclabs.de/#/room/#freifunk-nord:matrix.eclabs.de

[rubo77]

Problem ist gelöst. Es lag daran, dass in der Firmware der ddhcpd zwar mit drin war, aber eigentlich disabled. das Disablen hat nur leider nicht geklappt und richtig konfiguriert war der und die Gateways auch noch nicht.

[Matze1]

Hallo, ich habe zur Zeit ähnliche Probleme, komme über Freifunk nicht ins Internet.

Ich nutze Freifunk auf einem TP-Link TL-WR1043ND v4 mit VPN-Anbindung
https://mesh.freifunknord.de/#/de/map/60e327e75758#!/de/map/8416f966496a

und auf einem TP-Link TL-WR841N v10 als reinen Mesh-Knoten
https://mesh.freifunknord.de/#/de/map/60e327e75758#!/de/map/60e327e75758

Die verwendete Firmware-Version auf beiden Geräten war die Release-Candidate Version 2018.2.0.3
https://freifunk.in-kiel.de/nord-firmware/archive/2018.2.0.3/
die bisher auch einwandfrei lief. Seit gestern jedoch klappte die Einwahl ins Internet nicht mehr. Daraufhin habe ich eine manuelle Firmwareaktualisierung auf die experimentelle stabile Version 2018.2.1-733
https://freifunk.in-kiel.de/nord-firmware/stable/2018.2.1-733/
durchgeführt. Dies brachte jedoch leider keinen Erfolg, keine Verbindung mit dem Internet. Die Status-LED blinkte immer nur sporadisch ein paar mal kurz auf, ansonsten leuchtete sie dauerhaft. Es hatte also den Anschein, das der Knoten keine Verbindung zum GW bekommt. Auf der Mesh-Karte werden die Knoten als online angezeigt.

Zuletzt habe ich dann ein Downgrade auf die offizielle Firmware-Version 2016.2.7.1 durchgeführt und einen vollständigen Reset der Geräte durchgeführt und neu konfiguriert. Den jeweiligen VPN-Key habe ich natürlich auch per Mail an FF Nord geschickt. Mit dieser alten Firmware-Version läuft jetzt alles wieder. Dachte ich jedenfalls. Die Status-LED blinkt gleichmäßig vor sich hin, was darauf hindeutet, dass der Knoten auch Verbindung zum GW hat. Trotzdem geht das Internet nur sporadisch, dh, die Clients bekommen nur sporadisch per DHCP eine IPv4 zugewiesen. Wenn dies denn mal geklappt hat, dann geht auch das Internet ohne weitere Unterbrechungen, solange, bis man die Verbindung wieder trennt.
Hier mal die Ausgabe von ipconfig /all, wenn die Verbindung nicht klappt:

Drahtlos-LAN-Adapter WLAN:

   Verbindungsspezifisches DNS-Suffix: 
   Beschreibung. . . . . . . . . . . : Qualcomm Atheros QCA9377 Wireless Network Adapter
   Physische Adresse . . . . . . . . : 9A-22-8C-97-08-68
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   IPv6-Adresse. . . . . . . . . . . : fd42:eb49:c0b5:4242:7c20:7470:65ba:21b2(Bevorzugt) 
   Tempor„re IPv6-Adresse. . . . . . : fd42:eb49:c0b5:4242:b468:7ffd:1d0b:3f5a(Bevorzugt) 
   Verbindungslokale IPv6-Adresse  . : fe80::7c20:7470:65ba:21b2%7(Bevorzugt) 
   IPv4-Adresse (Auto. Konfiguration): 169.254.33.178(Bevorzugt) 
   Subnetzmaske  . . . . . . . . . . : 255.255.0.0
   Standardgateway . . . . . . . . . : 
   DHCPv6-IAID . . . . . . . . . . . : 127541900
   DHCPv6-Client-DUID. . . . . . . . : 00-03-00-01-9A-22-8C-97-08-68
   DNS-Server  . . . . . . . . . . . : fd42:eb49:c0b5:4242::fd04
                                       fd42:eb49:c0b5:4242::fd03
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

und Screenshot:

Woran liegt das, das die Interneteinwahl mit der Firmware-Version 2018.2.0.3 bisher einwandfrei funktionierte und jetzt plötzlich nicht mehr?
Ich würde nämlich gerne die 2018er-Version einsetzen. Die 2017er-Version möchte ich wegen der Probleme mit dem Autoupdater nicht einsetzen.

Ich habe fast alles genauso gemacht wie Michi84 und auch die Symptome sind ja fast identisch.

[adorfer]

Bitte schaue mal in Wiki und arbeite die Schritte aus dieser Anleitung ab:

https://wiki.freifunk.net/Mein_Freifunk_funktioniert_nicht_mehr

[Matze1]

Leider bin ich technisch nicht so versiert. Aber ich kann es ja mal versuchen.
Das Problem besteht übrigens weiterhin. Ich klicke rechts unten in Windows auf das Wlan-Symbol, wähle aus der Liste „nord.freifunk.net“ mache das Häkchen rein bei „Automatisch verbinden“ und klicke auf „Verbinden“ Dann wird zwar eine Wlan Verbindung hergestellt, aber daneben erscheint dann „Kein Internet, offen“. Dann ca. 5min gewartet: noch immer kein Internet. Manchmal klappt es erst nach mehreren Versuchen mit Trennen und neu verbinden oder gar nicht. Der PC bekommt einfach keine IPv4-Adresse zugewiesen. Das ist frustrierend. Die aktuelle und offizielle Firmware ist die 2016.2.7.1 / gluon-v2016.2.7 für Freifunk Nord auf einem TP-Link TL-WR1043ND v4. Der Knoten wird auf der Karte stets als „online“ angezeigt.

[Matze1]

So, ich habe jetzt noch mal die experimentelle Firmware-Version 2018.2.1-733 / gluon-v2018.2.1-20-gd43dbdca+ eingespielt, alle Einstellungen „vergessen“ lassen", und alles neu konfiguriert, jedoch VPN-Verschlüsselung abgeschaltet mit dem gleichen Ergebnis, wie in meinem vorherigen Post, dass das Internet mal funktioniert und mal nicht.
Ich werde wohl Freifunk bald abschalten.

[adorfer]

@michi84

Letztens die aktuelle Version mal drauf und geht immer noch alles.

Ich bin mir zu fast 100% sicher, dass KEIN Hardwareproblem des lokalen 1043ers ist.
Es wird auch in keiner Form ein „1043v5 generell“-Problem sein.
In der Richtung zu suchen ist zwecklos.

Wenn ihr die beschriebenen Tests nicht durchführen könnt, dann werden wir leider über Spekulation nicht herauskommen.

Mögliche Dinge sind:

• Probleme im Uplink-Homegateway oder dessen Netzzugang
• Probleme im Backend der Freifunk-Domain
• Probleme mit Störenden Nachbarknoten irgendwo in der L2-Domain
• Oder die allseits beliebte „L2-Domain größer als n Knoten“-Problematik.

[Matze1]

Also ich kann den Router ganz normal über den Config-Modus einrichten. Ist alles eingerichtet, Router neu gestartet und E-Mail mit dem aktuellen VPN-Key an knoten@freifunknord.de geschickt, erscheint der Knoten im Freifunk-Meshviever als online. Soweit alles normal. Wechsel ich jedoch ins Freifunknetz, bekommt der PC keine IPv4 Adresse aus dem 10er-Netz und keinen Standard-Gateway per DHCP zugewiesen und deshalb geht auch kein Internet, d. h. manchmal klappt es erst nach unzähligen Versuchen.
Ich kann aber über Freifunk die Statusseiten meines und anderer Knoten aufrufen, wenn ich im Freifunknetz eingewählt bin. Die Verbindung ins Freifunknetz selbst klappt also, allerdings kein Internet. Dabei spielt es keine Rolle, ob ich die offizielle oder eine experimentielle Firmware einsetze.
Irgendetwas stimmt da nicht. Mein Router ist ein TP-Link TL-WR1043ND v4.

[adorfer]

So what?
Was möchtest Du hören?

Es ist mit hoher Wahrscheinlichkeit eines der von mir oben beschriebenen 4 Problemfelder.
Welches? Wenn Du nicht debuggen magst, kannst Du jetzt wahlweise einen Würfel werfen. Oder aber darum bitten, dass wir Dich bedauern.

Aber wenn’s hilft: thoughts and prayers!

[Matze1]

Ich habe mal den Ping-Test gemacht.
Ergebnis:
ping nextnode IPv4: not ok
ping nextnode IPv6: not ok

Ping wird ausgeführt für 10.187.127.254 mit 32 Bytes Daten:
PING: Fehler bei der šbertragung. Allgemeiner Fehler. 
PING: Fehler bei der šbertragung. Allgemeiner Fehler. 
PING: Fehler bei der šbertragung. Allgemeiner Fehler. 
PING: Fehler bei der šbertragung. Allgemeiner Fehler. 

Ping-Statistik für 10.187.127.254:
    Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
    (100% Verlust),

Ping wird ausgeführt für fd42:eb49:c0b5:4242::ffff mit 32 Bytes Daten:
Zeitberschreitung der Anforderung.
Zeitberschreitung der Anforderung.
Zeitberschreitung der Anforderung.
Zeitberschreitung der Anforderung.

Ping-Statistik für fd42:eb49:c0b5:4242::ffff:
    Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
    (100% Verlust),

Ich hätte jetzt auch gerne den nächsten Test gemacht, weiß aber nicht, wie ich per SSH auf den Router komme, weiß also nicht, wie ich das eingeben muss.

[adorfer]

versuche bitte mal die Nextnode-Adressen anzupingen.
Diese findest Du ggf. in der site.conf der Firmware Deiner Community.

Da sollte etwas stehen wie etwa (gern mit Kommentarzeilen oder anderen Angaben wie Namen und mac-adressen gewürzt)

  next_node = {
    ip4 = '10.1.224.255',
    ip6 = '2a03:2260:300e:1700::ffff',
    }

Wenn das nicht geht, dann wirst Du die IP-Adressen für ipv4/v6 ggf. manuell festnageln müssen, wenn radv und/oder dhcp-server nicht wirklich zuverlässig erreichbar sind.

Ein weiter Test wäre, „wenn es denn mal geht“ den Ping durchaus 1-2h stehen zu lassen und dann am Ende den Packet-Loss zu betrachen.
Gern auch parallel a) Gateway IPv4/IPv6 anpingen und b) nextnode IPv4 und IPv6
Und dann die Packet-Loss-Rate vergleichen.

[adorfer]

Damit wären wir dann also in FF-Nord in „Zone15“, also einen Schritt weiter.

Freifunk-Nord/nord-zone-bat15/blob/master/db.ffnord

Dass aber von Deinem Rechner
fd42:eb49:c0b5:4242:7c20:7470:65ba:21b2 die
fd42:eb49:c0b5:4242::ffff
nicht anpingbar ist sagt mir: Der Fehler liegt zwischen Deinem Rechner und dem Plasterouter!
Denn wenn Dein Rechner immerhin (gemäß obigem Output) die IPv6 über das ND/radvd des Plasterouters bezogen hat, dann muss er die IP auch anpingen können.
Wenn nicht, dann klingt das für mich nach „Zugenagelte (Windows-)Firewall“