nyuuzyou/wikis huggingface dataset:
Arbeiten/ServiceLearning/SocialMedia

= Social Media im Monitoring =
* Ansprechpersonen:
** Name: Tim Niemeyer
** E-Mail: tim@tn-x.org
** Funktion: Vorstand
* Betreuer:
** Noch zu definieren..
** Name: 
** E-Mail:
** Funktion:
* Organisation: F3 Netze e.V.
* Form der Arbeit: Einzelarbeit (Maximal Zweier-Gruppenarbeit)
== Konkrete Fragestellung ==
* Über die technischen Status der Knoten sollen Menschen auf verschiedenen Wegen informiert werden:
** E-Mail an den Knotenbetreiber bei Downzeit, verfügbarem Update, ...
** Info in allgemeine Socialmediakanäle bei bspw. Netzausbau
== Angestrebtes Ziel ==
* Am Ende des Projektes sollen sich Knotenbetreiber über eingriffsbedürftige Status der Knoten informieren lassen können (Push-Benachrichtigung)
* Werbewirksame Ereignisse oder Ereignisse von allgemeinen Interesse sollen über SocialMedia-Kanäle am Ende des Projekts automatisch kommuniziert werden können
== Rahmenbedingungen ==
* Vorarbeiten: Nein
== Kosten ==
Sind Unkosten zu erwarten? Nein
Entwicklungs VM kann gestellt werden.
== Sonstiges ==
Ein Betreuer, der auch die weiteren Aspekte weiter ausarbeiten könnte, müsste sich finden.
Arbeiten/ServiceLearning/Vorlage

= Vorlage =
* Ansprechpersonen:
** Name:
** E-Mail:
** Funktion:
* Vertretung:
** Name:
** E-Mail:
** Funktion:
* Organisation:
* Form der Arbeit: Einzel- oder Gruppenarbeit
== Konkrete Fragestellung ==
Bitte beschreiben Sie in drei Sätzen, welche konkrete Fragestellung Sie in Kooperation mit der Technischen Hochschule Nürnberg bearbeiten möchten.)
* ..
* ..
* ..
== Angestrebtes Ziel ==
Bitte definieren Sie in drei Sätzen, welches konkrete Ziel Sie im Rahmen dieser Kooperation zur oben beschriebenen Fragestellung erreichen möchten.
* ..
* ..
* ..
== Rahmenbedingungen ==
* Vorarbeiten: Ja / Nein
* Wenn ja, welche: Wenn ja: Welche Vorarbeiten zu dieser Fragestellung gibt es bereits (z. B. Bachelorarbeiten)? Und kurze Beschreibung.
== Kosten ==
Sind Unkosten zu erwarten? Wenn ja, welche? (z. B. Fahrtkosten, Sachmittel)
Kostenübernahme: Ja / Nein (Gibt es eine Möglichkeit zur Kostenübernahme?)
== Sonstiges ==
Freifeld
Arbeiten/ServiceLearning/Z-Bau

