[Babel-users] link costs

[Harald Geyer]

> > a) There are many cases where the automatic detection if an interface is
> > wireless fails. [...] having some way to do this on an per interface
> > basis would be nice.
> 
> Yes, although if Babel is mis-detecting, then you're probably doing
> something wrong, such as running Babel over tunnels over wireless (which
> breaks ETX computation).

Yes, tunnel over wireless are broken - and I don't care what babel is
doing in this case (though setting some high link cost would be nice).

But there are other issues - mostly related with bridge setups:
For example at funkfeuer we have devices that connect to some other
router via cable, but forward all incoming traffic via a wireless
interface - thus acting as a second antenna for the router.
 
But babel thinks it is an wired link because it actually *is* a wired
interface - just using some strange bridge setup. We have this mostly
because olsr is pretty dumb concerning wired links, so we try to
save some hops.

I have solved this special problem by configuring the device as a
brouter (bridging olsr related traffic, routing babel related traffic)
and installing babel on this device too. But the general issue remains.

> > b) Currently the default costs 96 for wired links and 256 for ETX=1 links
> > are hardcoded into the program. In practice I want to set these costs on
> > a per interface basis too:
> 
> Yes, although as you justly note, in most cases you can get away with route
> filtering.
> 
> But I fully agree with you that we need some facilities for per-interface
> configuration.  The issue is designing a suitable user interface; I think
> I've been pretty good at keeping the babel.conf syntax simple and regular,
> and I'd like to keep it this way.

I agree the current syntax is very nice.

> I'm currently thinking of something like
> 
>   interface eth* wireless no cost 128

Would this make babel listen on all interfaces eth*, that it can find
or would babel only listen on those interfaces given on the command
line.

In the latter case it might be a cause of user errors that the
interface configuration is split in two parts, one on the command line,
the other one in the config file...

> The keyword ``interface'' is followed with a shell regexp, which specifies
> which interfaces this clause applies to.  The rest is a sequence of
> keyword/value pairs.
> 
> What are the per-interface properties we need?  I'm thinking of
> 
>   wireless
>   cost
>   hello-interval
>   idle-time
>   idle-hello-interval
>
> Anything else?

This seems to be fine. I think it is rather unlikely that anybody will
optimize the idle-hello-interval on a per interface basis, but who
knows ...

Harald