Archiv der Kategorie: Netzwerk

Neue Freifunk-Firmware für Mainz, Wiesbaden und Umgebung (Version 2016.2.5+mwu1 (stable))

Schöne Neuigkeiten vom Firmware-Team:

Hallo Freifunkas in Mainz, Wiesbaden und Umgebung,
 
nachdem es die beiden vorherigen testing-Versionen aufgrund von Fehlern nicht nach stable geschafft haben ist es nun soweit, mit 2016.2.5+mwu1 haben wir seit Heute eine neue stable-Version. Eure Knoten sollten sich innerhalb der nächsten 5 Tage automatisch aktualisieren wenn der Autoupdater auf stable eingestellt ist. Da es in der bisherigen Version einen Fehler gab der dazu führt, dass der Autoupdater gegebenenfalls hängen bleibt ist unter Umständen ein Neustart des Knotens nötig.
 
Gluon Source Code: https://github.com/freifunk-gluon/gluon/releases/tag/v2016.2.5
Gluon Release-Notes: https://gluon.readthedocs.io/en/stable/releases/v2016.2.5.html
MWU Gluon-Konfiguration: https://github.com/freifunk-mwu/sites-ffmwu/releases/tag/2016.2.5+mwu1
 
Link zur Firmware Mainz: https://firmware.freifunk-mainz.de/stable
Link zur Firmware Wiesbaden: https://firmware.wiesbaden.freifunk.net/stable
 
Happy Flashing wünscht,
das Firmware-Team

Neue Knotenkarte (Meshviewer) für Freifunk Mainz, Wiesbaden und Umgebung

Aktuelles vom Admin-Team:

Hallo Freifunkas in Mainz, Wiesbaden und Umgebung,

aus verschiedenen Gründen planen wir, die Software zu erneuern, die uns
unsere Karten malt. Wer die Details, unten, gelesen und die neue Karte
ausprobiert hat, soll uns gerne hier Feedback geben. 
Die Abschaltung der alten Karteninfrastruktur ist für den 20.4. geplant.

tl;dr https://mapng.freifunk-mwu.de

Seit Version 0.3 [1] enthält unsere Firmware den Dienst respondd [2].
Dieser läuft seit dem parallel zu alfred [3]. Beide Dienste haben
die gleiche Aufgabe, nämlich die Daten für unsere Knotenkarten
bereitzustellen.

Im Gegensatz zu alfred flutet respondd nicht periodisch das Netz mit
all seinen Statusinformationen, sondern sendet diese nur auf Anfrage.
Dies gibt uns z.B. die Möglichkeit das Datenaufkommen im Netz gezielter
zu steuern, in dem wir bei Bedarf die Frequenz der Abfragen reduzieren.

Bisher gab es außer HopGlass [4] keine wirkliche Alternative, um die
Daten über respondd abzufragen und zu visualisieren. Außerdem war
eine Übernahme der bisherigen Daten nicht ohne größeren Aufwand
möglich.

Auf dem letzten Hessen Meetup haben wir dann von Yanic [5] erfahren
und noch am selben Tag eine Testinstallation aufgesetzt.
Yanic bietet fast alles was wir benötigen und die fehlenden Sachen,
wie z.B Multi-Community-Support, konnten mit wenig Aufwand hinzugefügt werden.
Außerdem hat es die Möglichkeit unsere alten RRD Statistiken in die
von Yanic verwendete InfluxDB zu importieren, was uns die Möglichkeit
gibt die gespeicherten Daten in moderner und ansehnlicher Form aufzubereiten.

Da wir Aufgrund der begrenzten Ressourcen in den kleinen Plastikroutern
natürlich nicht ewig alfred und respondd in unserer Firmware pflegen wollen,
möchten wir das alte, seit über 2 Jahren nicht mehr weiterentwickelte,
Kartenbackend [6] so schnell wie möglich loswerden und alfred aus unserer
Frimware entfernen.

Im gleichen Zug gibt es auch einen aktualisierte Meshviewer, der durch den
Freifunk Regensburg einige neue Features [7] spendiert bekommen hat und
deutlich flüssiger auf schwachen/mobilen Endgeräten läuft, als die bisherige
Version.

Um die Last auf unseren Servern zu verringern, haben wir darauf verzichtet,
eigene Karten für die einzelnen Communities zu genieren, da wir die zwei
Klicks zum Filtern nach einer bestimmten "Site" für vertretbar halten.

Aber genug der Worte!

Karte:     https://mapng.freifunk-mwu.de
Statistik: https://stats.freifunk-mwu.de

Viele Grüße
das Admin-Team

[1] https://github.com/freifunk-mwu/site-ffmwu/releases/tag/0.3
[2] https://github.com/freifunk-gluon/packages/tree/master/net/respondd
[3] https://www.open-mesh.org/projects/alfred/wiki
[4] https://github.com/hopglass
[5] https://github.com/freifunk-mwu/yanic
[6] https://github.com/ffnord/ffmap-backend/commits/master
[7] https://github.com/ffrgb/meshviewer/blob/develop/README.md

IPv6-Optimierungen im Freifunk Mainz, Wiesbaden und Umgebung (MWU)

Seit der Aktivierung öffentlicher IPv6 Adressen für alle Clients hatten wir aufgrund unser Netzstruktur einen ungünstigen Datenfluss bei ein- und ausgehenden IPv6-Verbindungen. Weil Datenpakete nicht den kürzesten Weg durch unser Netz genommen haben, sondern intern weiter verteilt werden mussten, hat dies zu einem unnötigen Bandbreitenverbrauch geführt. Das Verhalten hat uns einiges an Kopfzerbrechen bereitet, letztendlich hat unser Admin-Team aber eine Lösung gefunden, die in den letzten Wochen stückweise aktiviert und verprobt wurde.

Das Problem

Unsere Freifunk MWU-Netze (Mainz, Wiesbaden und Umgebung) bestehen aus vielen kleinen Teilnetzen die mittels B.A.T.M.A.N. Advanced zu einem großen virtuellen Layer 2 Netzwerk zusammengeschaltet werden. Innerhalb dieser Netze kann jedes Gerät direkt mit allen anderen kommunizieren. In jedem dieser Netze gibt es vier Gateways die im wesentlichen drei Aufgaben haben. 1) Sie sind die VPN Gegenstelle für alle Knoten, 2) Default Gateway für alle Clients und 3) kümmern sich und die Ausleitung des Internetverkehrs über den Freifunk Rheinland. Aufgrund dieser virtuellen Netztopologie wissen die Endgeräte nichts über die wirkliche Struktur des Netzes.

Dies war solange kein Problem, wie wir extern nur über IPv4 kommuniziert haben, da jedes Gateway eine eindeutige Adresse hatte und sämtlicher Internetverkehr der Clients mit diesen geNATet wurde. Hierdurch konnte der Freifunk Rheinland immer eindeutig zuordnen über welches Gateway die Verbindung initiert wurde und hat die Daten immer auf dem für uns kürzesten Weg übertragen.

Mit IPv6 ist es aber nicht mehr nötig NAT einzusetzen (Nein, NAT ist kein Sicherheitsfeature!) da 2^128 Adressen verfügbar sind, dass sind ca. 600 Billiarden Adressen pro mm². Ohne NAT wird die Adresse bei ausgehendem Datenverkehr nicht mehr durch die des Gateways ersetzt wodurch die Systeme des Freifunk Rheinland nicht mehr zuordnen können über welches Gateway die Anfrage gesendet wurden und senden die Daten an das erstbeste. Unsere Gateways müssen sich dann darum kümmern die Daten intern an das Gateway weiterzuleiten über welches die Daten angefragt wurden. Da diese, wie bereits erwähnt, bei verschiedenen Hostern stehen entsteht ein unnötige Belastung der verfügbaren Bandbreite.

Die Lösung

Wir haben verschiedene Ansätze diskutiert und kamen am Ende nur zu einer Lösung. Wir müssen unsere Netze (/48) in kleinere Subnetze (/56) segmentieren. Gesagt, getan. Seit ein paar Tagen besitzt jedes Gateway sein eigenes Subnetz. Leider ist dies nur die halbe Lösung da es nur für eingehende Daten hilft. Durch unser Layer 2 Netz erhält jeder Client die Router Advertisements (im folgenden kurz RA genannt) von allen Gateways und trägt sich deshalb auch alle vier als Default Gateway ein. Da der Client nicht weiß, an welches Gateway der Knoten per VPN verbunden ist, kann er keine qualifizierte Entscheidung treffen, welches Gateway für ihn das Nächste ist.

Glücklicherweise haben sich bereits andere kluge Menschen darüber die Köpfe zerbrochen und ein Programm namens gluon-radv-filterd entwickelt. Dieses Programm muss auf den Knoten laufen und ist seit der Version 2016.2.2+mwu1 in unser Firmware enthalten. Die Funktion ist relativ einfach zu verstehen: Alles was das Programm tut, ist, sich jedes eingehende RA Paket anzuschauen und zu prüfen welche Verbindungsqualität (TQ) B.A.T.M.A.N Advanced zu der Gegenstelle hat die dieses gesendet hat. Anschließend wird eine Filterregel erstellt die alle RAs verwirft die nicht von der Gegenstelle mit der besten TQ kommen. Da die TQ mit jedem Hop sinkt können wir sicher sein, dass das RA Paket mit der besten TQ vom nächstgelegen Gateway kommt.

Bei Fragen oder Feedback wendet euch bitte an die Maschinenraum-Liste.

Erste WebCam im Mainzer Freifunk-Netz

Funkamateure sind bekannt dafür, dass sie gerne mal was Neues ausprobieren. Basteln mit Freifunk zu verbinden bietet sich da an. Eine WebCam mit einem Raspberry-PI 2 in den Räumlichkeiten des DARC Ortsverband Mainz zu installieren lag da nahe. Warum? Weil wir im unseren Clubraum im obersten Stockwerk des historischen Holzturms am Rande der Mainzer Altstadt einfach eine geile Sicht über die Stadt haben.

2016-10-10-11_05_14-mobilcam-user-ffmz-org_8080Unter http://mobilcam.user.ffmz.org:8080 könnt ihr Euch den Livestream 24/7 anschauen und an der tollen Aussicht teilhaben..

Empfangsberichte bitte an Wolfgang schicken.

 

Aktivierung von öffentlichen IPv6-Adressen im Mainzer Freifunk-Netz ab 15. September 2016

mitarbeiter des monatsSchon seit Längerem planen wir die Aktivierung von öffentlichem IPv6 im Mainzer Freifunk-Netz. Beim letzten Community-Treffen haben wir jetzt nochmal ausgiebig darüber diskutiert und unser Votum abgegeben, dass wir die Umstellung nun sobald wie möglich angehen wollen.

Dazu sind wir nochmal die Vor- und Nachteile durchgegangen und haben besonders zwei Punkte nochmal diskutiert, die bei den letzten Treffen und auf unserer allgemeinen Community-Mailingliste kritisch angemerkt wurden.

Erstens die nach Umstellung weltweite Sichtbarkeit von Kontaktdaten in den Freifunk-Knoten. Schließlich ist jeder Knoten dann ja weltweit erreichbar und bietet auf seiner IPv6-Adresse auch seine Webseite an. Hier gab es beim Treffen wie auch auf der Mailingliste kritische Stimmen, die sagten, dass sie nicht gerne hätten, dass ihre Kontaktdaten dann in noch größerem Stil abrufbar seien. Hierfür brauchen wir also auf jeden Fall eine Lösung. Diese kann Opt-Out (wer will, löscht seine Daten) oder Opt-In (wir löschen alle Daten mit dem nächsten Update und wer will, trägt sie wieder ein) sein. Wir haben uns für Opt-Out entschieden, mehr dazu siehe unten.

Das zweite Thema war die Angreifbarkeit der einzelnen Endgeräte: Mit öffentlicher IPV6 sind auch die Endgeräte dann zukünftig ja weltweit erreichbar, also auch angreifbar. Hier haben wir hin und her überlegt und uns Gedanken über die Verantwortung gemacht, die wir auch für unsere Netz-Nutzer mit tragen.

Klar ist: Wir wollen gemäß Pico-Peering-Agreement keine Eingriffe in den Datenverkehr, also auch keine Inhalte-Filterung, also auch keine Firewalls im Freifunk. Wir wollen Netzneutralität und einen „Free Flow of Information“.

D.h. wir müssen uns bewusst sein: Durch IPv6 steigt der Angriffsvektor auf die Endgeräte und wir werden keine Schutzmechanismen wie Firewalls im Freifunk-Netz etablieren, d.h. jede*r NutzerIn muss zukünftig noch mehr dafür sorgen, dass sein Endgerät möglichst sicher ist. Allerdings: Das müssen die NutzerInnen heute schon! Die NutzerInnen dürfen sich auch heute nicht drauf verlassen, dass ein öffentliches WLAN sie vor irgendwas schützt.

Auch heute schon werden alle WLANs in der Regel einfach so genutzt, ohne dass NutzerInnen wissen, ob ein NAT verwendet wird oder nicht und ob eine Firewall verwendet wird oder nicht. Die Endgeräte müssen damit also generell klar kommen und mit immer mehr offenen Netzen auch darauf ausgelegt und vorbereitet werden.

Und auf der anderen Seite ist es so, dass es für uns heute schon eine schwierige Situation ist, kein IPv6 anzubieten. Kein IPv6 anzubieten, bedeutet schließlich auch, Kommunikation netzseitig zu verhindern.

Insgesamt sind wir nach Abwägung aller Argumente zu dem Schluss gekommen, dass wir IPV6 via Freifunk Rheinland-Backbone auf den Gateways aktivieren wollen, d.h. das Admin-Team darum bitten werden, dies zu tun.

Wir haben uns folgende Vorgehensweise überlegt:

  1. Damit niemandes Kontaktdaten gegen seinen Willen im Netz abrufbar sind, weisen wir Alle auf die Umstellung hin und erklären, wie sie ihre Kontaktdaten löschen können, wenn sie das wollen. Wir schreiben dazu einen Blogbeitrag (this) und senden eine Mail an alle, die eine Adresse hinterlegt haben. Wer keine Mail-Adresse hinterlegt hat, aber eine Telefonnummer, den rufen wir an (das sind hoffentlich nur ganz wenige).
  2. Zum 15. September aktivieren wir dann öffentliches IPv6 im Mainzer Freifunk-Netz. Außerdem erklären wir in einem weiteren Blogbeitrag und ggf. per Pressemitteilung, dass und wie man sich in öffentlichen WLANs schützen sollte.

Bis zur Umstellung haben wir jetzt also noch ca. einen Monat Zeit, Alle zu informieren. Wer will, kann seine Kontaktdaten bis dahin manuell rauslöschen.

Bei Fragen oder Anmerkungen, kommentiert gerne hier im Blog oder auf unserer Mailingliste.

Neue Firmware Version „0.3.3-stable“ / Gateway-Änderungen

Ffmz_logo_black_800Als Nachtrag noch eine wichtige Info vom Admin-Team vom 19. Juli 2016:

Hallo Freifunkas in Mainz, Wiesbaden und Umgebung,