= Z-Bau =
* Ansprechpersonen:
** Name: Tim Niemeyer
** E-Mail: tim@tn-x.org
** Funktion: Vorstand + Betreuer
* Vertretung:
** Name:
** E-Mail:
** Funktion:
* Organisation: F3 Netze e.V.
* Form der Arbeit: Einzelarbeit (Maximal Zweier-Gruppenarbeit)
== Konkrete Fragestellung ==
* Im Z-Bau soll die Freifunk Access Infrastruktur weiter ausgebaut werden.
* Server und Gateway Installationen sind aufzusetzen.
* Prüfung und Absprache um einen möglichen Dachstandort zu erschließen.
== Angestrebtes Ziel ==
* Der Freifunk Access Zugang sollte nach der Arbeit ausgebaut sein, so dass auf dem ganzen Gelände und im Haus überall ein guter Freifunk Zugang möglich ist.
* Mindestens ein eigenes dezentrales Gateway sollte auf einem Server eingerichtet werden. Der Server wird gestellt, soll aber im Z-Bau ungerbracht werden.
* Mit den Verantwortlichen des Gebäudes soll das Gespräch gesucht werden, wie und ob auf dem Dach eine Freifunk Installation möglich ist. Dies stellt eine Vorarbeit für eine mögliche Anschlussarbeit dar.
== Rahmenbedingungen ==
* Vorarbeiten: Ja
* Wenn ja, welche:
** Absprachen bezüglich Server unterstellung im Z-Bau
** Absprachen bezüglich Server Anbindung
== Kosten ==
Es sind Kosten für die Freifunk Zugangshardware zu erwarten. Ein bisschen Equipment ist vorhanden, dies soll natürlich eingezogen werden. Der Server sowie die nötige Netzanbindung sind ebenfalls vorhanden.
Kostenübernahme: Nein
== Sonstiges ==
Einige Ziele der Arbeit hängen von äußeren Faktoren ab. Sollte es zu Problemen kommen, können diese ggfs weg gelassen oder umschifft werden.
Autoupdate

Ab der Firmwareversion 20170110, wurde eine einfache Möglichkeit um ein Autoupdate einzubauen geschaffen.
Bitte wendet dies nur an, wenn ihr euch ganz sicher seid, was ihr tut. Es übernimmt niemand die Haftung o.ä. wenn beim Update etwas schief läuft. Bedenkt, dass z.b. bei gebrochener Kompatibilität damit auch ein ganzes Meshnetz unbrauchbar gemacht werden kann! Bedenkt auch, dass jede Firmware angenommen wird, die anders ist als eure. Wenn jemand eine kaputte Firmware oder ähnliches hochlädt, wird diese ebenfalls eingespielt! KEINE HAFTUNG!
Folgendes muss gemacht werden, damit das Autoupdate läuft:
* Loggt euch per ssh auf den Router ein
* Gebt "vi /usr/lib/micron.d/fff-autoupdate" (ohne "") in die Kommandozeile ein
* Drückt die einf Taste auf eurer Tastatur
* Gebt folgenden Code in den Editor ein:
Y X * * * /etc/sysupgrade.sh --script
ersetzt die X dabei durch die Stunde und Y durch die Minute in der das Update geprüft werden soll. Es wird empfohlen dies in der Nacht zu tun und einen möglichst zufälligen Wert zu wählen, damit die Last von vielen Routern verteilt wird und nicht alle gleichzeitig das Update ziehen. Es ist ein normaler Cronjob und so kann z.b. mit entsprechenden Code auch nur an einem Wochentag o.ä. geprüft werden.
* drückt die ESC Taste auf eurer Tastatur
* gebt :wq ein und drückt enter
* gebt "/etc/init.d/micrond restart" (ohne "") ein. Alternativ hierzu könnt ihr den Router auch einfach einmal neu starten.
* Damit diese Änderung nach einen Update erhalten bleibt (falls dies gewünscht ist), muss dieser Cronjob noch in die sysupgrade.conf eingetragen werden
* "vi /etc/sysupgrade.conf"
* Mit der Tastatur die letzte Zeile anwählen und "o" drücken
* In die neue Zeile "/usr/lib/micron.d/fff-autoupdate" (ohne "") schreiben
* esc drücken, :wq eingeben und die Änderung wurde gespeichert man kann sich nun aus dem Router ausloggen
Ihr könnt euch nun ausloggen und der Router wird jede Nacht auf ein Update prüfen und falls eins vorhanden ist selbstständig einspielen.
Diese Vorgehensweise kann mann auch mittels vier Befehle direkt aus dem Shell auf dem Router ausführen:
read -p "Geben sie die Stunden ein:" Stunde
read -p "Geben sie die Minuten ein:" Minute
echo $Stunde" "$Minute" * * * /etc/sysupgrade.sh --script" >> /usr/lib/micron.d/fff-autoupdate
echo "/usr/lib/micron.d/fff-autoupdate" >> /etc/sysupgrade.conf
Ein anderer Weg ist es die vier Zeilen in eine autoupdate.txt die Endung muß auf "sh" umgenannt werden und auf dem Router einzuspielen (über Winspc) und mit chmod 777 <Dateiname> ausführbar machen, und mit ./<Dateiname> zu starten. Es könnte eine alternative sein wenn mann mehrere Router umstellen möchte. 
Kategorie:Scripte
BIRD

