Hi, On Thursday 27 December 2007 13:20, Simon Wunderlich wrote: well yes, and no :-) It's batmand now (as the package name). Thanks for noticing! regards, Holger

Hi, thanks for submitting your work. I published it on our website so that others can find it: https://www.open-mesh.net/batman/patches By the way: Using the TTL as basis for a hop metric is ambiguous and may lead to errors. By doing so you assume that every host uses the same start TTL and every hop decreases it in the same way. The B.A.T.M.A.N. protocol does not demand or enforce this behaviour. On the other hand the hop count does not reflect the quality of a path. May be it would be a better approach to calculate the link quality into the metric so that hop based protocols can do a better decission. Regards, Marek

Στις Monday 31 December 2007 02:01:49 ο/η Acinonyx έγραψε: Hello again, I've fixed a bug in zebra client route update which tried to delete routes with the new metric instead of the previously installed. 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. 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 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. The attached patch is against latest stable BATMAN release (revsion 502). Regards, Vasilis

Στις Sunday 20 January 2008 09:52:41 ο/η Axel Neumann έγραψε: Hello Axel, I would like to use it as primary input for metric calculation. The reason I wrote quagga zebra client is to be able to use B.A.T.M.A.N. as IGP in a BGP Confederation. BGP minimum route advertisement interval is by default 30 seconds and updating route metric more frequently than that isn't necessery. I haven't given this step much thought since I realised that there is no way to compare latency between different originators but I think I could calculate the average latency from an originator and update metrics every x seconds interval (30 secs in my case). In a BGP Confederation, best path selection is based on IGP metric since all the other criteria are always equal. If IGP metrics are also equal, then path selection falls to the rule: 'Prefer the route that comes from the BGP router with the lowest router ID'. This creates a major problem when all metrics are equal because it always favors the selection of paths that come from one specific BGP router. A subnet on an interface flaged as BROADCAST with a prefix length < /32 Best Regards, Vasilis