wie ihr ja wisst werden im Freifunk MWU Netz aktuell 4 Gateways betrieben:

  • Kaschu (gespendet von Markus)
  • Lotuswurzel (gespendet von Tobias)
  • Spinat (getragen durch den Verein Freifunk Mainz e.V.)
  • Wasserfloh (gespendet von Sebastian)

Das Gateway Kaschu ist nun abgeschaltet worden, weil der Spender es nicht mehr weiter betreiben möchte. Stattdessen hat Julian ein neues Gateway installiert, das seit ein paar Tagen funktionsbereit ist und den Namen „Ingwer“ trägt.

Wir bedanken uns an dieser Stelle bei Markus, dessen Gateway „Kaschu“ ca. 1 Jahr lang das Freifunk Netz mit getragen hat. Genauso bedanken wir uns bei Julian für die neue Gateway-Spende!

Die Gateways, genauer gesagt die fastd-Server, zu denen die Freifunk-Knoten den VPN-Tunnel aufbauen, sind fest in der Firmware hinterlegt. Deshalb gibt es nun eine neue Firmware-Version, in der diese Gateway-Liste aktualisiert wurde. Es handelt sich also nur um kleine
Konfigurationsänderungen, die Firmware-Basis Gluon v2016.1.5 bleibt identisch.

Infos zur neuen Firmware:
– MWU Firmware Version: „0.3.3-stable“
– Gluon Firmware Version: „v2016.1.5“

Gluon Source Code:
https://github.com/freifunk-gluon/gluon/releases/tag/v2016.1.5
Gluon Release-Notes:
http://gluon.readthedocs.org/en/stable/releases/v2016.1.5.html
MWU Gluon-Konfiguration:
https://github.com/freifunk-mwu/site-ffmwu/releases/tag/0.3.3

(der Build-Prozess ist noch nicht fertig – spätestens morgen Abend ist die Firmware verfügbar inzwischen abgeschlossen):
Link zur Firmware Mainz: http://firmware.freifunk-mainz.de/stable/
Link zur Firmware Wiesbaden: http://firmware.wiesbaden.freifunk.net/stable/

Änderungen an der Gluon Konfiguration (site) seit Version „0.3.2-stable“:

  • Signatur-Schlüssel von Markus wurde entfernt
  • Gateway „Kaschu“ wurde entfernt
  • Gateway „Ingwer“ wurde hinzugefügt
  • Die Anzahl der erforderlichen Signaturen für ein Autoupdate des Firmware-Branches „stable“ wurde von 4 auf 3 herabgesetzt

Eure Knoten werden sich innerhalb der nächsten 7 Tage automatisch updaten, sofern ihr den Autoupdater aktiviert und auf den Firmware-Branch „stable“ eingestellt habt.
Bitte beobachtet in dieser Zeit eure Knoten, ob alles glatt läuft.

Happy Updating wünscht,
das Firmware- + das Admin-Team

Umstellung unseres Internet-„Exits“ auf den Freifunk Rheinland-Backbone

Es gibt wichtige Neuigkeiten für alle Freifunker und Interessierten: Zum Jahreswechsel 2015/2016 stellen wir das Vereinsgateway und auch alle anderen Gates von dem bisherigen Exit-VPN „PerfectPrivacy“ auf das Backbone des Freifunk Rheinlands e.V. um.

Das bedeutet, dass der Traffic aus dem Freifunk-Netz von unseren Gates aus nicht mehr über einen VPN-Server der Firma LeaseWeb (PerfectPrivacy) ins In- oder Ausland geleitet wird, sondern über das Netz anderer Freifunker. Von deren Servern aus wird der Traffic dann in verschiedenen Rechenzentren in Deutschland direkt ins Internet geleitet.