BIRD Internet Routing Daemon (BIRD) ist ein TCP/IP-Routing-Daemon mit Unterstützung von IPv4 und IPv6 für unixartige Systeme, wie OpenWrt, und wird unter der GNU General Public License veröffentlicht.
== Freifunk Franken ==
BIRD wird ab der Firmware layer3-20221201 standardmäßig als Layer-3-Routingprotokoll im Freifunk-Franken-Backbone verwendet. Die Unterstützung in vorheriger Firmwares muss manuell aktiviert werden.
== Versionshistorie ==
Übersicht der BIRD-Versionshistorie und welche Freifunk-Franken-Layer-3-Firmwares welche Version implementiert haben.
=== Entwicklungszweig 3.0 ===
Version 	Datum 	Firmware	Bemerkung
3.0.0 	17. Dezember 2024	 	First stable mulithreaded version!
3.0-alpha2	12. Mai 2023 	 	Simple thread work balancing algorithm added
3.0-alpha1	21. April 2023 	 	Second testing release of multithreaded version
3.0-alpha0	2. März 2022 	 	First testing release of multithreaded version
=== Entwicklungszweig 2.0 ===
Version 	Datum 	Firmware 	Bemerkung
2.16 	7. Dezember 2024 	 	
2.15.1 	22. März 2024 	layer3-20241005-beta, 	layer3-20241107, layer3-20241219	Bugfixes in OSPF and RPKI
2.15 	10. März 2024 	 	Many improvements in BGP, BFD, RPKI
2.14 	7. Oktober 2023 	 	Many improvements in MPLS, BMP and filters
2.13.1 	22. Juni 2023 		layer3-20240119-beta, layer3-20240401, layer3-20240401-beta	This release fixes a security bug in 2.13. No new features
2.13 	23. April 2023 	 	New feature: RFC 9229, allow bgp_med, experimental BMP. We changed versioning to major.minor.patch
2.0.12 	23. Januar 2023 	 	Important bugfix release
2.0.11 	11. Dezember 2022 	layer3-20230321-beta, layer3-20230330 	BGP Route Leak Prevention and Detection Using Roles (RFC 9234) implemented
2.0.10 	27. Juni 2022 	layer3-20221019, layer3-20221201 	BGP</span> performance improved, VRF support in RPKI, many bugfixes
2.0.9 	20. Februar 2022 	 	Check NEWS file
2.0.8 	21. März 2021 	layer3-20220405-beta, layer3-20220413, layer3-20220814	Check NEWS file
2.0.7 	16. Oktober 2019 	 	Check NEWS file
2.0.6 	11. September 2019	 	Check NEWS file
2.0.5 	5. August 2019 	 	Check NEWS file
2.0.4 	1. März 2019 	 	Check NEWS file
2.0.3 	7. Januar 2019 	 	Check NEWS file
2.0.2 	22. März 2018 	 	Important security bugfix. A lot of new features.
2.0.1 	16. Januar 2018 	 	Linux MPLS kernel support, Channel templates improved, RFC 8212
2.0.0 	11. Dezember 2017 	 	Integrated IPv4 and IPv6 design, microsecond timers, RPKI, MPLS nexthops, VPN4 and VPN6 networks...
2.0.0-pre1	30. April 2017 	 	Experimental version
2.0.0-pre0	7. Dezember 2017 	 	Experimental version
== Siehe auch ==
* Layer3Firmware Config
== Weblinks ==
* Offizielle Website
* Quellcode auf CZ.NIC Gitlab
Kategorie:Technik
Belegte Airtime im Monitoring anzeigen

