OpenWRT Packages

From SOWNWiki
Jump to: navigation, search

This project aims to create OpenWRT-compatible packages for SOWN's OpenWRT Node firmware.

Motivation

The primary motivation of this project is the maintainability of SOWN's node firmware, especially with respect to new OpenWRT firmware releases.

Setup Path

Current

  • Boot plain OpenWRT image.
  • Copy package files to the node.
  • Run 'opkg update'
  • Run 'opkg install <path to packages>'.

Planned

  1. Boot plain OpenWRT image.
  2. Either:
    • Change opkg repository to sown and install bootstrap package from there
    • Copy bootstrap package onto the node and install from the filesystem
  3. Run the sown installer script.

Design Issues

Package Scope

Each package should have as small a defined footprint as is reasonable.

Individual node configuration

Packages should be generic, not specific to an individual node. Therefore node-specific configuration should be downloaded from a sown server on package configuration. Updating the configuration should not require reinstalling a package.

This raises the following issues:

Client certificates and keys
As Nodes will have to download these, and they are considered sensitive, nodes will have to be given permission to do this.
Bootstrapping
In order to configure a node, it will need access to a SOWN server, complicating the process of flashing one at home.

Implementation

See OpenWRT Packages/Implementation for further information about how important features have been implemented.

Development

Working copies of the codebase can be found in /home/package_build/ on sown-auth and sown-dev. The repository lives on sown-auth. Also in /opt/package_build on Leth's desktop. Please ask if you require a login.

See OpenWRT Packages/Development for further information about how to go about development.

There was previously a TODO list here, but it was never maintained.

Testing

We have plans to unit-test our packages using virtual machines and PHP_Unit.

We plan to test both install-ability and system behaviour by scripting scenarios using additional VMs configured to behave as clients.

A subset of the required tests are:

* hostapd is stopped if the tunnel is unavailable
* hostapd is started when the tunnel becomes available
* hostapd is started if it is not running 
* openvpn is started if it is not running
* If the firewall Host-Blacklist is enabled, the change occurs on the node (dnsmasq reload etc)