Ich habe hier eine alte Fritzbox, die leider nicht direkt als Freifunk Router eingerichtet werden kann.
Daher folgende Idee:
Ich schließe die alte Fritzbox per LAN an einen vorhandenen Freifunk Router an und nenne das WLAN der alten Fritzbox auch Freifunk. Ich nutze die Fritzbox quasi als AP (Accesspoint/Hotspot mit SSID „Freifunk“) oder vereinfacht für die Laien (und Suchmaschinen) als Repeater.
Kann ich dann in der Fritzbox als Internetverbindung einfach „vorhandene Internetverbindung über LAN“ angeben oder lieber irgendwas, dass er die IP Adressen vom Freifunkrouter bezieht?
Zur räumlichen Situation: Die beiden Router stehen dann im unterschiedlichen Gebäuden, ca 15-20 m entfernt. Weitere WLANs gibt es kaum. Freifunk WLAN ist auch kein weiteres in der Nähe.
Irgendwas funktioniert dann. Ein Hotspot, der eine SSID „Freifunk“ abstrahlt.
Es ist nur ziemlich weit von Freifunk entfernt. Da es dann kein Wifimesh mehr gibt.
Je nach lokaler Community könntest Du für so einen Vorschlag durchaus böse Antworten erhalten.
Wenn nur Wifimesh das Problem ist, dann ist das am geplanten Standort egal. Dort ist kein weiterer Freifunkrouter in Sicht. Und falls das doch irgendwann Mal der Fall sein sollte, kommt die Fritzbox halt weg - falls sie nicht sowieso schon vorher den Geist aufgibt.
Bleibt also die Frage, ob die Fritzbox eigene IPs vergeben soll, oder ob diese vom Freifunkrouter bezogen werden sollen/können.
(Lokale Community Freifunk Münsterland)
Du solltest (meine Meinung, muss nicht die anderer wiederspiegeln) definitiv die Fritz!Box als reinen AccesPoint verwenden (also die Fritz!Box vergibt keine eigenen Adressen), denn wenn Mesh schon wegfällt, dann sollte wenigstens eine Kommunikation innerhalb des Freifunk Netzes möglich sein. Dafür darf aber keine Firewall oder ein NAT dazwischen sein. Sonst bleibt ja wirklich nichts mehr von Freifunk, außer der SSID, übrig. Dann könntest du auch einen x beliebigen „anderen“ VPN-Server für die Ausleitung Des Traffics nutzen.
Wenn jemand meshen möchte, aber kein Wifimesh findet, dann wird die auch nicht auftauchen.
Will sagen „Es gibt aber doch gar keine potentiellen Meshpartner“: Ist kein valides Argument.
Das ist wie „keine barrierefreien (Haus-)-Eingänge bauen, weil ja gar keine Rollis hineinwollen“
Stehen die Ports des Freifunk-Knotens auf (Freifunk-) LAN oder auf MeshOnLAN? Sprich: bekommt ein Laptop an dem Port, wo jetzt die FB hängt, per DHCP eine IPv4-Adresse? Falls nicht, klingt das nach MeshOnLAN — ggf. ist das in Deiner Community die Voreinstellung?
Klingt erstmal nicht schlecht. Wie @wusel schrieb Mal testen ob du mit einem Computer am LAN 1 des Freifunkrouters Zugriff bekommst und dann, wenn das geht vielleicht Mal in einem der anderen Lan Ports der Fritz!Box probieren. Die verhält sich wie ein Switch, wenn sie richtig konfiguriert ist.
wenn man mag kann man 3370, 7320-30, 7360konsortitum auch unter gluon zum tanzen bewegen.
die dinger haben zwar kein wan if das sie da dsl sprechen, die hw ist aber zum meshen durchaus brauchbar wenn man ihr gluon beibringt.auch wird es da noch oenwrt patchwork zu den modellen geben müssen. aber at9fk geräte mit genug flash und ram a mesh nodes ohne uplink
Also ein Pull Request Richtung Gluon wäre schon cool.
Was das fehlende WAN Interface angeht, die Fritzboxen können doch eigentlich auch alle mit Original FW (wie oben im Thread besprochen) auf LAN 1 einen WAN Port bereitstellen. Da fehlt dann zwar die Beschriftung, die farbliche Abtrennung und ein Abstand zwischen LAN und WAN, aber wesentlich besser als nichts. Und die Chancen, das es in Gluon aufgenommen, und nicht als BROKEN markiert wird, stehen dann sicherlich auch besser.
@heini66 meinte „echtes“ WAN, sprich den DSL-Part der Fritzboxen; der tut unter OpenWrt wegen closed source nicht. Mit FritzOS geht kein Mesh, daher wären die unter OpenWrt (eingeschränkt) lauffähigen Modelle mit Gluon besser in Freifunknetzen weiter nutzbar als nur als reine Repeater.
Achso, du meinst die Idee wäre gewesen die Fritzbox als Freifunk DSL Router einzusetzen, das hatte ich jetzt nicht so interpretiert. Ich hattte angenommen, das @heini66 vielleicht davon ausgegangen war, das er den normalen DSL-WAN eben nicht verwenden kann, und das die restlichen LAN Ports sozusagen an einem unmanaged Switch hängen und man daher ohne VLAN nicht Uplink, FF-LAN, und FF-Mesh gleichzeitig auf den Ports hinbekommt. Und da wollte ich halt darauf aufmerksam machen, das es irgendwie möglich sein müsste Port 1 als einzelnes Interface anzusprechen. Port 4 übriges auch, da man dort ja das Gastnetz mit der Original FW ausgegeben kann.
klar kann man sich nen wan if auf dem switch hinfrickeln. das ganze wird im gluon aber niemals akzeptiert werden da die std’s der entwickler nicht erfüllt werden. ebenso ist da noch vie openwrt patchwork nötig da die imagnames noch nen echtes chaos sind.
pr #1803 -1805 im gluon
in der sodaföhn easybox ecke könnte man mit dem target auch räubern … ich hab nur keine geräte
Ich nähme auch einen Patch von außerhalb der Gluon-Götter für v2018 oder master … Derzeit bin ich schlicht zu doof dafür, OpenWrt-Patches nach Gluon „zu portieren“. (Ja, es fehlt auch das Interesse, da tiefer einzusteigen. Es müßte mich mal jemand ans Patschehändchen nehmen; bis „patch“ komme ich mit, was OpenWrt und/oder Gluon da mit mehrstufigen Patchen treiben, ist nicht meins …)
Das kommt darauf an, welche Standards du meinst.
Wenn es um die Methode der Dokumentation (Platform, tests) geht: Das ist erfüllbar. Muss man aber tun.
Wenn es um „fehlende Features“ geht: Das kann man alles argumentieren.
Wir haben in Gluon haufenweise Targets mit nur einem einzigen Lan-Interface
Wenn ich mich richtig an einige Vocores erinnere, dann sogar welche ganz ohne eth (ohne optionale Nachrüstung der Magnetics)
Wir haben Targets ohne funktionierendes Wifi-mesh (Bananapi-Routerboard)
Wir haben Targets mir allenfalls optionalem Wifi (x64) und ganz ohne Wifi (RPI1/2).
Will sagen: Auch ein Offloader oder Batman-Switch, oder reiner Meshnode in Gluon zu haben bringt Vorteile, weil
mit Status-Seite
auf der Map / im Monitoring (was an respondd so dranhängt)
im Autoupdater (wenn sich in der Domain mal was ändert)