Tasks » Historial » Revisió 9
Revisió 8 (Axel Neumann, 02-08-2012 10:18) → Revisió 9/10 (Pau Escrich, 02-08-2012 20:18)
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
D) A VPN between qMp nodes is needed to be able to manage them in remote. Tinc seems the best option.
h2. Statistics
There are several statistics systems integrated in OpenWRT (like collectd). But they seems to be too heavy for us kind of devices.
The statistics must be recollected in a central server (in the internet or in the mesh). It can be done using ftp for instance or snmp.
However firewalls can easy block this kind of trafic.
A quick idea is to develop an statistics system based on ICMP packages. The clients each N seconds get the data, encapsulate it in a ICMP packet and send it to the central server.
Any idea is welcome!
h2. WPA2 + ADHOC
Support for WPA2 encryption is now possible thanks to IBSS_RSN. Mac80211 (ath5k/ath9k) has support for it in OpenWRT trunk.
Some characteristics are:
- Broadcast messages are encrypted used the common shared key
- Unicast messages are encrypted using a uniq private token between the nodes
- It is managed by hostapd and wpa_supplicant (or wpad in OpenWRT)
It is very interesting for QMP to secure the backbone mesh network.
h2. Iptables Proxy
The current qMp version is using tinyproxy for captive portal task (or splash screen). However it consumes too much CPU, each new client is a new fork so it does not scale.
A Splash Screen based just on Iptables and a small webserver (uhttpd included in qMp) is possible.
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/