OpenWRT bietet die Möglichkeit die belegte Airtime auszulesen. Mit diesen Script wird die belegte Airtime ans Monitoring als Statustext geschickt. Die belegte Airtime ist dabei ein Durchschnitt aus der letzten Minute (oder je nachdem wie oft der Cron läuft).
== Für 2,4GHz Geräte ==
/etc/busy.sh
#!/bin/sh
iw dev w2mesh survey dump > /tmp/24dump
cat /tmp/24dump | sed '/Survey/,/\[in use\]/d' > /tmp/24reduced
ACT_CUR=$(ACTIVE=$(cat /tmp/24reduced | grep "active time:"); set ${ACTIVE:-0 0 0 0 0}; echo -e "${4}")
BUS_CUR=$(BUSY=$(cat /tmp/24reduced | grep "busy time:"); set ${BUSY:-0 0 0 0 0}; echo -e "${4}")
BUS_CUR_OLD2=$(cat /tmp/bus_cur2)
echo $BUS_CUR > /tmp/bus_cur2
let BUS_CUR_NEW=$BUS_CUR_OLD2-$BUS_CUR
ACT_CUR_OLD2=$(cat /tmp/act_cur2)
echo $ACT_CUR > /tmp/act_cur2
let ACT_CUR_NEW=$ACT_CUR_OLD2-$ACT_CUR
let BUSPROZ2=$BUS_CUR_NEW*100/$ACT_CUR_NEW
echo $BUSPROZ2
echo "Airtime $BUSPROZ2 %" > /tmp/status.txt
Datei ausführbar machen:
chmod +x /etc/busy.sh
/usr/lib/micron.d/fff-nodewatcher 
folgende Zeile hinzufügen (ja ist eklig, man kann auch einen eigenen Cron anlegen...)
*/1 * * * * /etc/busy.sh
micrond neu starten:
/etc/init.d/micrond restart
== Für 2,4GHz und 5GHz Komibgeräte ==
/etc/busy.sh
#!/bin/sh
MESHZWEI=$(iw dev w2mesh station dump | grep Station -c)
MESHFUENF=$(iw dev w5mesh station dump | grep Station -c)
APZWEI=$(iw dev w2ap station dump | grep Station -c)
APFUENF=$(iw dev w5ap station dump | grep Station -c)
iw dev w2mesh survey dump > /tmp/24dump
iw dev w5mesh survey dump > /tmp/5dump
cat /tmp/24dump | sed '/Survey/,/\[in use\]/d' > /24reduced
ACT_CUR=$(ACTIVE=$(cat /tmp/24reduced | grep "active time:"); set ${ACTIVE:-0 0 0 0 0}; echo -e "${4}")
BUS_CUR=$(BUSY=$(cat /tmp/24reduced | grep "busy time:"); set ${BUSY:-0 0 0 0 0}; echo -e "${4}")
BUS_CUR_OLD2=$(cat /tmp/bus_cur2)
echo $BUS_CUR > /tmp/bus_cur2
let BUS_CUR_NEW=$BUS_CUR_OLD2-$BUS_CUR
ACT_CUR_OLD2=$(cat /tmp/act_cur2)
echo $ACT_CUR > /tmp/act_cur2
let ACT_CUR_NEW=$ACT_CUR_OLD2-$ACT_CUR
let BUSPROZ2=$BUS_CUR_NEW*100/$ACT_CUR_NEW
echo $BUSPROZ2
cat /tmp/5dump | sed '/Survey/,/\[in use\]/d' > /5reduced
ACT_CUR=$(ACTIVE=$(cat /tmp/5reduced | grep "active time:"); set ${ACTIVE:-0 0 0 0 0}; echo -e "${4}")
BUS_CUR=$(BUSY=$(cat /tmp/5reduced | grep "busy time:"); set ${BUSY:-0 0 0 0 0}; echo -e "${4}")
BUS_CUR_OLD5=$(cat /tmp/bus_cur5)
echo $BUS_CUR > /tmp/bus_cur5
let BUS_CUR_NEW=$BUS_CUR_OLD5-$BUS_CUR
ACT_CUR_OLD5=$(cat /tmp/act_cur5)
echo $ACT_CUR > /tmp/act_cur5
let ACT_CUR_NEW=$ACT_CUR_OLD5-$ACT_CUR
let BUSPROZ5=$BUS_CUR_NEW*100/$ACT_CUR_NEW
echo $BUSPROZ5
echo "Mesh2,4GHz: $MESHZWEI ; Mesh5GHz: $MESHFUENF ; AP2,4GHz: $APZWEI ; AP5GHz: $APFUENF ; BUSY2,4GHz: $BUSPROZ2 % ; BUSY5GHz: $BUSPROZ5 %" > /tmp/status.txt
beim Rest so verfahren wie oben, als Zusatzfeature zeigt er auch noch alle Meshverbindungen und Clients in 2,4GHz und 5GHz aufgetrennt an.
Kategorie:Scripte
Bridge ohne WDS

