Tag: community

Monitoring and quality assurance of open wifi networks out of client view (final evaluation)

Posted on by Jan Tarek Butt

Hi together,

now the time has come to explain the full Google Summer of Code Project. In both blog posts before I explained the work packages and structure of the Project [0][1]. In the first post I declare the three main subjects. Here is a short overview to remind of the project structure:

sub-projects,

Mainline project

and seminars.

The sub-projects are background work for community projects.

The mainline Google Summer of Code project is to develop a new firmware for routers, based on LEDE [2]. The third point are seminars for enlightment of technical aspects of the Freifunk Community.

 

First I would like to list up all sub-projects and their status.

The first of the sub-projects is the hoodselector. For a final explanation of this construct I would like to explain the following points to give you a good understanding of this concept. On the Nordwest Freifunk community we had one big problem. Due to the batman-adv management traffic, the network setup is not really scalable. This problem also exists on many other communities where they have thousands of mesh routers inside one single network. If there are too many routers inside of one layer 2 network the batman-adv management traffic will flood this network and make it useless.

 

Therefore in the Nordwest Freifunk Community we decided to develop the concept of hood-networking. This concept consists of two main components: The hoodfile [3] and the hoodselector[4]. The hoodfile is a json file containing all informations necessary for a definition of a geobased hood. One hood is defined by a geostationary fixed quadrants, VPN-peering- and wireless configurations. Inside a hoodfile are multiple hoods defined[5]. Following an example of a definition of a hood:

 

{

     “name”: “rastede”,

     “bssid”: “02:00:0A:12:A0:00”,

     “defaulthood”: false,

     “servers”: [

         {

             “host”: “ras01.sn.ffnw.de”,

             “port”: “10000”,

             “publickey”: “ca1b5487ffc20a1f90e0ac14e835d84ab9e52612b5ca62e073d0a13dad98775e”

         }

     ],

     “boxes”: [

         [

             [

                 53.22,

                 8.09

             ],

             [

                 53.36,

                 8.32

             ]

         ]

     ]

},

 

A hood has the following definition:

 

– name

The name describes the region depending on its geo coordinates. For example, if you create a hood over the city Oldenburg(Oldb) (Germany), a good name could be Oldenburg or ol as short. Every name has to be unique inside a hoodfile. Redundant names are not allowed!

 

– bssid

The bssid will be set for the adhoc wireless interface. This is the main part of splitting the layer 2 network. Inside the bssid there is the IPv4 sub-network encoded which is in use inside the hood. In the above json part the following IPv4 sub-network is encoded “10.18.160.0/21” dec to bin => “0000’1010 0001’0010 1010’0000 0000’0000” bin to hex => 0x0A 0x12 0xA0 0x00 hex to mac => 02:00:0A:12:A0:00. Therefore the bssid should also be unique.

 

– defaulthood

The defaulthood boolean is only true on the default hood. The default hood doesn’t have coordinates and is the inverted form of all other hoods with geo coordinates.

 

– servers

Contains an array of VPN connection informations. These informations are:

VPN server address (host)

VPN port

VPN crypto key

One VPN server should be used for one hood only! If two hoods have the same VPN server, batman-adv will loop them over VPN.

 

– boxes

This 3 dimensional array describes the geographical size of the hood. The surface is rectangular. You just need two points per box to reconstruct it. Here is an example:

 

 

                                          53.22,

                                          8.09 #____________

                                                   |                  |

                                                   |                  |

                                                   |                  |

                                                   |____________|

                                                                      # 53.36,

                                                                          8.32

 

 

Each hood can have any number of rectangles inside the boxes array.

 

To make your life a little easier you can use the hoodgen[6] and source[7] to write your json with the required informations. This is a simple web visualization tool to plan hoods and generate the right json format for the hoodfile. This tool has been written by Eike Baran. Big Thanks to him for this helpful tool!

 

Now to the hoodselector.

It is a software that creates decentralized, semi automated ISO OSI layer 2 network segmentation for batman-adv layer 2 routing networks. This program reads the geobased sub-networks called hoods from the above mentioned hoodfile. The decision of choosing the right hood is made on following points: first, the hoodselector checks, if the router has a VPN connection. If it has, the hoodselector then checks, if a static geoposition was set on the router. If not, it tries to get a position using wireless based localization with the so called geolocator. The geolocator [8][9][10] is a software which makes it possible to receive a position based on wireless networks “seen” around. These informations will be sent to the openwifi map project [11]. Knowing the position of the router the hoodselector can find the right hood, because each hood is defined with geocoordinates. If the Router doesn’t have a VPN connection e.g. as a mesh only router, the hoodselector triggers a WIFI scan and searches for neighboured mesh routers in other hoods. If there is an other router with a different BSSID but with the same mesh SSID, the router chooses it’s hood based on the neighboured BSSID. I got much positive feedback from many other Freifunk Communities. Someone even created a integration request issue for gluon [12]. Gluon is a framework based on openWRT[13] and is very popular in the Freifunk community [14]. Before I will send this as a patch to gluon there remains one last urgent issue [15]. The current hoodselector is not able to handle mesh on LAN or WAN connections. So there is still a potential point of failure. Because persons who are not familiar enough with the hood-networking concept can accidentally interconnect hoods over the mesh on cable functions. I plan to fix this problem up to mid of september. When this issue is closed I would like sending patches for integration to gluon. Other issues can be found here[16].

 

On the Nordwest Freifunk community we currently have 10 active hoods including a default hood. That is a special hood where all routers will connect to, if they are not able to choose a hood, including also routers there out of ranges from other real hoods. After the last 3 months we can safely say that the setup works. Commits can be found here[17] All currently active hoods can be see here in this picture.

 

 

 

As next I would like to tell you about the second sub-project as a prework for the mainline project. In that part I work on a proper workaround with the continuous-integration (CI) system of Gitlab[18]. As I explained in the midterm evaluation, on our Nordwest community we started automatically building of nightly testing firmware images for our community firmware. The CI works now with a dynamical multiple core build processes and auto generated architecture targets out of source. At the moment it is not possible for Gitlab to handle high verbose inside the web-engine while the build process. I discussed the problem with the gitlab team and open an issue [19]. The CI builder is very helpful for the developing process of the monitoring drone. Here you can see the result for the local community image[20] and for the monitoring-drone [21].

 

