WAN Uplink im Monitoring bei layer3 fehlt #95
Labels
No Label
RFC
RFT
WIP
blocked
bsp
bug
build/scripts/tools
duplicate
feature
fixed
layer3
mantis
more details required
needs changes
node
packages/fff
rejected
security
trivial
upstream
No Milestone
No Assignees
6 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: freifunk-franken/firmware#95
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Da im Nodewatcher generell nur auf fastd abgefragt wird, funktioniert WAN Uplink im Monitoring bei Layer3 nicht:
https://git.freifunk-franken.de/freifunk-franken/firmware/src/branch/master/src/packages/fff/fff-nodewatcher/files/usr/lib/nodewatcher.d/10-systemdata.sh#L110
Mein Versuch den Abschnitt nach fff-fastd zu schieben und das gleiche für fff-wireguard zu machen ist daran gescheitert das diese Information innerhalb von system_data in der xml liegt. Man müsste also in dem 10-systemdata.sh Script nochmal ein "Unterscript" aufrufen und das ist mir dann zu schräg. Hab gerade keine Idee wie man das schön bekommt.
WAN Uplink bei layer3 fehltto WAN Uplink im Monitoring bei layer3 fehltDa die Option im Monitoring WAN Uplink heißt, könnte man das auch generell so machen wie es schon im WebUI gemacht wird und einfach nur prüfen ob WAN schon existiert:
https://git.freifunk-franken.de/freifunk-franken/firmware/src/branch/master/src/packages/fff/fff-web-ui/files/www/ssl/cgi-bin/home.html#L42
mir ist noch eine Idee eingefallen:
Man macht eine 10a-systemdata.sh die das system_data xml aufmacht, von 10b- bis 10y- kann dann in das xml rein geschrieben werden und 10z-systemdata.sh macht das system_data xml wieder zu.
Besonders gut gefällt mir das aber auch nicht
Sollte man nicht zwei Variablen einführen:
VPN Uplink und WAN Uplink.
Die Änderung in der 10a-systemdata.sh hat funktioniert auf dem L3 Routern.
Allerdings wird dafür die vpn_active variable missbraucht.
WAN Uplink ist VPN-Uplink, wie die Variable vpn_active nahelegt. Wir hatte diese Diskussion bereits und sind zu keinem eindeutigen Ergebnis gekommen, mein Erinnerung geht aber dahin, dass dieser Parameter eben nur für VPN-Verbindungen gilt.
Speziell der Begriff "WAN-Uplink" ist auch kaum zu definieren und für Layer-3-Geräte auch nicht unbedingt allzu sinnvoll als Information zu nutzen.
Also müssten wir im Monitoring die Zeile eigentlich nach VPN Uplink unbenennen und dann ist sowohl ein laufender fastd, wie auch ein laufender wireguard ein VPN Uplink und bekommt den Haken?
Versteh ich dich da richtig?
Ja. Ich glaube, wir sind damals so verblieben, dass das mit dem Umbenennen nicht so wichtig ist; aber im Prinzip ja.
Ob wireguard in diesem Zusammenhang als VPN Uplink zählt, ist dann eine separate Frage. Es ist wohl "VPN" und sicherlich auch ein "Link", aber ist es "up"? Ich würde das eher als horizontalen Link sehen, und daher wäre es streng genommen kein Uplink für mich. (Wie würdest du hier einen GRE behandeln?)
Im Prinzip ist die jetzige Verwendung "nur für fastd" stimmig unter der Prämisse, dass es sich um eine VPN-Verbindung "nach oben" handelt, also vom Knoten zum Gateway/"Router".
Ich bin deswegen nicht grundsätzlich gegen eine Umstellung, bitte verstehe dies primär als Erklärung. Aber unbedingt nötig finde ich eine Änderung hier auch nicht; hier sollte man mal eruieren, was die Mehrheit für sinnvoll hält bzw. erwartet.
Wie wäre mit "Verbindung ans FFF Netz" als Text.
Dann isses egal über welchen weg.
Darunter fällt dann aber auch Richtfunk. Auch darüber ist man in das FF Netz verbunden
Ja, das wäre möglich, aber wieder eine andere Information. Der wireguard-Tunnel allein bedeutet ja nicht, das z.B. Babel richtig darüber geroutet wird. Wenn "Verbindung ans FFF-Netz" einen Haken hat, würde ich erwarten, dass auch Routing vorhanden ist (was dann geprüft werden müsste).
Und hier wird es dann interessant. Warum wäre dann z.B. Wireguard ein VPN-Uplink und Richtfunk nicht, obwohl das Ergebnis das gleiche ist? Interessiert uns hier wirklich das Protokoll?
Genau diese Unstimmigkeit zwischen verschiedenen Links war meiner Erinnerung nach der Grund, VPN-Uplink nur für Nodes zu benutzen.
Weil Richtfunk kein VPN ist. Ich selbst definiere hier (wenn auch das wieder leicht für falsch ist aber für Freifunk Definition passt es einfach am besten) VPN als: "Ich baue eine Tunnel durch ein fremdes Netz"
Ein wireguard wird typischerweise durch ein Telekom/Vodafone/whatever Netz gebaut, Richtfunk ist aber mein/unser eigenes Netz da ist niemand anders dazwischen.
Das ist mir schon technisch klar, nur ist diese Information inhaltlich wirklich wertvoll genug?
Dann sollte man wirklich eine Feste stelle im Freifunk netz pingen und es "Verbindung zu FFF" nennen.
Dann wäre es Aussagekräftig.
WAN Verbunden sagt nix aus, Tunnel verbunden sagt nix aus, RF verbunden auch nicht.
Erst wenn Zentrale Dienste erreichbar sind.
Ich persönlich finde halt, dass dieses Feld in seiner enormen Vereinfachung eigentlich nur für Nodes Sinn macht. Beim Node will man wissen, ob es ein Uplink- oder Mesh-Knoten ist. Nur dafür ist das gut.
Beim Gateway ist die Situation komplexer, und ein einzelner Parameter wie "WAN/VPN-Uplink" ist eigentlich zwangsläufig irreführend. Daher macht es in meinen Augen Sinn, diesen Wert einfach nicht zu befüllen.
also ich sehe das ehrlich gesagt nicht so.
Auch bei Layer 3 gibt es "Meshknot.." nee "Meshrouter" das sind nämlich alle Router die keinen Internetanschluss haben sondern irgendwo auf nem Hochhaus/Kirche/Treibhaus/etc. stehen.
Dann gibt es noch die Router die bei mir und anderen im Wohnzimmer stehen und per wireguard VPN haben.
Das ist bei Layer 3 halt alles nur eine Nummer größer als bei den alten Batman-adv Netze wo die Knoten normalerweise im gleichen Haus stehen. Aber rein vom Prinzip ist es genau das gleiche nur das es eben ein Layer höher ist.
Nein, du kannst diese Unterscheidung mit oder ohne Internetanschluss nicht mit dem Begriff "mesh" zusammen bringen.
Darum geht es aber auch nicht. Wie Adrian schon sagte, dient das Feld zur unterscheidung bei der node-firmware ob vpn oder nicht. Und ist meines Erachtens auch nur da sinnvoll. Da macht es wirklich einen Unterschied.
Dass eine l3-firmware irgendwie mit "dem Netz" verbunden ist versteht sich von selbst. Und zwar via Layer 3 Verbindungen. Da ist die Information, ob ein vpn-Tunnel dabei ist, kein wirklicher Mehrwert. Darum wuerde ich es bei l3-Routern ev. sogar im Monitoring ausblenden.
Ich habe tatsächlich auch schon überlegt, das vorzuschlagen. Das ist aber so einfach gar nicht möglich, weil das Monitoring nicht weiß, was ein Layer-3-Router ist und was nicht. Am einfachsten wäre hier noch, nach Firmware zu filtern, das möchte ich aber eigentlich auch nicht, weil das ist Pfusch und muss aktuell gehalten werden.
Mesh hab ich hier so verwendet, wie es normalerweise im Freifunkumfeld verwendet wird. Ein Meshrouter / Meshnode ist da ein Gerät das keinen Internetuplink hat sondern sich "aus der Luft" (oder Kabel) Netzzugang holt
Das ist doch bei Layer 3 genau das gleiche? Auch da gibt es VPN oder nicht. Es ist halt nur eine andere Ebene aber sonst genau das gleiche. Es gibt Geräte die Internetuplink (VPN) haben und es gibt welche die das nicht haben. Ich verstehe nicht wo ihr da einen Unterschied seht das dies bei Layer 3 anders ist?
Das ist aber bei Node Firmware das gleiche. Die ist ja auch irgendwie "mit dem Netz verbunden". Also wäre da nach deiner Begründung auch da kein Mehrwert vorhanden?
Nochmal ganz allgemein:
Wo seht ihr einen Unterschied zwischen Node und Layer 3? Der Aufbau ist genau das gleiche. Es gibt Geräte die per VPN (fastd, wireguard, gre, vxlan, whatever) ans Netz angebunden sind und es gibt Geräte die per LAN-Kabel/Wifi/RF/whatever angebunden sind und zwar bei beiden Varianten nur das eben andere Technologien verwendet werden aber ansonsten genau der gleiche Netzaufbau.
Prinzipiell ist mir der Haken ja wurscht, wenn ihr das alle nicht wollt bleibt das so, ist mir im Prinzip wurscht. Aber irgendwie würde mich dennoch jetzt interessieren wo ihr den Unterschied seht und deshalb führe ich die Diskussion nochmal weiter ;)
Schließe mich Christians Beschreibung und Meinung an.
Der Mehrwert für den Betrachter des Monitorings ist da auch ganz klar: Man sieht auf einen Blick, ob es noch Verbindungen gibt (geben könnte), die über die Linien auf der Karte hinaus gehen (z.B. ins RZ etc.)
Meiner Meinung nach ist die einzig sinnvolle Info, ob der Router mit dem FFF Netz verbunden ist oder nicht.
Ich schließe mich Christian an. Wenn das Ding ein aktives VPN hat, sollte der Haken bei dem Feld drin sein. Der Name wäre mir egal.
Wenn jemand einen Wireguard manuell auf einem L3 konfiguriert und der eine Verbindung hat, reicht das als Info, dass es ein Gerät ist, was am Internet hängt.
Ob Babel richtig routet, ist ne andere Sache, welche das Feld nicht beantwortet muss.
(Und das sollte doch über das Neighbours-Feld ersichtlich werden?!)
Es hilft aber beim Verstehen von fremden RF-Netzen, sei es aus Interesse, oder weil man diese geerbt bekommt und bringt eben eine zusätzliche Info, die man je gerne in einem Monitoring hat.