View Issue Details

IDProjectCategoryView StatusLast Update
0000120Freifunk Franken FirmwareGeneralpublic2019-11-21 21:26
ReporterChristianD Assigned To 
PriorityhighSeveritymajorReproducibilityalways
Status closedResolutionunable to reproduce 
Summary0000120: Neue Firmware wechselt VPN Daten der Hood nicht mehr bei Hoodwechsel
DescriptionEs sieht aktuell so aus als würde die neue FIrmware 20181202 fastd nicht mehr neu reloaden bei Hoodwechsel.
Die config ist komplett auf die neue Hood angewendet (fastd config, ULA v6, usw.) er bleibt aber per VPN mit der alten Hood verbunden.
Ich konnte das ganze bisher nur remote analysieren:
- /etc/init.d/fastd restart killt den Router und er ist danach weder in der neuen noch in der alten Hood auffindbar
- reboot behebt das Problem und der Router ist anschließend in der richtigen Hood

Ursache bisher unklar
TagsNo tags attached.
Attached Files
socketfastd.txt (1,895 bytes)   
{
  "uptime": 25421,
  "interface": "ffffustdVPN",
  "statistics": {
    "rx": {
      "packets": 1561,
      "bytes": 385778
    },
    "rx_reordered": {
      "packets": 0,
      "bytes": 0
    },
    "tx": {
      "packets": 949,
      "bytes": 208302
    },
    "tx_dropped": {
      "packets": 0,
      "bytes": 0
    },
    "tx_error": {
      "packets": 0,
      "bytes": 0
    }
  },
  "peers": {
    "d13b737d444e0190c1882adf5ac94db84a6a2XXX": {
      "name": null,
      "address": "188.194.XXX.XXX:46821",
      "connection": {
        "established": 23719,
        "method": "null",
        "statistics": {
          "rx": {
            "packets": 1003,
            "bytes": 232718
          },
          "rx_reordered": {
            "packets": 0,
            "bytes": 0
          },
          "tx": {
            "packets": 461,
            "bytes": 103402
          },
          "tx_dropped": {
            "packets": 0,
            "bytes": 0
          },
          "tx_error": {
            "packets": 0,
            "bytes": 0
          }
        },
        "mac_addresses": [
          "32:51:d0:64:3b:26"
        ]
      }
    },
    "d4afb4357a4c5e08c12b17faf2f9a4a41081XXX": {
      "name": null,
      "address": "77.2.XXX.XXX:34952",
      "connection": {
        "established": 22922,
        "method": "null",
        "statistics": {
          "rx": {
            "packets": 558,
            "bytes": 153060
          },
          "rx_reordered": {
            "packets": 0,
            "bytes": 0
          },
          "tx": {
            "packets": 488,
            "bytes": 104900
          },
          "tx_dropped": {
            "packets": 0,
            "bytes": 0
          },
          "tx_error": {
            "packets": 0,
            "bytes": 0
          }
        },
        "mac_addresses": [
          "16:60:8f:ac:91:08"
        ]
      }
    }
  }
}
socketfastd.txt (1,895 bytes)   

Activities

ChristianD

2019-01-13 23:31

manager   ~0000327

Kleiner Zusatz:
- /etc/init.d/fastd restart killt den Router und er ist danach weder in der neuen noch in der alten Hood auffindbar
nach paar Minuten (ca. 10Minuten) war der Router dann doch wieder in der neuen Hood auffindbar, ein restart behebt das Problem also ebenfalls, ich teste jetzt bei einem Router noch ein reload

ChristianD

2019-01-13 23:34

manager   ~0000328

sieht so aus als hätte /etc/init.d/fastd reload keinen Effekt, es passiert einfach gar nix
https://github.com/FreifunkFranken/firmware/blob/master/src/packages/fff/fff-vpn-select/files/usr/sbin/vpn-select#L77-L80

ChristianD

2019-01-14 00:23

manager   ~0000329

Kleiner Zusatz noch:
Alte Hood gab es 2 Gateways, eines war mit DNS eingetragen, das 2. mit IP
In der neuen Hood waren die gleichen Gateways eingetragen, diesmal haben aber beide einen DNS bekommen (die erste Hood lief mit IP vom 2. GW weiter)

Sofern nur das 1. Gateway das immer einen DNS hatte in den Hoods aktiv war, war alles ok, wo die Router aber genau hin verbunden waren kann ich nicht mehr sagen da ich das nur über das Monitoring geprüft habe und da die config der Router ja komplett auf der neuen Hood war, sah dort alles richtig aus. Seitens Batman am Gateway hab ich das nicht geprüft wobei ich im nachhinein glaube das es zu wenig Router (nur alte FW und die neuen waren noch in der alten Hood?) waren. Sicher sagen kann ich das aber nicht mehr

