[Babel-users] link costs

[Harald Geyer]

> > 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.
> 
> Interesting -- how do you do that?  arptables?  Could you show your setup?

The brouter setup is pretty much straight forward:

| root at FoneraBridge:/tmp# ebtables -t broute -L
| Bridge table: broute
| 
| Bridge chain: BROUTING, entries: 1, policy: ACCEPT
| -p IPv6 -j DROP

(Luckily we decided to use babel together with v6 - that makes this
kind of stuff rather easy.)
 
But the tricky part is setting a bridge up that works in ad-hoc mode.
I started out with some recent kamikaze, recompiled the kernel with
the bridge-netfilter patch enabled (so that bridged frames go through
arptables) and installed some mac rewriting and arp rewriting rules,
because the ad-hoc mode needs proper source mac addresses to correctly
ACK the frames.

We use this setup on foneras (routers as cheap as 6 EUR), the details
can be found at http://texas.funkfeuer.at/~harald/firmware-0.3/

In case you have some spare fonera and want to try it yourself, you
will need the following files:
fonerabridge-vmlinux.lzma
openwrt-atheros-root.squashfs
bridge-minimal.tgz
0xff-config-bridge_0.3.tgz

I have put quite some effort to make sure that this setup behaves well
in all cases for IPv4, but I never tried to get IPv6 work. For IPv6
I think the brouter setup is all we need.

> >> 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.
> 
> I'm thinking of the latter.
> 
> > 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 way I see it -- /etc/babel.conf is the source of configuration data,
> while the command line is the source of information about actions to be
> taken.  In other words, I'm making a distinction between what needs to be
> done (given on the command line), and how to do it (given in /etc/babel.conf)
> .

I see. But I fear that people will rename some interface, for example
because the tunnel endpoint has changed, change it on the command line
but forget about the config file. I babel handles this gracefully, then
nobody might notice for quite some while ...
 
> But I agree that the distinction might be tenuous -- it might make more
> sense to unconditionally add all interfaces listed in /etc/babel.conf (and
> hence disallow wildcards).  Opinions?

Yes, I think I would prefer this over splitting the configuration in
two parts.

An other possibility would be to have the entire interface configuration
on the command line (similiar to how is now). This would need a rewrite
of the command line parser to allow mixing options and interfaces:
Both would be read from left to right, later options overriding earlier
ones.

Example: babel -c 1 vlan0 -c 256 eth1 -w vlan1
would mean:
vlan0 wireless no (autodetected) cost 1
vlan1 wireless yes (forced) cost 256
eth1 wireless yes (autodeteced) cost 256

I'm not sure if I'd prefer the command line or the config file for
interface configuration: I think route filtering is mostly a matter
of site policy and pretty static while interface configuration
might often be changed. So it might make sense the have it on the
command line. But on the other hand as you add more features to babel,
the command line might become clumsy...

Harald