Home Features History Support Docs Code People

OpenWISP

Home Features History Docs Support Code People

OpenWISP

Google Summer of Code 2017 Idea List

Do you want to apply with us? We have a page that describes how to increase your chances of success. Please read it carefully.

Get started!

OpenWISP 2 Network Topology

Languages & technologies used: python, django, django-rest-framework, javascript, netjson.

One of the use case scenarios of OpenWISP 2 is mesh networking.
In these scenarios being able to collect and visualize topology information is crucial.

The basic work to implement this feature has been already done, read "Network Topology Visualizer: django-netjsongraph" to know more details.

This project idea consists in pulling django-netjsongraph in OpenWISP 2 and adding new features on top of it, in a similar way as the package openwisp-controller pulls in django-netjsonconfig and adds features to it.

To work on this idea, the student will have to create a new django reusable app as well as improve existing components like django-netjsongraph, netdiff and netjsongraph.js.

The new app will be named openwisp-network-topology and must have a code structure similar to the wrapper django apps already shipped with OpenWISP 2: openwisp-controller, openwisp-users.

This app, in substance, will be a web interface to setup the collection of network topology data from mesh networks as well as a mesh network visualizer and very basic monitoring system.

Measurable outcomes:

  • implement a reusable django app named openwisp-network-topology which depends on django-netjsongraph
  • add multi-tenancy features by using openwisp-users: each model of django-netjsongraph must be related to a specific organization
  • avoid duplication of the logic contained django-netjsongraph as much as possible
  • improve django-netjsongraph, netdiff and/or netjsongraph.js when is necessary to implement a feature upstream
  • create a new signal in django-netjsongraph that is sent when the status of a link changes
  • add a way to customize the theme (CSS and netjsongraph.js options) of the visualizer
  • add a netdiff parser for OpenVPN that works with both of its status formats (version1 and version2)
  • implement a way to save daily snapshots of the network topology so users can go back in time and visualize the status of the network in specific days
  • add a switcher in the visualizer that allows to go back in time and see one of the previous daily snapshots
  • document all the features in the README
  • prepare a setup.py script that will be used to install the python package of the reusable django app
  • achieve a test coverage higher than 80%
  • provide documentation using python-sphinx, the documentation must be included in a docs/ directory in the repository

Ansible plugin for the netjsonconfig library

Languages & technologies used: python, ansible.

Ansible is an IT automation tool that has been recently gaining popularity also in the OpenWrt world.

We want to implement an ansible plugin that integrates netjsonconfig and allows using its two most interesting features, that is templates and context, in ansible.

It should be possible to define configuration templates, assign them to specific playbooks and define specific configurations for hosts.

The configuration format format used by netjsonconfig is NetJSON DeviceConfiguration, but a YAML conversion of NetJSON would be good as well. Support for both would be preferred.

Measurable outcomes:

  • Implement an ansible module that integrates netjsonconfig in ansible and allows using NetJSON DeviceConfiguration (or its YAML equivalent) to configure OpenWrt devices
  • Achieve a test coverage higher than 80%
  • Provide documentation using python-sphinx

netjsongraph.js: canvas and geographic data

Languages & technologies used: javascript, ES6, CSS, netjson.

netjsongraph.js is a javascript library based on d3 that allows visualization of NetJSON NetworkGraph objects.

The library uses SVG for visualization, which can be quite slow when many elements are shown, therefore we would like to try switching to canvas. We also need an optional mode in which the network is displayed on a map.

Measurable outcomes:

  • Rewrite the visualizer to use canvas
  • Add an optional map mode
  • Modernize javascript code organization: you may want to use some modern JS tool for building the library, you may rewrite the code in ES6, up to you
  • Update documentation and examples in README

Implement NetJSON output in ubus (OpenWrt/LEDE)

NetJSON is emerging as a common format to exchange configuration and monitoring information from network devices. Year after year it's becoming easier to achieve interoperability between different software packages for community networks. Now is time to start implementing NetJSON in a lower level of the stack and the next natural step in that direction is to implement it in ubus (OpenWrt micro bus architecture), which is included by default in LEDE and OpenWrt, the two linux distributions commonly used with OpenWISP.

In this project the student will have to develop ubus API extensions that allow retrieving two NetJSON object types: DeviceConfiguration and DeviceMonitoring.

Measurable outcomes:

AirOS backend for OpenWISP 2

Languages & technologies used: python, AirOS, json-schema, netjson.

Implement an AirOS backend in netjsonconfig.

Measurable outcomes:

  • The AirOs backend must generate a configuration archive compatible with AirOS 6.x and AirOS 7.x, two separate classes can be created if preferred
  • The AirOs backend schema must cover at least 75% of the configuration features offered by AirOS web interface, with particular attention to interfaces, wireless settings and vlans
  • The general test coverage of the library must be kept higher than 95%
  • Both backends must be documented inside the python-sphinx docs dir contained in the netjsonconfig repo

Raspbian backend for OpenWISP 2

