Netzstörung - Einzelfall bei mir oder allgemein?

während ich das so bislang nicht bemerkte, gibt es heute Abend, trotz IP und DHCP, massive Unterbrechungen „kein Internetzugriff“ „server not found“.
Ablauf ist relativ konstant immer gleich: sehr lange Zeit bis Login, ca. 5 Min, teils mehr, dann ca. 1-2 Min online mit ca. 3-5 Mbit/s down, dann Abruch der Internetverbindung „server not found“, nach ca. 5-10 Min wieder Internet da, Ablauf wie zuvor, also Abruch alle 1-2 Min für einige Minuten.
z.B. IPv4 Standardgateway + DHCP-Server = 10.156.244.232 wenn OK, dann wechselnd zu 10.156.9.247 und Trennung

aktuell 1,37 Mbit/s down, 0,.53 up, gewechselt auf 10.156.0.242
scheint, als würde Standardgateway + DHCP-Server andauern wechseln.

DNS Server ist konstant 8.8.8.8

Für die Meldung. Die Angabe der IP-Ardessen liefert die Ursache der Störung: 10.156.9.247 ist keine von Wupper vergebene IP-Adresse. batctl gwl liefert mir auch keine anderen Gateways, außer den offiziellen. Die Störung scheint bei Dir zu liegen. Wenn dies noch andere Stimmen aus RBK bestätigen, kann ich noch bei Gelegenheit tiefer graben. Gebe noch die Adresse, des nicht offiziellen GWs, welches versucht sich bei Dir rein zu mogeln. Alles außer 10.156.0.24{0-3} ist falsch.

jetzt IPv4 GW + DHCP-Server auf 10.156.0.242 und wieder Trennung
Time: 11/28 00:01 h
… warte bis wieder da …
00:02 wieder da
selbe IPs
versuche speedtest mit

und wieder weg nach Laden der Seite vor Start Speedtest : 00:04
IPv4 DHCP-Server gewechselt auf 255.255.255.255
Standard GW immer noch 10.156.0.242
00:07 IPv4 DHCP-Server gewechselt auf 10.156.0.242
Internet wieder da
und wieder weg 00:08
IPs noch 0.242
0013: Internet wieder da
IPs unverändert 0.242

ich bin auf 2 Rechnern, der eine ist WLAN FF (den berichte ich), an 2. Instanz an Firtzbox Port 4,
der, mit dem ich poste ist direkt an Fritzbox port 1 ohne Störungen
Netcologne

00:15 weder weg

nachtrag,
jetzt hab ich lt. Verbindungsanzeige zwar wieder Internet, aber bekomme immer noch Server not found für alles bei FF

nachtrag 2
hab jetzt 841 direkt per LAN an Fritzbox, mit VPN,
StandardGW + DHCP Server 10.156.0.241
lt. map viewer mit w0 + w2 verbunden
vorher mit w1 + w2
speedtest klappt 5.4 Mbit/s
2. speedtest 10,5
3. 9.5
bin am Ende meines Lateins

ncoh ein Nachtrag
hab den 841 direkt an LAN wieder aus, bin wieder mit dem anderen per WLAN verbunden, bekomme IPv4 Standard GW + DHCP Server 10.156.0.241
und alles läuft gut wie es soll, speedtest 11.5 Mbti/s

Wenn ich das oben vergleiche, hat die IP von 10.156.0.242 auf 10.156.0.241 gewechselt. Erstere hakt, zweite scheint OK

es ist Wochenende und die Server sind weniger ausgelastet, als in der Woche. w2 ist von RBK zu 37% ausgelastet.

Es kann seitens des DHCP-Servers keine Trennung geben. Wenn der Client richtig funktioniert, fragt er den Gleichen DHCP nach DHCP-Erneuerung, selbst wenn es laut Batman kein GW mehr ist. Ich müsste DHCP auf w2 explizit ausschalten, damit dieser nicht mehr antwortet.

Da niemand außer Dir Probleme mit w2 hat, ich diesen selbst gerade nutze und Du „komische“ IP berichtest, kann ich den Fehler nicht lokalisieren. Findet jemand einen Fehler hier:

subnet 10.156.0.0 netmask 255.255.0.0 {
interface bat-gl;
range 10.156.244.0 10.156.247.255;
default-lease-time 600;
max-lease-time 1200;
option interface-mtu 1280;
option domain-name-servers 8.8.8.8;
option broadcast-address 10.156.255.255;
option subnet-mask 255.255.0.0;
option routers 10.156.0.242;
}

war FF offline, bin wieder rein, bekomme wieder 0.242 und bekomme kein Internet
was unterscheidet 10.156.0.242 von 10.156.0.241 ?
irgendwie scheint der nicht richtig zu reagieren.
nach 10 Min warten bin ich endlich drin

edit
hab tracert gemacht. 3 Durchläufe. jeweils 2x * und nur 1x Wert 90 bzw. 95 ms
23-25 wäre richtig.
der 0.242 antwortet nicht immer
und jetzt mal wieder gar nicht => timeouts trotz Internetverbndung lt. Status
Also entweder das DC oder der Server

der DHCP-Server wurde neu gestartet, bin gespannt ob es sich bei Dir verbessert… Aus GL kommen nicht viele Anfragen, jedoch werden auch diese beantwortet.

1 „Gefällt mir“

dasselbe. für wenige Sekunden ist es da, dann timeouts
aber ich bekomme den 0.242 immer, auch wenn ich reboote und alles lösche.

jetzt bekomme ich ihn wieder, aber vielleicht hilft das tracert, denn jetzt bekomm ich

  1. 23 - 24 - 26 - 10.156.0.242
  2. 43 - 44 - 43 - 100.64.0.220


also Timeouts nach 100.64.0.220
also DC-Problem

edit:
100.64.0.220 lässt sich auch nicht via Netcologne direkt erreichen.
und damit auch 10.156.0.242 nicht

btw: seh ich das richtig, dass mittlerweile GL zeitweilig mehr Nodes und clients hat, als Wupper?

bei 100.64.0.220 handelt es sich um eine CGN-Adresse. Diese wirst Du niemals von fremden ASen erreichen können. Nach dieser Adresse folgt das FFRL-Backbone. Wie gesagt: ich sehe keine Probleme.

traceroute to wieistmeineip.de (212.19.62.76), 30 hops max, 60 byte packets
 1  10.3.0.242 (10.3.0.242)  31.880 ms  33.252 ms  34.695 ms
 2  100.64.0.220 (100.64.0.220)  61.511 ms  62.684 ms  62.998 ms
 3  irb-1050.bb-a.fra3.fra.de.oneandone.net (195.20.242.193)  63.596 ms  64.168 ms  64.541 ms
 4  te0-0-2-3.c150.f.de.plusline.net (80.81.192.132)  65.283 ms  65.964 ms  66.728 ms
 5  82.98.102.13 (82.98.102.13)  67.553 ms  68.127 ms 82.98.102.9 (82.98.102.9)  71.011 ms
 6  82.98.102.63 (82.98.102.63)  227.918 ms  150.905 ms  61.177 ms
 7  vhost03.anw.de (212.19.62.76)  46.464 ms  49.506 ms  50.469 ms

Um auf die Frage des Threads zu antworten: es scheint sich um ein Einzelfall zu handeln. Kann das bitte von @PetaByteBoy verifiziert werden. Und stelle bitte die Hop Penalty auf mindestens 100 auf dem Kartenserver

echo 120 > /sys/class/net/bat0/mesh/hop_penalty

w2 bekommst Du nur, weil der besser angebunden ist als w0 und w1.


Total OT:

Nein, GL ist ein Teil von Wupper. Wupper hat um die 1200 Knoten wovon 290 auf GL entfallen. Was Du da siehst ist die Momentandarstellung aus der Vergangenheit: Wuppertal verglichen mit GL. Da Hat Wuppertal weniger Knoten als Ihr. Das ist schon seit langem so, da wir nicht so viele Freifunker sind, wie bei Euch im Kreis. Aktuelle Statistiken gibt es übrigens hier: http://statistik.freifunk-wuppertal.net/

Klingt für mich so als ob da irgendwie noch zusätzlich Routen announced würden und auf dem (lokalen Freifunk-)Netz bei Dir noch ein weiterer DHCP-Server herumfunkt, also z.B. ein Kabelmodem.

bei 100.64.0.220 handelt es sich um eine CGN1-Adresse.

ja, mein Denkfehler fiel mir erst später auf

Nein, GL ist ein Teil von Wupper.

ja, ich meinte auch Wuppertal und nicht Wupper. Hatte immer angenommen, Wuppertal sei wesentlich grösser als alle anderen.

bei Dir noch ein weiterer DHCP-Server herumfunkt, also z.B. ein Kabelmodem.

keine Idee, wie das sein könnte.

Das Problem habe ich auch erstmalig gestern registriert, jetzt verbindet es immer mit 0.141 und alles ist OK
Allerdings deutet das tracert vom FF-Router aus

  1. 23 - 24 - 26 - 10.156.0.242
  2. 43 - 44 - 43 - 100.64.0.220

für mich auf ein Problem bei dem physischen Server hin
10.156.0.242 ist ja wohl kein eigenes Blech, oder?

was trst Du überhapt an? Die ganze Zeit über sehe ich die Ausgabe von irgendeinem Befehl. Wie soll ich das nachvollziehen?

Kann nicht sein, da ich bereits schrieb, dass neben anderen in GL auch andere in Wupper den w2 nutzen und keine Probleme berichten. @PetaByteBoy hat das Problem auch nicht bestätigt.

siehe Wiki

Ich (GL.Wupper) habe bei meinen Flüchtlingsunterkünften (hier nur wegen lokalen Probs., z.B. Uplinkrouter down etc.) und den anderen Knoten keine allgemeine Probleme.

das beantwortet nichts.
Frage ist: Wer bekommt im Client StandardGW + DHCP Server 10.156.0.242 UND hat Problem? (aber keine Probleme, wenn StandardGW + DHCP Server 10.156.0.241)

Ich hab auch schon ein paar mal meinen Uplink neu gestartet und auch schon Wupper2 problemlos benutzt.

Problem trat auch seit dem nicht wieder auf. Gestern wurde nur immer 10.156.0.241 (problemlos) zugewiesen, und heute 10.156.0.242, auch ohne Probleme. Da das vorher noch nie bemerkt wurde und danach auch nicht, tippe ich immer noch auf eine Ursache, die beim DC oder, noch eingegrenzter, bei der Hardware, zu suchen ist.