[Olsr-dev] OLSRd 0.5.4 and 0.5.5 with ETT available

Erik Tromp (spam-protected)
Thu Feb 21 13:22:11 CET 2008

> Jens Nachtigall wrote:
> > Hence, best way to do it is PacketPair atm, at least for a generic 
> > routing daemon like olsrd that should be working independent of what's 
> > below the IP layer.
> if your target OS does not support what *should* be around, 
> then we could fallback to packet/pairing.
> or let me ask the question in a different way:
> if one OS in the wireless mesh does not support wireless APIs 
> and cannot compute 'good' metrics, why should we squash the 
> rest of the network to that lower limit.

With 'that lower limit' you mean 'use PacketPair'? And with 'squash'
you mean 'force'?

> actually i am more in favor of a reflection of this in the metric.
> if the target OS can do good airtime estimation (by means of 
> reading out wireless stats) its offered links should be more 
> attractive than a link offered by a system that needs to do 
> heuristics.

IMHO, PacketPair is just as much heuristics as ARF.

OLSR is designed as a pure layer 3 protocol. If we rely on
layer-2 information we might as well remove the complete HELLO

Is it ok to conclude that we *need* a PacketPair link metric
estimation (purely layer 3), and that we *would like* to use
any (other) information we can read out the radio layer, if


More information about the Olsr-dev mailing list