|
⇤ ← Revision 1 as of 2012-11-16 17:23:22
Size: 3567
Comment: Summary of discussions so far
|
Size: 4548
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| == Flashing == | = 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. |
| Line 3: | Line 4: |
| 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: |
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: |
| Line 10: | Line 10: |
| 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. |
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. |
| Line 15: | Line 14: |
| I guess the best idea would be to get these routers and try it out. We can postpone the decision until then ... |
I guess the best idea would be to get these routers and try it out. We can postpone the decision until then ... |
| Line 18: | Line 16: |
| 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. :) |
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 = 1. '''wbm-testbed''' <<BR>>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. 1. '''wbm-protocols '''<<BR>>It will contain all the protocols. So the protocol developer will need commit perms here. 1. '''wbm-experiments<<BR>>''' 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. https://github.com/battlemesh 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! |
| Line 23: | Line 52: |
| == Packages == | |
| Line 25: | Line 53: |
| 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. |
= Coordination channels = 1. Git repository https://github.com/battlemesh 1. Private Mailing list @ninux 1. Wiki page with all information (API) |
| Line 31: | Line 58: |
| == 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 == 1. Git repository (the battlemesh one can be used) 2. Private Mailing list @ninux 3. Wiki page with all information (API) == VLANs? == |
= Other Stuff = |
| Line 83: | Line 85: |
| Line 92: | Line 93: |
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.