Mainline Project.

The mainline project was to create a new firmware for monitoring and quality assurance of open wireless networks. So I started reading of informatins about openWRT [13] and LEDE [2]. I decided to use LEDE as base system. I know there still no release to use this as a defined base structure (we are all looking forward to this moment) but since july 2016 I am on the developer list and the way where LEDE is growing looks good. Next I looked for a build management script. First I thought about using make and Makefiles but this was not my favourite, so I decided to use the buildscript from the Franken Freifunk community as base, which is written in bash. Now I’ll explain the structure how to work with and use it. The following directories and files are important for basic work:

 

buildscript ← File

     BSP ← Dir

     Community ← Dir

     build_patches ← Dir

     modules ← File

 

The buildscript is mainly a bash script for a humanly working with this buildroot. In other words it is an abstraction from the LEDE build ENV.

 

Inside the BSP directory are all necessary architecture specific informations.

BSP means Board-Support-Package. Also inside this directory are default informations like the shell banner system configs and so on.

 

The community directory includes community specific configurations, similar like the gluon siteconf [22]. Currently there are only two config parameters inside: first the “AP SSID” to set a default SSID with witch WIFI network should the monitoring-drone connect and the second parameter, the “AP BSSID” to set a node specific BSSID in case if more than one router with the same SSID is present. Then the monitoring drone is pinned on one specific node. This config parameter will be dropped in the future because it is not really effectively if a default BSSID is set . In future I plan to configure thous parameters over an extra web interface[23].

 

In the build_patches directory you can put patches for LEDE or if you what you can also put patches for each package repository. Here is a schemata:

 

build_patches

     lede

         0001-this is a patch.patch

         0002-this is another one.patch

     ffnw-packages

         0001-this is a patch.patch

         0002-this is another one.patch

 

The last file is called modules. Inside this file you can add external package repositories and also select specific packages out of this repositories. Following an example:

 

OPENWRT=(ffnw-packages

     $PACKAGEURL

     $PACKAGEREV)

OPENWRT_PKGS=”libwlocate lwtrace ffnw-node-info hoodselector”

 

Clemens and I discussed about the API design[24] regarding the communication between the monitoring drone and the netmon core. So we met together. Here a picture:

Jan-Tarek Butt (left) and Clemens John (right)

 

At last point were the seminars. During the Google Summer of Code we started to gave seminars for technical aspects of Freifunk because we have not enough developers and system administrators. That is mostly a big problem in volunteer activities. On the hacking sessions we follow a simple structure:

 

– two lectures about Freifunk technical aspects.

– discus about the contend of the lectures

– work session on projects

 

On the first hacking session at the 28. may 2:00 PM we created video recordings of the two lectures, you can find them here[25]. The next hacking session were failures because of Clemens and my exams. In future there will follow other streams about tecnical aspects of Freifunk.

 

Last but not least, my future plans:

For the hoodselector, I plan to close up the last urgent issue[15] that I mentored in the above for the migration into gluon I also started prework on gluon for this. One part was the implementation of a sequential code minifying process at compile time [26]. Also some other issues are still open so I will continuing the work on the hoodselector[16].

 

For the monitoring firmware they currently is just configurable over ssh. A web interface should follow soon and also a plugin system for community specific monitoring data requests.

 

On the Kieler Linux information days[27] inside the Kieler Innovations- and technology center I will hold amongst others 4 presantations about Freifunk relevants themes:

 

    Hoodselector – Network segmentation for Layer 2 routing at 11:00 (16.09.2016)[28]

    Wireless-based localization (openwifi.su project) at 13:00 (16.09.2016)[29]

    OpenWRT Embedded Linux distribution at 16:00 (16.09.2016)[30]

    Freifunk Kiel/Nordwest (2016) – year review at 16:00 (17.09.2016)[31]

 

[0] http://blog.freifunk.net/2016/monitoring-and-quality-assurance-open-wifi-networks-out-client-view

[1] http://blog.freifunk.net/2016/monitoring-and-quality-assurance-open-wifi-networks-out-client-view-midterm-evaluation

[2] https://lede-project.org/

[3] https://git.nordwest.freifunk.net/ffnw-firmware/packages/blob/master/hoods/files/lib/ffnw/hoods/hoods.json

[4] https://git.nordwest.freifunk.net/ffnw-firmware/packages/blob/master/hoodselector/luasrc/hoodselector

[5] https://git.nordwest.freifunk.net/ffnw-firmware/packages/commits/master/hoods

[6] http://hood.ffnw/hoodgen.html#

[7] https://git.nordwest.freifunk.net/ffnw-server/hoodgen

[8] https://git.nordwest.freifunk.net/ffnw-firmware/packages/tree/master/libwlocate

[9] https://git.nordwest.freifunk.net/ffnw-firmware/packages/tree/master/lwtrace

[10] https://git.nordwest.freifunk.net/ffnw-firmware/packages/tree/master/ffnw-node-info

[11] http://openwifi.su/

[12] https://github.com/freifunk-gluon/gluon/issues/789

[13] https://openwrt.org/

[14] http://gluon.readthedocs.io/en/latest/

[15] https://git.nordwest.freifunk.net/ffnw-firmware/packages/issues/63

[16] https://git.nordwest.freifunk.net/ffnw-firmware/packages/issues?label_name%5B%5D=hoodselector

[17] https://git.nordwest.freifunk.net/ffnw-firmware/packages/commits/master/hoodselector

[18] https://about.gitlab.com/gitlab-ci/

[19] https://gitlab.com/gitlab-org/gitlab-ce/issues/18039

[20] https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/builds

[21] https://git.nordwest.freifunk.net/ffnw-firmware/monitoring-drone/builds

[22] https://github.com/freifunk-gluon/gluon/tree/master/docs/site-example

[23] https://git.nordwest.freifunk.net/ffnw-firmware/monitoring-drone/tree/master

[24] https://git.nordwest.freifunk.net/groups/netmon-sc

[25] https://www.youtube.com/channel/UCX0nJzimLNF38pfgQIuZLEQ

