ich bin gerade dabei ein paar APs zu testen, da ich plane in unserer Gegend freifunk etwas publiker zu machen. Nun frage mich ob folgendes Scenario mögich ist, erstmal unabhängig von der Community, aber möglicherweise abhängig von der verwendeten Firmware-Version:
Schritt - Clients
Ein Router mit Freifunkfirmware
mehre APs ohne Freifunkfirmware die im Freifunk-Router-LAN hängen, mit muenchen.freifunk.net SSID
die Clients verbinden sich korrekt, da der eine Freifunk-AP im LAN auch den Clients an den nicht-Freifunk-APs das passende Netz zuweist
Dieser Schritt funktioniert, allerdings ist so natürlich kein mesh möglich
2.Schritt - Mesh
wäre es ebenfalls möglich mit „mesh on lan“ und den APs mit SSID mesh.ffmuc und Ad-Hoc Modus meshing zu ermöglichen oder muss man dazu noch andere parameter anpassen z.b. BSSID? Würde der AP mit Freifnkfirmware dann über diese „Bridge“ meshen oder unterscheidet sich „mesh on lan“ vom „mesh on wlan“?
Natürlich wäre dann so wieder kein Client-Access möglich. Um Rückkopplungen zu vermeiden müßte dann am Freifunk-AP „mesh on wlan“ deaktiviert werden?
Kombi
Wenn 1+2 funktionieren, dann müßte es möglich sein wenn die APs MultiSSID-fähig sind, via VLAN das Freifunk-Client-Netz sowie das mesh-Netz am Router mit Freifunkfirmware in VLANs zu legen, so dass die jeweilige passende SSID das passende Netz bekommt.
mit WLANs / VLANs etc bin ich soweit vertraut, nur nicht mit den „Features“ der Freifunkfirmware.
Hintergrund: ich möchte Hardware einsetzen für die es keine Freifunkfirmware gibt, die aber untereinander per LAN verkabelt sein kann
Der Entwicklungsaufwand würde sich dann ggf. auch verringern.
Konkret im Einsatz habe ich einen TP-Link TL-WR841ND v10 mit Freifunkfirmware sowie 3 TP-Link CPE210 v2.0 mit Original-Firmware (nur für V1.0 und V1.1 gibt es soweit ich weis Freifunkfirmware)
Einen TP-Link Archer C7 hätte ich auch noch zur Verfügung, hier gibts aber für meine Community auch keine Firmware(ffmuc).
Hallo wakkomon, von den Münchnern habe ich hier bisher kaum jemanden gesehen. Zum meshing braucht man auch ein bisschen mehr als nur die mesh seid and adhoc, am besten kontaktierte mal die Münchner direkt
die Konfiguration „1. Schritt“ ist so möglich und funktioniert, sollte aber mit der Community abgestimmt werden. Nicht alle sehen das gerne, der eine meschende Router sollte dann wenigstens in Fensternähe oder am Rand des Gebäudes platziert werden, nicht irgendwo tief im Keller. Wie mein Vorredner schon angemerkt hat, sind die Münchener nicht so aktiv hier in diesem Forum.
„2. Schritt“, also Vermaschung über Geräte mit Originalfirmware ist nicht möglich. Die meisten der Geräte können überhaupt kein adhoc mehr, das ist quasi eigentlich tot. Und 11s noch nicht nutzbar implementiert oder nur proprietär (Stichwort Ubiquity Mesh). Außerdem ist genau da das Problem, die WLAN-Treiber können oft nicht zwei verschiedene WLAN-Standards (AP- und adhoc-Modus) gleichzeitig. Bisher läuft das stabil nur auf den Atheros-Chipsätzen und dann kannst du auch gleich die Freifunksoftware aufspielen. Außerdem reicht ein reines Weiterleiten des Signals auch nicht. Die Routinglogik muss auch abgebildet werden (Batman), und dazu braucht es ebenfalls die Freifunksoftware.
Die Kombination daraus entfällt, weil eben dein „2. Schritt“ nicht funktioniert.
ok danke für die schnelle Info, das Schritt 2 so nicht geht ist schade aber dann erstmal nicht zu ändern.
Ja der FF router ist in meinem Fall auf dem Dachboden(4.OG). Die CPE210 sind ja Richtfunk-Outdoor-APs und im Freien am Antennenmast, daher wäre die Kombi super gewesen. Habe nur leider keine V1.1 mehr bekommen. Die Idee war wegen der „Übersprechung“ in der Hochlage durch die Richtfunkkarakteristik wie beim Mobilfunk eine Zellenstruktur zu bekommen.
Dann versuche ich mein Glück mal im ffmuc Mailverteiler
Ah Danke für den Tipp, den foreneintrag verfolge ich schon ganz gespannt, sieht nach kurz vor Durchbruch aus
Stimmt Ad-Hoc muss es ja auch noch sein, das kann die Originalfirmware ldier garnicht, dann fällt Meshing damit wohl erstmal aus. Aber Interessehalber, spielt die MAC oder BSSID eine rolle beim meshing oder reicht allein die passende SSID?
ich würde nämlich soweit es von ffmuc keine Firmware für ein bestimmtes Gerät gibt einfach eine aus einer anderen Community benutzen und die site-conf von ffmuc verwenden, weis aber nicht ob das reicht, weil es anscheinend verschiedene Arten des mehings gibt und das muss ja als passendes Packet in der Firmware sein.
z.B. um den etwas schwachbrüstigen TL-WR841ND gegen meinen Archer C7 zu tauschen. Beim CPE210v2 wäre das sicher auch erstmal der Fall sobald die Jungs die Firmware lauffähig haben(in München drehen die Firmwareuhren lauch etwas langsamer).
Aber dann muss reines Client-Netz auf diesen CPE210V2 wohl erstmal reichen., danke für das super Feedback auf jeden Fall!
jo das ist wohl war , naja bis jetzt wirds nicht unterstützt, von daher kann ich sie eh nicht bauen. aber:
dafür ist die firmware unter dem thread TP-Link CPE210 v2 - Gluon Support fertig und ich kann bestätigen das die LEDE firmware auf dem CPE210v2 funktioniert. damit sollte nun Ad-Hoc Betrieb und VLANs realisierbar sein soweit ich weis, damit käme ich meiner ursprünglichen Idee mit Client- und MEsh Netz auf 2 VLANS und eigener SSIDs wieder näher.
wenn das klappt schreib ich gern hier ein wie es geht
Bin inzw. mit meinem „Konstrukt“ weitergekommen, die LEDE firmware funktioniert, kann damit am CPE210v2 VLANs erstellen, ad-hoc mode aktivieren etc… allerdings klappt das meshing noch nicht so wie gedacht.
Habe folgendes Setup:
am CPE210v2 ein VLAN1 für client, VLAN2 für mesh am ersten CPE, die Packete sind definitiv getagged
um einen Ethernet-Loop über Ad-Hoc und den Switch zu vermeiden hat jeder CPE sein eigenes mesh-vlan
am WR841N internen switch VLAN aktiviert und auf allen ports getagged, das tagging greift auch
am WR841N ist br-client auf eth0.1, bat0 und client0 gebridged, funktioniert
problem:
am WR841N mesh_lan auf eth0.2 gestellt (ohne bridge)
hier passiert nichts, kommt mir so vor als würde batman-adv packete auf eth0.2 einfach ignorieren
geht evtl hier der ethX.Y syntax nicht?
network.mesh_lan.ifname=‚eth0.2‘
oder muss ich auch erst eine bridge anlegen?
und dann noch was ganz anderes:
Habe um das ganze zu verstehen mit einer „normalen“ OpenWRT Firmware an einem Archer C7 ebenfalls experimentiert um zu verstehen wie batban-adv überhaupt funktioniert, habe es dort sogar geschafft mesh, passende bridge und freifunk-clientnetz über ad-hoc ans laufen zu bekommen(ohne mesh-vpn). allerdings natürlich auch ohne node-informationen für karte oder dass in der ibss0 übersicht am ff-node der name erscheint, wahrscheinlich fehlt hier noch „alfred“? Gibt es irgendwo eine Übersicht welche Packete etc man generell für einen funktionierenden Freifunk node benötigt, ohne eine spezielle FF firmware zu verwenden?
Hintergrund: wenn die Firmware die ich jetzt für den CPE210v2 habe funktioniert, macht es ja eigentlich schon direkt Sinn die passenden Packete gleich dort laufen zu lassen, dann hätte sich das VLAN-gebastle evtl. gleich erledigt - klar irgendwann gibts die Firmware dann vielleicht eh komplett, aber mir gehts ja mehr ums „Verstehen“
okay okay habe inzw. verstanden, dass Ad-Hoc ohne batman-adv nicht funktioniert. habe es inzw. aber auch hinbekommen eine LEDE firmware für den CPE210v2 inkl. batman-adv zu bauen
allerdings verstehe ich noch nicht ganz was ich für die knotenkarte brauche, „albert“ ja, aber wie muss ich es konfigurieren?
die Wiki bei ffmuc ist dazu leider noch etwas dürftig und bisher konnte mir dort auch keiner weiterhelfen
denke aber mal in anderen comminuties funktioneirt das ähnlich, weis hier jemand was?
das wirkt stark danach, als ob du versuchst Gluon nachzubauen. Letztendlich brauchst du alles, was Gluon auch hat: Die Firewall per iptables, VPN, Batman, Adhoc- und Clientnetz etc.
Wäre es nicht einfacher, die CPE210 v2 ins Gluon zu holen? Das ist vermutlich sogar weniger Arbeit, wenn Lede schon läuft und du hast alles fertig. Und das beste ist, davon profitieren dann alle.
schöner wäre natürlich die nötigen Änderungen aus dem „CPE210-v2-clock“ Projekt ins gluon zu übernehmen, und dann muss es ja noch ins project der jeweiligen community?
da das Packet aber nicht von mir ist und ich im Details keine Programierkenntnisse habe weis ich nciht welche Änderungen das genau sind. auch hab ich keine Ahnung von dem „Flow“ wie Änderungen von einem Source zum anderen kommen. robimarko wird das denke ich sicher irgendwie einpflegen
das Problem ist aber eher, dass das gefühlt seeehr langgeee dauern wird bis es bei meiner comunity ankommt und ich wollte einfach mal schnell loslegen
da es kein neues Target ist, sollte das relativ problemlos möglich sein. Folgende zwei Schritte müsste man durchführen:
Übernahme der Patches aus Lede in Gluon (Backport), am Besten in den Master
Hinzufügen des Images in der targets-Datei: targets/ar71xx-generic
Der erste Teil ist natürlich der aufwändigere.
Jeder kann für jede Community jede Firmwareversion jederzeit bauen. Wenn du es im Gluon hast, kannst du einfach mit eurer site.conf bauen und erhältst die für deine Community angepasst Firmware.
ok ich habe inzw. eine andere Lösung, habe die Firmware von hier:
gluon-ffv-b20171221-v-tp-link-cpe210-v2.0-sysupgrade.bin from Files...
/lib/gluon/site.json vom „ffmuc“ router kopiert
einige uci settings manuell angepasst
mesh vpn deaktiviert, nur mesh on lan aktiv
die uci settings im detail:
uci set autoupdater.settings.enabled=‚0‘
uci commit autoupdater
uci set batman-adv.bat0=mesh
uci set batman-adv.bat0.gw_mode=‚client‘
uci set batman-adv.bat0.orig_interval=‚5000‘
uci set batman-adv.bat0.hop_penalty=‚15‘
uci set batman-adv.bat0.gw_sel_class=‚3‘
uci set batman-adv.bat0.multicast_mode=‚0‘
uci commit batman-adv
uci set fastd.mesh_vpn.enabled=‚0‘
uci set fastd.mesh_vpn_backbone.enabled=‚0‘
uci set fastd.mesh_vpn_backbone_peer_ffv01=’’
uci set fastd.mesh_vpn_backbone_peer_ffv02=’’
uci set fastd.mesh_vpn_backbone_peer_ffv03=’’
uci set fastd.mesh_vpn_backbone_peer_ffv04=’’
uci set fastd.mesh_vpn_backbone_peer_ffv05=’’
uci set fastd.mesh_vpn_backbone_peer_ffv06=’’
uci set fastd.mesh_vpn_backbone_peer_ffv07=’’
uci set fastd.mesh_vpn_backbone_peer_ffv08=’’
uci set fastd.mesh_vpn_backbone_peer_ffv09=’’
uci set fastd.mesh_vpn_backbone_peer_ffv10=’’
uci commit fastd
uci set wireless.ibss_radio0.bssid=‚02:0E:8E:1E:61:17‘
uci set wireless.ibss_radio0.mcast_rate=‚12000‘
uci set wireless.ibss_radio0.ssid=‚mesh.ffmuc‘
uci set wireless.client_radio0.ssid=‚muenchen.freifunk.net‘
uci set wireless.client_radio0.disabled=‚0‘
uci set wireless.radio0.channel=‚6‘
uci commit wireless
damit klappt es erstmal wunderbar, die nodes sind inzw auch auf der karte und meshen auch mit anderen „nativen“ nodes
zusätzlich muss man auch noch die Packetfilter entsprechend anpassen, leider weis ich nicht wie man ebtables dauerhaft rebootfest speichern kann, daher tut es auch erstmal ein init-script in /etc/init.d/ebtablesinit mit folgenden ausführungsrechten: chmod u+x,g+x,o+x /etc/init.d/ebtablesinit
das script muss folgendes enthalten:
#!/bin/sh /etc/rc.common #ebtables configuration
START=10
STOP=15
start() {
echo start ebtables configuration
# commands to launch application
ebtables -t filter -N IN_ONLY
ebtables -t filter -N OUT_ONLY
ebtables -t filter -N MULTICAST_OUT
ebtables -t filter -N MULTICAST_OUT_ICMPV6
ebtables -t filter -A INPUT -p IPv4 --ip-proto udp --ip-dport 68 -j IN_ONLY
ebtables -t filter -A INPUT -p IPv6 --ip6-proto udp --ip6-dport 546 -j IN_ONLY
ebtables -t filter -A INPUT -p IPv6 --ip6-proto ipv6-icmp --ip6-icmp-type router-advertisement -j IN_ONLY
ebtables -t filter -A INPUT -p IPv6 -i bat0 --ip6-proto ipv6-icmp --ip6-icmp-type router-solicitation -j DROP
ebtables -t filter -A FORWARD -p IPv4 --ip-proto udp --ip-dport 67 -j OUT_ONLY
ebtables -t filter -A FORWARD -p IPv4 --ip-proto udp --ip-dport 68 -j IN_ONLY
ebtables -t filter -A FORWARD -p IPv6 --ip6-proto udp --ip6-dport 547 -j OUT_ONLY
ebtables -t filter -A FORWARD -p IPv6 --ip6-proto udp --ip6-dport 546 -j IN_ONLY
ebtables -t filter -A FORWARD -p IPv6 --ip6-proto ipv6-icmp --ip6-icmp-type router-solicitation -j OUT_ONLY
ebtables -t filter -A FORWARD -p IPv6 --ip6-proto ipv6-icmp --ip6-icmp-type router-advertisement -j IN_ONLY
ebtables -t filter -A FORWARD -d 16:41:95:40:f7:dc --logical-out br-client -o bat0 -j DROP
ebtables -t filter -A FORWARD -s 16:41:95:40:f7:dc --logical-out br-client -o bat0 -j DROP
ebtables -t filter -A FORWARD -p ARP --logical-in br-client --arp-ip-src 10.80.32.1 -j DROP
ebtables -t filter -A FORWARD -p ARP --logical-in br-client --arp-ip-dst 10.80.32.1 -j DROP
ebtables -t filter -A FORWARD -p IPv4 --logical-out br-client -o bat0 --ip-dst 10.80.32.1 -j DROP
ebtables -t filter -A FORWARD -p IPv4 --logical-out br-client -o bat0 --ip-src 10.80.32.1 -j DROP
ebtables -t filter -A FORWARD -p IPv6 --logical-out br-client -o bat0 --ip6-dst fdef:ffc0:4fff::1/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff -j DROP
ebtables -t filter -A FORWARD -p IPv6 --logical-out br-client -o bat0 --ip6-src fdef:ffc0:4fff::1/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff -j DROP
ebtables -t filter -A FORWARD -d Multicast --logical-out br-client -o bat0 -j MULTICAST_OUT
ebtables -t filter -A OUTPUT -p IPv4 --ip-proto udp --ip-dport 67 -j OUT_ONLY
ebtables -t filter -A OUTPUT -p IPv6 --ip6-proto udp --ip6-dport 547 -j OUT_ONLY
ebtables -t filter -A OUTPUT -p IPv6 --ip6-proto ipv6-icmp --ip6-icmp-type router-solicitation -j OUT_ONLY
ebtables -t filter -A OUTPUT -d 16:41:95:40:f7:dc --logical-out br-client -o bat0 -j DROP
ebtables -t filter -A OUTPUT -s 16:41:95:40:f7:dc --logical-out br-client -o bat0 -j DROP
ebtables -t filter -A OUTPUT -p IPv4 --logical-out br-client -o bat0 --ip-dst 10.80.32.1 -j DROP
ebtables -t filter -A OUTPUT -p IPv4 --logical-out br-client -o bat0 --ip-src 10.80.32.1 -j DROP
ebtables -t filter -A OUTPUT -p IPv6 --logical-out br-client -o bat0 --ip6-dst fdef:ffc0:4fff::1/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff -j DROP
ebtables -t filter -A OUTPUT -p IPv6 --logical-out br-client -o bat0 --ip6-src fdef:ffc0:4fff::1/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff -j DROP
ebtables -t filter -A OUTPUT -p IPv6 -o bat0 --ip6-proto ipv6-icmp --ip6-icmp-type router-advertisement -j DROP
ebtables -t filter -A OUTPUT -d Multicast --logical-out br-client -o bat0 -j MULTICAST_OUT
ebtables -t filter -P IN_ONLY RETURN
ebtables -t filter -A IN_ONLY -i ! bat0 --logical-in br-client -j DROP
ebtables -t filter -P OUT_ONLY RETURN
ebtables -t filter -A OUT_ONLY --logical-out br-client -o ! bat0 -j DROP
ebtables -t filter -P MULTICAST_OUT RETURN
ebtables -t filter -A MULTICAST_OUT -p ARP --arp-op Reply --arp-ip-src ! 10.80.0.0/16 -j DROP
ebtables -t filter -A MULTICAST_OUT -p ARP --arp-op Request --arp-ip-dst ! 10.80.0.0/16 -j DROP
ebtables -t filter -A MULTICAST_OUT -p ARP --arp-op Reply --arp-ip-src 0.0.0.0 -j DROP
ebtables -t filter -A MULTICAST_OUT -p ARP --arp-op Request --arp-ip-dst 0.0.0.0 -j DROP
ebtables -t filter -A MULTICAST_OUT -p ARP -j RETURN
ebtables -t filter -A MULTICAST_OUT -p IPv6 --ip6-proto udp --ip6-dport 6696 -j RETURN
ebtables -t filter -A MULTICAST_OUT -p IPv4 --ip-dst 239.192.152.143 --ip-proto udp --ip-dport 6771 -j RETURN
ebtables -t filter -A MULTICAST_OUT -p 0xfc00 -j RETURN
ebtables -t filter -A MULTICAST_OUT -p IPv4 --ip-proto udp --ip-dport 67 -j RETURN
ebtables -t filter -A MULTICAST_OUT -p IPv6 --ip6-proto udp --ip6-dport 547 -j RETURN
ebtables -t filter -A MULTICAST_OUT -p IPv4 --ip-proto igmp -j RETURN
ebtables -t filter -A MULTICAST_OUT -p IPv4 --ip-proto ospf -j RETURN
ebtables -t filter -A MULTICAST_OUT -p IPv6 --ip6-proto ospf -j RETURN
ebtables -t filter -A MULTICAST_OUT -p IPv6 --ip6-dst ff02::9/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff --ip6-proto udp --ip6-dport 521 -j RETURN
ebtables -t filter -A MULTICAST_OUT -p IPv6 --ip6-proto ipv6-icmp -j MULTICAST_OUT_ICMPV6
ebtables -t filter -A MULTICAST_OUT -j DROP
ebtables -t filter -P MULTICAST_OUT_ICMPV6 RETURN
ebtables -t filter -A MULTICAST_OUT_ICMPV6 -p IPv6 --ip6-proto ipv6-icmp --ip6-icmp-type echo-request -j RETURN
ebtables -t filter -A MULTICAST_OUT_ICMPV6 -p IPv6 --ip6-proto ipv6-icmp --ip6-icmp-type 139/0:255 -j RETURN
ebtables -t filter -A MULTICAST_OUT_ICMPV6 -j ACCEPT
}
stop() {
echo stop
# commands to kill application
}
Je nachdem welche ebtables-Regeln in Deiner Community gefahren werden könnte es sein, dass so ein Knoten ganz erheblich stört und evtl Dinge „durchreicht“; die man nicht in der Domain haben möchte.
Will sagen: Tut soetwas nur nach Absprache mit der jeweiligen Community-Admins.
danke für den tipp, da hast du natürlich recht. ich hab die ebtables regeln ebenfalls alle „kopiert“ (bzw. ein init-script angelegt, dass die regeln beim booten einspielt, da ich nicht wußte wie ich die config sonst reinbekomme)
aber ich versuche trotzdem kontakt zu den community-admins zu bekommen um sicher zu gehen
, naja bis jetzt wirds nicht unterstützt, von daher kann ich sie eh nicht bauen. aber: