Software

Your API file in only 6 steps

  1. Call up http://freifunk.net/api-generator/ 
  2. Fill in the information about your community in the form and press "OK - generate...". Mandatory fields are marked with an asterisk. The more information you enter, the better. 
  3. Your results will be displayed on the right hand side. If information is missing or fields are incorrectly filled, you will see it marked under the text box. Fill in or correct the information and generate the API file again.
  4. Save the content of the text box to a text file on your computer or press the download button.
  5. Upload the file created under point 4. to the Internet on to your Web space, in your content management system or our freifunk wiki. You will need a link to that file.
  6. The link must be added to the API directory. If you trust yourself, create a pull request, or you can send the link via contact form. If you chose the later, select "question about the API" as subject.

Please note: If you want to update, download or edit your API file, you can choose to do so after the entering the API directory, in the drop-down menu on the top right. The file must however be resaved or downloaded and uploaded to the Web server again.  

Please also use the possibilities to update information such as the number of nodes or services automatically and regularly. Gluon developers have written an examplary script, and there is a solution for OLSR-based networks on Github

You can find background information on the API in the blog and on freifunk.net.  

The most recent changes are summarized here.

Translation by Karin Kuschel.

In 6 Schritten zum API-File

  1. Ruf http://freifunk.net/api-generator/ auf
  2. Trag die Informationen zu deiner Community in das Formular ein und drücke auf "OK - generate...". Pflichtfelder sind mit einem Stern gekennzeichnet. Je mehr Informationen eingetragen werden, umso besser.
  3. Auf der rechten Seite werden dir die Ergebnisse angezeigt. Falls Informationen fehlen oder Felder falsch befüllt sind, steht es dort unter dem Textfeld. Ergänze oder berichtige die Informationen und generiere das API-File erneut
  4. Speicher die Inhalte des Textfeldes in einer Textdatei auf deinem Rechner oder drücke auf den Download-Button.
  5. Lade die unter 4. erstellte Datei hoch ins Internet auf einen Webspace, in euer Content Managementsystem oder in das Freifunk-Wiki. Als Ergebnis benötigst du einen Link zu der Datei, der aus dem Internet erreichbar ist
  6. Der Link muss noch in das API-Directory eingetragen werden. Wenn du es dir selbst zutraust erstelle einen Pull-Request, ansonsten schickst du den Link über das Kontaktformular an uns und wählst als Betreff 'Frage zur API'
Hinweis: Wenn du dein API-File aktualisieren willst, kannst du es nach dem Eintrag ins API-Directory im Auswahlmenü oben rechts auswählen, laden und bearbeiten. Danach muss die Datei allerdings erneut gespeichert oder heruntergeladen und auf den Webserver hochgeladen werden.
 
Nutz bitte auch die Möglichkeiten, Informationen wie die Anzahl der Knoten oder Dienste automatisch und regelmäßig zu aktualisieren. Die Gluon-Entwickler haben ein Beispiel dafür ein Script geschrieben und für OLSR-basierte Netzwerke gibt es eine Lösung bei Github.

Hintergründe zur API findest du im Blog und auf freifunk.net.

Die letzten Änderungen sind hier zusammengefasst.

Neues aus der API-Werkstatt

Nach einige Zeit hat es mal wieder einen Versionssprung bei der Freifunk-API gegeben: Unsere Freifunk-API steht ab sofort in Version 0.3.0 bereit. Bestehende API-Dateien sollten schnell aktualisiert werden, da sich einige nicht rückwärtskompatible Änderungen ergeben haben.

Neuerungen und Änderungen der Spezifikation

    • Services hinzugefügt, netz-interne Dienste können hier angegeben werden. Später soll aus diesen Daten eine freifunk-weite Serviceübersicht entstehen
    • Timeline hinzugefügt, hier können Communities wichtige Meilensteine ihrer Geschichte eintragen (z.B. Gründung, Neugründung, wichtige Ereignisse wie Vereingründung oder Rekordstände bei Nutzern/Routern). Mit diesen Daten können schöne Zeitstrahlen erstellt werden
    • TLD hinzugefügt, damit Communities die von ihnen genutzten Top Level Domains (.ffhh, ffl, ...) benennen können. Die Informationen können genutzt werden, um die DNS-Konfiguration über die eigene Community hinaus nutzen zu können
    • Kalender-Sektion entfernt, durch Feed vom Typ ics ersetzt. Eine eigene Kalenderspezifikation erwies sich als zu komplex. Mit ics-Files kann man leicht übergreifende Kalender erstellen 
  • Country als Feld aufgenommen
  • Pattern zur Validierung von Eingaben für diese Felder eingeführt: urls, irc, twitter, email, facebook, ip-Adressen
  • Zeitstempel von Unix-Timestamp auf ISO8601-Format umgestellt
  • Netzwerke in CIDR-Notation
  • API Generator validiert