[26] https://github.com/freifunk-gluon/gluon/commits/master?author=2tata

[27] http://www.kilux.de/

[28] http://www.kilux.de/index.php?seite=programm.html&untermenu=Besucher-Info#248

[29] http://www.kilux.de/index.php?seite=programm.html&untermenu=Besucher-Info#246

[30] http://www.kilux.de/index.php?seite=programm.html&untermenu=Besucher-Info#247

[31] http://www.kilux.de/index.php?seite=programm.html&untermenu=Besucher-Info#263

Monitoring and quality assurance of open wifi networks out of client view (midterm evaluation)

Posted on by Jan Tarek Butt
Hey everyone,
 
Now we are on the midterm evaluation. I would like to tell you what I have done so far and what will come next. In the first post [0] I explained the work packages. In this post I will come back to the work packages  and show you what I have done for each package.
 
The first sub-project was the hoodselector. At the beginning of the work period I did some bugfixing for the hoodselector so that we where able to deploy the hoodselector in our live environment. The hoodselector creates decentralized, semi automated ISO OSI layer 2 network segmentations. You can find a detailed discription here [0]. Retrospective I can say that the deploymend of the hoodsystem went without any major problems opposed to my first expectations. Currently we have 4 hoods active. Around Oldenburg(Oldb), Ibbenbüren, Osnabrück and Friesland. More hoods will follow in future. Open Issues can be find here [1].
 
The second sub-project was to create a propper workaround for building images with the continuous-integration (CI) system of Gitlab using make on multiple cores.
The Freifunk Nordwest firmware now has automatically built testing images that are not only build on a single core but can be built on multiple cores. And the architecture targets are also autogenerated out of the sourcecode. This makes it possible to generate images dynamically for all targets also including new targets that may come in the future. I implemented a small algorithm that manages the thread counter of make commands. I use the number of CPUs out of /proc/cpuinfo * 2 this means for each logic core will follow two threads. In example our runner02.ffnw.de server has 8 cores so the CI build process will automatically build with 16 Threads [2]. Here is an example of a passed buildprocess with our CI builder[3]. Actually it is not possible to build images with a high verbose output, because the CI logfiles will get to big. That makes it impossible to use the webfrontend for analyzing the buildprocesses. I opened an issues for this and discussed the problem with the gitlab developers [4].
The CI builder is very helpful for the developing process of the monitoring drone.
 
Following I would like to report about our first hacking seminar.
The first hacking seminar was on 28.05.2016. We started with two presentations. One about Wireless Geo Location and the second one about the Hoodselector. We recorded the presentation with our new recording equipment [7] bought using some of the money for the mentoring organisation and uploaded the recordings to youtube [5].
 
The first presentation was about geolocating with wireles technologies.
Based on the Nordwest Freifunk geolocator [6]

The second presentation was about the function of the Hoodselector

 
After this two presentations we had a smal disscussion about the presentation topics and than we started our hacking session where the developers started coding on their projects.
 
Now all sub-Projects are finnisched and I will continue with the Monitoring Drone Project after I finish my Study exams. Also the date of next hacking seminar is set for 9th of Juli 2016. Again we will have two presentations. One on Gitlab CI and one about how to use our new Puppet Git repositories including the submodule feature. The presentations will be recorded and after the presentation we will have a coding session like last time.
 
Timeline:
23. May: Community Bonding (3 weeks)
test and deploy hoodselector  <- Done
16. May 6:00 PM: GSoC Mumble  <- Done
Refine the roadmap  <- Done
23. May – 20. June: Work period 1 (4 weeks) <- Done
28. May 2:00 PM: hacker-session  <- Done
  1. Presentation about the hoodselector <- Done
  2. Presentation about the openwifi.su project[4] and the geolocator <- Done
13. June 6:00 PM: GSoC Mumble  <- Done
Midtermevaluation
Tarek & Clemens exams!!!
20. June – 15. August: Work period 2 (8 weeks)
9. July 2:00 PM: hacker-session
  1. Presentation about workaround with git CI processes.
  2. Presentation about puppet deployment system
13. June 6:00 PM: GSoC Mumble
25. June 2:00 PM: hacker-session
  1. Presentation about workaround with git CI processes.
  2. Presentation about puppet deployment system
18. July 6:00 PM: GSoC Mumble
30. July 2:00 PM: hacker-session
  1. actual unknown
  2. actual unknown
15. August 6:00 PM: GSoC Mumble
Finalevaluation
 

Monitoring and quality assurance of open wifi networks out of client view

Posted on by Jan Tarek Butt
Hey everyone,
 
My name is Jan-Tarek Butt and I am in my second term of computer science at Emden University in Lower Saxony (Germany). I am one of the students that are participating for Freifunk in the Google Summer of Code 2016. In the following post I would like to introduce you to my Google Summer of Code project. I split up the project into 3 main subjects: Mainline project, sub-projects and seminars.
 
Before I explain the three mentioned subjects I would like to give you some background information about the project in general. My project mentor is Clemens John. He studies computer science at University Osnabrück in Lower Saxony (Germany) and recently started to write his bachelor thesis. As part of his bachelor thesis he will build a monitoring and administration software for open wireless networks called “Netmon-SC” based on a previosly existing software that will be rewritten to follow a decentralised idea. The coarse structure of Netmon-SC will consist of a core module as a data storage backend that can be queried by using a REST API based on NetJSON. In addition to the REST API the core module will include a plug-In system which developers can use to easily extend the core module to build data storages for creating visualisation tools, quality assurance metrics or any other community specific tools like special administration applications.
 
My mainline GSoC project is to develop a new firmware for routers based on openWRT or LEDE. This firmware will  be the basis for an application to monitor the clients view onto an open wireless network. From now on we will call this firmware the “Monitoring-Drone”. This monitoring firmware will gather quality assurance metrics and send them to Netmon-SC. This metrics will help developers and administrators to enhance the quality of open wireless networks and find bugs more easier. The firmware will include an API package to communicate with Netmon-SC. It will also contain a small LUCI web-interface for basic configuration e.g. wireless network settings etc. Additionally to the basic settings it should be possible to integrate small plugins in form of  .sh or .lua files witch contain custom commands.This will allow communities to gather network specifics metrics without compiling community specific firmware images. The API for communication with Netmon-SC, the web-interface and the plugin system will embedded into a package bases structure. The git repository for this project can be found here.
 