== TL;DR ==
Mit nftables und Änderungen von MAC-Addressen kann man selbst ohne WDS eine Layer 2 Verbindung für ein Gerät, welches hinter einem normalen Wifi-Client hängt, erstellen. Das ist unter anderem für Babel Peerings nützlich und spart damit andere unangenehme Workarounds, wie z.B. Tunnel.
== Problem ==
Ohne WDS (4addr mode) ist es nicht möglich, sauber ein Gerät hinter einem Wifi Client zu einem Netz zu verbinden. Das scheitert schon bei dem Versuch unter Linux ein Wifi Client Interface an eine Bridge zu kleben:
 # brctl addif bridge0 wlan0
 Operation not supported
Die Ursache liegt darin, dass ohne WDS nur 3 MAC Adressen in so einem WLAN Paket Stecken. Normalerweise braucht es ja eigentlich nur Quell und Ziel MAC, bei einem WLAN ist aber zusätzlich immer noch die Accesspoint Adresse mit dabei. Der Client "verbraucht" immer einen Platz mit seiner MAC, mit welcher er ins WLAN eingebucht ist. Sieht ein Accesspoint eine MAC Addresse, die nicht eingebucht ist, wirft er so ein Paket in der Regel weg. Wenn man also hinter einem WLAN Client ein Paket los schickt, dann ist für diese Quell MAC kein Platz im WLAN Paket. 
Will man hinter eineM Client noch mehr Geräte, muss man WDS (oder 4addr mode) benutzen. Und wie der Name schon andeutet wird in diesem Fall eben noch ein zusätzliches 4. Adressfeld bereit gestellt. Jetzt ist Platz für Quell und Ziel MAC Adressen der Endgeräte, sowie den Client und AP MAC Adressen.
So... aber was ist, wenn der AP oder Client kein WDS kann?
== Lösungen ==
Also zunächst einmal gibt es keine saubere Lösung. Punkt.
Es gibt aber halb-schlimme Lösungen, wenn man mit gewissen Einschränkungen Leben kann.
=== Routing ===
Man kann hinter dem Client ein weiteres Netz haben und über den Client Routen oder NATten (blaaarg).
=== Tunnel ===
Man kann sich fast immer mit Tunneln helfen. Allerdings macht das beim Routing einige Probleme, wenn man für den Tunnelendpunkt keine separate IP bereit stellen kann. Außerdem braucht man Zugriff auf fast alle Gerät und man verringert wieder die MTU für die Strecke.
=== Relay ===
Wenn hinter den Client nur ein Gerät verbunden werden soll und der Client selbst nicht erreichbar sein muss, gibt es eine Lösung, die eine direkte Layer 2 Verbindung zwischen 2 Routern herstellen kann.
* https://openwrt.org/docs/guide-user/network/wifi/relay_configuration
* https://wiki.debian.org/BridgeNetworkConnections
* https://wiki.debian.org/BridgeNetworkConnectionsProxyArp
 #!/usr/bin/nft -f
 
 flush ruleset;
 
 # mind the NIC, it must exists
 table netdev rewrite {
 chain rewritewlan0 {
 		type filter hook ingress device wlan0 priority 0;
 		meta protocol { ip, arp, ip6 } fwd to eth0.102;
 		
 	}
 	chain rewritevlan {
 		type filter hook ingress device eth0.102 priority 0;
 		meta protocol { ip, arp, ip6 } fwd to wlan0;
 	}
 }
