I have some questions:
I've also tried to calculate a metric based on
link quality. Unfortunately,
I wasn't able to find a way to compare latency between two different
Assuming information about the latency is available. I guess you would like to
use it as a secondary input when calculating the metric. Do you know (or have
any feeling) how problematic it can become if the indicated latency for a
given route is changing very frequently (definitely much more often than the
best next hop and related TTL).
Originators could only be compared based on packet
isn't what we want because it would lead to having the same metric (1) for
all nodes if there isn't some packet loss present. So, we are staying for
the moment with the TTL approach with some adjustment to make it safer with
different TTL settings.
I am not familiar with quagga. Why is it problematic to have several routes
with the same metric. Or asked another way: There could also be several
routes (to the same destination) with the same TTL. Why does this problem not
exist in this case?
I also want to point out an issue with batmand host routes and Quagga.
Although Quagga succesfully installs host routes, it doesn't treat them as
valid gateways if the associated interface isn't flaged as P-t-P. I don't
know if this is a bug or a feature but it renders all batmand second level
routes inactive. I added a workaround in zebra client which disables host
route installation. This means that you can use quagga zebra client only if
you have standard broadcast subnets.
what is your definition of a standard broadcast subnet ?
is it "POINTOPOINT,MULTICAST,NOARP,..." and /32 ?
The attached patch is against latest stable BATMAN release (revsion 502).