Now to the sub-projects. Sub-projects are small projects adjacent to the mainline project. The first sub-project is the so called hoodselector that I finished reviewing on Mai 21th. The hoodselector creates decentralized, semi automated ISO OSI layer 2 network segmentations based on geostationary fixed quadrants for batman-adv mesh networks. It detects in which quadrant the node is in by using wireless location services and configurates the router using the settings that have been stored for this quadrant. In conclusion the hoodselector enables us to build scaled decentralised mesh-networks. It is a small program on open wireless routers on the Nordwest-Freifunk community network.
 
The second sub-project is, to create a proper workaround for building images on a multicore system instead of a single core system by using Gitlabs continuous-integration (CI) feature. This will fully automate the firmware image building process for the Monitoring-Drone and also for the open wireless firmware images from the local community.
 
The third sub-project are regular seminars. The idea of this seminars is to give earned knowledge to the public and also acquire new developers for open wireless projects. The seminars should have one or two short presentations about technical processes from open wireless networks, for instance how the hoodselector works or how batman-adv works. The Presentations will be video recorded and uploaded to the internet. After thous presentations on the seminars I plan short discussions about the contend of the presentations. Afterwards hack-sessions should do force forward the developing processes for the Google Summer of Code project and illuminate the opensource software development scene of the open wireless project.
 
Last but not least we created a project timeline. Clemens and I, will have regular Mumble meetings during the GSoC, at the middle of every month. On this meetings we will discuss the work already done and what should happen next. Beside the work on the main project we will also use the meetings to plan the next seminar that will always follow at the end of each month.
 
Timeline:
23. May: Community Bonding (3 weeks)
test and deploy hoodselector  ← Done
16. May 6:00 PM: GSoC Mumble ← Done
Refine the roadmap ← Done
23. May – 20. June: Work period 1 (4 weeks)
28. May 2:00 PM: hacker-session
  1. Presentation about the hoodselector
  2. Presentation about the openwifi.su project and the geolocator
Midtermevaluation
20. June – 15. August: Work period 2 (8 weeks)
Tarek & Clemens exams!!!
13. June 6:00 PM: GSoC Mumble
25. June 2:00 PM: hacker-session
  1. Presentation about workaround with git CI processes.
  2. actual unknown
18. July 6:00 PM: GSoC Mumble
30. July 2:00 PM: hacker-session
  1. actual unknown
  2. actual unknown
15. August 6:00 PM: GSoC Mumble
Finalevaluation
Cheers
Jan-Tarek Butt

Links sammeln und Termine teilen

Posted on by Andreas Bräu

Was ist das?

Die beiden Werkzeuge LinkSink und Calcifer sind nun einsatzbereit. Mit LinkSink können wir für Freifunk Links zu unseren Themen zusammentragen und daraus RSS-Feeds erstellen. Durch Kategorisierung und Hinzufügen von Tags können wir damit sehr flexibel RSS-Feeds zu bestimmten Themen bereitstellen und bei vorhandenen Mediendateien sogar diese einbinden. Calcifer kann man zum Verwalten von Terminen und Erstellung von ics-Dateien verwenden. Auch hier kann nach Tags und Orten gefiltert werden.

Für einige Anwendungen nutzen wir beide Werkzeuge schon aktiv:

Wie funktioniert das?

Auswahl und Filter

LinkSink Filter

Auf der Startseite sind zunächst alle Einträge zu sehen. Durc h einen Klick auf ein Tag eines Eintrags oder durch Nutzung der Filterleiste kann man diese Auswahl einschränken. In Calcifer kann derzeit entweder nach Tags oder nach Orten gefiltert werden. Filter in LinkSink können Kategorie, Jahr und ein Tag enthalten.

Link zum Feed

Fü r ein Filterergebnis steht dann ein Link zum RSS-Feed oder der ICS-Datei bereit. Die URL des Feeds bleibt konstant, so dass diese in anderen Anwendungen permanent eingesetzt werden kann. Mit jedem Aufruf wird der dahinterliegende Feed neu erzeugt und mit aktuellen Daten gefüllt. Calcifer erzeugt dabei nur in der Zukunft liegende Termine. LinkSink ordnet die Einträge absteigend nach Erscheinungsdatum.

Neue Links oder Termine kann man mit einem Klick auf Neuer Link bzw. Neuer Termin oben in der Navigationsleiste anlegen. Dann öffnet sich das entsprechende Formular. Sind alle Pflichtfelder richtig gefüllt, kann der neue Eintrag gespeichert werden.

Formular MediendateienMediendateien wie bei Podcasts können zu einem Linkeintrag hinzugefügt werden. Die notwendigen Felder für Länge und Typ stellt LinkSink beim Speichern fest und schreibt die Werte in die Datenbank. Die RSS-Feeds sind so aufgebaut, dass Podcastclients integrierte Audiodateien erkennen können und abspielen.

Calcifer kann auch wiederholende, regelmäßige Termine anlegen. Als Intervalle sind wöchentlich, 2-wöchentlich und monatlich auswählbar. Das Verwaltung wiederkehrender Termine erreicht man durch einen Klick auf den Link in der Navigationsleiste oben.

BookmarkletZur Erleichterung der Aufnahme neuer Links gibt es ein sogenanntes Bookmarklet. Das ist in der Navigationsleiste rechts oben zu finden. Um es zu nutzen, zieht man es in die Bookmarkleiste des eigenen Browsers. Auf Webseiten, die als man als Link speichern möchte, drückt man dann auf dieses Bookmark und wird zu einem vorausgefüllten Formular in LinkSink weitergeleitet. Das Bookmarklet erfordert ein aktiviertes Javascript im Browser, bei Erweiterungen wie Privacy Badger müssen Ausnahmen für rss.freifunk.net erstellt werden, damit Javascript von einer anderen Seite ausgeführt werden kann.

Vereinbarungen

Damit das Chaos überschaubar bleibt sind hier noch ein paar wenige Regeln: 

  • soll ein Link im Medienspiegel auftauchen muss das Tag Medienspiegel gesetzt sein. Wenn es eine Community betrifft ist es schön, wenn ein weiteres Tag mit dem Communitynamen dazukommt
  • Für eine schöne Darstellung im Medienspiegel sollte das Quellmedium auftauchen. Der Titel für einen Medienspiegeleintrag sollte so aussehen: <Quellmedium>: <Titel>
  • Termine in Calcifer, die communityübergreifend stattfinden (z.B. WCW oder der Congress) verseht ihr bitte mit dem Tag freifunk_common. Diese Termine erscheinen dann im gemeinsamen Kalender mit der Markierung, dass es sich um einen übergreifenden Termin handelt. Communityeigene Termine taggt ihr bitte nicht mit freifunk_common, sondern z.B. mit eurem Communitynamen. Den Feed dafür könnt ihr dann per Freifunk API bereitstellen, wodurch sie ebenfalls in den gemeinsamen Kalender kommen. Dann sind sie aber als Termine eurer Community markiert.

Nutzung

Jede Community darf die beiden Werkzeuge gern benutzen. Achtet bitte darauf, die Tags und Orte richtig zu setzen, damit es nicht zu Überschneidungen mit anderen Communities kommt. Versucht auch, doppelte Einträge zu vermeiden, fügt lieber euer Tag zu einem Eintrag hinzu, falls ihr ihn auch in eurem Filterergebnis haben wollt.

Falls euch das alles zu unübersichtlich wird könnt ihr auch eigene Instanzen installieren. Beide Werkzeuge sind quelloffen und werden in Github-Repositories gepflegt (LinkSink, Calcifer) und freuen sich über weitere Installation oder Mithilfe und Anregungen zur Weiterentwicklung.

Die neue Freifunk API. Aufruf zum Mitmachen!

Posted on by Andreas Bräu

Zum Wireless Community Weekend 2013 in Berlin fand ein ersten Treffen zum Relaunch unserer Website freifunk.net statt.  Dabei kam auch die Frage auf, wie man die einzelnen Freifunkcommunities am besten präsentieren kann, ohne alle Daten zentral zu erfassen und zudem den Communities eine einfache Möglichkeit zu bieten, eigene Daten selbst aktuell zu halten.

