Willkommen im Freifunknetz

Dies ist das Internetportal des Freifunks in Halle und dem Umland, sowie ein Ausgangspunkt für soziale, technische und allgemeine Informationen rund um das Thema Freifunk und die Freifunk-Community in Halle.

Termine 2016

28.05.2016 Jahreshauptversammlung Förderverein Freifunk Halle e.V.

21.06.2016 Netzpolitischer Freifunk Abend im Eigenbaukombinat ab 19 Uhr

30.07.2016 Freifunksommerfest

Nächste Treffen Kommt einfach vorbei. Jeder ist willkommen.

Neue Foreneinträge

Amtsblatt vom 25.05.2016 Seite 2

von kwm (Verfasst 25.05.2016 18:28:29)

"Kabellos und kostenfrei ins Internet" Amtsblatt vom 25.05.2016 der Stadt Halle auf Seite 2 gibt es eine Artikel über WLAN und Freifunk. >> weiterlesen

Keine Route ins Internet

von 3dfxatwork (Verfasst 23.05.2016 07:44:08)

Freizeit hatte ja Vorrang, deshalb ging es ja auchden halben Tag nicht. >> weiterlesen

Ausfall Hauptserver

von 3dfxatwork (Verfasst 21.05.2016 20:28:42)

Hi ihr,

wie vielleicht einige von euch heute mitbekommen haben, war unser Hauptserver heute ausgefallen, er wurde ohne Mitteilung vom Hoster gesperrt. Ich habe versucht anzurufen, jedoch ohne Erfolg. Auf ein Support ticket wurde bis jetzt nicht reagiert, allerdings ist der Server erst mal wieder da, auch ohne Mitteilung.
Da wir schon des öfteren mit Ausfällen bei diesem Hoster zu kämpfen hatten, werden wir mittelfristig hier nun doch mal einen anderen Hoster suchen müssen. >> weiterlesen

Suche Empfehlung für miniPCIe halfsize WLAN Modul

von thekillah (Verfasst 20.05.2016 23:26:56)

Einsatzziel ist Archlinux auf einen Intel Nuc dc3217by. >> weiterlesen

Letzte Blogeinträge

Overview: GSoC projects at freifunk.net

In 2016 we found 9 students doing Google Summer of Code projects for freifunk. This is an overview on all our projects including links to repositories and further information:

TitleStudentRepositoryProject information
A schema-based configuration system for OpenWrtNeoraider https://gitlab.com/neoraider/ece 
DynaPoint - A dynamic access point validator and creator for OpenWrtAsco https://github.com/thuehn/dynapoint 
Implementing Pop-RoutingGabrielhttps://github.com/gabri94/poproutinghttp://firenze.ninux.org/
Monitoring and quality assurance of open wifi networks: the client viewTarekhttps://git.nordwest.freifunk.net/ffnw-firmware/monitoring-drone  
netifd extension: external device handlersarkap  
OpenWrt - poWquty (poWer quality)Neez  https://github.com/neez34/
Provide a cryptographic implementation for Qaul.netspacecookie https://github.com/spacekookie/qaul.net https://spacekookie.de/gsoc2016/
Sharable Plugin System for qaul.net – Mesh Network Communication AppAnu https://github.com/anuvazhayil/qaul.nethttps://github.com/anuvazhayil 
SWOON: Simultaneous Wireless Organic Optimization within Nodewatchermarn 




Blog posts on these projects you can find with the tag GSocC 2016. Use the RSS feed to receive all updates. You can also see our projects from previous summers.

>> weiterlesen

GSoC 2016 Introduction: external device handlers for netifd


It's time I started blogging about my Google Summer of Code project with Freifunk.

To begin, let me introduce myself. I am Arne, computer science student at TU Berlin and pursuing my Bachelor's degree. This is my first GSoC -- and the first time I contribute to an Open Source software project, so, naturally, I'm pretty excited to get to know the process.

My project aims at extending OpenWRT/LEDE's network interface daemon (netifd).