Änderungen am Generator

  • Die Eingabefelder wurden umsortiert. Pflichtfelder verstecken sich nicht mehr hinter eingeklappten Elementen
  • Der Generator kann API-Dateien validieren. Entweder wählt man seine Datei aus dem Auswahlfeld über dem Textfeld oder man kopiert den Inhalt einer Datei in das Textfeld
  • Bei der Validierung werden die Daten direkt in die Formularfelder kopiert, so dass sie danach gleich bearbeitet werden können
  • Gültigkeit von API-Dateien zeigt der Generator farblich an
  • Das Ergebnis der Validation zeigt die problematischen Felder an, man muss sie nicht mehr erraten
  • Zeitpunkt der letzten Änderung und API-Version setzt der Generator automatisch beim der Erstellung, wenn die Eingaben gültig sind

Weitere Änderungen

  • die zusammengefassten API-Dateien legen wir mit jeder Erzegung gesondert ab, um später die Entwicklungsgeschichte verfolgen zu können (Anzahl Communities, Anzahl Router, ...)
  • Es gibt mehrere Ansätze, z.B. die Anzahl der Knotennummern in den API-Files automatisch aktualisieren zu lassen. Solche Scripte und Anleitungen sammeln wir im Github-Repository common.api.freifunk.net 

Die gesamte Änderungsgeschichte ist Github-Repository aufzufinden. Fehler, neue Anforderungen oder Anregungen meldet ihr bitte auch im Github unter "issues".

Freifunk Google Summer of Code 2014

We are excited that Freifunk has been accepted as a Google Summer of Code Mentor organization again in 2014.

We are now looking for interesting student projects. Participating community networks and projects have already put up a list of ideas on the wiki.

Students can apply for example for projects developing packages for OpenWrt (the basis of the freifunk firmware) extending its functionality or other useful network tools such as management server tools, graphic interfaces for existing tools, map extensions, p2p tools that take routing into consideration, implementing wlan sleeping modes, routing protocols and more.

The deadline for student applications is 21 March: 19:00 UTC. We recommend to start your application now. You also need to add an enrolement form into the system.

 

Freifunk Google Summer of Code Timeline

21 March:

19:00 UTC

Student application deadline.

Interim Period:

Mentoring organizations review and rank student proposals; where necessary, mentoring organizations may request further proposal detail from the student applicant.

7 April:

Mentoring organizations should have requested slots via their profile in Melange by this point.

9 April:

Slot allocations published to mentoring organizations

Interim Period:

Slot allocation trades happen amongst organizations. Mentoring organizations review and rank student proposals; where necessary, mentoring organizations may request further proposal detail from the student applicant.

15 April:

First round of de-duplication checks happens; organizations work together to try to resolve as many duplicates as possible.

18 April:


  1. All mentors must be signed up and all student proposals matched with a mentor - 07:00 UTC

  2. Student acceptance choice deadline.

  3. IRC meeting to resolve any outstanding duplicate accepted students - 19:00 UTC #gsoc (organizations must send a delegate to represent them in this meeting regardless of if they are in a duplicate situation before the meeting.)

21 April:

19:00 UTC

Accepted student proposals announced on the Google Summer of Code 2014 site.

Community Bonding Period:

Students get to know mentors, read documentation, get up to speed to begin working on their projects.

19 May:


  1. Students begin coding for their Google Summer of Code projects;

  2. Google begins issuing initial student payments provided tax forms are on file and students are in good standing with their communities.

Work Period:

Mentors give students a helping hand and guidance on their projects.

23 June:

19:00 UTC

Mentors and students can begin submitting mid-term evaluations.

27 June:

19:00 UTC


  1. Mid-term evaluations deadline;

  2. Google begins issuing mid-term student payments provided passing student survey is on file.

Work Period:

Mentors give students a helping hand and guidance on their projects.

11 August:

Suggested 'pencils down' date. Take a week to scrub code, write tests, improve documentation, etc.

18 August:

19:00 UTC

Firm 'pencils down' date. Mentors, students and organization administrators can begin submitting final evaluations to Google.

22 August:

19:00 UTC


  1. Final evaluation deadline

  2. Google begins issuing student and mentoring organization payments provided forms and evaluations are on file.

22 August: 20:00 UTC

Students can begin submitting required code samples to Google

25 August:

Final results of Google Summer of Code 2014 announced

Links

* GSoC Page: https://www.google-melange.com/gsoc/org2/google/gsoc2014/freifunk

* Idea Page: http://wiki.freifunk.net/Ideas

Neue Version des Freifunk-API-JSON-Generator released

Ralf hat eine neue Version des "API-JSON-Generator" für die Freifunk-Api released.

Es gab... hier eine Diskussion ob man nicht bestehende Daten aus JSONs in das Formular übernehmen könnte und das hab' ich gerade mal umgesetzt.  (Daneben auch noch ein bisschen Code-Refactoring ...)

Der Code ist verfügbar auf http://freifunk-ffm.github.io/api.freifunk.net/generator/

Die Freifunk-API ermöglicht Communities automatisch in Diensten wie der Freifunk-Karte (Map) oder dem freifunk.net-Feed-Aggregator auf der Startseite angezeigt zu werden. Besucher von freifunk.net erhalten somit einen einfachen Überblick über Communities und lokale Kontaktmöglichkeiten.

Der Api-Generator unterstützt Communities bei der Erstellung der für die API benötigten JSON-Dateinen mit Informationen über die Community und Ansprechpartner.

Der API File Generator wird unter http://ja.ishalt.so/ffapi bereit gestellt. Hier werden die notwendigen Daten eingetragen, aus dem Ergebnisfenster auf der Website kopiert und lokal auf dem Computer in eine Datei gespeichert. Der Unix-Timecode [Unixzeit Wikipedia] stellt sicher, dass stets die neueste Version mit Informationen einer Community zusammengetragen wird.

Die Datei kann nun im eigenen Webspace (Wiki, Website, Blog etc.) abgelegt werden und der Link in das Verzeichnis auf github hier eingetragen werden. Das Verzeichnis auf github besteht aus einer Zuordnung von Communitynamen und URL zu den bereitgestellten Daten. Die dezentrale Struktur bietet den Communities eine einfache Möglichkeit, eigene Daten selbst aktuell zu halten. Die aktuellen Daten werden in regelmässigen Abständen von der im github-Verzeichnis angegebenen URL heruntergeladen.

 

Links

* Freifunk API File Generator http://ja.ishalt.so/ffapi

* Repository https://github.com/freifunk/api.freifunk.net

* Link deiner Community auf Github hinzufügen: https://github.com/freifunk/api.freifunk.net/blob/master/directory/direc...

EFF: Mesh Networking, Good. Overbroad Patents, Bad. Help Us Protect Mesh Networking.

Die Electronic Frontier Foundation bittet um Mithilfe in Bezug auf Mesh-Patente. Die EFF sieht ein großes Problem in bestimmten Patenten, die Einfluss auf verbreitete Mesh-Protokolle (wie das von Freifunk entwickelte B.A.T.M.A.N.-Protokoll) haben könnten:

Wireless Mesh Networking is still in its nascent stages, and the innovations and experimentation of the open source community are playing a vital role in advancing the technology. However, there has also been significant proprietary and military interest in the technology, and companies are seeking patents in many areas of WMN already explored by the open source community. We unfortunately know what can happen when overbroad patents get granted—the rise of patent trolls, lawsuits that can threaten growing businesses, and threats that target entire areas of technology. We don't want to see that happen to mesh networking.

We have identified several patent applications that we believe particularly threaten the free development of mesh networking technology. There is a danger that these patents, if granted, will lock up the basic mesh network infrastructure and restrict advancement of and access to the technology.

Die EFF bittet nun um Mithilfe auf der Suche nach sogenanntem Stand der Technik (Prior Art), um die Patente zu Fall zu bringen:

Which is why we need your help. We are again partnering with Ask Patents so you can help us identify the best prior art to reign in these applications. While prior art for issued patents must date back many years, these are recently filed applications for which relatively recent publications may be helpful. Look at each “Request for Prior Art” we post to learn the exact priority date.

Working together we can protect the mesh networking community from overbroad, illegitimate patents that threaten to stifle innovation and access to technologies that preserve personal freedoms.

Copyright-Hinweis: Der Artikel von Julie Samuels steht unter einer Creative Commons-Attribution (CC-BY 3.0)-Lizenz.

Cross-post aus dem Blog "Offene  Netze und Recht".

Erstes Release für Freifunk-Bielefeld

