qMp (Quick Mesh Project) - Packages

h1. Tasks

h2. IPv6

Right now qMp is using IPv6 ULA between the mesh nodes as main IP protocol.

However clients can only get IPv4 address (by DHCP). 

A) The first step of this task is to give IPv6 ULA to end users (by radvd announcements)

B) Another needed point is all related with IPv6 public addresses. 

   A Gateway node can get an IPv6 network range from its ISP.

   When another node wants to use this node as gateway, it ask for an available IPv6 range using AHCP.

   Then configure it to some interface (br-lan?) and give public IPv6 addresses to end users (by radvd announements)

h2. Tinc VPN

A VPN between qMp nodes is needed to be able to manage them in remote. Tinc seems the best option.

h2. smsfs

The bmx6 sms is a cool feature which permits to send small messages (represented as files) to all nodes of the network. 

However there is a restriction of XXX bytes per file (or message). 

A) A nice approach would be to create an abstraction layer of this sms feature, something like sms filesystem. 

   Then if the maximum size is M and the file size is N (where N > M). 

   The file is splited in X parts ( X = N/M ). Also gzip encryption can be used to minimize the network overhead.

B) Alternative approach is to have a rsync-based daemon which uses sms feature only to exchange md5 or sha2 sums

   of directories or files and automatically update/sync these with neighbors and other nodes.

C) Alternative approach is to refactor BMX6 to handle non-atomic descriptions (enable descriptions to be fragmented over multiple packets).

   That would scale much better and solve the above restriction from the root.

D) The fuse module may be used to provide an userspace-transparent filesystem.

   There exist a LUA API for fuse (flu): http://piratery.net/flu/index.html http://hg.piratery.net/flu/overview

h2. Centralized control

System to control all nodes from the network is needed. 

A) Maybe the SMS plugin can be used to broadcast the commands.

B) Some security must be implemented too (node A can get instructions from B but not from C).

C) If security is not ignored I would concentrate on an ssh based approach.

   If its simple, the ssh layer can later still be replaced with a future-secure-sms version.

   Advantage would be to be reusable for other systems and have no dependencies on BMX6

h2. Statistics

h2. WPA2 + ADHOC

h2. Iptables Proxy

h2. bmx6 health daemon

 See: http://qmp.cat/issues/155

h2. BMX6/SMS MDNS/Avahi plugin

Avahi (aka Bonjour) is a protocol to announce and share local services within a local network.

This way, home computers connected to the same ethernet link can instantly chat or use each others Multimedia repositories, playlists, streaming.

Therefore each computer announces its services using multicast messages.

The goal is to extend this local service announcements over the mesh network.

The approach is that a mesh router connected to the same link can capture these messages and encapsulate the content in a bmx6 sms message

to be propagated to all other routers in a mesh network.

An other mesh router finally receives this (avahi) service-advertisement sms, decapsulates the content, and retransmits it on its local ethernet/AP network to all home computers/notebnooks.

Read more about this (for olsr) here: http://zioproto.ninux.org/wordpress/2009/04/04/olsrd-mdns-plugin/