Free Network News

WLAN-Störerhaftung: Petition fordert Abschaffung ohne Hintertüren für Abmahnindustrie

Freifunk statt Angst -

„Von einer Abschaffung der Störerhaftung kann nur dann die Rede sein, wenn WLAN-Betreiber nicht mehr damit rechnen müssen, für Rechtsverstöße Dritter kostenpflichtig abgemahnt zu werden. Um diese dringend nötige Rechtssicherheit zu erreichen, müssen die Betreiber ausdrücklich auch von der Haftung auf Unterlassung befreit werden. Nur unter dieser Voraussetzung entfällt das Abmahnrisiko, welches bis heute das […]

Union will die WLAN-Störerhaftung doch nicht abschaffen

Freifunk statt Angst -

Wie im vorherigen Beitrag geschrieben, gibt es keinen Grund zur Euphorie. Die WLAN-Störerhaftung ist noch nicht vom Tisch. Erstens liegt noch immer kein finaler Entwurf vor, obwohl der Bundestag schon kommende Woche darüber abstimmen will. Zweitens vermuten wir, dass es diese überarbeiteten Entwurf zwar gibt, die Union diesen aber blockiert, weil sie Unterlassungsansprüche und Abmahnungen […]

Overview: GSoC projects at freifunk.net

Freifunk Blog -

GSoC 2016 Introduction: external device handlers for netifd

Freifunk Blog -

HELLO WORLD

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 includes extending OpenWRT/LEDE's network interface daemon (netifd). I've familiarized myself with the source code during a class I took at TU. The work I did as part of this course is the foundation of what I'll implement during GSoC but it never became more than a very rudimentary minimum working example.

 

THE 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_. Whenever someone wanted to introduce a new device class, he or she would have to alter the netifd code base and maintain these changes. I'm writing a mechanism that allows the device handlers to be external programs communicating with netifd via the ubus IPC system. Then if someone wants to introduce a new device class into netifd, writing device handling logic and linking it to netifd will be all that he or she has to do. No maintenance -- or knowledge of the innermost workings of netifd -- 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's called will relay calls to the device handler interface it receives from netifd to the 'ovs-vsctl' command line utility to set up Open vSwitch bridges and ports.

 

MY DEVELOPMENT ENVIRONMENT

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.

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

 

WHERE I AM AT

As of today I have a mechanism in place 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 '172.17.1.123'

    option gateway '172.17.1.1'

    option netmask '255.255.255.0'

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.

 

THE ROAD AHEAD

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 '172.17.1.123'

    option gateway '172.17.1.1'

    option netmask '255.255.255.0'

 

    option of-controller '1.2.3.4:5678'

 

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.

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

Freifunk Blog -

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  ← Done16. May 6:00 PM: GSoC Mumble ← DoneRefine the roadmap ← Done23. 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 geolocatorMidtermevaluation20. June – 15. August: Work period 2 (8 weeks)Tarek & Clemens exams!!!13. June 6:00 PM: GSoC Mumble25. June 2:00 PM: hacker-session  1. Presentation about workaround with git CI processes.  2. actual unknown18. July 6:00 PM: GSoC Mumble30. July 2:00 PM: hacker-session  1. actual unknown  2. actual unknown15. August 6:00 PM: GSoC MumbleFinalevaluation
CheersJan-Tarek Butt

Sharable Plugin System for qaul.net

Freifunk Blog -

Hi everyone,

I'm Anu Vazhayil, exchange student at University of Paderborn from India. I am one of the Google Summer of Code participant for the project qaul.net

Qaul.net is a mesh network communication app which can be run in Linux, OSX, Windows and Android. It can be used to send text messages, file sharing and even make voice calls with people who are connected to this network without being connected to internet or cellular networks. There is also a feature to share your internet with the other users connected to the qaul.net network. All this makes it a cool app which everyone will feel to try atleast once.  If you have not installed it in your system, you can still connect to the network via web interface after connecting to a wifi.

As part of the GSoC project, we are planning to extend the usability of the messaging system of qaul.net. The messaging system can be used as a communication layer for other purposes like location sharing, sending contacts etc. Such apps/extensions can be downloaded by the user as a zipped file which will automatically get downloaded to the web plugin directory available to the web server. It also proposes an additional feature to share the installed plugins with other users in the network over file sharing.

The following needs to be implemented for the project:

  • Plugin API: to describe the features of a library and how to interact with it. It defines a mechanism to use the messaging system for plugins and give it access to the qaul.net topology.
  • Plugin structure: a zipped folder with a special extension that can be shared with other users in the network over file sharing.
  • Plugin management function: Installation and plugin sharing. Once the Plugin is installed, it is copied and extracted to a directory in the web server.
  • Sample Plugin: Share the location details of the user. It will have access to the user's location through the API implemented.