In Anlehnung an die Hackerspaces API (http://hackerspaces.nl/spaceapi/) wurde die Idee einer Freifunk API geboren: Jede Community stellt ihre Daten in einem definierten Format an einer ihr zugänglichen Stelle (Webspace, Wiki, Webserver) bereit und trägt sich in das Verzeichnis ein. Das Verzeichnis besteht lediglich aus einer Zuordnung von Communitynamen und URL zu den den bereitgestellten Daten. Die erste Anwendung soll eine Karte mit darin angezeigten Freifunkcommunities sein, um Besuchern und Interessierten einen Überblick zu geben und lokale Ansprechpartner zu vermitteln.

Die Freifunk API soll die Metadaten der Communities dezentral sammeln und anderen Nutzern zur Verfügung stellen. Die API ist nicht zu verwechseln mit einer Datenbank für Freifunkknoten oder als Verzeichnis von Firmwareeintellungen einzelner Communities.

Der Relaunch von freifunk.net soll August stattfinden – verbunden mit verschiedenen Aktionen, Pressearbeit und Kooperationen –  und wir möchten euch aufrufen, eure API-Dateien zu erstellen und abrufbar abzulegen. Teilt uns dann bis Ende Juli den Namen eurer Community und die URL zu eurer API-Datei mit, damit wir das Verzeichnis aufbauen können. Das könnt ihr z.B. über den Issue Tracker von Github machen oder schreibt eine Mail an freifunk@ja.ishalt.so oder kontaktiert uns persönlich.

Die Entwicklung der API und ihrer Umgebung findet auf github.com statt, das Repository ist unter https://github.com/freifunk/api.freifunk.net zu finden. Das Datenschema in der ersten Version ist hier definiert: https://github.com/freifunk/api.freifunk.net/blob/master/specs/0.1.json.

Um die Erstellung der Dateien zu vereinfachen, wurde ein API File Generator entwickelt und unter http://freifunk.net/api-generator/ bereitgestellt, der passenden JSON-Code zurückgibt. Aus dem Ergebnisfenster müssen diese Daten dann kopiert und in eine Datei gespeichert werden. Im Moment ist das alles noch ein wenig improvisiert, aber für die Zukunft sind noch einige Verbesserungen zur Komfortsteigerung geplant. 🙂

Zum Schluss noch einmal der Aufruf an euch: Legt so schnell wie möglich, spätestens aber bis Ende Juli eure API-Dateien an und gebt uns wie beschrieben die Verzeichniseinträge bekannt!

Freier Informationsaustausch ist ein Grundrecht – Keine Rechtssicherheit um den Preis der Freiheit

Posted on by cven
Zur Bundesratsinitiative “Änderung der Störerhaftung für WLAN-Betreiber – Freies WLAN in Berlin”[1] der Großen Koalition in Berlin erklärt der Förderverein Freie Netzwerke e.V.:
 
Wir begrüßen sehr, dass sich die rot-schwarze Koalition für Anbieter freier WLAN-Zugänge einsetzt, denn die Anwendung der sog. “Störerhaftung” macht die Betreiber von offenen WLAN-Zugängen für den Datenverkehr ihrer Nutzer juristisch verantwortlich. Die Störerhaftung ist damit Angstmacher und größtes Hemmnis für die Weiterentwicklung Freier Netze. 
 
Gleichzeitig fragen wir uns jedoch, welche “Anforderungen an die jeweils einzusetzenden Schutzmaßnahmen” gesucht werden und warum man zwischen befugter sowie unbefugter Nutzung differenziert. Hierzu möchten wir feststellen, dass solche “erforderlichen Schutzmaßnahmen” technisch wie juristisch äußerst fragwürdig sind und für kommerzielle Anbieter bislang nicht vorgesehen sind. 
 
Diese Forderungen stehen sowohl dem Fernmeldegeheimnis wie den allgemeinen Grundsätzen des Telemediengesetz entgegen, in denen es heißt: “Diensteanbieter (..) sind nicht verpflichtet, die von ihnen übermittelten oder gespeicherten Informationen zu überwachen” (§7 Satz 2)  und “für fremde Informationen (..) nicht verantwortlich” (§8 Satz 1). 
 
“Ob des Grundrechts auf vertrauliche und verschlüsselte Kommunikation lässt sich der Austausch von Daten, praktisch nicht verhindern – hierfür technische Auswege zu suchen ist schlichtweg naiv und gefährdet die Integrität der Informationsnetze” warnt Netzaktivist wetterfrosch. Er erinnert, dass der Gesetzestext vom Anbieter explizit fordert “die Nutzung von Telemedien (..) anonym oder unter Pseudonym zu ermöglichen, soweit dies technisch möglich und zumutbar ist” (§13 Satz 6).
 
“Im Gegensatz zu kommerziellen Providern welche aus guten Gründen nicht in den Datenstrom eingreifen dürfen, wird dies im Moment von privaten WLAN-Betreibern – wie Freifunkern – verlangt” erklärt André Gaul und fordert, dass eine solche Benachteiligung privater Initiativen verhindert wird.
 
Freifunk ist eine seit 2002 existierende nicht-kommerzielle Initiative für freie und selbstverwaltete Funknetzwerke. Freifunker aus ganz Deutschland stellen an über tausend Punkten freie Internetzugänge zur Verfügung. “Wir stehen für diskriminierungsfreie, dezentrale und für jeden nutzbare Möglichkeiten zum offenen Informationsaustausch” stellt Freifunker cven klar.
 
Weitere Informationen
 
[1] Antragstext der SPD/CDU-Fraktionen des Abgeordnetenhaus Berlin “Änderung der Störerhaftung für WLAN-Betreiber – Freies WLAN in Berlin”
 
Kritik des Medienrechtsanwalts Thomas Stadler
 
TMG §7 Allgemeine Grundsätze
 
TMG §8 Durchleitung von Informationen
 
TMG § 13 Pflichten des Diensteanbieters
 
Störerhaftung in der Wikipedia
 
Kontakt
    Website von Freifunk
 
    @c_v_e_n / cven@c-base.org

    Matthias @wetterfrosch Mehldau
    wetter@netzpolitk.org

    André Gaul, wissenschaftlicher Mitarbeiter an der TU Berlin
    @andrenarchy 
    gaul@math.tu-berlin.de

Freifunk Google Summer of Code 2010 applications

Posted on by Mario Behling

Freifunk is again applying as a project for the Google Summer of Code 2010.
For students it is a good way to get deeper involved into Free and Open
Source Software and freifunk specifically. During the summer students have
the chance to code on freifunk and get paid by Google.

Some other projects also offer freifunk related work. Check out the GSoC site after March 18 when the info on participating projects is released.

We are already gathering project ideas, as a way to
start for applicants here.
If you are interested to join freifunk at the summer of code and would like
to discuss project ideas, please join us on IRC at #freenode on irc://irc.freenode.org
and on the mailing list: http://freifunk.net/mailman/listinfo/wlanware

If you have already an idea about a project you would like to do, please also leave your idea here as well: http://wiki.freifunk.net/Ideas

Background info on Google Summer of Code

The most common question we get from students is “How do I prepare for Google Summer of Code?”
The simple answer is not to wait for the program to get involved in
open source. Start checking out projects now: take a look at
documentation, check out their source code and idle in some IRC
channels to see what interests you. The projects who have been past
participants in Google Summer of Code are a great place to start; use the categorized list of mentoring organizations (e.g. projects listed by programming languages) from 2009 to help you get started.

About Google Summer of Code

Google Summer of Code
(GSoC) is a global program that offers student developers stipends to
write code for various open source software projects. We have worked
with several open source, free software, and technology-related groups
to identify and fund several projects over a three month period. Since
its inception in 2005, the program has brought together nearly 3,400
students and more than more than 3,000 mentors & co-mentors from
nearly 100 countries worldwide, all for the love of code. Through Google Summer of Code,
accepted student applicants are paired with a mentor or mentors from
the participating projects, thus gaining exposure to real-world
software development scenarios and the opportunity for employment in
areas related to their academic pursuits. In turn, the participating
projects are able to more easily identify and bring in new developers.
Best of all, more source code is created and released for the use and
benefit of all.

* Frequently asked questions: http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs

* Freifunk Project Ideas: http://wiki.freifunk.net/Ideas

freifunk – Ein interessantes Modell fuer selbstverwaltete Medien – Interview mit Professor Angelo Serpa aus Brasilien

Posted on by Juergen Neumann

Angelo Serpa kommt aus Brasilien und ist Professor an der Bundesuniversität Bahias (Universidade Federal da Bahia). Zur Zeit ist er Gastwissenschaftler (Post-Doktorand) im Geographischen Institut an der Berliner Humboldt-Universität.

J: Herr Serpa, Sie beschäftigen sich bereits seit einigen Jahren wissenschaftlich mit Kommunikationsmedien, die von einer lokalen Community selbst verwaltet und betrieben werden. Was ist das besondere an diesem Prinzip und welche Projekte haben Sie bereits untersucht?

AS: Wir haben im Jahr 2005 in Salvador da Bahia, Brasilien, diese Forschung über lokalbezogene Medieninitiativen angefangen. Salvador ist eine 3 Millionen Einwohner Metropole, wo es grosse soziale Unterschiede gibt, die in der Stadtlandschaft sehr ausgeprägt sind. Einerseits gibt es einige reiche Viertel, die sehr gut mit Infrastruktur versorgt sind, andererseits Viertel, die „arm“ sind, wo keine gute Infrastruktur vorhanden ist. Es herrscht Stadtsegregation und gibt viele Vorurteile gegen die „armen“ Viertel: sie seien gefährlich, dort gäbe es nichts ausser Kriminalität und Drogenhandel. Aber gerade in diesen Vierteln leben viele Künstler, die zum Beispiel den Karneval von Salvador, das grösste Strassenfest Brasiliens, mit ihrer Kunst, mit ihrem Tanz, ihrer Musik sozusagen „ernähren“. Ich spreche hier von Leuten, die die Armut zum künstlerischen Reichtum im Alltag umwandeln. Es sind diese Leute, die in diesen Vierteln „Community Radios“ machen, Radios, die nicht kommerziell sind und keine öffentliche Unterstützung bekommen. Meistens hört man diese Radios einfach direkt per Lautsprecher auf der Strasse, obwohl einige von ihnen auch richtig über eine eigene Frequenz senden.

Andere Initiativen beschäftigen sich mit der Herstellung von Inhalten für Homepages, die die Vorurteile gegen ihre Viertel abbauen wollen. Das besondere an solchen Initiativen ist die Tatsache, dass sie überhaupt existieren, in einem Kontext, wo der Zugang zur Technik, zur Technologie, derart begrenzt ist, dass es im Alltag schon eine Menge Kreativität und Mühe von diesen Leuten abverlangt.

J: Welche Möglichkeiten sehen Sie im Umgang mit diesen Do-It-Yourself betriebenen Medien für die Menschen, die sie betreiben und die jeweilige lokale Community?

AS: Das ist eben die Möglichkeit, Inhalte für Radios und Internet selbst herzustellen. Inhalte und Programme, die mehr mit dem Alltag dieser Viertel, diesen Bezirken zu tun haben. Das kann auch mehr Autonomie für diese Gruppen und Initiativen bedeuten, indem sie sich die Medien auf lokaler Ebene aktiv aneignen und die Inhalte von Radiosendungen und Homepages selbst bestimmen. Natürlich hängt der Erfolg solcher Initiativen sehr stark von den vorhandenen technischen Kentnissen und Möglichkeiten ab. Eigentlich lernen diese Leute den Umgang mit der Technologie in ihrem Alltag, indem sie nämlich selbst die alltäglichen Problemen damit und mit dem generellen Mangel an Infrastruktur in diesen Vierteln und Bezirken zu lösen versuchen. Gleichzeitig wird durch solche Initiativen auch versucht, die Isoliertheit dieser Viertel zu durchbrechen. Diese Do-it-yourself-Medieninitiativen und -gruppen sind in Brasilien für viele Menschen ein Fenster zur Welt.

J: Hier in Deutschland interessieren Sie sich gerade auch für freifunk.net. Was ist aus Ihrer Sicht das besondere an diesem drahtlosen Community-Netzwerk "Made in Germany"?

AS: Ich sehe freifunk.net als eine politische Medieninitiative, obwohl es sehr viel mit Technik zu tun hat. Ein dezentralisiertes Netz, das von den Nutzern selbst betrieben wird, das ist ohne Zweifel sehr geeignet, um die Medienkompetenz der Teilnehmer zu erhöhen. Andererseits verlangt Freifunk von den Teilnehmern in Kontakt mit ihrer Umgebung, mit den Nachbarn zu treten, was heutzutage fast „subversiv“ klingt. Das heisst, in diesem Kontext fördert die Technik, die Technologie, die Begegnung, das Treffen von Menschen, um etwas Kollektives auf die Beine zu stellen. In Berlin, scheint das Freifunk-Netz in einigen Bezirken wie Friedrichshain sehr gut zu funktionieren. Die Herausforderung ist, in anderen Bezirken, wo DSL bereits sehr verbreitet ist, das Freifunk-Netz zu etablieren.

J: Sie möchten gerne auch in Brasilien in den ärmeren Stadtvierteln freifunk-Initiativen starten. Welche Chancen sehen Sie darin? Warum ist gerade freifunk.net aus Ihrer Sicht dafür so geeignet?

AS: Aus meiner Sicht muss man in solchen Vierteln zunächst von den Kenntnissen der Einwohner ausgehen. In diesem Fall müsste man also Partnerschaften in den Vierteln suchen und versuchen mit den Leuten vor Ort zusammen zu arbeiten, die irgendwie fähig dazu sind, andere Einwohner zu mobilisieren und sich an dem Projekt zu beteiligen. Gleichzeitig  muss man sich auch Gedanken machen, wie mehr Zugang zum Netz geschaffen werden kann, vor allem dort, wo es sehr wenige Computer gibt. Vielleicht sollte man zusammen mit den Internet Cafes, die in diesen Vierteln schon vorhanden sind, arbeiten, aber gleichzeitig auch neue Computer kaufen und in bestimmten Teilen des Viertels verteilen. Oder, nach einer Idee von Frieder Bronner, von Openmedia hier aus Berlin, eine eigene Computerfabrik aufbauen, damit die Einwohner des Viertels selbst die Computer zussamensetzen. Das wäre vielleicht sinnvoller als alte Computer wieder aufzubereiten – vielleicht auch billiger. In jedem Fall könnte sich dadurch die Situation für die Menschen im Viertel in einigen Bereichen sehr verbessern.

J: Sie kommen aus Brasilien und leben aber gerade für einige Zeit in Berlin. Was denken Sie darüber, dass die Stadt Berlin schon seit einiger Zeit versucht, das Thema "Offenes WLAN für Berlin" an einen kommerziellen Provider abzugeben und dabei die Idee von freifunk.net als lokale Initiative und vor allem als "Kooperatives Modell" bisher völlig ingnoriert wurde?

AS: Ich finde das schade. Es ist schade, dass all die Erfahrungen, die die Leute hier mit Freifunk in den letzten Jahren gemacht haben, nicht von der Stadt Berlin berücksichtigt werden. Aber es ist auch verständlich, dass so etwas wie ein dezentralisiertes Netz, ein nichtkommerzielles Netz, ohne Hierarchie, mit einiger Skepsis von Seiten der Stadtregierung angesehen wird. Das ist überall so, auch in Salvador und anderen Städten Brasiliens. Solche Sachen machen den Stadtregierungen Angst, vielleicht weil solche Initiativen nur schwer unter „soziale Kontrolle“ zu bringen sind. Es ist schade, weil gerade eine Initiative wie Freifunk die Medienkompetenz der Teilnehmer erhöhen könnte und mehr Autonomie in der Stadt schaffen würde.

J: Halten Sie freifunk.net für einen geeigneten Weg, um in einer Art Public-Private-Partnership das Netzwerk auch in die strukturschwacheren Gegenden der Stadt zu bringen, wo es eigentlich am dringensten gebraucht würde?

AS: Sicher, aber hier müsste man die Stadtregierung davon überzeugen, dass ein nicht hierarchisches Netz, in dem die Leute selbst die Funktionsweise des Netzes bestimmen und auch selbst dafür verantwortlich sind, welche Inhalte und Erfahrungen sie darüber austauschen wollen, ein geeigneter Weg zur Erhohung der Medienkompetenz ist. Andererseits ist es meiner Meinung nach sehr schwierig, dass eine solche Idee ein positives Echo unter den Politikern findet.  Ich frage mich auch, ob es wirklich der beste Weg wäre, mit Stadtregierungen zusammen zu  arbeiten. Vielleicht gibt es auch andere Wege, ein solches Netz aufzubauen, zum Beispiel NGOs als Partner zu haben.

J: Herr Serpa, Ich danke Ihnen für dieses sehr interessante Gespräch.

NinuxDay in Rome from November 27-29, 2009

Posted on by Mario Behling

The Ninux.org team announced the first “Ninux Day”, a weekend with about and for wireless communities. You will meet software and hardware hackers, geeks, nerds, engineers, artists, the curious and
academics. Experts from all over Europe offer technical and social presentations in the area of wireless community networks.

Join the Ninux Days in Rome, Italy, from November 27-29, 2009.

More Info here:

* http://wiki.ninux.org/NinuxDay2009
* http://wiki.ninux.org/NinuxDay2009en (English)
* http://wiki.ninux.org/NinuxDay2009it (Italian)
* Announcement: http://blog.ninux.org/2009/09/03/ninux-day-2009
* Ninux Blog http://blog.ninux.org

[via ZioPRoTo]

Multicast for OLSR mesh networks: Obamp release by Saverio Proto

Posted on by Mario Behling

Saverio Proto (ZioPRoTo) has the released the olsr OBAMP plugin, that was a freifunk project for the Google Summer Of Code. The OBAMP plugin allows multicast traffic to be forwarded in a OLSR mesh network. OBAMP is an overlay protocol. It first makes a mesh network with overlay links (udp tunnels) between the OBAMP nodes, and then it creates a distribution spanning tree over these mesh links.

This version of the OBAMP protocol, implemented as an OLSR plugin, is a simplified one for Wireless Community Networks, where we assume the nodes to be in fixed positions on the roof of the houses. Protocol features regarding mobility have not been implemented (yet).

To explain how the plugin works consider the scenario in the following figure:

There are 7 routers, where only 5 have the OBAMP plugin working. Router 1 2 and 6 also have an attached HNA network with some hosts.

OBAMP nodes generate OLSR OBAMP_ALIVE messages, these OLSR messages are forwarded in the whole network (also by the nodes that do not understand OBAMP thanks to the OLSR design). Because of the flooding mechanism every OBAMP node has a complete list of all the other OBAMP nodes in the mesh network. Every OBAMP node listens on the UDP port 6226 for OBAMP signalling.

When a OBAMP nodes starts it has 5 timers to periodically start operations:

OBAMP_alive_timer: every obamp node sends alive messages to advertise its presence to the other obamp nodes in the network. In the alive message every nodes states its IP address, and if it has already a tree link or not (we will see later this information is important for the outer tree create procedure).
The OBAMP network must have a member called “Core”, that starts the TREE_CREATE procedure. The core is the node with the smallest IP address. When the list of known OBAMP nodes changes, the Core Election procedure is eventually called.

mesh_create_timer: every obamp node every OBAMP_MESH_CREATE_IVAL evaluates how far the other obamp nodes are and selects a subset of nodes to keep mesh links with. Note that to reduce signalling and to increase scalability, the overylay mesh links are setup only with a subset of the nearest OBAMP nodes. To select the overlay neighbor the OBAMP nodes first calculates the ETX distance of the nearest OBAMP nodes, and the creates overlay mesh links to every node that are far in the range (minETX,minETX+1)

tree_create_timer: the core of the network every OBAMP_TREE_CREATE_IVAL sends a message called TREE_CREATE on its mesh links. The creation of the spanning tree is very similar to the spanning tree protocol. When a TREE_CREATE message is received a OBAMP node enables a tree link with its parent and forwards the TREE_CREATE on the other mesh links. TREE_CREATE messages are generated only by the core and are numbered, so TREE_CREATE received over loops can be discarded.

outer_tree_create_timer: The mesh_create algorithm may create cluster of OBAMP nodes within the network that are disconnected between each other. This happens if there are groups OBAMP nodes that are far from each other. If this happens only the cluster where the Core is present will receive the TREE_CREATE and will receive traffic from the distribution tree. To overcome this problem if in a cluster there are not TREE_CREATE every OBAMP_TREE_CREATE_IVAL the node with the smallest IP in the cluster will make a long mesh link with the nearest node that has at least a tree link. All the necessary information to perform this procedure is diffused in the OBAMP_ALIVE messages.

purge_nodes_timer: checks expire time of various variables, and deletes nodes or tree links in a soft state fashion

The OBAMP nodes will capture the multicast udp traffic from the non-OLSR interfaces, and will forward this traffic encapsulated in the UDP tunnels of the distribution tree. The other OBAMP nodes will forward the traffic in the tree and will decapsulate it on their non-OLSR interfaces. To avoid duplicated packets the data is carried into OBAMP_DATA messages, that are identified by a sequence number, and the OBAMP source node where the traffic has been encapsulated.

In the figure black links represent real radio links, and red links represent overlay mesh links (udp tunnels). Router 1 2 3 and will create a OBAMP cluster, with two mesh links. Router 6 and 7 will create a mesh link between them. Because the mesh_create algorithm does not create a mesh link between the two clusters, the router 6 (supposing it has the smallest IP address in the mesh) will create an outer tree link with Router 3.

So please download the code and use it . If you find bugs please report them to Saverio and in the Sourceforge tracker here: 

http://sourceforge.net/tracker/?atid=681702&group_id=117612&func=browse

Thanks for this great result of the summer. Special thanks also to Nino from ninux.org who was the mentor for this projet.

Links

* http://zioproto.ninux.org/wordpress/2009/08/31/olsrd-obamp-plugin/
* http://gredler.at/hg/olsrd/rev/8e7887c1247f
* http://olsr.org
* http://blog.freifunk.net
* http://ninux.org