Cccamp19

=Planungsseite fürs Chaos Communication Camp 2019=
Beschreibung kopiert von https://wiki.freifunk.net/index.php?title=Chaos_Communication_Camp_2019
* 21. - 25. August 2019
* https://www.ccc.de/de/updates/2019/camp-zelte
* Ziegeleipark in Mildenberg
== Tickets ==
Beware: Voucher replication happens roughly once a day. Have patience.
===How to buy===
Go to the presale system, enter your received voucher under "Redeem a voucher" (DE: Gutschein einlösen). Now you can add the desired ticket type to your cart. Roughly at the day your payment is confirmed you'll receive a new voucher code, send this one to the next person listed unter "Voucher needed" and move the corresponding entry to "Voucher received". Also change your status to "Ticket bought". Please buy and pay as fast as possible since only then the voucher replicates and another visitor can get his ticket. When in doubt ask the person you've got the voucher from for help.
=== Voucher received ===
* delphiN, freifunk (at) wunschik (punkt) net
* fritzoid, fritzi.h (äd) gmx (pungd) net
* matmai, m_m (at) freakmail (punkt) de
* fl00df1ll, comm1968 (at) yahoo (pungd) de
=== Voucher needed ===
* Bitte eintragen...
Client Interface Zeit gesteuert an- und abschalten

um das Client w2ap Interface zeitabhängig an- und abzuschalten und dies auch updatefest zu haben, kann das Packages fff-support verwendet werden.
Man loggt sich in dem Router per SSH ein.
vi /etc/rc.local.fff_userconfig
fügt (i drücken) folgendes ein:
echo "0 23 * * * ifconfig w2ap down" > /usr/lib/micron.d/startstopw2ap
echo "0 8 * * * ifconfig w2ap up" >> /usr/lib/micron.d/startstopw2ap
/etc/init.d/micrond restart
gibt danach
chmod +x /etc/rc.local.fff_userconfig
ein und führt das Script einmalig per Hand aus:
/etc/rc.local.fff_userconfig
nach ein paar Sekunden ist der Cronjob angelegt, der das w2ap um 23Uhr beendet und um 8Uhr wieder startet.
Bitte darauf achten, das die Routeruhr auch richtig geht, in einigen Betaversionen war der ntp kaputt!
Kategorie:Scripte
Community

