In fact, it's just: ====A....B-----
A solution I see might be to modify babel itself to give it more control over these external routes. I was hoping babel-pinger would help manage this but now I more fully understand what it does and this is not it's role. I started writing a script to replace babel-pinger. On B, it would try to ping A's connection and if it exists it would delete the default route and set the default route towards A. I have not tested this thoroughly, it may cause a routing loop if A is trying to use B's connection. Another solution similar to your solution would be to use a node, C out side somewhere on the internet and create tunnels from A to C and B to C and run babel on all 3 nodes: C===A...B----C (where C is the same machine, somewhere on the internet with good bandwidth in and out) Michael On Thu, Nov 5, 2009 at 19:19, Juliusz Chroboczek <[email protected]> wrote: > Oh, I see. > > Basically, you've got the following topology: > > === A ... B ... C --- > > where === and --- are external (wired) routes, and ... are wireless > links controlled by Babel. > > Now what you can easily do is select which route B will prefer, since > B's routing tables are under the control of Babel. What is more > difficult is controlling which route will be taken by C, since the route > taken by C is under control of an external agent (DHCP, Babel, whatever). > > I really don't see a good solution that doesn't require modifying the > DHCP server on C. A workaround would be to move C into the Babel > network by adding a new node C': > > ==== A ... B ... C . C' --- > > where C' routes through the slow ADSL line, and C chooses between B and > C' using Babel. > > Juliusz > > _______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/babel-users