I've familiarize myself with the inner workings of netifd while I was working on a student project last semester. The result of that student project will assist me in realizing the GSoC project. Moreover, the existing source code will partially build the foundation of the new device handler which will be realized in this project.



Here's the general idea: Netifd allows the user -- as the name suggests -- to create and configure network devices and interfaces. Per device class, there is a hard-coded structure called a 'device handler'. Each device handler exposes an interface for operations such as creation or re-configuration of device instances of its class.

The point I'm tackling is the structures hard-codedness. Today, whenever someone wants to introduce a new device class, is necessary to alter the netifd code base and maintain these changes. The proposed mechanism allows to realize external device handlers as separate programs communicating via the bus system ubus. Accordingly, to introduce a new device class into netifd, one just needs to implement device handling logic and link it to netifd. Thus, no maintenance -- or knowledge of the innermost workings of netifd -- is necessary.

Building on my work from the aforementioned class I'll write a device handler to integrate Open vSwitch support into OpenWRT/LEDE using netifd. The 'ovsd' as it is called will relay calls to the device handler interface via the 'ovs-vsctl' command line utility to set up Open vSwitch bridges and ports.



I am hosting my code in a git repository that's included in the GitLab of the INET department which is employing me at TU Berlin. Once the code becomes usable, it will appear on GitHub here.

We also have a repository providing an OpenWRT/LEDE feed that bundles the Open vSwitch software with ovsd: (link will follow)


Testing is done on a PC Engines Alix 2 board which is part of our testbed:



As of today I have realized a mechanism to generate device handler stubs within netifd when the daemon is first started and before it parses /etc/config/network. The device class' parameters, such as its name in the ubus system and most importantly the format of its configuration, are stored in JSON files in /lib/netifd/ubusdev-config/. The logic to parse a configuration format from JSON files existed already within netifd but was only used for protocol handlers before. I adapted it to generate device handlers dynamically.

When such a device handler is generated, it subscribes to its corresponding external device handler using ubus. This way, the latter can generate events asynchronously for the former to react to.

In order for this to work, the external device handler must be up and running before netifd attempts the subscription.

I also realized a simple proof-of-concept implementation that works in one simple case: create an ovs-bridge with one or more interfaces like this example /etc/config/network file demonstrates:


config interface 'lan'

    option ifname 'eth0'

    option type 'ovs'

    option proto 'static'

    option ipaddr ''

    option gateway ''

    option netmask ''

This will create an Open vSwitch bridge called 'ovs-lan' with the port 'eth0' -- and that's about all it does right now. Error handling is missing and more complex options like setting OpenFlow controllers or adding wireless interfaces don't work yet.



Among the first things I'll tackle when GSoC's coding phase begins are adding the possibilities to incorporate WiFi-interfaces to the bridges created with external device handlers and introducing the missing parts of the device handler interface. Since I'm dealing with netifd and the external device handler which is an independent process running asynchronously, getting their state to stay in sync will take some work. I need to think about the way the callback system that comes with ubus' pubsub-mechanism will function. In the end, it is supposed to be abstract enough to work not only for my Open vSwitch use case but for any external device handler.

Then, further into the coding phase, I want to increase feature coverage of the Open vSwitch options, so that users can assign OpenFlow controllers for their bridges like so:


config interface 'lan'

    option ifname 'eth0'

    option type 'ovs'

    option proto 'static'

    option ipaddr ''

    option gateway ''

    option netmask ''

    option of-controller ''

In the end I would like to have the mechanism implemented and documented so that others can build on it. Documenting my work is especially important to me, because I found myself frustrated with the scarcity of the netifd documentation more than once before. I wish for my code to become a part of OpenWRT/LEDE and be extended and improved in the future and I would like to make it easy for anyone insterested to doing that with a helpful manual and commented code.

I'm excited to get started and hope to find the time to blog about my progress here, regularly.

>> weiterlesen

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

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.
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
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

Jan-Tarek Butt
>> weiterlesen