Warum werden LAN Ports standardmässig nicht abgeklemmt

Nach meinem bisherigen Wissenstand ist das Einstecken von LAN Kabeln im normalen Betrieb das größte und einzige Risiko das ein Freifunker hat. Auch wenn wir es x mal überall schreiben und vielleicht auch mit Aufklebern die LAN Ports abkleben frage ich mich warum überhaupt die LAN Ports an einen Feld Wald und Wiesen Freifunk Router aktiviert sind. Es besteht immer das Risiko das 6 Monate nach Installation die Putzfrau den Router aus versehen rausrupft und dann falsch wieder anschliesst.

Könnte man die LAN Ports im normalen Modus nicht einfach abschalten und nur im Konfig Modus scharf schalten?

Die Leute die das wirklich brauchen könnten das doch wahrscheinlich dann über SSH konfigurieren.

Ja, geht per site.conf beim Firmwarebacken:
Site — Gluon 2015.1.2 documentation (option mesh_on_lan)

Zwar sind sie dann nicht ganz aus, sondern Teil des Meshdevices, aber da die meisten Geräte die man anschließt eh kein Mesh sprechen, sollte das die meisten Probleme abfangen.

Und welche Gründe sprechen dagegen?

Höchstens Nutzer, die bisher einen kabel-gebundenen Client an den Lanports betrieben haben und es dann aktiv freischalten müssten.

3 „Gefällt mir“

Wobei die meisten Communities es den Nutzenden zutrauen, das selbst per Config (ssh, configmode) einstellen, wenn sie es denn wirklich benötigen.
(Drucker&Co will man nicht in einem offenen Netz)

Die Option wird nur bei neu aufgestellten, also mit factory-Image bespielten Knoten, aktiviert. Bei einer normalen Aktualisierung per sysupgrade oder autoupdater passiert nichts.

und was muss geschehen das es einen Beschluss gibt mit der option mesh_on_lan ab sofort in neuen Firmwares die gelben Anschlüsse abzuklemmen?

Beschlüsse allein helfen wenig, wenn nicht klar ist, wer es umsetzt.
Zumindest in der Standard-Einstellung besteht keine Möglichkeit, Lan-Ports abzuklemmen.
Gluon sieht seit der Revision 2015.1 lediglich die Auswahlmöglichkeit wor, die Lanports wahlweise mit „Freifunk-Clientnetz“ oder mit „Freifunk Meshprotokoll“ zu belegen und dafür auch einen Standardwert (für Neuinstallationen) vorzugeben.

also ich dachte es gäbe

  • jemanden der heute die Firmwares baut
  • einen Parameter mesh_on_lan der die normale Nutzung verhindert
  • und wir bräuchten nur noch allgemeine Zustimmung das wir es machen

Stimmt was nicht und wenn ja was fehlt?

Ein Beschluss? Um diejenigen, die freiwillig, in ihrer Freizeit, unentgeldlich an der Firmware arbeiten dazu zu zwingen, es nach deinen Wünschen umzusetzen?

YMMD!

2 „Gefällt mir“

Es freut mich das ich durch meine vielleicht unglückliche Wortwahl zu Deinem Wohlbefinden beigetragen habe. (das wort „zwingen“ hast Du Dir aber selbst ausgedacht.)

Es ging mir nur darum dieses Thema einer Lösung zuzuführen und durch meine Unwissenheit war ich auf der Suche nach einer Art und Wiese wie man diesem offenen Thema eine (bitte das richtige nette unschuldige wohlwollende Wort auswählen)

  • Beschluss · Entscheidung · Entschließung · Resolution

abzuschließen.

Mein Vorschlag wäre jeden LAN-Port einzeln konfigurierbar zu machen.

Man bräuchte für jeden Anwendungsfall eine Bridge (WAN, Client-LAN, Mesh und eine vierte, ohne weitere Interfaces). Durch zuordnen der einzelnen Ports, kann man diese als Switch-Ports im eigenen Netz (bridged mit WAN), als Client-Ports (bridgen mit dem Client-Netz), zum Meshen (bridged mit Mesh-Netz) und ungenutzt bzw. als eigenständigen Switch (bridged mit der unabhängigen Bridge) verwenden.

Fände ich einen echten Mehrwert.

3 „Gefällt mir“

Ich habe gerade ein DejaVu:

2 „Gefällt mir“

Wenn man es ganz richtig machen will, bezieht man noch die VLAN-Settings mit ein, um Ports die die selbe Funktion bekommen sollen, nur ein VLAN-Interface zur Bridge zuzuordnen und das Switchen in Hardware gemacht wird - das kann der Baustein nämlich selber.

Oder man macht es nur über die VLAN-Settings des Switch, indem mann drei VLAN-Interfaces an die drei Bridges (Client, Mesh, WAN) hängt und den Rest ohne Interface-Geschubbse über den Switch zuordnet.

Es gibt doch eine klare Frage, die den Weg zum Ziel versperrt:

Wer baut die Firmware für Rhein Sieg?

@stefan $Leute wünschen sich MoL

Ich glaube die Uursprüngliche Idee war unbedarfte Knotenaufsteller die Möglichkeit zu rauben ihre anderen Geräte ausversehen ins Netz zu stellen weil sie das Netzwerkkabel falsch einstöpseln. Eine grafische Konfigmöglichkeit für VLan im Expertenmodus wäre toll. Werde mit der Konsole nicht so richtig warm :slight_smile:

1 „Gefällt mir“

Hi @PetaByteBoy

ja ich habe das hier verfolgt, aber noch nicht die Zeit gehabt mich einzubringen.

Die Entscheidung liegt nicht bei mir das einzubinden. Wenn der hier anwesende teil des RSK das gerne in der Firmware haben möchte ist das natürlich kein Problem.

Die Fragestellung des Threas „Warum werden die Lanports nciht abgeklemmt“ klingt danach, dass wir uns gemeinsam bemühen sollten, eine Antwort darauf zu finden.
Also entweder eine tecnische Rechtfertigung, dass es eben sinnvoll ist, dort die br-client anliegen zu haben.
Oder aber eine organisatorische Antwort der Richtung „Derjenige, der die Firmwarebaut, der besteht darauf“.
Oder eben ein Verweis auf einen Beschluss der Community, dass es eben genau so zu handhaben ist in der „offiziellen“ Firmware.

Das kann ich schonmal verneinen :wink:

Ansonsten bin ich einer von denen die eher der Meinung sind aus den LAN Ports sollte Freifunk rausfallen. Aber wie gesagt würde ich mich nicht dagegen streben MoL in die Firmware einzubauen wenn das gewünscht ist.

Ich sehe zumindest mit dem Standard-Gluon keine Möglichkeit, die Lanports komplett abzuklemmen.
Oder gibt es ein Paket, welches ich nicht kenne, was das übernimmt?