Google Summer of Code Ideas
Here is a list of ideas for projects we thought up on what would be interesting and useful to do in a course of Google Summer of Code program for wlan slovenija open wireless network. Of course you can also propose other (your) idea(s). As long as they are connected with open (wireless) networking and mesh networking, connecting people with technology, tools for better collaboration and other things we are interested in (or you can get us interested in).
You can also check GSoC ideas of our umbrella organization Freifunk. Many technologies we are developing can be and are used in other open (wireless) networks around the world as well.
You can find more information about our participation in Google Summer of Code here.
Ideas are listed in no particular order.
|#328||Node data matrix comparison module for nodewatcher||normal|
The idea is to create a module which provides a page/matrix for node data comparison. Currently data is displayed only as a simple list of nodes with a fixed set of columns. The idea is to improve this so that custom columns can be added/removed. And also to add another dimension to get a matrix so that it is easy to compare values between nodes. For example, see how stability of nodes relate to number of clients. Additionally, this idea could be extended by an option to draw/plot selected columns/values as scatterplots.
You can see many data we collect as potential interesting and it would be interesting to be able to compare them. With matrix display this could be possible. So, a better way to compare nodes among themselves is wanted, and if possible to also visualize that.
|#329||Overview of used IP space module||low|
Currently we have a very limited overview of used IP space without more precise division of existing and used subnets. This could be improved in a similar manner that it is shown here. A compact and colorful matrix with IP ranges and links to nodes. Maybe also with some additional hover effect when you go over block to get some more information.
|#457||Plotting signal coverage on node map||high|
We currently have a map that shows geographical location of nodes. It would be great to have tools that could overlay signal coverage over this map. This can be done even without exact antenna radiation diagrams, we just need the node's general antenna direction. Then we can check neighboring nodes and color all the appropriate triangles (so the first node and its two neighbors – for all neighbors). This can then be used to mark areas that the node's signal should reach. Of course this will not be an exact computation but it can serve as a general reference when checking signal coverage and having data from neighbors available.
We could also take link quality into account. For example if one node has two links with 60° inner angle, both having 1.0 link quality, we could assume that the signal will also be ok +/- 30° to either side of the triangle. These additional triangles could then be drawn with a lighter color (and they could also be transparent).
Extra useful it would be if this would be a general library for plotting signal coverage on maps, so that it could be used with nodeshot node mapping software. Also that it supports both Google Maps and OpenStreetMap.
|#545||HMAC signing of nodewatcher data||normal|
Currently all monitoring reports by nodes are unsigned and can be spoofed by anyone. This represents a security problem and a possible solution is that every node would be assigned its own nodewatcher signing key. The node would then sign the monitoring output using a hash function in HMAC mode. Every request from nodewatcher would also contain a random nonce that would be used in signature computation to prevent replay attacks.
Such HMAC-based signing should not be too expensive in terms of CPU usage as it is a simple SHA-256 computation that can be performed via the OpenSSL library.
Signature verification failure would then generate an event and a warning within the nodewatcher monitoring system.
Student should have experience or be willing to learn Python and Django, shell scripting and maybe C, and development of OpenWrt packages and integration. Understanding of basic cryptography is needed, too.
|#859||Integrated link planner||high|
Integrate a link planner into nodewatcher, where potential the links to all surrounding nodes are calculated, the elevation profile is drawn for each of the potential links and the signal loss is calculated.
The benefit of such planner would be much simpler link planning. When a node is added, the full potential of the links from that location is seen.
A desktop tool for that is for example Radio Mobile. Integration and scripting for it should be checked, especially running/porting it on Linux. If not already existing, a library (with Python bindings) or standalone console application based on it could be developed.
It seems also an online version already exists.
|#1030||nodewatcher instalation/configuration wizard||high|
nodewatcher is currently being in the process of transforming to the new backend – much more pluggable and extendable, so that different wireless community networks and installations can configure it to their needs. The idea is that at the end we have a bunch of Django apps users will be able to enable or disable.
To ease all this configuration options an admin installation and configuration wizard could be made so that after the installation of nodewatcher user could select through web interface which modules/components/plugins (Django apps) it wants enabled. Of course there is also possibility of dependencies between apps. And information about additional steps necessary for module enabling (like running background processes, cron jobs, or something similar).
Even crazier would be to allow installation of new apps and upgrade of existing apps through the same interface (for example through Django Packages), of course if nodewatcher is running with necessary system privileges.
|#1187||IPv6 support for Tunneldigger||normal|
Tunneldigger is a VPN solution used in many community/mesh networks to connect nodes which do not have a wireless link between them into a common network. It uses existing network connectivity (like Internet) between nodes to create L2TP tunnels between them. Current limitation is that those tunnels use only IPv4 and cannot be established over IPv6. (Tunnels are layer 2 and can carry both IPv4 and IPv6 traffic already. The issue here is that they themselves cannot be established over IPv6.)
The aim of the 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. Student should have experience or be willing to learn Python and C, compiling and running code for OpenWRT, have experience with networking stack (IPv4, IPv6, NAT).
|#1188||Linux kernel support for multiple L2TP tunnels on the same server port||highest|
Current L2TP tunneling support in Linux kernel is limited by the fact that each tunnel requires unique UDP port on the server side. This creates problems for clients behind NAT as it would be much easier to configure NAT traversal if all tunnels would connect to the same server port. L2TP tunnels are used in Tunneldigger for providing a VPN solution for community/mesh networks.
The aim of the GSoC project is to implement support for multiple L2TP tunnels on the same server port in Linux kernel, create a patch for OpenWrt and Linux and send it upstream for inclusion. Student should have experience or be willing to learn Python and C and Linux kernel hacking/compiling and have experience with networking stack (IPv4, IPv6, NAT) and reading and implementing RFC standards.
|#1189||Add real-time (push) support to Datastream API||high|
Datastream API (with its HTTP interface) is a library for collecting and visualizing time-series data. It is used in nodewatcher to store and visualize measurements from nodes in a mesh network. Such visualizations through time allow better insight into network's status and operation for both experienced and novice users. Current implementation provides a RESTful API for fetching data to the client (browser) side for visualization. The issue is that for real-time visualization of such RESTful API requires from the client side to constantly poll the API endpoint for new data. A better model would be to use a push based API to get data from the server as new data is available (probably as a publish/subscribe pattern).