Flashing
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
Pau thinks the best would be to create an OpenWRT package named something like "wbm-testbed" with all needed packages as dependences and the custom files/scripts inside. Then it can be use somewere by someone (WBMv1-America?) or re-used in the next WBM.
Subnets
Pau thinks the best approach would be to use different VLANs for each protocol. It is how we are running BMX + OLSR + BABEL in qMp.
For instance, and IPv4/IPv6 scheme would be (EE:FF are four last MAC bytes):
OLSR: 10.0.EE.FF/16 fdfe:aaaa:aaa0:EEFF::/64 BATMAN: 10.1.EE.FF/16 fdfe:aaaa:aaa1:EEFF::/64 BMX: 10.2.EE.FF/16 fdfe:aaaa:aaa2:EEFF::/64 BABEL: 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.
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.
Coordination channels
- Git repository (the battlemesh one can be used)
- Private Mailing list @ninux
- Wiki page with all information (API)
VLANs?
> 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.