Moin Alex,
On Thu, Jan 07, 2010 at 05:10:39PM +0100, Alex Morlang wrote:
Am 07.01.2010 um 14:23 schrieb Marek Lindner:
On Thursday 07 January 2010 15:44:36 Alex Morlang wrote:
are you considering attaching metrics to HNA?
That is not necessary as each non-batman host is connected to a batman host which has a metric. Therefore the implementation just needs to support the HNA metric. The batman daemon does so since quite a long time. It is on the feature list for batman-adv 0.3 but does not require any protocol changes unless I miss your point.
At the moment, every mac address announced by a batman-adv node in the mesh network has the same value. In an open mesh network an evil batman-adv node could do some serious DoS attacks. Therefore it is planned to prefer HNAs from the closest batman-adv node in batman-adv 0.3 instead so that such an attack would be limited to the local area only. As Marek already pointed out, this behavior had already been implemented in batman-daemon (the old layer 3 version) and would probably just need to be ported without any internal batman-adv protocol changes.
maybe you do, as you might have costs between the connected network and the connecting batman node.
In general, batman-adv adds a little header of 24 Bytes. But this kind of extra cost also applies to packets between batman nodes, not only when a packet comes from the connected network. So if you are bridging any other networks/hosts into the mesh network (i.e. bridging eth0 + bat0) does not matter, you should just a) increase the MTU of the mesh-interfaces to 1524 which is usually not a problem for wifi interfaces or b) decrease the MTU on all hosts to 1476 (usually not so do-able).
when you have more then one batman node connecting a network to the mesh, this costs should be relevant.
Hmm, well, batman-adv is adding the HNAs stating the hosts' mac addresses behind a certain batman-node (the bat0 interfaces directly or nodes being bridged into this one) to its originator messages, which get flooded one in a second by default so far. Do the maths how bad that might be for larger mesh networks (keeping the intended packet loss of wifi in mind).
How about ipv6?
I can't follow you here. The length of the protocol identifier (IPv4 address/IPv6 address/mac address/random number) is not relevant for the routing protocol.
ok, i thought you were talking about an implementation, so i asked about support for this addresstype.
so am i right in thinking the next batman will be protocol independent?
batman-adv is operating between layer 2 and 3, you can use ipv6, ipv4, ..., any layer 3 internet protocol you like. And this has already been supperted in previous versions, this won't be a new feature of a batman-adv 0.3 version :).
Regards, Marek
Gruss, Alex
Cheers, Linus