Hey,

I propose the name "SHLIQ", pronounced sh-lik, kind of like slick, for "Single Hop LInk Quality".

ok, is noted. :)

Thanks, Marek

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.

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.

Regards, Marek

Hello,

we probably did not make this very clear in the document, but we will focus our work on batman-adv (layer 2) and will keep the batmand (layer 3) as it is for now. As a consequence, some ideas for BATMAN V are layer 2 exclusive (mesh bonding, incoming interface based routing).

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.

maybe you do, as you might have costs between the connected network and the connecting batman node.

when you have more then one batman node connecting a network to the mesh, this costs should be relevant.

That might be true, however in batman-adv we are dynamically adding and removing MAC addresses. IMHO, it would not make so much sense to add custom metrics to each mac address. If you need to connect subnets, it might be feasible to use something like BGP and extract batman metrics out of the module.

...

...

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?

Even now, batman-adv is independent. We don't have an IPv6 verson of BATMAN layer 3 however.

best regards, Simon

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

Would you happen to know what the maximum MTU you could use on the wireless interface?

The 802.11 standard says the MSDU size is 2304 octets. How many IP bytes you can fit into this depends on what encryption scheme you are using, which adds different size headers.

However your hardware may not support this, since typically 1500 bytes for Ethernet is what you need to work with. Also, as the packet gets bigger, the more likely it is to get corrupted, and more likely that the retry will also get corrupted etc... If you do increase the frame size to its max, i would suggest enabling RTC/CTS, use 5GHz, and in a mesh network of 2 nodes....

Andrew