Stay tuned for my next blog posts with the updates regarding my project. I will also update my blog: https://captanu.wordpress.com/ in the coming days. Our coding period starts today so, I wish All the best to other GSoC students too. Happy coding everyone!Cheers!

Implementing Pop-Routing

Freifunk Blog -

Hi everyone!

I am Gabriele from the Ninux community. I am participating in GSoC 2016 for the first time and I am very glad I have been accepted as a Student for Freifunk. I am from Florence, Italy. Here I’m studying Computer Science, soon I will graduate and I hope to use the results of this project to write my bachelor thesis.

Four years ago, with others community networks’ enthusiasts we have funded Ninux Firenze[1], the fist Wireless Community Network in Florence where I had the chance to learn how these networks work and to meet many others people interested in this field. The network is constantly growing, and now it counts almost 20 nodes. In May ’14 I have been for the first time to Wireless Battle of the Mesh in Leipzig where I met the Freifunk community. For this GSoC I will work on a project called PopRouting[2]:

OONF (OLSRv2) is a link state routing protocol. It works sending periodical messages to his neighbors with the aim of transmitting information about topology changes. With these information each node of the network is able to calculate the paths to reach any other destination. These messages are periodically generated, based on the configuration parameter that regulates the sending interval. A short period will make the network react rapidly but it will also cause a large overhead due to control messages. Pop Routing is a recent technique that takes advantage of the knowledge of the network topology to find the optimal value for the OONF’s timers. Using Pop Routing every node computes the “betweenness centrality” of every other node and uses it to calculate the optimal trade-off between convergence and overhead for its timers. The algorithm has been developed at the UniTN and the algorithm to compute the BC in C++ is available as free software. My goal is to code a daemon (in C) that is able to calculate autonomously the BC of the network and push it to OONF using the telnet plugin.

In this month of community bonding I have been to Wireless Battle of the Mesh v9 in Oporto(PT). There I met the OONF developers and we discussed how to implement this inside OONF. I also gave a presentation on the project. After the Battlemesh I started working on the algorithm developed by UniTN and I made a C/C++ library out of it [3].

Today I will start coding for the GSoC, stay tuned and I will give you more updates soon.

 

Gabriel

 

[1]: http://firenze.ninux.org/

[2]: https://ans.disi.unitn.it/users/maccari/assets/files/bibliography/INFOCOM2016.pdf

[3]: https://github.com/gabri94/poprouting/tree/master/graph-parser

OpenWrt - poWquty (poWer quality): Computing and providing power quality information on OpenWrt routers.

Freifunk Blog -

Dear Freifunkers,

Please allow me to introduce the poWquty Project within Google Summer of Code 2016 at Freifunk.

The big picture behind this project relates to the energy production and consumption. Sustainable energy production and consumption are crucial for a prospering life on earth. The importance of energy led many theorists to even define the level of civilization by its energy profile. With the renewable energies shift the energy production paradigm from centralized to decentralized energy production which poses one of the next big challenges, which will influence the energy production in the future years.

From the big picture we move to the concrete case, increasingly faced when dealing with renewable energies: monitoring and control.
The emerging smart grids include an inherent need for communication for monitoring and control purposes in a more and more dynamic environment. One of the major challenges is monitoring the power quality parameters in a decentralized manner. In such case, decentralized information need to be retrieved and transported with the lowest latency possible. One way to solve this challenge could be to install expensive infrastructure to each point. The better way is to use wireless mesh infrastructure that could also serve this purpose.

Here where Freifunk comes in: The Freifunk mesh network is an outstanding example for a decentralized infrastructure that could be augmented with grid related functionalities to cope with future energy challenges. In order to use wireless mesh networks such as Freifunk for energy monitoring, we could use extra hardware that does the power measurements and use the wireless networks solely for transporting the information. The drawback of this is the need to install separate hardware. But, since all routers run on power, we could integrate the measurements into the router, which is the main goal of this project: to enable power quality measurements on OpenWrt.

Here is the initial plan how to do this. First we need to retrieve voltage samples from the power grid. For the beginning we will rely on an oscilloscope device that delivers the real time samples over a USB interface. This way voltage samples from the electric socket are retrieved at the router. With these voltage samples we can go ahead and calculate the power quality parameters, using moving window algorithms, fourrier transform, and z-transform to get the phase angle, the effective power, the frequency, and the harmonics. This calculation should be time, and memory efficient since it has to run on the OpenWrt embedded devices. Once these values are calculated we need to think about how we want to make them available for retrieval over IP networks.

