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