= Aufbau der Freifunk Franken Community =
Die Freifunk Franken Community ist selbst kein Verein, sondern sieht sich als loser Zusammenschluss von diversen Personen, Firmen, Vereinen, usw. an. Es darf jeder daran teilnehmen und wir schließen auch niemanden aus, weder aufgrund des Wohnortes, noch der politisches Einstellung oder aus anderen Gründen. Anders als es der Name vermuten lässt, ist unser Netz nicht regional auf Franken begrenzt, sondern darf weltweit errichtet, betrieben und verwendet werden.
Wir sehen das Freifunk Franken Netz als ein freies, dezentrales und nichtkommerziell betriebens Netzwerk an und bekennen uns daher zum PicoPeeringAgreement. Zudem darf unser Netzwerk auch zu Forschungs- und Experimentierzwecken verwendet werden, sofern dieses dadurch nicht bewusst gestört wird. 
Vorrangies Ziel der Community ist es, das Netzwerk dezentral zu halten, so dass jeder seinen Netzbereich unter eigener Kontrolle behält und niemand "zentral" das ganze Netz abschalten kann, ganz ähnlich wie das Internet aufgebaut ist.
Ebenfalls wird bei uns Wissensvermittlung groß geschrieben. Dazu sind wir über diverse Kommunikationsmedien erreichbar, um bei Fragen und Problemen zu helfen und unsere Kenntnisse weiterzugeben. Jeder Teilnehmer ist aufgefordert, sein eigenes Wissen mit der Community zu teilen, damit sich das Know-How über den Aufbau freier Netze weiter verbreitet.
== Besondere Teilnehmer ==
Hier sollten Firmen und Vereine aufgelistet werden, die einen wesentlichen Beitrag für die Community leisten.
 
=== F3 Netze e.V. ===
F3 Netze e.V. ist ein Verein, der viel Infrastruktur für das Freifunk Franken Netz zur Verfügung stellt. Informationen über den Verein sind hier zu finden: https://f3netze.de/der_verein/
=== FabLab Region Nürnberg e.V. ===
Mitglieder des Verens FabLab Region Nürnberg e.V. betreiben auf dem Dach des Gebäudes vom Vereinssitz einen der größten Richtfunkverteiler in der Region. Ebenfalls wird am Dach ein LoRaWAN Gateway betrieben.
Community/Fuerth

__NOTOC__
= Freifunk in Fürth =
Domains die auf diese Seite leiten:
* www.freifunk-fuerth.de
* www.freifunk-fürth.de
* fuerth.freifunk.net
== Treffen ==
Das Treffen ist zusammen mit Nürnberg im CoWorkingspace.
Sehr wichtigt ist auch die Kommunikation untereinander, nimm auf jeden Fall Kontakt mit uns auf .
== Information ==
In Fürth wird der Aufbau von dezentralen Setups vorangetrieben. So wird im Bereich Fürth davon abgeraten die normale Node Firmware zu installieren. Diese ist in Fürth höchstens noch für HotSpot Netze ohne jegliche Vernetzung zu gebrauchen und kann hier zum experiementieren oder als purer HotSpot (z.b. in einer Wirtschaft) verwendet werden. Um ein Freifunknetz aufzubauen und sich mit anderen zu vernetzen sollte innerhalb Fürth nur noch die Layer 3 Firmware Verwendung finden welche auch deutlich perfomanter ist. Zentrale Gateways für die Hood Fürth sind daher nicht mehr nötig und werden auch keine mehr benötigt. Eine Anbindung über VPN ist über diverse Personen weiterhin möglich, dazu einfach auf der Mailingliste melden wo sich immer Serverbetreiber finden die einen VPN Zugang zur Verfügung stellen. Eine Anbindung über Richtfunk ist auch an diversen (weiter unten folgenden) Standorten möglich, falls Sichtkontakt zu einem dieser Standorte besteht einfach den Betreiber des Standorts anschreiben um individuelle Einzelheiten zum verbinden zu klären, ein eigener Internetanschluss ist in diesem Fall nicht mehr nötig.
Allgemein ist es hilfreich, sich auf der Mailingliste oder anderen Kontaktmöglichkeiten (siehe oben) bei der Community zu melden wenn man beim Freifunk aktiv mitmachen möchte.
== Wichtige Standorte in Fürth ==
Kategorie:Fuerth
Kategorie:Community
DDWRT zu FreifunkFranken Firmware

