web backend

Das Community Blog
I am Arunkumar Ravichandran, about to pursue my MS in Electrical and Computer Engineering at University of California, San Diego. I have almost 2 years of Software Engineering experience at EmbedUR Systems in the Wireless networks domain. I was working on wireless device drivers implementing Network assisted roaming and SDN support for the Linux based Enterprise Access Points and Wireless LAN Controllers.
The main aim of the project is to bring in support for NETJSON object in the LEDE/OpenWRT Linux distributions. The support for NETJSON is brought in at the interconnect system – ubus. In this project, we need to add support for a new ubus API which allows retrieving these two NetJSON object types: DeviceConfiguration and DeviceMonitoring.
NetJSON is a data interchange format based on JSON designed to ease the development of software tools for computer networks. This specification defines several types of JSON objects and the manner in which they are combined to represent a network: configuration of devices, monitoring data, network topology and routing information.
Network infrastructure is deeply closed source. Open source won the battle in web development and system administration, but not in network management. The status-quo in networking is closed source software, poor interoperability and poor documentation.
NetJSON aim to challenge the status-quo and improve the openness of internet infrastructure by offering a set of tools (like a framework) which communities and companies can use to build network infrastructure using mainly open source software products.– Federico Capoano, OpenWisp
Hi, my name is Johannes Wegener and I’ll be working on OpenWifi this Google Summer of Code. I’m 27 years old and study computer engineering at TU Berlin. In this blog post I’m going to explain to you what OpenWifi is and what should be done during this summer of code.
OpenWifi is a OpenWRT/LEDE configuration management system. It is intended to manage a bigger or smaller amount of OpenWRT/LEDE devices.
If a new access point joins a network it is be able to auto detect the management Server and register to it. After the node has been registered its configuration (static configuration like what you’ll typically find in /etc/config/ on OpenWRT/LEDE devices) will be downloaded by the server and stored in a database.
It is now possible to query and modify aspects of the configuration. It also possible to change values depending on other values. This means configuration changes can be applied to a lot of different routers. There is an older templating system which shall be replaced by a new graph-oriented one. It also manages SSH-Keys, has a rudimentary file upload functionality (for uploading new images for example) and extensible API. It is possible for example for a node to ask for an image it should install. (Currently this is not very dynamic – but it is intended that an image could be selected on various parameters)
The Server also regularly pulls the health-state of the node and displays it in an overview. Furthermore the server acts as a luci2 proxy.
It is also extensible via PlugIns and is able to serve as an entry point to other services like icinga or location services. (Both already have a proof of concept PlugIn available)
The main software is written in python and uses the pyramid framework and sqlalchemy as ORM. It uses pyramid-rpc for json-rpc requests (which is used for nodes to register for example) and cornice for a REST-style API (which is intended for the user of the system). The Core-System can be found in this repository.
Most of the tasks operating on nodes are done by a jobserver that uses celery – so that they don’t block the main thread.
All Webviews have been moved to a different repository and are realised in fact as a PlugIn. (If you just want to manage your nodes on CLI/with scripts this will be possible in the near future!)
The nodes use a notification script written as a shell script. It uses a fixed DNS entry (openwifi), a configuration file (/etc/config/openwifi) or mdns (using umdns or avahi) to detect a server and register to it. The packages can be found in the openwifi-feed repository. There is also a boot-flasher which is intended for flashing an alix2-style board from ramfs – since it is also possible to execute commands on the node I’ll integrate an update solution that uses sysupgrade.
The communication between the server and the node is realized currently via rpcd. But one goal during this Google Summer of Code is to abstract that and realize it via a rpcd-communication-PlugIn – this would make it possible to also a NetJSON-communication-PlugIn for example.
The PlugIns are realized with python entry points. There are some special named entry points which will extend the main application. You could have a look at the example plugin to get an idea how it works.
You can easily try the software with docker. Navigate to the Docker directory – there three files that will assist you with the setup. In conf.sh you setup if you want to use LDAP for authentication, avahi for mdns announcement and dnsmasq as dhcp server in the docker container.
With build_image.sh you build the docker image. It tries to detect if you need to use sudo for docker or not. Last but not least you need run_image.sh to start the image.
You can easily add PlugIns to the docker image if you just check them out or copy them inside the Plugins directory. To start off I would recommend to add the Web-Views Plugin and use avahi. Now you can navigate your browser to http://localhost:6543 to see the webviews (you need to restart the container after Plugin install – use docker stop OpenWifi and docker start OpenWifi).
In the next section I’ll explain what should be done during Google Summer of Code. I need to prioritize these things because I’m not sure if it is possible to do everything. I think most important things are Testing, Authentication and the new graph-based database model.
Currently just very few things have tests. But because it is possible to start a LEDE container in docker (there are some scripts helping to create a LEDE container in the Docker/LEDEImage directory) a lot of things are possible to test with docker orchestration. I want to provide a small LEDE image with the code to test it.
Before adding big new things I like to transfer the development to true test-driven development and having test for at least 90% of the core component code. And after that continuing development by writing tests first.
For that I would also have a look at coverage.py.
There is a simplistic authorization for OpenWifi with a LDAP backend. I would like to add authorization based on user/password (without LDAP), API-Key and client side certificate (for the nodes to authenticate theirself against the API).
I would like to have the authorization as granular as possible. Authorization should check whether the authorized identity is able to operate on this node and what kind of action is allowed.
Security is provided by TLS. Last week I added the last bits to also use https for client communication – but right now it needs to be setup up by the user. I would like to add the appropriate hooks to the notification shell script.
The new DB-Configuration model is based on a graph – where configurations can be connected by links (the link can contain addition information – like what kind of link it is – currently the addition data is the option name (for example if you have a wifi-iface configuration the “device” links it to a wifi-device)).
The model is implemented and there is a query API to get and set options. But for communication purposes the configuration is stored as uci-json-config. There is code to convert between these two (but the one from uci to graph-model needs quite some more intelligence to detect everything right). There are also some hooks that update each part. But the update process is not consistent – the graph-based config gets a new ID for example. It would be nice to have a consistent conversion.
Furthermore I like nodes to share parts of a configuration. This should be easy to implement with some small DB changes. For this consistency is also very important. By default UCI generates unique strings for every configuration – this could be used for consistency.
The DB-Model also currently lacks creating new configurations and reordering configurations.
The API to modify nodes should get expanded and everything should get documented. (see above) This should be done in code and a document generated by sphinx.
I also like to implement a CLI program to use the API.
The uci-json parser supports diffs between configurations. I would like to save a diff for each change which is applied – to have roll back configurations or delete a specific change.
There is a simplistic revisioning implemented. But the diff should be updated to a class of its own with json import and export and operations to apply a diff to a UCI configuration. (upgrade and downgrade)
OpenWifi is right now is already quite modular – but I also want to modularize configuration parsing and communication. It would also be nice to have some interoperability with OpenWISP.
I use alembic for tracking database changes it would be nice to find a good way to use alembic for database changes needed by PlugIns as well.
I want to schedule config updates – for example if you have a mesh you probably want to update the deepest nested nodes first and than the ones above etc. – this should be easy with celery (as long as the mesh is known and somehow represented in the database).
Hi everyone,
I’m Stefan and happy to present my GSoC 2017 project to you.
That is extending the PowQuty daemon and luci web-app with an event log and notification system for events violating the EN-50160 norm.
Probably most of you don’t know powquty. Therefore i will give a short introduction to it, before I present my actual project.
PowQuty[1] is an application for measuring power quality parameters of the power grid like voltage and frequency. It receives samples by a USB connected oscilloscope and writes the calculated values to a log file. This log can be read by the powquty luci web-app. The web interface will plot the measurements directly into several graphs. These are power over time, frequency over time and metrics over time.
It was implemented during the last GSoC by Neez El Sayed [2] and its intention is “to strengthen the role of open software in the uprising smart grids by providing some essential functionalities”.
The goal of this project is to provide an event log of measurements that are outside defined parameters.
Public power distribution networks have to meet certain criteria. These are formulated in the EN50160 norm.
If there is a power drop, or a frequency spike PowQuty will write this to its log like every other value. The user can examine the log file or its graphical representation for critical values, but essential equipment could already be damaged.
If such an event occurred, a user or power network administrator should be notified. This event log will get a graphical interpretation in the luci powquty app as well to enable a better tracking of events.
This will allow users of PowQuty to react quickly to changing conditions in power supply networks.
Therefore we will add a notification system to PowQuty as well as additional logging options.
To collect events at a central server we will extend the mqtt usage to send an mqtt notification on a violating event.
In addition we will add an email and slack notification option to allow quick responses.
[1]: https://github.com/thuehn/PowQuty
[2]: https://blog.freifunk.net/author/Neez-El-Sayed/
In 2017 we got 15 slots for our projects. That’s great, we’ve never got so many slots for GSoC before. Our students are from 8 countries. They do their work for 6 sub organizations.
Until the end of May the Community Bonding Period takes place, so students can introduce their projects to the community. They also prepare together with their mentors the folling coding period.
This post will give a short overview on the selected projects. In the next weeks some detailed blog posts will follow describing all the projects.
Title | Org | Student | Abstract |
---|---|---|---|
RetroShare Improvements | retroshare | ange | The aim of this proposal is to improve RetroShare incrementally during the summer in the following work lines: – Semi-automatic RetroShare friendship suggestion based on phone contacts – Semi-automatize JSON API code and documentation generation – Multiple simultaneous heterogeneous network connection for each peer – Improve RetroShare Android usability and performances – Seamless key exchange via Quiet Modem – Chat and messages multiple device synchronization – Directories multiple device synchronization |
Implementing Pop-Routing in OSPF | ninux | Gabriele Gemmi | Prince is a network daemon that continuosly monitors the network topology and sets the timers for OLSRv2, it is developed in C and we are currently deploying it in the Ninux community network in Florence. This year we want to implement Pop-Routing for another link-state routing protocol: OSPF. OSPF is the state-of-the-art interior routing protocol for wired networks and it is used also in some wireless community networks. This project consists in realizing a plug-in of the OSPF open source routing daemon (Quagga or Bird) that will: – Expose the network topology to Prince using NetJson – Receive and re-set the network parameters from Prince |
Improving nodewatcher data representation capability | wlan slovenija | rasovica | Currently nodewatcher has very limited overview of used IP space without more precise division of existing and used subnets. This could be improved using compact and colorful matrix with IP ranges and links to nodes. I would display data about used ips similar to the [IP Census 2014](http://census2012.sourceforge.net/images/hilbert_icmp_map_lowquality.jpg), better tables and other data representation that would help explain the network structure, it would help in explaining the network and its statistics even to an uninformed observer. I would also update the look and functionality of other graphs and tables representing statistical data from nodewatcher |
Extending LoxiGen and ONOS to enable SDN control of wireless switches via OpenFlow | lede | Arne Kappen | LoxiGen is a tool by the Floodlight project to generate OpenFlow libraries for several programming languages including Java and C. The goal of this project is to extend LoxiGen to include messages for controlling wireless switches using OpenFlow. It will include the necessary extensions to LoxiGen as well as a proof-of-concept implementation of the control channel. This encompasses an application for the ONOS SDN controller and an agent for the LEDE router operating system.SDN-enabled wireless switches offer comfortable centralized management of larger deployments and may provide the basis for more complex use-cases in the future such as network slicing and seamless mobility. |
OpenWRT/LEDE Configuration Management | lede | Johannes Wegener | Improve the proof-of-conecpt version of a OpenWRT/LEDE configuration software. |
Web interface for Retroshare, a secure communication software | retroshare | Stefan Cokovski | I am applying to work on the web interface for RetroShare, secure communication software. RetroShare already has a web interface with limited functionality and questionable look, compared to the main Qt GUI which RetroShare uses. My goal will be to improve the already present functionalities, introduce new functionalities to the web interface and design a new look for the web interface. |
Implement NetJSON output in ubus (OpenWRT/LEDE) | lede | Arunkumar Ravichandran | To bring in support for NETJSON object in the LEDE/OpenWRT Linux distributions. The support for NETJSON is brought in at the interconnect system- ubus. To add support for a new ubus API which allows retrieving these two NetJSON object types: DeviceConfiguration and DeviceMonitoring. DeviceConfiguration NetJSON object is filled in using the plugins available in System Configuration Abstraction Layer(SCAL). DeviceMonitoring NetJSON is retrieved by reusing the code parts and adding hooks in the nodewatcher-agent. |
LibreMesh Attended Sysupgrade | libremesh | paul0 | Performing updates on routers is quite different from full Linux distribution. It’s not sustainable to do release upgrade via a packet manager. Instead it’s usually required to re-flash the system image. Depending on the installed packages an image rebuild may be to complex for regular users. A more convenient way is needed.
This project will implement an “image as a service” server side which provides custom build images depending on installed packages. A notification in the web interface will notify about the new release. After image creation a one-click installation is offered within the web interface. The server side implementation will use established tools like LEDE’s ImageBuilder to provide an generic approach for image creating. In this way the entire OpenWrt/LEDE community including several community-mesh firmware projects will benefit from that new update routine. |
Spectrum Analyzer | libremesh | Nicolas Andres Pace | I believe that Community Networks’ Operating Systems could use the Spectrum Analysis a lot to make better decisions on how they use the electromagnetic field wisely and efficiently.
As of now, no Free OS has been using Spectrum Analysis, so they can’t know whether the radios are being used efficiently or not. This module would allow all routers that use Atheros radios (the main radio manufaturer around) to see how is the spectrum and take better decisions on which channels they use. Deliverables |
HMAC signing of Nodewatcher data & IPv6 support for Tunneldigger | wlan slovenija | red_moo | Currently all monitoring reports by WLAN nodes are unsigned and can be spoofed by anyone. This represents a security problem and a possible solution is to add HMAC-based signing to encrypt node monitoring reports to prevent spoofing. Nodewatcher’s monitoring system will also be improved so it will generate an event and a warning in case of a signature verification failure.The aim of the second part of this GSoC project is to design and implement IPv6 support for Tunneldigger so that it works in IPv6-only and IPv4/IPV6 mixed environment where both server and client have IPv6 connectivity in some form. |
Add MPTCP support in LEDE/OpenWRT trunk | lede | SPYFF | Create an MPTCP supported OpenWRT/LEDE trunk and ensure its operation in a multipath Wi-Fi aggregation environment. The trunk should contain the tooling for establish a SOCKS proxy for operating systems without MPTCP support. |
geolocator (Software defined GPS) | FF Nordwest | Jan-Tarek Butt | A dynamical and flexible geolocator which should provide a software defined GPS device and receives its position over WIFI hardware with various services like openwifi.su, MLS and etc. |
netjsongraph.js: visualization of netjson data | ninux | GeekPlux | NetJSON is a great work attracted some interest from around the world, but there are a lot of defects. And I’m a front-end developer and now focus on Data Visualization, so I want to contribute to NetJSON. In my proposal, I come up with my idea and list some tasks and schedules. |
lime-webui: port to LuCI2 | libremesh | Marcos Gutierrez | Make an inventory of all LuCI components that LibreMesh uses and that will not be compatible with LuCI2. Analyze which dependencies must be replaced or rewritten and generate the views according to the new framework selected. |
Powquty Live-Log | lede | Stefan Venz | PowQuty provides statistics from measurements taken by a USB oscilloscope. The statistics provide information about the power distribution network, but don’t highlight the most important information. Power networks need to comply with EN50160, if this norm is violated, damage to connected devices is possible. To avoid damage, powqutyd will log violations and notify users on occurrence. |
Good news: Freifunk has been accepted again as mentoring organization for GSoC. If you’re a student, please bookmark March 20th in your calendar. That is the date when student application period opens and proposals can be submitted. In the meantime you should visit our ideas page and get in touch with the mentors and our community.
This year we offer much more ideas than in the past but as always we don’t know how many slots (aka projects) we will get from google at the end. So we can’t give you any guarantee for proposals to be chosen. We will select the students and assign them to projects, but the final announcement will be made by the GSoC Program Office.
You aren’t limited to the ideas listed on our ideas page. It is possible to propose your own idea. But keep in mind that you need a mentor from one of our communities, too.
If want to apply please visit our students checklist page before. You can find a lot of information there on how to get in touch with our community. You’ll also find our application template there. It’s necessary to follow that template for a successful application.
There are some things we expect from you:
To give you a short prospect of what is planned to get you into the project after successful application:
Use this period to refine your proposal. Add more specific milestones. Try to get into software development, e.g. by fixing small bugs. Talk to your mentor and the developers of your project to introduce yourself and your proposal.
From 26th to the 28th of May (the last weekend before Coding Phase 1 starts) there’s the Wireless Community Weekend (WCW) in Berlin. Here the Freifunk community will meet with their guests to create an unconference and hackathon. You have the chance to learn a lot about free wireless networks. It’s your chance to show your project/idea to a lot of community members. So you can get your first feedback before coding starts.
If you need help with accomodation or travel costs, please don’t hesitate to ask your mentors or organization admins.
There’s something new this year: We have 3 coding phases with 3 evaluations. Both, students and mentors have to complete evaluations to proceed. Maybe you can use these evaluations as milestones of if you want to work agile as sprint dates.
If you can’t make it to the WCW in May there’s another great chance in the first coding period to meet a lot of developers and community members during Battlemesh V10 in Vienna from June 05 to June 10. Focus of this event are routing protocols. You can use that event to get a lot of detailed technical knowledge, e.g. by doing pair programming.
If you have any questions please contact the organization admins.
So let’s have a great summer! 🙂
(Thanks to Clemens who wrote some parts if this text before)
Unser Freifunkblog ist auf eine neue Plattform umgezogen. Das alte Drupal 6, das sein Lebensende längst erreicht hat und keine Updates mehr bekam, haben wir abgelöst und die Inhalte nach WordPress migriert. Nun ist das Blog mit neuer Technik unter der Haube und neuem Design für die nächste Zeit gerüstet. Der älteste Artikel im Blog ist im Übrigen über 11 Jahre alt und stammt aus dem Jahr 2005.
Alle Artikel, Schlagwörter und Autoren sind erhalten geblieben. Frühere Benutzer wurden wieder angelegt, nur die Passwörter haben wir nicht übernommen. Die Anmeldung kann mit der beim alten Blog verwendeten Emailadresse erfolgen. Mit der “Passwort vergessen”-Funktion kann man ein gültiges Passwort erhalten. Bei Problemen mit der Anmeldung schreibt bitte eine Email an das Webteam (web(at)freifunk.net).
Wer noch keinen Account auf diesem Blog hat und einen hier Freifunkartikel veröffentlichen möchte wendet sich bitte auch an das Webteam. Gerade für communityübergreifende Themen eignet sich diese Plattform.
Einige Bilder lassen sich leider nicht mehr auffinden, da sie extern eingebunden waren und nicht mehr online sind. Auch der in Drupal integrierte Editor hat manchmal ganz schön viel unsinnigen HTML-Overhead erzeugt und führt auch unter WordPress zu komischen Formatierungen. Diese ließen sich nicht automatisiert aufräumen, das ist wohl mal ein Thema für einen Editathon :).
Hello again, for two months I have been working on my project and I have achieved all the goals.
An alpha version of my program was released for the mid-term evaluation.Since then I have fixed all the bugs, packaged the program for OpenWRT, tested the code and written the documentation.
Everything is available on the GitHub repository [0]
I structured my work opening by issues for all the bugs I had to fix and for everything I wanted to improve. Then, I organized the issues in milestones. Milestone 0.1 [1] is the one that I had to complete to finish the project. When that milestone was closed I made the branch “v0.1” [2].
In order to be sure that my program worked correctly. I wrote a simulator in python. It’s made by a small server, with the same interface as OONF’s telnet plugin, and two python libraries written by my mentor: cn_generator [3] and pop-routing[4]. The first one generates synthetic graphs using the Cerda-Alabern[5] algorithm, the second one is a pop-routing implementation in python. In the server I implemented the commands to push the NetJson[6] topology and the ones to receive the timers values.
When prince requests a topology from my test program, cn_generator generates a random graph and pushes it back; meanwhile using the python implementation of pop-routing, the references values are computed. The values received from prince are then compared to ones calculated using python.
The goal of tests is to verify that the difference between the reference and the measured values is always less than 1%.
I’m going to use my work to write my Bachelor Thesis, so I wanted to perform some measurements to check how well it worked.
My goal was to implement the algorithm on an embedded device, so I chose to measure the execution time on a “Ubiquiti Picostation M2HP” to see how well it was performing.
I branched Prince [7], modifying the code to measure the time needed to calculate the betweenness centrality and push it back along with the timers.
I used the graph generator to create graphs from 5 to 500 nodes, and I measured the time needed to compute with a sample every 10 nodes. For each sample I ran 5 tests, then calculating the mean and the standard deviation. The results are shown here:
As you can see from the graphic above, the computation time on the embedded device is quite good if we use the heuristic (8s for 100 nodes), it proved to be unusable without it (100s for 100 nodes)
The last objective I gave myself in the previous post was to write a plugin for OLSRd. Since OLSRd isn’t maintained anymore – and since all the developers are working on OONF – I decided to focus on it while avoiding the plugin. Instead, I wrote a makefile and packaged prince for openWRT / LEDE. The makefile hasn’t been published yet in any openWRT feed, but it is hosted in my repository [8]. Instructions are available along with documentation.
I’ll keep working on this project, mantaining the code and fixing the future issues. Since the graph-parser library is the last piece of code implemented in C++ and it depends on the Boost libraries, I’m looking forward to re-implement it in pure C.
One of my goals was also to run prince in my WCN (Ninux Firenze), but switching from OLSRd to OONF is taking more time than expected, so I’m hoping to try it in the future.
Gabriel
[0]: https://github.com/gabri94/poprouting/
[1]: https://github.com/gabri94/poprouting/milestone/1?closed=1
[2]: https://github.com/gabri94/poprouting/tree/v0.1
[3]: https://ans.disi.unitn.it/redmine/projects/cn_generator/repository
[4]: https://ans.disi.unitn.it/redmine/projects/pop-routing/repository
[5]: https://pdfs.semanticscholar.org/4ac8/05e7359c6b20c3cdd5da24284d3826b9609c.pdf
[6]: http://netjson.org/
[7]: https://github.com/gabri94/poprouting/tree/exec_time
[8]: https://github.com/gabri94/poprouting/blob/master/Makefile.openwrt
Freifunk ist nach über 10 Jahren sehr erfolgreich, bekannt und verbreitet. Wir sehen jedoch die ursprünglichen Ideen und Ziele von Freifunk nicht (mehr) von allen Communities bzw. Communitymitgliedern berücksichtigt. Es geht uns nicht darum, Communities auszuschließen, die sich mit dem hier formulierten Selbstverständnis nicht identifizieren. Wir sind aber an einer grundsätzlichen Auseinandersetzung über das interessiert, was wir hier unter dem Label Freifunk gemeinsam tun. Dieser Textentwurf wurde von einer Gruppe aus dem direkten Umfeld des Fördervereins Freie Netzwerke e.V. verfasst. Er ist als Verständigungsgrundlage gedacht und soll alle Communities dazu ermutigen, die angesprochenen Punkte zu reflektieren. Wozu machen wir Freifunk? Welche Ideen stecken dahinter? Welche Ziele verfolgen wir? Nach welchen Prinzipien entscheiden und handeln wir? Das Ziel dieses Textes ist es, ein Verständnis zu entwickeln, das alle Individuen und Gruppen, die unter dem Label Freifunk agieren, verbindet.
Freie (Funk-)Netze werden von vielen lokalen Initiativen aufgebaut und angeboten. Die Benutzer*innen sind auch gleichzeitig die Betreiber*innen der Computernetzwerke. Sie schaffen ein “Selbstmachnetz”, indem sie Wohnungen, Häuser, Straßenzügen, Stadtteile, Dörfer oder ganze Städte selbst vernetzen. Ein Freifunk-Netz ist dezentral aufgebaut und wird von vielen Individuen betrieben. Diese dezentrale Organisationsstruktur fördert bewusst lokale Aktivitäten, statt sie von einer übergeordneten Entität steuern lassen zu wollen. “Frei” bedeutet dabei, diese Netze öffentlich und anonym zugänglich zu machen, sie nicht kommerziell zu betreiben oder auszuwerten und die darin transportierten Informationen nicht einzusehen, zu verändern oder zu zensieren. Obwohl sich Freifunk vorrangig auf WLAN-Netze bezieht, ist der Begriff “Freie Netzwerke” breiter zu sehen. Er orientiert sich unter anderem an der freenetworks.org Definition.
Bei aller Dezentralität halten wir es für sinnvoll und wichtig, uns über die Grundsätze und Prinzipien des Projektes Freifunk einig zu sein, damit wir gemeinsam agieren und uns in unserem Handeln gegenseitig unterstützen können.
Obwohl die Nutzung technischer Netzwerke für sehr viele Menschen längst zum Alltag geworden ist, werden die dahinter liegenden Macht- und Wirkmechanismen unserer Meinung nach häufig nicht ausreichend reflektiert. Freifunk hat sich unter anderem zum Ziel gesetzt, ein Bewusstsein für diese Zusammenhänge in der Gesellschaft zu entwickeln, den freien Zugang zu öffentlichen Netzwerken zu fördern und dabei Anregungen für ein selbstbestimmtes Handeln zu geben. Dabei wollen wir die Bedürfnisse unterschiedlicher gesellschaftlicher Gruppen einbeziehen. Diversität und ein breites Spektrum an Ideen verstehen wir als wichtige Grundlagen, um diese Ziele zu erreichen. Wir möchten alle Teilnehmenden (User*innen/Knotenbesitzer*innen) ermutigen, selbst Hand anzulegen und sie dabei unterstützen, sich mit der Materie vertraut zu machen. Uns ist bewusst, dass dies ein aufwändiger Lernprozess ist. Wir möchten aber vermeiden, dass sich (Wissens-)Hierarchien dadurch fortsetzen und verstärken, dass sich Teilnehmende im Freifunknetz einfach “beliefern” lassen wollen. Unserer Ansicht nach führt dies nämlich mit dazu, dass die Grundideen des Selbstmachnetzes verloren gehen.
Als Freifunker*innen beteiligen wir uns am politischen Prozess, um die rechtlichen Voraussetzungen für freie Netze zu schaffen. Die Freifunkbewegung ist dabei überparteilich.
Es ist unser Anliegen, das soziale Community-Building und die technische Umsetzung freier Netze in den Communities nach ähnlichen Prinzipien zu gestalten: dezentral, mit möglichst wenigen/flachen Hierarchien und dennoch abgesprochen.
Viele unserer Prinzipien wurden bereits an anderen Stellen formuliert. Als Freifunker*innen bekennen wir uns zu den folgenden bereits existierenden Dokumenten:
Technische Prinzipien
Das Pico Peering Agreement ist die Grundlage unserer Netzwerke. Folgende Grundsätze machen für uns ein freies Netz aus:
Wir achten bei der Gestaltung unserer Netze auf Dezentralität. Deshalb ist es nicht in unserem Sinne, dass eine kleine Admingruppe oder Einzelpersonen per Fernzugriff die Kontrolle über ein ganzes (Teil-)Netz haben. Die Knotenbetreiber*innen haben die Wahl, sich für Fernwartung zu entscheiden. Eingriffe in die Knoten, z.B. Firmwareupdates oder andere Fernwartungsarbeiten, müssen immer mit dem ausdrücklichen Einverständnis der jeweiligen Betreibenden geschehen. Knotenbetreiber*innen können sich ferner entscheiden, ob sie auch Internetzugang bereitstellen wollen, sei es für die Teilnehmenden im Meshnetz, sei es für die Öffentlichkeit. Es ist uns dabei wichtig, dass Freifunk nicht in erster Linie als “Provider für kostenlosen Internetzugang” wahrgenommen wird. Entscheidungen über Releases werden in den lokalen Communities gemeinschaftlich getroffen.
Die Firmware für unsere Knoten basiert auf freier Software. Weiterentwicklungen veröffentlichen wir ebenso als FLOSS. Durch eine möglichst gute Dokumentation sollen Betreiber*innen in die Lage versetzt werden, die Firmware selbst weiterzuentwickeln oder Anregungen zur Verbesserung beizusteuern. Die Offenheit schafft Vertrauen in die Software.
Ein angenehmes soziales Klima ist uns in unseren Communities wichtig. Bei Freifunk wollen wir erreichen, dass sich Menschen unabhängig von Geschlecht, sexueller Orientierung, Herkunft, Glauben, Aussehen, Alter und anderer (tatsächlicher oder zugeschriebener) Merkmale in den Communities einbringen und wohlfühlen können. Der Umgang miteinander soll respektvoll sein; neue Interessierte sind uns stets willkommen. Wir dulden keinerlei Diskriminierungen. Das bedeutet für uns: Wir haben weder Platz für Nazis, noch für Rassismus, Sexismus oder andere Formen von menschenverachtendem Verhalten.
“Mitmachen”, das kann nach unserem Verständnis mindestens alles Folgende bedeuten: Freie Netze nutzen und selbst (mit)betreiben, sich in lokalen Communities sozial vernetzen, in der lokalen oder überregionalen Freifunk-Gemeinschaft mit den jeweils eigenen Fähigkeiten aktiv werden. Mitmachen beschränkt sich keinesfalls auf technische Fähigkeiten. Alle Formen von Engagement sind explizit willkommen und werden als Beitrag zur Community begriffen.
Wir sind uns bewusst, dass in unseren Communities auch Machtfragen auftauchen: Macht, Machtzuschreibung und Machtausübung werden sowohl durch zentralistische soziale, als auch durch zentralistische technologische Strukturen begünstigt. Dies ist einer der Gründe, weshalb wir nach dem Prinzip der Dezentralität arbeiten. Auch mit dem ungleich verteilten technischen Fachwissen können Machtfragen verbunden sein. Uns ist es wichtig, verantwortungsvoll damit umzugehen, Machtverhältnisse zu thematisieren und – wo möglich – abzubauen. Das möchten wir durch größtmöglichen Wissenstransfer und dezentrale Strukturen erreichen.
Wir wollen lernen, Netze zu bauen und zu betreiben, statt sie von “Expert*innen” hingestellt und gewartet zu bekommen. Wir nennen das Selbstmachnetz. Wir wollen Menschen befähigen und ermutigen, sich aktiv in die Gestaltung von Infrastruktur einzubringen und die Auswirkungen von Technik auf die Gesellschaft zu erforschen und zu gestalten. Wir fördern das Verständnis von Netzwerken und Netzwerktechnik (“Network/Code Literacy”), deshalb geben wir unser Wissen jederzeit weiter und machen nicht nur Code verfügbar. Wir experimentieren und forschen mit unserer Infrastruktur, deshalb gibt es keinen Anspruch auf permanente Verfügbarkeit.
Selbstmachnetze zu entwickeln ist ein Prozess. Uns ist bewusst, dass wir in diesem Prozess nicht alle Ziele immer gleichermaßen erreichen. Daher hinterfragen wir uns regelmäßig kritisch, ohne uns dabei anzufeinden. Das Lernen und Verbessern sozialer und technologischer Strukturen steht für uns im Vordergrund.
Eine Freifunk-Community ist im einfachsten Fall ein loser Zusammenschluss mehrerer Individuen. Lokale Vereine können die Gruppe unterstützen, z.B. beim Spendensammeln oder Abschließen von Verträgen. Die Gründung eines eigenen Vereins ist für Freifunk keine Voraussetzung. Veränderungen werden von allen Aktiven gemeinschaftlich beschlossen, nicht nur von Mitgliedern eines Trägers oder Vereins.
Für die wenigen community-übergreifenden Entscheidungen gründen wir den Beirat “Freifunk Advisory Council”, eine Vertretung von Community-Mitgliedern aus den unterschiedlichen Bundesländern. Dieses Gremium kann bei Konflikten zwischen Communities hinzugezogen werden.
Die Quellen sind auf github zu finden: https://github.com/freifunk/MoU