Warum wollen wir das? Es gibt eine ganze Reihe Vorteile, die wir durch den Umstieg gewinnen:

  1. Freifunk Rheinland ist kein anonymer VPN-Dienstleister, bei dem wir gar nicht wissen, wen wir finanzieren und ob wir den Menschen 100%ig vertrauen können. Der Rheinland-Backbone dagegen wird von Leuten betrieben, die uns ideologisch nahestehen und unser gemeinsames Ziel verfolgen: Ein freies Netz für alle.
  2. Mehr Bandbreite: Über die Gateways des Freifunk Rheinland geht erheblich mehr Bandbreite als wir es bisher gewohnt sind. Perfect Privacy liefert pro Gateway nur etwa 20-70Mbit/s Durchsatz. Bei Freifunk Rheinland dagegen haben wir 300-600Mbit/s gemessen. Die Umstellung bietet uns also die Möglichkeit unser Netz um Weiten schneller zu machen.
  3. Zugewinn an Redudanz: Über das Freifunk-Backbone verbinden wir uns zukünftig nicht mehr nur zu einem Exit-VPN-Anbieter pro Gateway, sondern bauen pro Gate 6 Verbindungen (GRE-Tunnel) auf und zwar zwei zu jedem Standort von Freifunk Rheinland in Berlin, Frankfurt und Düsseldorf. So erhalten wir einen enormen Zugewinn an Redundanz.
  4. Abuse-Handling/Haftungsfragen: Die IPv4-Adressen, die in der Öffentlichkeit auftauchen, sind nicht mehr auf LeaseWeb registriert, sondern auf drei bei der RIPE registrierte Mitglieder der Mainzer und Wiesbadener Freifunk-Community (Tobias, Markus und Sebastian). Für den normalen Freifunk-Benutzer und Knoten-Betreiber ändert sich in der Haftungsfrage dadurch nichts. Es ist weiterhin gewährleistet, dass die Daten über unsere Server ins Internet fließen und hier auf eine IPv4 Adresse des Freifunk Rheinlands „geNATed“ werden. Etwaiger Abuse (also Hinweise auf Rechtsverletzungen o.Ä.), der von Dritten zu diesen öffentliche IPs gemeldet wird, wird von Freifunk Rheinland bzw. von uns gehandhabt.
  5. Zukünftige Möglichkeiten: Die aktuelle Umstellung wird nur IPv4 betreffen. Über den Freifunk Rheinland haben wir aber die Möglichkeit endlich auch natives IPv6 im Freifunk-Netz anzubieten. Dadurch wird es im Freifunk-Netz bald möglich sein „Ende-zu-Ende“ im Internet zu kommunizieren. Weitere Details hierzu wird es mit der Umstellung geben.

Zu den Kosten: Für den Betrieb eines solchen Backbones entstehen dem Freifunk Rheinland e.V. natürlich nicht unerhebliche Kosten für Traffic, Hardware, etc., die wir mit kompensieren wollen. Der Vorstand des Freifunk Mainz e.V. hat daher in der vergangenen Woche bereits beschlossen, den Freifunk Rheinland zukünftig finanziell mit 200€ pro Jahr zu unterstützen. Ob wir dies als Fördermitglied tun oder durch eine jährliche Spende, beraten wir gerade noch.

Über Erfahrungsberichte würden wir uns sehr freuen. Bei Fragen wendet euch immer auch gerne an das Admin-Team.

Wer sich für die technischen Details interessiert, für den bietet dieses oder dieses Video der Rheinländer vielleicht einen guten Einstieg:

Kaschu und Wasserfloh – neue Gates für MWU

Gateway-Schema (credits: spookey)

schematische Übersicht der Netzwerke und Aufgaben eines Gate (credits: spookey)

Seit dem ersten Februar diesen Jahres stützen sich die beiden Netze des Wiesbadener und des Mainzer Freifunk auf einen redundanten Aufbau mit drei Gates; fällt eines aus, können die zwei verbleibenden diesen Ausfall gut auffangen. Seit ein paar Wochen arbeitet das Admin-Team an zwei weiteren Gates, die in Kürze in die beiden Netze integriert werden und damit die Redundanz weiter erhöhen werden.