Now we come to the Code: The goal of the project is to create an OpenWrt package which ensures three functionalities:
1-    Retrieving sample data from the measurement device
2-    Calculating power quality parameters form the retrieved samples
3-    Provisioning of the calculated parameters for retrieval

This project is intended to strengthen the role of open software in the uprising smart grids by providing some essential functionalities, communication devices need to have in the context of smart grids, especially in regard to the future role of the home routers in the future energy solutions.

More updates on this will follow in the next weeks.

Cheers,

Neez

GSoC: A new configuration system for OpenWrt/LEDE

Freifunk Blog -

Hi,
I'm Matthias (aka NeoRaider), and this year, I'll participate in the Google Summer of Code for the Freifunk project.

The goal of my project is to develop an alternative to the UCI configuration system, as UCI has a number of issues that make it cumbersome to use in some situations.

One of the basic issues of UCI that affects many Freifunk (or generally community mesh) firmwares is the upgrade behaviour. Mesh firmwares usually contain elaborate default configurations, which set up network interfaces and other things to allow participating in a mesh without deep knowledge of the setup.

But this setup needs to change from time to time, as the firmware is upgraded. In the Gluon firmware framework, we usually solve this by providing upgrade scripts which modify the configuration after flashing the firmware. Writing these script is often a tedious task, and the scripts easily break when the configuration differs too much from the expected one.

But the ability to change the configuration is important for many Freifunk users: They want to change the role of ethernet ports, WLAN settings, and a lot more. But UCI doesn't provide information how a setting was changed: if a script encounters an unexpected value, it can't find out if it is an old default value, or was changed by the user. This often leads to a difficult choice for the script author: either to overwrite the value unconditionally, maybe disregarding voluntary configuration changes, or not to overwrite it, rendering communities unable to change certain configuration during upgrades.

My project aims at solving this by saving the user configuration independently of the defaults provided by packages. This way, a package upgrade can change the default values, but explicit user configuration will not be affected.

Another issue is that the upgrade scripts are usually part of the packages that bring the configuration. Removing a package will leave the configuration behind, which is usually a good thing (for users which know about this and may be interested in the the old config), but for mostly-automatic upgrades, old configuration may accumulate, which can quickly become problematic on devices with very limited flash.

I plan to fix this by basing the new configuration system on schema definitions, which specify which configuration options and values are valid. The schema will probably be based on JSON, as there are already lots of existing systems for defining JSON schemas, which may be used for my project or at least serve as inspiration. This will also finally provide real datatypes for the configuration and make things more consistent (finally no more 1/true/on/yes/0/false/off/no booleans!). If we want too keep the package/section/option organization of UCI, or rather allow defining schemas for any JSON structure, is still a subject of debate.

Instead of going into detail even more in this post, I'll provide a link to my Gitlab project: https://gitlab.com/neoraider/ece

Design documents, examples for configuration and schemas, and first code will start to appear there very soon

DynaPoint - A dynamic access point validator and creator

Freifunk Blog -

Hi everybody,

 

I am Tobias, a Computer Science student at the TU-Berlin. I am glad to have the opportunity to participate at GSoC for Freifunk this year.

 

My project aims at making the handling with access points in OpenWrt/LEDE easier. The goal is defined as follows: Find an easily configurable solution (with reasonable defaults) for making the wireless access SSID in OpenWrt/LEDE dependent on a set of network conditions.

 

What does that mean? Consider the following example. You have a wireless access point with SSID "Freifunk". Suddenly for whatever reason the AP looses Internet connectivity without anyone noticing it. When users now connect to this AP, expecting a working Internet connection, they get frustrated, because they can't check their emails or surf the Internet.

 

With DynaPoint I want to develop a daemon, which regularly monitors the Internet connectivity. When it's lost, the SSID will automatically be changed. In this example it could be changed to "Freifunk-offline". When Internet connectivity is re-established, the SSID would automatically be changed back to "Freifunk".

This way users as well as admins get informed about the state of an access point just by looking at the SSID.

 

To verify Internet connectivity the first obvious step would be to do a ping. For this purpose there already exists a package called pingcheck, which I am planning to use. Further steps could include DNS-Queries and HTTP-Downloads.

 

Speaking about easy configuration and reasonable defaults, I want to require as little configuration steps as possible, but also provide enough configuration options to be adjustable to different kind of setups. Ideally the configuration will also be possible via the LuCI web interface.

 

Until next time,

 

Tobias

SWOON: Simultaneous Wireless Organic Optimization within Nodewatcher

Freifunk Blog -

Hi everyone,

I will contribute to one of the Freifunk projects; nodewatcher, via Google Summer of Code this summer and I wanted to keep you updated on my progress as well as exchange thoughts about my ideas.