= Auf dem Router läuft DD-WRT =
Mitunter bekommt man einen gebrauchten Router, auf dem nicht die Original-Firmware, sondern DD-WRT läuft. Dann ist ein Flashen der Freifunk-Firmware via Webinterface nicht möglich, da DD-WRT nur DD-WRT-Firmware flasht.
Mit folgendem Vorgehen habe ich mehrere TP-Link TL-1043ND mit DD-WRT darauf geflasht (von Linux aus):
Zunächst muss Telnet aktiviert werden. Hierzu per Webinterface anmelden, und unter „Administration“ den Telnet-Zugriff aktivieren.
Dann wird die Firmware auf den Router kopiert. Es wird die „sysupgrade“-Variante benötigt, in meinem Fall „fff-20181202-ar71xx-g-tl-wr1043nd-v1-squashfs-sysupgrade.bin“.
Die einfachste Variante, die Firmware auf den Router zu bekommen, ist, sie von da aus per wget von einem Webserver abzuholen. Entweder verwendet man einen richtigen HTTP-Server, oder behilft sich – wie im folgenden beschrieben – mit dem Mini-Webserver, den Python mitbringt:
Der Einfachheit halber macht man zunächst eine Kopie mit einem griffigeren Namen:
:cp fff-20181202-ar71xx-g-tl-wr1043nd-v1-squashfs-sysupgrade.bin firmware.bin
Dann startet man im selben Verzeichnis den Mini-Python-Webserver:
:python -m http.server
Der Server lauscht auf 0.0.0.0 (also allen verfügbaren Netzwerkinterfaces) auf dem Port 8000. Wenn man in einem Webbrowser die Adresse 127.0.0.1:8000 öffnet, sieht man ein Directory Listing (incl. der Datei „firmware.bin“).
Dann auf dem Router einoggen (der Router hatte hier die IP-Adresse 192.168.11.1):
:telnet 192.168.11.1
Dann die Firmware nach /tmp kopieren (der Client hatte hier die IP-Adresse 192.168.11.147):
:cd /tmpwget http://192.168.11.147:8000/firmware.bin
und schließlich die Firmware flashen mit
:mtd -r write /tmp/firmware.bin linux
Der Router startet neu und begrüßt einen dann mit der Freifunk-Firmware.
Dienste

== Bestehende Dienste ==
* DNS-Server 
bitte ergänzen …
== Dienste die gerade nicht funktionieren ==
* Community-NAS mit verschiedenen Diensten
* kleiner, anonymer FTP-Server
* http://10.50.64.11 via Eutelsat 13° Ost (Hot Bird 13B, 11.470,00 MHz, vertikal) dieser Verbreitungsweg eingestellt ab zirka August 2016, von Radiator (Infos: Outernet, Outernet Service Status, Outernet Wiki)
* http://10.50.40.66:8080/ Flightradar über Nürnberg live
== Neuen Dienst im Freifunk-Netz anbieten ==
=== Lokalen Server betreiben ===
Hier wird kurz beschrieben, wie man z.B. einen Raspberry Pi mit dem Freifunk-Netz verbindet, um darauf einen freifunkinternen Dienst anbieten zu können.
# Sich im Wiki eine statische IPv4-Adresse in seiner Hood reservieren.
# Die feste IP auf dem Raspi einstellen.
# Den Raspi mit einem der Client-Ports seines Freifunk-Routers verbinden. Welche der gelben Ports die Client Port sind steht auch im Wiki.
Das wars schon. Ab jetzt ist der Raspi und alle Dienste, die auf ihm laufen, im gesamten Freifunk-Netz zu erreichen. 
=== Internet-Dienste im Freifunk-Netz verfügbar machen ===
bitte ergänzen …
Kategorie:Technik
Dokuanleitung

Wenn Du Dein System dokumentierst, dann erwähne bitte folgende Aspekte:
* Welche Hardware wird verwendet? (ggf. warum)
* Wie hoch sind die Kosten?
* welche Software ist installiert? (OS, spezielle Pakete, Versionen)
* welche Konfigurationsdateien wurden neu erstellt oder angepasst?
* besonders interessant: Wo gab es die größten Schwierigkeiten?