Die beiden neuen Gates (Kaschu und Wasserfloh) werden von zwei engagierten Mitgliedern der Communities bereitgestellt – schön paritätisch eines aus Wiesbaden und eines aus Mainz. Auch zwei der bereits bestehenden Gates (Hinterschinken und Lotuswurzel) sind private Beiträge zum Freifunk, beide aus Wiesbaden. Das dritte bestehende Gate (Spinat) steuert der Freifunk Mainz e.V. bei. Das Admin-Team freut sich besonders darüber, dass die beiden Betreiber der neuen Gates auch Ihr Können und ihre Mitarbeit in das Admin-Team einbringen. An dieser Stelle sei aber darauf hingewiesen, dass die Bereitstellung eines Gates keine Bedingung für die Mitarbeit im Admin-Team ist.

Weiterlesen

ADS-B im Mainzer Freifunk Netz – Flugzeugen beim fliegen zuschauen

Aads-b-setupuch wenn manchmal der Eindruck entsteht, Freifunk würde nur Internet für möglichst viele bereitstellen,  ist Freifunk viel mehr als nur das. Im Freifunk Netz kann jeder seine eigenen Dienste anbieten unabhängig von Internetprovidern oder Serverbetreibern. Diese Möglichkeit habe ich genutzt und möchte euch heute meinen ADS-B Tracker vorstellen. ADS-B ist ein Signal, dass von Flugzeugen mit hoher Leistung (meist 250W) auf einer Frequenz von 1090 MHz abgestrahlt wird. In diesem Signal sind eine Vielzahl von Informationen enthalten z.B. die aktuelle GPS Position, die Geschwindigkeit, die Höhe, die Flugnummer und vieles mehr. Sofern ihr im Freifunk Netz unterwegs seid, könnt ihr euch unter http://flugzeug.user.ffmz.org das Web-Interface des Trackers ansehen.

Hardware

  • Für die Verarbeitung der Signale habe ich einen Raspberry Pi gewählt, da ich den von einem älteren Projekt über hatte :-)IMG_4383
  • Als Empfänger wurde ein RTL-SDR kompatibler DVB-T dongle verwendet (z.B. diesen)
  • Die Antenne habe ich wie in diesem Youtube Video nachgebaut. Bei mir hängt eine mit ~1 m Länge also 8 Elemente.
  • Den USB Hub brauche ich, da ich den Raspberry per WLAN ins Freifunk gehängt habe und das Model A nur einen USB Anschluss hat.
  • Das Dings links ist ein DC/DC Wandler um die Leitung (12V) auf eine für den Raspberry angenehme Spannung (5V) zu wandeln.

Software

  • rtl_sdr erlaubt die Nutzung der RTL2832U Tuner (Ursprünglich für DVB-T gedacht) als Software Defined Radio (SDR).
  • dump1090 ist ein Decoder für ADS-B Signale, die mit rtl_sdr aufgefangen wurden. Dump1090 bietet auch das Web Interface an, und kann die decodierten Signale an andere Anwendungen weiterleiten.ads-b
  • Über Piaware lade ich die Daten zusätzlich an FlightAware weiter, wer sich meine Statistiken mal angucken will kann hier gucken…

 

Meshen am Lessingplatz und in der Leibnizstraße

Mesh an Lessingplatz und Leibnizstraße

Mesh an Lessingplatz und Leibnizstraße

Seit gestern gibt es in der Neustadt in Mainz am Lessingplatz und entlang des oberen Teils der Leibnizstraße ein relativ großes Mesh-Netz. Eigentlich war nur geplant, die Standorte SPD-Neustadtladen, Unplugged-Beratungscafé und Kiosk-Lessingplatz miteinander zu vermeshen und dabei den SPD-Neustadtladen als Uplink zu nutzen. Dank guter Router (TP-Link WDR3600) und stärkerer 2,4-GHz-Antennen (LogiLink WL0037A) funktioniert das Meshing auch sehr gut.

Weiterlesen