First of all, nodewatcher is an open source, modular community oriented platform used for network planning, node deployment, node monitoring and maintenance. nodewatcher was initially developed to be primarily used by the wlan slovenija project. With 1336 nodes, it's really successful and a great example for community networks. As nodewatcher gets deployed elsewhere with even more nodes, it's natural to ask ourselves if we can be smarter about allocating spectrum to our wireless nodes - these nodes are mostly inexpensive wireless routers but it's natural to extend the meaning of the term to dedicated wireless access points (i.e. Unifi AP).

The theoretical foundation for this problem is fascinating by itself: Each node has a different amount of noise in each channel (the 2.4GHz band allows 3 non-overlapping channels where each channel is 20MHz wide) and each node wants to maximize its SNR (signal-to-noise ratio). I will term this as the greedy approach, which is already used in enterprise level devices. However, in an urban setting, nodes are close enough to each other for their signal to act as noise to other nodes. The greedy approach is no longer optimal as it bears a high price of anarchy. Instead, our goal is now to maximize the sum of channel capacities (under a power constraint). I will have to devise an algorithm to solve this problem and the algorithm does not seem trivial since the number of combinations is increasing exponentially with the number of nodes in the system. Even with only 10 nodes, we haveover 59000 possible allocations on 2.4GHz band and over 95 trillion on the 5GHz band.

Traditional networking literature tackles this optimization problem with Lagrange multipliers. An alternative is to look at approximate graph coloring schemes and compute chromatic numbers. I hope to experiment across various settings and approaches.
Over the course of the project, I hope to experiment with a real network which consists of at least 10 nodes and measure the improvements. One exciting thing about real life experiments is that nodewatcher was mostly used inside wlan slovenija's network and I get to run it independently! This will probably allow me to fix some bugs on the way and contribute to nodewatcher in this aspect as well.

The algorithm will initally be developed as a nodewatcher module, but I hope to eventually port it to openwrt (possibly after the summer ends). The main difficulty is that nodewatcher can act as a central level planner, whereas the openwrt scenario requires negotiation among nodes. So it's harder to convince a node to decrease its TX power to benefit other users. But imagine a network where nodes can communicate and achieve a socially optimal point of spectrum allocation! A glorious future awaits us.

Provide a cryptographic implementation for Qaul.net

Freifunk Blog -

Hey there,

my name is Katharina (aka spacekookie) and I am one of the Google Summer of Code participants for Freifunk projects; qaul.net in particular.

I wanted to write up a short article on what it is I will be doing this summer, how I will do it and what I hope to achieve. This will be one of three articles published on this blog.

Qaul.net provides a mesh-wifi network for people to connect and share information to other people on the network. Like freifunk it uses the OLSR mesh routing library. But unlike freifunk it's main goal isn't to connect to the www-internet but rather create a network of it's own on which people can communicate, share data and come together. No centralised infrastructure required.

Currently all traffic on qaul.net is sent in the clear which is...suboptimal. For one nothing said on the network is in any sense of the word "private". On the other there is no way to verify identities. And that's what my Summer of Code project is about.

The changes to the qaul.net code base required are quite extensive but with a bit of clever planning shouldn't break too many things. The core thing required is an abstraction layer between user and network.

Currently a user gives their node a nickname and that's then them. "Identify verification" (if you want to call it that ) is done by checking IP addresses against nick-names. Man in the middle attacks are very easy in such a network and the only defense is the benevolence of its users.

