Hello Vasilis,
cool work. 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 originators.
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 loss which 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).
copied to http://downloads.open-mesh.net/batman/patches/quagga/
Regards, Vasilis
ciao, axel