Nach längerer Entwicklungszeit haben wir endlich die erste Firmware-Version (0.1) für unsere Freifunk-Bielefeld Gruppe fertig. Die Firmware baut auf batman-adv (2013.1.0), fastd (7) und auf OpenWRT (Attitude Adjustment) auf und wurde mit dem Ziel entwickelt eine simple und möglichst dezentrale Konfiguration zu bieten. Ein Router muss nur mit der Firmware bespielt werden und benötigt ansonsten nur Strom um sich sich mit gleichartigen Routern in Reichweite zu verbinden. Eine weitere Konfiguration ist nicht nötig aber natürlich möglich.

Die Firmware wurde so konfiguriert, dass es (fast) keinen routerspezifischen Code gibt und mehrere Wlan-Karten (2.4/5Ghz) unterstützt werden. Jeder Router hat eine öffentliche Statusseite mit dem Namen des Routers, der Anzahl der Nachbarn und einer Liste von alternativen Gateways. Über eine Web-GUI können sehr vielfälltige Einstellmöglichkeiten wie z.B. das Konfigurieren einzelner Ports, eines privaten WLAN-Netzes oder einer Splash-Seite vorgenommen werden.

Wer also in Bielefeld oder Umgebung wohnt kann gerne einen Router aufstellen. Wir helfen dabei auch gerne und laden dazu jeden Dienstag Abend in den Hackerspace Bielefeld ein.

Natürlich haben wir noch eine offizielle Release-Ankündigung, fertige Images, eine Freifunkkarte und eine Seite mit Stichpunkten zu technischen Details.

Frohes Maschen,

die Freifunk-Bielefeld Gruppe :-)

Node Database and Map Server Yaffmap: Yet Another Freifunk Map

yaffmap is a project from Dennis Bartsch from Freifunk Berlin, which he started with a friend. It is called yaffmap. It got its name because at the beginning of the project we had many mapservers in Berlin and so it started as yet another approach for a Freifunk map. 
 
yaffmap - screenshot
 
The intention was to make a server that not just produces points and lines (nodes and their links) but to gather all information that might help to understand why a link is as bad as it is. This includes to gather wireless scan results, the effective rate chosen/calculated by the wireless driver to a specific neighbour and so on. Furthermore it had to be independent from the routing-protocol and its daemons (but needs it to gather useful info) and the IP version (or even no IP version for RPs like batman) and had to be able to upload and store data from multiple routing protocols on the same node. In order to sample so much information we went the route of scripting an agent for the map-server which runs on the nodes gathering the information and uploading it through a JSON interface to the server. For link-state-protocols like OLSR we even implemented the upload of the global topology to the server, which gave us some headache. From the beginning on the need for decentralized operation was stressed, so replication between the servers was implemented and any community which wants can have their own map data server. Moreover they cleary wanted the datacollection/storage to be independent from the frontend the map user is presented. In Berlin everytime a new map came along and an old one was gone we saw huge ammounts of data simply disappear. So the server only provides a SOAP interface for UIs and other services to use to get map data. The representation of a node in the database ist best seen on a graphic. Dennis uploaded it to imageshack, see [1]. A little bit of documentation is found under [2], but wasn't thoroughly updated after we left concept stage.
 
We got to the point where the agent (bunch of shell/AWK) for the nodes runs on openWRT (best with madwifi and ath9k/ath5k) with olsrd (other routing daemons simply need scripts for data gathering, agent is held modular), uploades many useful information to the server (or another if the first does not respond; multiple can be configured) using JSON, where it gets stored correctly into a SQL database and replicated to other servers and provided through a SOAP interface. The agent even is already provided as a package in the respected PBerg Freifunk Firmware. There also exists a 'proof-of-concept' implementation for a map frontend, see [3]. The code is hosted on github as seen und [4]. Because of the frontend development got stuck the frontend SOAP interface is not very sophisticated nor much tested as is the frontend itself.
 
The result is a database which can answer more complex question to the mesh engineer or software developer. Maybe you want to know the average effective rate on all 11n interfaces or all 5GHz interfaces? Or you might be interested in the average ETX on different channels in a certain geographic area. Or you want to compare how different routing daemons evaluate the quality of a certain link. Maybe you even want to draw a noise map. Or wouldn't it be interesting to see the correlation between the effective rate of a wifi link and the metrics which result in the routing daemons? Because the node data includes a 'misc' field through which any kind of node id or statistics could be stored/sent this is can even be integrated into existing community portals.
 
 
Syndicate content