Tasks » Historial » Revisió 7
Revisió 6 (Axel Neumann, 02-08-2012 09:10) → Revisió 7/10 (Axel Neumann, 02-08-2012 09:36)
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) C) 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 A 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