WR1043N v5, Clients bekommen kein Internet und andere Probleme

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

Fehler%20nach%20Update

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 :frowning:

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?

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

2 Likes
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

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

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

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

Komisch sollte er aber doch normal automatisch bekommen.

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

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

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.

1 Like

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

und auf einem TP-Link TL-WR841N v10 als reinen Mesh-Knoten

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:
Anmerkung%202019-07-21%20175514

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.

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

https://wiki.freifunk.net/Mein_Freifunk_funktioniert_nicht_mehr

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.

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. :frowning:

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.
2 Likes

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.

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!

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.

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.

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

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“