BattleMesh v6 Firmware
This page describes test firmware and important details for the experiment teams and the mesh network teams. To discuss the tests, please join the test mailing list (link available below).
Contents
Flashing
The idea is to prepare a OpenWRT system with automatic configuration. So a generic image can be installed in all devices and the there is not configuration needed.
Maybe we can use ap51-flash to do that. It does not seem to have support for that kind of operation yet, but supports a few other APs with TFTP image support [1]. This would speed up the process a lot:
- plug ~50 routers in a switch, and one laptop with ap51
turn them on at the same time and see the pretty flash LEDs blinking
- done after ~3 minutes
AP51-flash has its own ARP/TFTP implementation, so IP address collisions are not a problem. We have used it for other mass-flash purposes as well.
[1] http://dev.cloudtrax.com/wiki/ap51-supported-devices
I guess the best idea would be to get these routers and try it out. We can postpone the decision until then ...
BTW, if ap51-flash would be theortically possible but doesn't support the platform yet, we can ask Marek to help us on that. He is maintaining ap51-flash any way and has offered his assistance.
Packages
wbm-testbed
This package will include a set of dependencies needed for the WBM testbed such as ping, mtr, iperf and so on. And also the scripts to autoconfigure the node.wbm-protocols
It will contain all the protocols. So the protocol developer will need commit perms here.wbm-experiments
A set of prepared experiments to run during the battle Mesh.
These three packages will be created and maintained in the BattleMesh GitHub, so if someone wants to contribute he/she should just ask for participation.
The good point of making standalone packages is that it can be used in other places/events or re-used in the next WBM.
Subnets
I think best approach would be to use different VLANs for each protocol. Then they are layer2 isolated.
The IPs are autoconfigured according to the MAC address.
For instance, and IPv4/IPv6 scheme would be the next (EE:FF are two last MAC bytes):
OLSR: VLAN1 10.0.EE.FF/16 fdfe:aaaa:aaa0:EEFF::/64
BATMAN: VLAN2 10.1.EE.FF/16 fdfe:aaaa:aaa1:EEFF::/64
BMX: VLAN3 10.2.EE.FF/16 fdfe:aaaa:aaa2:EEFF::/64
BABEL: VLAN4 10.3.EE.FF/16 fdfe:aaaa:aaa3:EEFF::/64
The tests can be performed sequentially or in parallel, it would depend on the kind of experiment. However all nodes must be always reachable using all protocols.
Autoconfiguration
Write a small system to leave nodes auto-configure their IP addresses. So no DHCP nor SLAAC is needed. Just install firmware and spread nodes.
All entropy we have is the "random" MAC address. So the nodes should configure itself according to it. As seen in subnets section the IP address is calculated using such MAC address.
This script is only executed the first boot!
Coordination channels
Git repository https://github.com/battlemesh
- Private Mailing list @ninux
- Wiki page with all information (API)
Other Stuff
> Ah, vlan support can be tricky, hardware switch in tl-mr3220 for example > > doesn't play properly. We should confirm the buffalo's do. > > > Mmm, I'm not sure if we are speaking about the same kind of VLAN. I'm not > referring to layer1 (port switching) but to layer2 (VLAN tags in MAC > header). So in theory the physical switch from the routers have nothing to > do with it. > To make it clear, we will have: > - wlan0.1 > - wlan0.2 > - eth0.1 > - eth0.2 > The first protocol will run in .1 devices, the second in .2, and so on. There are some devices which have troubles with VLAN on Ethernet, because VLAN is also used internally for port switching - so if you have a "real" VLAN on a specific port, in hardware you'd end up with VLAN in VLAN, which is not supported by some hardware. ... Pau said: But in such case you can disable the port switchuing and that's it, no? Simon said: If the hardware is still usable then, yes. Have to test. :)
> The VLAN approach can be very interesting because we are layer-2 isolating > the protocols. > We have more control over what are we sending through the protocols. We can > see, for instance, the amount of data sent by protocol X just looking the > interface description. > They are actual virtual interfaces, also from the kernel point of view! > adhoc + vlan works fine. We are using it in qMp.
Analyzing
to see some information about that network you can use following commands:
ip -6 route show uptime ifconfig