What I thus plan to do is introduce an abstraction layer between a node, routing and what a user sees. A "user identity" which can be shared between different nodes (but doesn't have to be), something that can be written to an addressbook and is later on verifiably the same and will make users aware if their are being man-in-the-middled, which is now much easier to verify.

In addition to that I plan to introduce asymmetric encryted messages, completely transparent to the user. While qaul.net can flood a message acress the network that should be seen by as many people as possible, there should be the ability for two people on the network to talk to each other without anybody else knowing what they're talking about.

What's planned is something that resembles PGP. A users identify will be their master-private key fingerprint. From that each node gets a subkey-pair (public and private). The public key will be flooded into the network for people to use to write messages to that node. The private will be unique to the node. And when sending messages to another person people can either choose "all" which means that the messages is encrypted against all (non-revoked) public keys of the target identity or choose a specific node to talk to. This implementation also allows for mailing list style group discussions.

 

Through Google Summer of Code I hope to become a regular contributer to qaul.net as I am a big fan of the project ideas. I also hope that my contributions will make it a much safer place to communicate and share information on.

As already mentioned I will be updating this blog two more times: one around the half-way point of the project and one as a wrap-up of how it all went.

If you’re interested in reading more of my insane ramblings about the project, maybe micro updates and what not, check out my personal blog https://spacekookie.de or go directly to the GSOC category.

 

Until another day,

Katharina/ spacekookie

 

FFRADIO039: Vom Wireless Community Weekend

Freifunk Podcast -

Das Wireless Community Weekend findet seit vielen Jahren immer am Wochenende nach Himmelfahrt auf der c-base in Berlin statt. Ekektra hat die Chance genutzt und mit zwei Teilnehmern ein Interview aufgenommen.

Wenn euch unser Podcast gefällt, bewertet uns bitte bei iTunes und empfehlt uns weiter. Wir freuen uns auch über Fragen und konstruktive Kritik als Kommentar, oder per E-Mail.

jQuery('#podlovewebplayer_b5c0e5ff5ae372ddcdaf3212a396f5aba807f9c1').podlovewebplayer({"pluginPath":"http:\/\/radio.freifunk.net\/wp-content\/plugins\/podlove-podcasting-plugin-for-wordpress\/lib\/modules\/podlove_web_player\/player_v2\/player\/podlove-web-player\/static\/","alwaysShowHours":true,"alwaysShowControls":true,"timecontrolsVisible":false,"summaryVisible":false,"hidetimebutton":false,"hidedownloadbutton":false,"hidesharebutton":false,"sharewholeepisode":false,"loop":false,"chapterlinks":"all","permalink":"http:\/\/radio.freifunk.net\/2016\/05\/13\/ffradio039-vom-wireless-community-weekend\/","title":"FFRADIO039: Vom Wireless Community Weekend","subtitle":"Elektra hat Vertreter von Freifunk Dresden und Freifunk Halle interviewt","summary":"Das Wireless Community Weekend findet seit vielen Jahren immer am Wochenende nach Himmelfahrt auf der c-base in Berlin statt. Ekektra hat die Chance genutzt und mit zwei Teilnehmern ein Interview aufgenommen.","publicationDate":"2016-05-13T00:29:32+00:00","poster":"http:\/\/radio.freifunk.net\/wp-content\/cache\/podlove\/27\/2261309159c3b4206e6a7e6646821a\/freifunk-radio_200x200.png","showTitle":"Freifunk Radio","showSubtitle":"auf colaboradio","showSummary":"Jeden 2. Dienstag im Monat um 22:15 live im Radio, in Berlin auf 88,4 MHz und Potsdam auf 90,7 MHz","showPoster":"http:\/\/radio.freifunk.net\/wp-content\/cache\/podlove\/27\/2261309159c3b4206e6a7e6646821a\/freifunk-radio_200x200.png","show":{"title":"Freifunk Radio","subtitle":"auf colaboradio","summary":"Jeden 2. Dienstag im Monat um 22:15 live im Radio, in Berlin auf 88,4 MHz und Potsdam auf 90,7 MHz","poster":"http:\/\/radio.freifunk.net\/wp-content\/cache\/podlove\/27\/2261309159c3b4206e6a7e6646821a\/freifunk-radio_200x200.png","url":"http:\/\/radio.freifunk.net"},"license":{"name":"Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License","url":"http:\/\/creativecommons.org\/licenses\/by-nc-sa\/4.0"},"downloads":[{"assetTitle":"MP3 Audio (mp3)","downloadUrl":"http:\/\/radio.freifunk.net\/podlove\/file\/100\/s\/webplayer\/c\/website\/Freifunk-Radio_Interviews_mit_Freifunk_Dresden_und_Freifunk_Halle-WCW-2016.mp3","url":"http:\/\/radio.freifunk.net\/episodes\/Freifunk-Radio_Interviews_mit_Freifunk_Dresden_und_Freifunk_Halle-WCW-2016.mp3"}],"duration":"00:29:50","chaptersVisible":false,"features":["current","progress","duration","tracks","fullscreen","volume"]});
⬇ Downloads: MP3 Audio (24 MB) Elektra Employ Klaus (function() { var s = document.createElement('script'), t = document.getElementsByTagName('script')[0]; s.type = 'text/javascript'; s.async = true; s.src = 'https://api.flattr.com/js/0.6/load.js?mode=auto'; t.parentNode.insertBefore(s, t); })(); Sendungsnotizen

Bundesregierung kündigt Abschaffung der WLAN-Störerhaftung an

Freifunk statt Angst -

Toll, oder? Naja, nach den vielen Lippenbekenntnissen in den letzten Jahren die WLAN-Störerhaftung endlich abzuschaffen, sind wir mit verfrühter Euphorie doch sehr vorsichtig geworden und wollen jetzt erstmal den finalen Gesetzestext abwarten und prüfen. Erst dann wird ersichtlich, ob die WLAN-Störerhaftung wirklich im Sinne aller Nutzerinnen und Nutzer abgeschafft wird oder (wieder) nicht. Unklar ist […]

Fast 2 Jahre später: Union gibt Widerstand gegen Abschaffung der WLAN-Störerhaftung (anscheinend) auf

Freifunk statt Angst -

Im Laufe der Woche wurde bekannt, dass die Bundeskanzlerin Angela Merkel das Streitthema WLAN-Gesetz vom Tisch haben will. Klingt erstmal erfreulich, oder? Hier der Crosspost vom Blog des Digitale Gesellschaft e.V. mit dem wir gemeinsam seit über 2 Jahren an der Abschaffung der WLAN-Störerhaftung arbeiten: „Die Abschaffung der WLAN-Störerhaftung ist lange überfällig. Wir begrüßen daher […]

FFRADIO038: OLSRv2 & IPv6

Freifunk Podcast -

André und Elektra tauchen tief in die Geheimnisse von OLSRv2 und IPv6 ein

Wenn euch unser Podcast gefällt, bewertet uns bitte bei iTunes und empfehlt uns weiter. Wir freuen uns auch über Fragen und konstruktive Kritik als Kommentar, oder per E-Mail.

jQuery('#podlovewebplayer_93dd6581e1aefd2b4ac9ba8b09f096749163c28e').podlovewebplayer({"pluginPath":"http:\/\/radio.freifunk.net\/wp-content\/plugins\/podlove-podcasting-plugin-for-wordpress\/lib\/modules\/podlove_web_player\/player_v2\/player\/podlove-web-player\/static\/","alwaysShowHours":true,"alwaysShowControls":true,"timecontrolsVisible":false,"summaryVisible":false,"hidetimebutton":false,"hidedownloadbutton":false,"hidesharebutton":false,"sharewholeepisode":false,"loop":false,"chapterlinks":"all","permalink":"http:\/\/radio.freifunk.net\/2016\/04\/24\/ffradio038-olsrv2-ipv6\/","title":"FFRADIO038: OLSRv2 & IPv6","subtitle":"Next Generation Protocols","summary":"Andr\u00e9 und Elektra tauchen tief in die Geheimnisse von OLSRv2 und IPv6 ein","publicationDate":"2016-04-24T19:19:00+00:00","poster":"http:\/\/radio.freifunk.net\/wp-content\/cache\/podlove\/27\/2261309159c3b4206e6a7e6646821a\/freifunk-radio_200x200.png","showTitle":"Freifunk Radio","showSubtitle":"auf colaboradio","showSummary":"Jeden 2. Dienstag im Monat um 22:15 live im Radio, in Berlin auf 88,4 MHz und Potsdam auf 90,7 MHz","showPoster":"http:\/\/radio.freifunk.net\/wp-content\/cache\/podlove\/27\/2261309159c3b4206e6a7e6646821a\/freifunk-radio_200x200.png","show":{"title":"Freifunk Radio","subtitle":"auf colaboradio","summary":"Jeden 2. Dienstag im Monat um 22:15 live im Radio, in Berlin auf 88,4 MHz und Potsdam auf 90,7 MHz","poster":"http:\/\/radio.freifunk.net\/wp-content\/cache\/podlove\/27\/2261309159c3b4206e6a7e6646821a\/freifunk-radio_200x200.png","url":"http:\/\/radio.freifunk.net"},"license":{"name":"Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License","url":"http:\/\/creativecommons.org\/licenses\/by-nc-sa\/4.0"},"downloads":[{"assetTitle":"MP3 Audio (mp3)","downloadUrl":"http:\/\/radio.freifunk.net\/podlove\/file\/98\/s\/webplayer\/c\/website\/ffradio038-olsrv2-ipv6.mp3","url":"http:\/\/radio.freifunk.net\/episodes\/ffradio038-olsrv2-ipv6.mp3"}],"duration":"00:29:04","chaptersVisible":false,"features":["current","progress","duration","tracks","fullscreen","volume"]});
⬇ Downloads: MP3 Audio (43 MB) Elektra André (function() { var s = document.createElement('script'), t = document.getElementsByTagName('script')[0]; s.type = 'text/javascript'; s.async = true; s.src = 'https://api.flattr.com/js/0.6/load.js?mode=auto'; t.parentNode.insertBefore(s, t); })(); Sendungsnotizen

EU-Richtlinie verhindert freie digitale Kommunikation

Freifunk -

Die EU-Richtlinie zur Regulierung von Funkanlagen, die ab Juni in Kraft tritt (2014/53/EU), gefährdet aus unserer Sicht die Sicherheit von WLAN-Geräten, statt sie zu verbessern. Neue Softwareversionen müssen entsprechend der neuen Richtlinie ein Zertifizierungsverfahren durchlaufen, bevor sie auf der Hardware installiert werden können. Das können Freie Software-Projekte jedoch kaum gewährleisten, dabei werden viele Sicherheitslücken von freien Entwicklern behoben.

Die folgende Erklärung wurde von Freifunk und der Free Software Foundation Europe (FSFE) initiiert und mittlerweile von vielen weiteren Organisationen unterzeichnet, die damit Ihrem Unmut gegenüber der Richtlinie Ausdruck verleihen.

Gemeinsame Erklärung gegen die Radio Lockdown-Richtlinie (Sperrung von Funkanlagen)

Die EU-Richtlinie für Funkanlagen bedroht die Rechte von Usern und Freier Software, den fairen Wettbewerb, Innovation, die Umwelt und freiwilliges Engagement – das alles, ohne überhaupt große Vorteile für die Sicherheit zu bieten. Viele Organisationen und Unternehmen haben sich nun zusammengeschlossen, um den EU-Institutionen und -Mitgliedsstaaten Maßnahmen vorzuschlagen, wie die negativen Auswirkungen verhindert werden können, ohne das gewünschte Ergebnis der Richtlinie zu verfehlen. Lesen Sie dazu auch unsere Analyse, die wir beständig auf dem aktuellen Stand halten.

Den Lockdown von Funkanlagen vermeiden – Sicherheit und Innovation erhalten

Mehr und mehr Geräte verbinden sich mittels drahtloser und mobiler Funkverbindungen mit dem Internet. Dazu gehören nicht nur zahllose Endgeräte wie Router, Handys, WLAN-Karten und Laptops, sondern auch die sogenannten “Internet-of-Things”-Geräte. Die “Richtlinie über die Bereitstellung von Funkanlagen 2014/53/EU” (im Weiteren ‚die Richtlinie‘), die im Mai 2014 vom Europäischen Parlament und dem Europäischen Rat beschlossen wurde, umfasst aktuelle und künftige Geräte. Hauptzweck der Richtlinie ist die Harmonisierung existierender Richtlinien, die Verbesserung der Sicherheit im Funkspektrum und der Schutz von Gesundheit und vor Gefahren.

Wir unterstützen die generelle Ausrichtung der Richtlinie. Dennoch möchten wir klar unsere Befürchtungen zu den weitreichenden Konsequenzen des Artikel 3.3(i) der Richtlinie zum Ausdruck bringen, welcher von Herstellern verlangt, jede Software für Funkanlagen auf Konformität mit den Bestimmungen der Richtlinie hin zu überprüfen.

Drohender Lockdown (Verriegelung) des Funkmoduls

Wir glauben, dass eine solche Regelung negative Folgen für Nutzerrechte und auf Freie Software, den fairen Wettbewerb, Innovation, die Umwelt und freiwilliges Engagement haben wird – größtenteils ohne nennenswerte Vorteile für die Sicherheit zu bringen.
Der Artikel 3.3(i) verlangt von Geräteherstellern, dass sie Software, die auf ihren Geräten installiert werden kann, auf Konformität mit bestehenden nationalen Bestimmungen prüfen. Diese Anforderung verhindert, dass Benutzer und Unternehmen Software auf ihren Geräten selbstständig aktualisieren können, solange sie nicht vom Hersteller überprüft worden ist. Dies bedeutet nicht nur für die Gerätehersteller selbst eine starke Einschränkung, sondern verletzt auch die Rechte der Endbenutzer zur freien Wahl der Software, die sie einsetzen wollen.

Die in Artikel 3.3(i) festgeschriebenen Anforderungen haben Auswirkung auf die Freiheiten der zahlreichen Unternehmen, deren Geschäftsmodelle auf der Bereitstellung alternativer und freier Software für solche Geräte basieren. Alternative Software ist das Fundament vieler Produkte und wir sollten ökonomische Nachteile für diese Unternehmen vermeiden.

Die weitreichende Vorschrift, jede mögliche Software auf Konformität prüfen zu müssen, wirkt sich auch negativ auf Innovation und gemeinnützige, nicht gewinnorientierte Organisationen aus, die auf Alternativen zur von den Geräteherstellern mitgelieferter Software angewiesen sind. Die Bemühungen von Freiwilligenorganisationen, hilfsbedürftigen Menschen Zugang zum Internet bereitzustellen, könnten so zunichte gemacht oder stark eingeschränkt werden.

Des Weiteren begünstigt alternative Software auf drahtlosen Geräten die Nachhaltigkeit. Eine Menge Geräte, für die von den Geräteherstellern keine Aktualisierungen mehr angeboten werden, kann dank freier Software weiter genutzt werden. Alternative Software, die in gemeinschaftlicher Anstrengung entwickelt und verbessert wird (wie etwa Freie Software), hat eine deutlich längere Lebensdauer und trägt dazu bei, dass Benutzer und Kunden funktionierende Ausrüstung nicht entsorgen müssen. Ein weiteres Ergebnis ist die verbesserte Sicherheit für Benutzer, da ältere Hardware weiterhin Sicherheitsupdates erhält, nachdem Hersteller die Unterstützung und Weiterentwicklung bereits eingestellt haben.

Wir begrüßen das Ziel der Richtlinie, die Sicherheit von Funkanlagen zu verbessern, allerdings nicht zu Ungunsten der Balance zwischen Nutzerfreiheiten und Sicherheit in anderen Gebieten. Erstens stärken Softwareupgrades die Sicherheit der Geräte. Zweitens sind wir überzeugt, dass solch strenge Regelungen für typische Endanwender-Produkte mit eingeschränkter Sendeleistung nicht notwendig sind. Drittens glauben wir, dass auch technische Einschränkungen nicht verhindern können, dass Menschen sich vorsätzlich über bestehende Regelungen für Funkanlagen hinwegsetzen.

Unsere Vorschläge

Darum bitten wir die EU-Institutionen und die Mitgliedsstaaten, unsere Anliegen in ihre Überlegungen einzubeziehen und dafür zu sorgen, dass diese Richtlinie keine pauschalen, unnötigen und unverhältnismäßigen Einschränkungen für die Rechte von Kunden und Unternehmern einführt, wenn sie in nationales Recht überführt wird.

Was wir von den EU-Institutionen erwarten

Wir bitten die Europäische Kommision, delegierte Rechtsakte – zu denen sie vom Europäischen Parlament und dem Rat (Artikel 44) befugt sind – so anzupassen, dass sie

  • entweder: alle Freie Software von der Regelung ausnehmen, die von Dritten (Unternehmen oder Einzelpersonen) – also nicht von den Herstellern der Funkanlage selbst – entwickelt wurde
  • oder: die Verantwortlichkeit für die Regelkonformität der Software nicht von den Nutzern auf die Hersteller zu übertragen, wenn Nutzer Änderungen an der Standardkonfiguration ihrer Geräte vornehmen wollen. Software und Hardware sollten in dieser Hinsicht nicht unterschiedlich behandelt werden.
Was wir von den EU-Mitgliedsstaaten erwarten

Wir bitten die Gesetzgeber der Mitgliedsstaaten darum,

  • die Bestimmungen der Richtlinie so auszulegen, dass Freie Software gleichermaßen weiterhin auf Geräten mit Funkanlagen installiert werden kann, als auch Benutzerrechte zu wahren. Wie im Erwägungsgrund (19) dargelegt sollen Drittanbieter, z.B. Freie Softwareprojekte nicht benachteiligt werden.
  • sicherzustellen, dass mittelständische Hersteller nicht überproportional belastet werden, indem sie gezwungen werden jegliche, auch alternative, Software zu überprüfen.
  • sicherzustellen, dass Benutzer nicht gezwungen werden, nicht-freie Software zu installieren.

Wo bleibt die politische Unterstützung für die „Digitale Hilfe für Flüchtlinge“?

Freifunk statt Angst -

Folgendes Schreiben habe wir heute an alle Ausschuss-Mitglieder des Bundestagsausschuss Digitale Agenda verschickt. Betreff: Digitale Hilfe für Flüchtlinge Sehr geehrtes Mitglied des Ausschuss Digitale Agenda, am 4. November 2015 waren wir als zivilgesellschaftliche Vertreter bei Ihnen im Ausschuss geladen. Bei dem Tagesordnungspunkt „Vorstellung von Initiativen/Verbänden“ zum Thema „Digitale Hilfe für Flüchtlinge“ haben wir Ihnen über […]

Auch am Europäische Gerichtshof ist man gegen die WLAN-Störerhaftung

Freifunk statt Angst -

In der heutigen Sitzung des Europäischen Gerichtshofs hat sich der Generalanwalt klar gegen die WLAN-Störerhaftung und gegen den Entwurf der Bundesregierung zur Änderung des Telemediengesetzes ausgesprochen und die Abschaffung der Störerhaftung für WLANs ohne alle Hürden wie Vorschaltseite oder Passwort gefordert. Die Bundesregierung muss jetzt endlich handeln und wie von uns und anderen gefordert die […]

Pages

Subscribe to The Next Layer  aggregator - Free Network News