Re: [B.A.T.M.A.N.] B.A.T.M.A.N. V outlook

["Linus Lüssing" <linus.luessing@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2982 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]