Languages & technologies used: python, raspberry pi, debian, json-schema, netjson.

Implement a Raspbian backend in netjsonconfig.

Measurable outcomes:

  • The Raspbian backend must generate a configuration archive compatible with Raspbian Jessie

  • The Raspbian backend schema must cover at least the following features:
    • general (eg: hostname)
    • ntp settings
    • network interface settings
    • wireless setttings
    • dns servers
    • dns search domains
    • static routes
    • files

  • The general test coverage of the library must be kept higher than 95%

  • The backend must be to be documented inside the python-sphinx docs dir contained in the netjsonconfig repo

PfSense backend for OpenWISP 2

Languages & technologies used: python, pfsense, json-schema, netjson.

Implement a PfSense backend in netjsonconfig.

Measurable outcomes:

  • The PfSense backend must generate a configuration archive compatible with PfSense 2.2.x
  • The PfSense backend must generate a configuration archive compatible with PfSense 2.3.x
  • The PfSense backend schema must cover at least 75% of the features offered by the PfSense web interface, with particular attention to interfaces, wireless settings, vlans, firewall rules and VPNs
  • The general test coverage of the library must be kept higher than 95%
  • The backend must be to be documented inside the python-sphinx docs dir contained in the netjsonconfig repo

netjsonconfig backward conversion

Languages & technologies used: python, json-schema, netjson.

As of today, netjsonconfig is only able to generate a native router configuration (eg: OpenWrt) from a NetJSON DeviceConfiguration object and not vice versa.

We want to add the backward conversion process into the library.

This project will require a thoughtful design, probably involving some serialization and deserialization mechanism.

Measurable outcomes:

  • Backward generate() pocess: a configuration archive must be converted to NetJSON DeviceConfiguration through the available backends
  • Backward render() process: a configuration string (eg: uci export in OpenWrt) must be converted to NetJSON
  • The general test coverage of the library must be kept higher than 95%
  • The feature must be documented in the documentation files contained in the netjsonconfig repo

django-radius: web interface for freeradius

Languages & technologies used: python, django, freeradius, django-rest-framework.

One of the most important features missing in OpenWISP 2 is the AAA (Authorization, Authenticatio and Accounting), which in OpenWISP 1 is implemented with OpenWISP User Management System from now on (OWUMS).

OWUMS is implemented in ruby on rails and suffers the same limitations that brought us to develop OpenWISP 2: monolithic, hard to extend without changing the core code, hard to maintain, hard to reuse in different contexts than the ones for which it was specifically designed.

For these reasons, in this project we aim to reimplement the basic, "core" features of OWUMS in a new lightweight django reusable app so it can fit with the emergent OpenWISP 2 ecosystem.

The app must have a code structure similar to the core django apps of OpenWISP 2: django-netjsonconfig, django-x509.

This app, in substance, will be a web interface to manage a freeradius database, with an additional RESTful API (using django REST framework) that will be used to retrieve session data from freeradius and to allow new users to register via third party apps.

Measurable outcomes:

  • implement a reusable django app which allows to manage the main freeradius database tables (session/accounting, check, group, nas, reply) via the django-admin
  • model references to the User must should be implemented using the swappable user model mechanism of django and default to django.contrib.auth.models.User
  • implement a "batch add users" feature, each batch operation and its details must be saved to the database
  • implement a RESTful API through which authorized users will be able to retrieve radius sessions, this API must be implemented using django REST framework
  • achieve a test coverage higher than 80%
  • provide documentation using python-sphinx, the documentation must be included in a docs/ directory in the repository

Javascript based configuration UI

Languages & technologies used: javascript, css, json-schema, netjson.

The configuration editor present in OpenWISP 2 is built with jsoneditor, a JSON-Schema compatible UI generator that builds a UI from the NetJSON DeviceConfiguration JSON-schema.

This solution has been a first step toward a configuration UI but it's not the best we can achieve.

We want to explore the possibility of using alternative solutions. These are our needs and measureable outcomes:

  • the configuration UI must be automatically generated from JSON-Schema
  • it must validate the JSON-schema before saving, and provide useful error messages to the user
  • it must provide an advanced mode for editing NetJSON directly
  • when using the advanced mode, it should provide syntax highlighting, line numbers and JSON-schema validation before saving or before going back to normal mode
  • should have the possibility to guide the user in some way
  • should have a mechanism to show only relevant categories of configuration options (eg: network, wireless, vpn) and switch between these views without reloading the web page
  • it must be built as a standalone javascript library that can be imported in larger projects (eg: openwisp2)
  • the most important features must be covered by some sort of automated tests; this is vital to allow future maintainers to add new features or perform refactoring without being worried of breaking existing functionality
  • it should not bring in too many dependencies, it should find a right balance between feature set and dependencies
  • it should be published as a javascript package on the most popular javascript package manager
  • its features should be documented briefly in its README

Apply with us

Do you want to apply with us? We have a page that describes how to increase your chances of success. Please read it carefully.

Get started!