Sobald das 2. Gateway online ging, waren die Hoods über das 2. Gateway verbunden. Es sah so aus als würden die Router zu beiden Hoods diesen Gateways verbunden zu sein. Dies schien aber nur bei Routern mit der neuen Firmware (Dezember) der Fall zu sein, ältere Router mit August FIrmware sahen richtig aus.

Ganz sicher bin ich mir nicht mehr ob das alles genau so stimmt oder ob ich was übersehen habe. Ich denke man muss diesen Fall nochmal im kleinen mit einem Router am Schreibtisch nachstellen um das Problem zu analysieren im Produktivsystem ist eine Diagnose schwierig weil die problematischen Router alle remote stehen.
Ich habe die neue Hood erstmal wieder gelöscht und danach sieht alles wieder gut und richtig aus

ChristianD

2019-01-23 23:07

manager   ~0000330

Der Bug scheint in ähnlicher Form wieder aufgetreten zu sein:
Ein Router der vorher anscheinend in der Hassfurt Hood war, ist auf einmal in meiner priv. Hood wo das Hoofile öffentlich ist aufgetaucht. Man kommt in diese Hood nur rein, wenn man die Hoodfile per Hand auf den Router kopiert (/etc/hoodfile). Anscheinend hat er aber die Verbindung in die Hassfurt Hood nicht los gelassen und somit meine Hood mit Hassfurt verbunden. Zusätzlich ist dieser Router nie Online im Monitoring aufgetaucht und sendet auch keinerlei Alfreddaten. Da es sich um ein fremdes Gerät handelt, hab ich auch keinen Zugriff auf diesen Router, u.U. kann es sich hier auch um eine mutwillige Störung des Netzes handeln und um keinen Bug, dies kann ich nicht sicher sagen. Es hat sich um einen wdr4300v1 gehandelt. Die einzige Möglichkeit diese Verbindung zwischen den Hoods zu lösen war, am Gateway den Router im fastd zu sperren.

ChristianD

2019-01-24 08:26

manager   ~0000331

Zusatz zum ursprünglichen Problem:
Ich hab gestern auf meinen Gateway die alte Polygonhood die schon seit das Problem bekannt wurde wieder aufgelöst wurde, wieder eingeschaltet und es verbinden sich nach wie vor 2 Router per VPN mit meinem Gateway obwohl die Hoodfile nirgendwo mehr existiert. Es handelt sich aktuell um diese 2 Router:
https://monitoring.freifunk-franken.de/routers/7594
https://monitoring.freifunk-franken.de/routers/3454
Im Anhang die socket Daten von fastd (IP und Key sind manuell zensiert)

ChristianD

2019-01-27 09:16

manager   ~0000332

Wir haben nun die Polygone Hood wieder angelegt:

- Vor einer Woche wurde das 2. GW schon in der alten Hood auf DNS statt IP umgestellt und auch in der neuen Hood wurde es mit DNS nun eingetragen
- Das 1. GW hat bisher immer den gleichen fastd key verwendet, er wurde jetzt für die neu erstellte Hood geändert und einzigartig gemacht

Durch diese Änderungen scheint es nun geklappt zu haben und die Router haben alle ordentlich gewechselt und die Hoods sind sauber getrennt.

Woran es endgültig lag kann ich nicht mehr sagen.

fbl

2019-06-22 22:24

administrator   ~0000342

Besteht dieses Problem noch?

Adrian Schmutzler

2019-10-07 14:36

manager   ~0000346

Nach meiner Kenntnis trat seitdem nichts vergleichbares mehr auf.

fbl

2019-11-21 21:26

administrator   ~0000348

Mir ist nicht bekannt, dass etwas vergleichbares erneut aufgetreten wäre.

Issue History

Date Modified Username Field Change
2019-01-13 23:29 ChristianD New Issue
2019-01-13 23:31 ChristianD Note Added: 0000327
2019-01-13 23:34 ChristianD Note Added: 0000328
2019-01-14 00:23 ChristianD Note Added: 0000329
2019-01-23 23:07 ChristianD Note Added: 0000330
2019-01-24 08:26 ChristianD File Added: socketfastd.txt
2019-01-24 08:26 ChristianD Note Added: 0000331
2019-01-27 09:16 ChristianD Note Added: 0000332
2019-06-22 22:24 fbl Note Added: 0000342
2019-10-02 12:46 fbl Category Freifunk Franken Firmware => General
2019-10-02 12:48 fbl Category General => General2
2019-10-02 12:49 fbl Category General2 => General
2019-10-07 14:36 Adrian Schmutzler Note Added: 0000346
2019-11-21 21:26 fbl Status new => closed
2019-11-21 21:26 fbl Resolution open => unable to reproduce
2019-11-21 21:26 fbl Note Added: 0000348