View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000120 | Freifunk Franken Firmware | General | public | 2019-01-13 23:29 | 2019-11-21 21:26 |
Reporter | ChristianD | Assigned To | |||
Priority | high | Severity | major | Reproducibility | always |
Status | closed | Resolution | unable to reproduce | ||
Summary | 0000120: Neue Firmware wechselt VPN Daten der Hood nicht mehr bei Hoodwechsel | ||||
Description | Es 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 | ||||
Tags | No 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" ] } } } } | ||||
|
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 |
|
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 |
|
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 |
|
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. |
|
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) |
|
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. |
|
Besteht dieses Problem noch? |
|
Nach meiner Kenntnis trat seitdem nichts vergleichbares mehr auf. |
|
Mir ist nicht bekannt, dass etwas vergleichbares erneut aufgetreten wäre. |
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 |