Tunneldigger Gatewayauswahl kaputt

Moin,

wir sollten uns kurzfristig überlegen, wie wir mit diesem Bug umgehen.

Möglichkeiten:

  1. Von mir vorgeschlagenen Patch überall einkompilieren
  2. Alle L2TP-Domänen auf zwei Gateways reduzieren und auch die IP-Adressen entfernen
  3. Von „usage“ auf „first-available“ umstellen

Gegen letztere Variante spricht, dass wir das dann wieder rückgängig machen müssten.

Das sollten wir innerhalb der nächsten Woche umsetzen, da wenn uns in einer Domäne das primäre Gateway wegbricht, alle Knoten der Domäne offline sein werden.

@Fungur, @kgbvax, @FanLin, @Parad0x, @void, @paulinsche, @descilla, @MPW

Grüße
Matthias

1 „Gefällt mir“

Ich wäre für Variante drei, denn denn ein gateway ist meiner Ansicht nach ausreichend und vereinfacht das ganz auch. Das zweit gateway sollte nur aktiv werden, wenn das primäre wegbricht.

Das führt aber zu einer ziemlichen Einschränkung: Wenn wir Durchsatz von einer VM auf eine andere verschieben wollen, müssten wir jedes mal ein Firmwareupdate ausrollen.

Ich dachte eher an eine Änderung des DNS. Aber das hatten wir schon mal an einer anderen Stelle diskutiert.

1 „Gefällt mir“

Was ist der “von dir vorgeschlagene Patch”?

Ein Fallback auf den first_available-Auswahlalgorithmus, wenn usage kein sinnvolles Ergebnis liefert, weil z. B. das ausgewählte Gateway gar nicht erreichbar ist. (Zur Erklärung, der Client hat drei Algorithmen, nach denen er das Gateway auswählt: zufällig, zuerst verfügbar und nach Auslastung. Zufällig liefert auffällig oft dasselbe Ergebnis, zuerst verfügbar funktioniert korrekt und nach Auslastung (von dem ursprünglichen Programmierer „usage“ genannt) ist völlig kaputt, wenn mehr als zwei Gateways konfiguriert sind. Usage ist bei uns eingestellt.)

@Fungur und ich haben heute das Ding so umprogrammiert, dass usage jetzt aber funktioniert. Es ist zwar nicht ganz sauber, aber das Ding ist völlig chaotisch programmiert, mehr ging nicht. Wir wollen es zusammen mit @descilla mal neu strukturieren.

1 „Gefällt mir“

Show me the code :slight_smile:

https://github.com/ffrl/tunneldigger/pull/3

1 „Gefällt mir“

Ist ja schon merged :smile:

Denk ihr dann daran das zu up-streamen?

Hey,

ich lese hier ja auch zwischendurch mal mit.

Wir verwenden für eine Domäne auch Tunneldigger. Unter gluon 2015 lief alles einwandfrei. Jetzt haben wir images mit gluon 2016 gebaut. Nach längerer Zeit kamen die router erst online. Außer einen v6 Prefix erhält der Client nichts: Kein IPv4, kein Durchsatz.

Habt ihr hier auch Ideen?

Hm, der Tunneldigger baut das Interface nur auf. Um den Rest kümmert sich dann der Kernel.

Verwendet ihr schon die gepatchte Version?

Ja, die neue Version.
Naja mit Gluon 2015 läuft es ja. Daher funktioniert das Gateway

Zeig mal ein logread.

Hier einmal der logread:

Edit: http://pastebin.com/EWtb7JxA
Da fehlte die hälfte

Der hat Probleme mit der DNS-Auflösung. Beim ersten mal läuft alles ins Timeout und dann wird der Tunneldigger neu gestartet und dann klappt es.

Dann müsste der Tunnel eigentlich stehen. Guck dir mal

batctl o

an. Sind da alle anderen Knoten zu sehen? Wo finde ich eure site.conf und -.mk?

Hi,

der Router hat sogar statische DNS Daten daher sollte es klappen.

Die siteconf ist hier zu finden:

Konntest du schon einen Blick riskieren?

Leider noch nicht.

@stefa6, dieses Image hier (http://firmware.nordwest.freifunk.net/stable/gluon-ffnw-0.8.2-x86-virtualbox.vdi) hat Fastd und funktioniert. Wo finde ich das mit L2TP?

Diese sind unter http://runner02.ffnw.de/osna/0.1.6%2Bexp20160507/ zu finden.

Leider haben wir kein x86er Image…