[Babel-users] Welcome to the babel-users mailing list
Dear all,
Welcome to the babel-users mailing list.
This list is mainly for discussion of the Babel routing protocol and
the babel sample implementation. You are welcome to use this list for
discussing other issues related to mesh networking and to IPv6, such
as the AHCP autoconfiguration protocol, the experimental Babel network,
or your favourite community network.
I intend this to be mostly an English language list. Please try to
avoid posting in French, unless you're discussing purely local matters.
For subscribers, this is an unmoderated list. If you send mail from
an address different from the one you subscribed with, your mail will
go through a moderation process.
Resources:
The babel sample implementation:
http://www.pps.jussieu.fr/~jch/software/babel/
The ahcpd autoconf daemon:
http://www.pps.jussieu.fr/~jch/software/ahcp/
The experimental Babel network:
http://wifi.pps.jussieu.fr/
A description of the Babel protocol is in the works, and is available
on demand.
Juliusz Chroboczek
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Testing...
Sorry, just a test. pgpfTcwFwNy7f.pgp Description: PGP signature ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] News from wifi.pps.jussieu.fr
The Babel network is now routed natively once again. 64 bytes from alpha.wifi.pps.jussieu.fr: icmp_seq=1 ttl=63 time=2.65 ms Juliusz pgp0w54UvPhQT.pgp Description: PGP signature ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Welcome to the babel-users mailing list
Dear all,
Welcome to the babel-users mailing list.
This list is mainly for discussion of the Babel routing protocol and
the babel sample implementation. You are welcome to use this list for
discussing other issues related to mesh networking and to IPv6, such
as the AHCP autoconfiguration protocol, the experimental Babel network,
or your favourite community network.
I intend this to be mostly an English language list. Please try to
avoid posting in French, unless you're discussing purely local matters.
For subscribers, this is an unmoderated list. If you send mail from
an address different from the one you subscribed with, your mail will
go through a moderation process.
Resources:
The babel sample implementation:
http://www.pps.jussieu.fr/~jch/software/babel/
The ahcpd autoconf daemon:
http://www.pps.jussieu.fr/~jch/software/ahcp/
The experimental Babel network:
http://wifi.pps.jussieu.fr/
A description of the Babel protocol is in the works, and is available
on demand.
Juliusz Chroboczek
pgpRcn6uxGJ04.pgp
Description: PGP signature
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Un autre test...
Sorry for that -- there are some minor issues with the list archives. Juliusz pgpddz0f46v9P.pgp Description: PGP signature ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Bug in ahcpd: tunnel interfaces not handled correctly
There's a bug in ahcpd -- it won't work correctly if the first interface you pass on the command-line doesn't have a MAC-48 address, e.g. if it's a tunnel. An IPv6 address will be autogenerated, but it won't be removed when you kill ahcpd. As a workaround, make sure that the first interface you pass to ahcpd is a hardware interface, e.g. ahcpd wl0 tun0 or remove the address manually after killing ahcpd. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Babel news...
Hello to all, I've spent much of the last two nights looking at packet traces, hacking babel and playing with OpenVPN and OpenWRT. The results are as follows. Requests for a new seqno are partially implemented -- they are properly parsed, forwarded towards the source, but the reply is not forwarded speedily enough, and lost requests are never resent. What that implies is that the protocol definition is now complete -- I'll re-read it, and put it on the web. Babel is now a little more aggressive when sending hellos to a newly discovered neighbour. Taken together, these two new features make converging on a new route when the old one is lost dramatically faster. You can get my head version by doing darcs get http://www.pps.jussieu.fr/~jch/software/repos/babel/ or, if you haven't got darcs, wget -r -l1 -nH --cut-dirs=3 http://www.pps.jussieu.fr/~jch/software/repos/babel/ OpenVPN basically works, but I haven't found yet how to build a multi- point tunnel with it; in other words, to have multiple clients speaking to a single server. Until I find that out, there's no point trying to build our network using OpenVPN. I've managed to build an OpenWRT config that automatically works as either a normal Babel peer or an OpenVPN client and Babel peer; this was somewhat tricky, due to ntpd not noticing new interfaces and new routes until you restart it, and the OpenVPN daemon refusing certi- ficates when the time is not set correctly (sigh). I needed to make a fair number of small changes to the OpenWRT scripts, I'll get in touch with Florian and Nico over the week-end to try to get them merged into the OpenWRT trunk. That's all for now. I need a nap. Juliusz P.S. This mail is brought to you by a Babel node. Merci, Gabriel. ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Babel protocol now online
A description of the Babel protocol is now on-line; it's linked from the Babel page. Please delete any preliminary versions of the protocol description that you may have. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Babel protocol now online
> Je lirais la spec complète plus tard car le domaine jussieu.fr ne semble > pas routé depuis free.fr :-( Le routage IPv4 vers Jussieu est réparé. Cette fois-ci, le routage IPv6 n'a jamais cessé de fonctionner ;-) Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Babel news
I've started implementing the support for multi-hop requests in Babel. It's slightly incomplete right now -- multi-hop requests should be correctly sent and forwarded, but replies are not forwarded yet, and lost requests are not resent. The new version is installed on huponomos, alpha, beta, and pirx. Feel free to give it a spin, darcs get http://www.pps.jussieu.fr/~jch/software/repos/babel Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Forwarding of replies implemented
Forwarding of both requests and replies is now implemented (Section 2.5 of the protocol spec). The code is in the darcs tree, and installed on alpha, beta and huponomos. It's completely untested, expect it to break. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] ANNOUNCE: Babel 0.5
Dear all, Babel 0.5 is now available from http://www.pps.jussieu.fr/~jch/software/files/babel-0.5.tar.gz http://www.pps.jussieu.fr/~jch/software/files/babel-0.5.tar.gz.asc This version adds (finally) forwarding of requests and of replies to requests; reconvergence after a route loss should be on the order of 250 ms per hop. Reemission of lost requests is not implemented yet, performance will remain poor in the presence of very lossy links. Juliusz 9 October 2007: babel 0.5 * Implemented forwarding of requests and replies. * Fixed a bug that prevented requests from being parsed correctly. * Fixed a bug that prevented IHU intervals from being sent. * Respect reboot_time even after an id change. * Deal with neighbours rebooting and losing their hello seqno when computing link quality. pgpiFkv9ATOfy.pgp Description: PGP signature ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Babel-aware tcpdump
Thanks to Grégoire Henry, there is a Babel- and AHCP-aware version of tcpdump in http://www.pps.jussieu.fr/~jch/software/files/tcpdump-babel-20071009.patch A Debian/x86 package is available in http://www.pps.jussieu.fr/~jch/software/files/tcpdump_3.9.8-1j_i386.deb Juliusz pgpTuVjDC6QX9.pgp Description: PGP signature ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Babel news
Thu Oct 11 21:19:07 CEST 2007 Juliusz Chroboczek <[EMAIL PROTECTED]> * Implemented resending of requests. Thu Oct 11 21:01:46 CEST 2007 Juliusz Chroboczek <[EMAIL PROTECTED]> * Don't check recorded requests for unspecified prefix. We'd check recorded requests for a null prefix, which caused a crash. Thu Oct 11 21:00:22 CEST 2007 Juliusz Chroboczek <[EMAIL PROTECTED]> * Avoid reading freed memory. Le deuxième, notamment, explique probablement pourquoi j'ai dû relancer Babel à plusieurs reprises sur beta. Julien, si t'as le temps de relire ça avant que je fasse une release, ce sera cool. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] ANNOUNCE: babel-0.6
Dear all, I've just put babel-0.6 in http://www.pps.jussieu.fr/~jch/software/files/babel-0.6.tar.gz http://www.pps.jussieu.fr/~jch/software/files/babel-0.6.tar.gz.asc For more information about the Babel routing daemon, please see http://www.pps.jussieu.fr/~jch/software/babel/ This version implements resending of lost requests; reconvergence after moving into an area with no connectivity should now take 250 ms per hop on average (after the link quality is estimated). It also fixes a rather nasty crash that would only happen on week-ends, with a full moon, and only on diskless machines that don't have a debugger and don't generate core dumps. Enjoy, Juliusz 16 October 2007: babel 0.6 * Implemented resending of unsatisfied requests, with exponential backoff. * Fixed a potential crash in the request handling code. * Send IHUs more aggressively. pgpAQAMDjKoyT.pgp Description: PGP signature ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Routing table right now...
After upgrading the backbone to Babel 0.6, the experimental network is stable again. Here's the routing table on Huponomos: http://www.pps.jussieu.fr/~jch/software/babel/table-huponomos-20071016.text Huponomos is the network's hub, with alpha and beta hanging off it. It has two VPNs, one to Gamma (an access point in the fifth arrondissement), and one to Thus's mesh. It looks as so: alpha-beta 914e 1502 \/ \ / \/ huponomos /\ / \ /\ gamma Thus As you can see from the routing table, huponomos and alpha have routes to the Internet, there's one node hanging off alpha, and Thus's mesh has four nodes. Gamma is dead, it doesn't appear in the routing tables right now. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Babel protocol: about undoing history
I've just received (by PM) a request for clarification of section 2.2.1 of the Babel spec: When a hello is received, its sequence number is compared with the next expected sequence number for this neighbour. If the sequence number of the received Hello is higher than expected, then one or more Hellos have been missed. If the sequence number is lower, then this neighbour decreased the Hello interval without us noticing, and part of the history must be undone. In order to avoid undoing history, a node SHOULD always send a Hello immediately after increasing its periodic Hello interval. Suppose that peer A has a hello interval of 1s. At time t=0, it sends a hello with sequence number 0. Its neighbour B expects it to send a hello with sequence number 1 at time t=1. Now suppose that after sending the hello with seqno 0, A decides to increase the hello interval to 10s. At time t=1, B decides a hello was lost; at time t=9, B decides 9 hellos were lost. At time t=10, it expects a hello with seqno=10, but instead it receives a hello with seqno=1, which causes it to conclude that the loss was spurious, and that actually no hellos have been lost. Hence, the loss history must be undone. In order to avoid undoing history, this section recommends that a peer should only change its hello interval *before* sending a hello; or, equivalently, that a hello should be sent whenever the hello interval changes. This avoids undoing history when there is no packet loss. Of course, in presence of packet loss, all bets are off. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] ENOBUFS on the netlink socket
> using babel from Oct 11th, I just got this message: > netlink_read: recvmsg(): No buffer space available > which sounds weird. > Any idea what might have caused this? According to the docs, it means that the kernel had more than a socket buffer worth of changes to communicate at a time. We should deal with that gracefully if somewhat brutally (we close the netlink socket, reopen it, and request a full table dump), but I'd be more comfortable if Grégoire could confirm that. If you see it again, I'll see if I can increase the socket buffer size. What's your value of /proc/sys/net/core/rmem_default ? rmem_max ? Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] ahcpd and babel dying on huponomos
> ahcpd and babel are dying with EINVAL on
> setsockopt(IPV6_ADD_MEMBERSHIP), because they call this on
> interfaces with no address (namely the vpn interfaces).
That's the expected behaviour if the interfaces have no link-local
address yet. This shouldn't happen if they do have one.
> I don't think that should be a fatal error
I guess I could sleep(1) and try again... but I'd rather clarify the
issue.
> (it works again after restarting openvpn, but.).
Hmm, there could be a race condition somewhere. Have a look at
/etc/openvpn/up.huponomos, which does the following:
ip -6 addr add "$addr"/64 dev ${interface}
notify ahcpd and babel of the new interface
/etc/init.d/babel stop
/etc/init.d/ahcpd stop
sleep 1
/etc/init.d/ahcpd start
/etc/init.d/babel start
As far as I can tell, there's no race condition in the above, but
I may be mistaken.
Juliusz
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Symptoms of multiple simultaneous instances
Hi, The babel daemon does not currently protect itself against being run multiple times. If you see your network converging than diverging again immediately after that, you've probably got multiple Babel instances running on a single machine. I'll make sure in a future version that you cannot run multiple Babel instances on a single machine; for now, you've just got to be careful. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] ANNOUNCE: ahcpd-0.3
Dear all, Ahcpd-0.3 is now available from http://www.pps.jussieu.fr/~jch/software/files/ahcpd-0.3.tar.gz http://www.pps.jussieu.fr/~jch/software/files/ahcpd-0.3.tar.gz.asc For more information about AHCP, the all-dancing, all-singing autoconfiguration protocol for IPv6 mesh networks, please see http://www.pps.jussieu.fr/~jch/software/ahcp/ Minor tweaks mostly in this version, notably the ability to hook into the autoconfiguration process by running a script /etc/ahcp/ahcp-local.sh. I'm using this to integrate ahcp with OpenWRT's hotplug system. Juliusz 28 October 2007: ahcpd 0.3 * Moved user-serviceable parts to /etc/ahcp/ * Added support for configuring an NTP server. * Made ahcp print warnings when a clock inconsistency is detected. * Fixed error handling when the configuration script dies unexpectedly. pgpzJrCaJSxrb.pgp Description: PGP signature ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] ahcpd and babel dying on huponomos
>> ahcpd and babel are dying with EINVAL on >> setsockopt(IPV6_ADD_MEMBERSHIP), because they call this on >> interfaces with no address (namely the vpn interfaces). > That's the expected behaviour if the interfaces have no link-local > address yet. This shouldn't happen if they do have one. It happened again. Apparently, OpenVPN does something that causes the link-local interfaces to disappear. Restarting OpenVPN, ahcpd and Babel (in this order) fixes it. I don't have time to investigate further right now, but the problem is definitely with OpenVPN, not with Babel. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] ahcpd and babel dying on huponomos
> It happened again. Apparently, OpenVPN does something that causes the > link-local interfaces to disappear. Restarting OpenVPN, ahcpd and > Babel (in this order) fixes it. > I don't have time to investigate further right now, but the problem is > definitely with OpenVPN, not with Babel. I've just added the ``up-restart'' option to all of the VPNs' config files. Let's see if it helps... Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Babel and IPV4
[ Replying to the list, with the OP's permission. ] > what would it take to implement IPV4? There's basically nothing in Babel itself that is fundamentally linked to IPv6. The main reason for using IPv6 rather than IPv4 for the initial development was simply that it is easy to get a /64, while getting just a /24 in IPv4 would be politically challenging. Other than that, the APIs are more portable (especially when dealing with multicast traffic), and that the unconditional presence of link-local addresses makes certain things easier (notably dealing with unnumbered links). Now, however, the time has come to think about IPv4. I can see three ways to do that: 1. Implement a purely IPv4 version of Babel, that would be run in parallel to the IPv6 version; 2. Make Babel a hybrid protocol, similar to multi-protocol BGP. The routing traffic would still be carried by IPv6 packets, but they would announce both IPv4 and IPv6 prefixes. 3. Only route IPv6 natively, and use tunnels for IPv4. (1) is the natural approach; however, it almost doubles the routing traffic, and causes a number of issues (such as finding a suitable multicast group for IPv4 Babel). (3) has the advantage of allowing the use of multiple unsynchronised NAT gateways on a single Babel mesh; however, it suffers from the overhead of tunnelling; more generally, tunnelling has bad press (wrongly or rightly) in the routing community. My current preference is therefore (2). The basic idea is to encode the (link-local or global) IPv4 address of a node either in HELLO messages, in the Babel packet header, or in an ad-hoc message. I'm thinking of simply reusing the same message type for IPv4 prefixes, and simply encode them as IPv6-mapped addresses, rather than defining a new message type. So I do have a fairly clear plan of how to proceed, I just need to take a few days to implement it (and this is a rather busy time). Let me know if you want to help. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Babel and IPV4
>The routing protocol would be IPv6 to IPv4 tunnel aware. I'm not sure tunnelling belongs in the routing daemon (and yes, I know that early versions of mrouted used to implement tunnelling). I think it is better done in a different program, or natively at the kernel level. Of course, Babel has no issues routing across tunnels. > The routing protocol would discover and keep track of IPv6 to IPv4 > gateways where tunnels are available, No, that's a different protocol (route autoconfiguration), no need to clutter the routing protocol with that. > I'm part of a small 70 family wireless coop that is considering deploying > a mesh in support of an exisiting Motorola Canopy network. Where are you? > The 800Mhz Canopy Hmm... has the 800 MHz band been made license-free in the US while I wasn't looking? > There will be some members that do not have LOS to a Canopy AP that are > 802.11 only, when near multiple Canopy members with a stable local mesh. > > We would also add 802.11 at selected Canopy Access Point sites, and replace > the switches at the AP sites with a mesh router to allow redundant soft > failover for the Canopy using 802.11 as a backup or alternate route. Yes, all of this sounds like the perfect application for Babel: your network is mostly static and to a great extent sparse, so Babel will be much more efficient than olsr. Obviously, we need to implement the IPv4 support before Babel can be useful for you. I know I'm going to be very busy until the middle of next week. I'll let you know when I implement something. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Filtering
I'm slowly starting to work on a filtering infrastructure for Babel, and I'm wondering what kind of filter predicates are needed. I'm thinking of starting with gated's filtering language, http://madhaus.utcs.utoronto.ca/gated/config_guide/filter.html removing some features, and adding filtering by router id both of the route originator and of the next hop neighbour. This is so that you can, say, avoid routing through a router that you don't like, or choose the internet gateway that you use. Do people have any better ideas? I'm not just doing that for the fun of it -- filtering is a necessary prerequisite for IPv4 support. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Filtering
> I'm thinking of starting with gated's filtering language, > > http://madhaus.utcs.utoronto.ca/gated/config_guide/filter.html After more thought, Zebra's filtering language might be a better choice, since it's based on CIDR notation: http://www.quagga.net/docs/docs-multi/IP-Prefix-List.html Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Filtering
>> [...]removing some features, and adding filtering by router id both of the >> route originator and of the next hop neighbour. > When you talk about "router id", it remembers me : "WISPr" or "NAS-ID". > It's not directly relevant to your question, but perhaps there could be > some things you can use for the router identification ? Every router already has a router ID in Babel -- it's used for loop avoidance. I'm simply speaking of using the same filtering language as Cisco and Quagga, but adding the ability of banning routers by router-id. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Babel: news about IPv4 support
Dear all, Since this list has been somewhat silent for the last weeks, this is a good time to tell you about the work going on. I've started working on an IPv4 extension to Babel. The idea is to keep Babel packets within IPv6, but allow it to distribute IPv4 routes, somewhat in the manner of multi-protocol BGP. The protocol extension is undocumented. A new packet type, type 5, is used for IPv4 addresses, and carries both the IPv4 prefix and the IPv4 next hop; the originating router id is carried by a preceding update message (type 3), just like for IPv6 prefix messages (type 4). Internally, IPv4 prefixes are encoded as IPv6-mapped addresses. Next hop information is added to the routes. (This is one of the three designs that I considered, and it is by far the cleanest and the simplest.) The work is almost complete, but the kernel support is missing. Very little has been committed at this time, I hope to be able to publish the code over the Christmas holidays. There is some other unpublished work going on, but since I haven't asked the people doing it for permission to announce it, I'll keep silent for now. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] ANNOUNCE: experimental IPv4 code
Dear all, An experimental version of IPv4 support for Babel is in my Darcs repository, http://www.pps.jussieu.fr/~jch/software/repos/babel This code is almost completely untested; it may work, but it will most probably segfault, cause your computer to crsh, your printer to jam, your wife to leave you, your daughter to join Microsoft and your son to vote for Sarkozy. This warranty is void in case of nuclear war, whether caused by Babel or otherwise. The IPv4 support is disabled by default. You enable it by running Babel with the ``-4'' command-line flag. Unlike IPv6, the Linux IPv4 stack doesn't support unnumbered links. SInce AHCP can't number IPv4 links yet, you will need to manually add an IPv4 address to every interface you want to route IPv4. However, you may add the same address to every interface -- nothing prevents you from having the same IPv4 address on your wired interfaces, on your wireless ones, and on your tunnels. Babel should automatically detect which interfaces have an IPv4 address, and will only participate in IPv4 routing on those. For example, suppose that your IPv6 address is 2001:0DB8::dead:beef, while your IPv4 address is 192.168.05.68, and that you want to run Babel on eth0 and wl0. Then you should do something like ifconfig eth0 192.168.05.68 up ifconfig wl0 192.168.05.68 up ip -6 addr add 2001:0DB8::dead:beef/128 dev eth0 babel -4 -X 192.168.05.68 0 -X 2001:0DB8::dead:beef 0 eth0 wl0 Note that in this example, wl0 has no global IPv6 address, but has to have an IPv4 address. An important caveat: -x won't work yet. Please use -X for now. The Mac OS X code is incomplete (it probably won't even compile). In order to bring the Mac OS X code to the level of the Linux code, somebody will need to modify kernel_route and add code to kernel_setup to enable IPv4 forwarding. Finally, in order to make -x work, kernel_routes and kernel_callback will need to be modified to return IPv4 routes in addition to IPv6 ones. Regards, Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] IPv4 updates
Under Linux, -x now works for IPv4 routes -- in other words, IPv4 and IPv6 have the same level of support. As to the network at P7, only small bits of it route IPv4 right now (huponomos, gamma and pirx). I'll expand the IPv4 coverage when I implement filtering and support for multiple routing tables, and decide on a firewall policy. Thus, Gabriel, let me know if you want me to route IPv4 on the tunnels you have to huponomos. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] ANNOUNCE: babel 0.7
Release 0.7 of Babel, the all-dancing, all-singing routing daemon for IPv6 and IPv4, is available from http://www.pps.jussieu.fr/~jch/software/files/babel-0.7.tar.gz http://www.pps.jussieu.fr/~jch/software/files/babel-0.7.tar.gz.asc For more information about Babel, please see http://www.pps.jussieu.fr/~jch/software/babel/ The main news in this version is support for IPv4 (Linux-only, for the moment). A number of bugs have been fixed, notably the incorrect encoding of unicast route requests (silly me). The complete changelog is appended. Juliusz 3 January 2008: babel 0.7 * Implemented support for IPv4. * Fixed sending of unicast requests. * Don't send poison when receiving a request for an unknown route. * Basic filtering infrastructure. * Removed support for broadcast IHU. * Changed the behaviour of -d. pgp6qvfl7ZEwd.pgp Description: PGP signature ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] ANNOUNCE: babel 0.7
Hi Florian, > We can probably make a presentation of it with France-Wireless at > Solutions Linux in end January ? I'd love to -- but I'll be abroad from the 18th until the end of the month. Sorry for that. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Babel and bridged interfaces
As you probably know, Babel tries to automatically detect whether an interface is wired or wireless, and uses a more economic algorithm for determining link quality on wired interfaces. The wireless algorithm works well on wired interfaces, but the wired one won't work well (or at all) on wireless interfaces. This behaviour fails in one significant case, when people run Babel on bridged interfaces, which Babel detects as wired interfaces. According to the (private) e-mails I'm getting, this is particularly common on OpenWRT systems, where eth0.0 and wl0 are bridged by default. I do not recommend running Babel on bridged interfaces, since the inverse multiplexing caused by the bridge removes some information, and prevents Babel from dropping the hello interval. It is better to remove the bridge and run Babel separately on the underlying interfaces. (Of course, this is not possible if you need to forward broadcast traffic between interfaces.) On OpenWRT, you will need to edit /etc/config/network, so that it looks something like config interface lan option ifname "eth0.0" option proto static config interface wan option ifname "eth0.1" option proto static config interface wifi option ifname "wl0" option proto static In a future version, I'll try to detect bridged interfaces and run the wireless algorithm on them by default, and provide a means to configure the algorithm used on a per-interface basis. If you have any better ideas, I'm interested. Regards, Juliusz P.S. I prefer correspondence about Babel to go to the list, rather than to me personally. ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Babel and bridged interfaces
> We could probably tune a bit the init script to make it run on each > member of the bridge for instance. This would avoid adding bridge > detection to babel, which seems to be an OpenWrt specific > problem/feature. I'm not sure how well that would work; I'm afraid that we'd confuse the bridge by running on the underlying interfaces. The simple work-around is to simply run the wireless algorithm on bridge interfaces, as that will work in all cases. Of course, it will generate somewhat more traffic on your Ethernets, but since it's still just one packet every 6 seconds (as opposed to one packet every 30 seconds with the wired algorithm), it should remain bearable. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Disable wired optimisations
I've just added a new flag, -w, to Babel, which can be used to disable the optimisations for wired networks. If Babel is invoked with -w, it will use the wireless algorithm on all interfaces, which means that: - the hello interval will not be increased; - link quality information will be performed normally; - split-horizon will be disabled. This flag is recommended if you're running Babel on bridge interfaces with an underlying wireless interface. In any case, it won't do any harm, except slightly increasing the amount of traffic on wired interfaces. This is completely untested, so feedback would be appreciated. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Disable wired optimisations
>> I activated it (I almost always use babel over a wireless interface) and >> I'll let you know if it solves the issue I had when using Babel over >> OpenVPN (ie. freeze after some time). > Nope, I still get the connection freezing from time to time. The tunnel > seems to stay up, I can see some packets with tcpdump, but I have no > default route (and no DNS by the way). Can't explain it... No, that's a different issue. My scripts on huponomos are buggy somewhere -- they're supposed to restart babel and ahcpd after the OpenVPN daemon creates a new interface, but for some reason they stop the daemons but fail to restart them sometimes. The long-term solution is to have Babel react automatically to changes in link status; I've done some work in that direction, but not enough. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Bug with multiple neighbours
There was a bug that could spuriously remove IPv4 routes if you had multiple neighbours with small metrics (diagnosed by Julien Cristau, to whom thanks). I've just fixed it in the Darcs repository, so please upgrade if you're using IPv4. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] IPv4 sur le réseau Babel
[This is about the configuration of IPv4 on the experimental network, here in Paris. Since it's a purely local matter, I'll write in French.] Je viens de mettre en place du IPv4 sur le réseau Babel, sur le préfixe 192.168.4.0/24. Tout se passe comme vous l'imaginez, avec une petite subtilité: pour distinguer le traffic local de huponomos du traffic forwardé par celui-ci, je mets les routes babel dans une table de routage non-défaut: [EMAIL PROTECTED]:~$ ip rule show 0: from all lookup local 100:from 192.168.4.0/24 lookup 8 101:from all to 192.168.4.0/24 lookup 8 32766: from all lookup main 32767: from all lookup default [EMAIL PROTECTED]:~$ ip route show 134.157.168.0/25 dev eth0 proto kernel scope link src 134.157.168.121 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.28 default via 134.157.168.126 dev eth0 [EMAIL PROTECTED]:~$ ip route show table 8 192.168.4.25 via 192.168.4.26 dev beta proto 42 metric 21 onlink 192.168.4.26 via 192.168.4.26 dev beta proto 42 metric 21 onlink C'est un peu bancal, mais ça marche. Si vous avez une meilleure idée, je vous écoute. Pour le moment, ce n'est pas très utile, comme personne n'importe une route par défaut IPv4 (il faudrait mettre en place un NAT et une politique de sécurité, ce qui n'est pas vraiment le genre de chose qui m'amuse). Cependant, si vous voulez essayer, 1. demandez-moi de vous affecter une adresse IPv4 dans 192.168.4.0/24; 2. ajoutez le fichier /etc/ahcp/ahcp-local.sh qui contient un truc du genre #!/bin/sh case "$1" in start) for i in $AHCP_INTERFACES; do ip addr add 192.168.4.toto dev $i done ;; esac 3. ajoutez un fichier /etc/ahcp/ahcp-babel-options qui contient -4 -X 192.168.4.toto 0 Je sais, c'est un peu lourd; la solution, c'est l'autoconf IPv4 dans ahcpd. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] ANNOUNCE: Babel 0.8
Dear all, Babel 0.8 is now available from http://www.pps.jussieu.fr/~jch/software/files/babel-0.8.tar.gz http://www.pps.jussieu.fr/~jch/software/files/babel-0.8.tar.gz.asc This version fixe a serious bug that would sometimes spuriously discard perfectly good IPv4 routes in dense networks. It also adds support for non-default routing tables, and makes IPv4 operation more robust by checking for changes in IPv4 addresses. Finally, it adds an option to disable a number of optimisations specific to wired networks for people who insist on bridging wired and wireless interfaces together. Enjoy, Juliusz 8 February 2008: babel 0.8 * Babel will now automatically check for interfaces' up/down status, IPv4 address, and optionally for carrier sense. * Implemented the -w option, which disables all optimisations for wired interfaces. * Implemented support for non-default routing tables. * Fixed a bug that could spuriously remove IPv4 routes (thanks to Julien Cristau). pgpNrIfI9QVc7.pgp Description: PGP signature ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Babel now has a proper configuration language
Dear all, I've just committed into the Darcs repository a version of Babel that uses a proper configuration language to specify input, output filters and redistribution policies. It needs more testing, but appears to work. Incompatible changes: the flags -x, -4 and -c no longer exist, they're subsumed by the configuration language. Configuration directives can be specified in /etc/babel.conf, or on the command line using the -C flag. It's completely undocumented right now, but here are a few examples: - refuse to participate in IPv4 routing: in 0.0.0.0/0 deny out 0.0.0.0/0 deny - I'm short on battery, advertise routes with an artificially higher metric: out metric 256 - the interface eth1 is slow, avoid routes going through it unless there's no better alternative: in if eth1 metric 256 - redistribute the default IPv6 and IPv4 routes: redistribute ::/0 le 0 metric 128 redistribute 0.0.0.0/0 le 0 metric 128 - redistribute all routes from Quagga (IPv4 and Iv6): redistribute proto 11 metric 128 - reject any routes from a neighbour with router-id ::dead:beef: in neigh ::dead:beef deny - reject any routes originated by the router ::dead:beef: in id ::dead:beef deny For those of you concerned about embedded systems, it's a hand-written parser, and takes some 1300 bytes of code. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Some news about the wifi.pps network
Dear all, Julien and I spent much of last night setting up a NAT-ed IPv4 default route (and a fascist firewall to go with it) on the wifi.pps network. Since the routing policies on the NAT box and on Huponomos become somewhat baroque with this addition (you don't want to mix up native routing with the routing of the NAT-ed network), the filtering language got a fair amount of exercise, and appears to be working flawlessly. However, I haven't tested all of its features exhaustively yet. I found a fairly serious bug in the IPv4 routing code, fortunately introduced after the 0.8 release. If you're running from the Darcs repo, please upgrade. We put the network through some moderately serious load (as in upgrading two Debian laptops simultaneously from IPv4 archives), and nothing unexpected happened. While I was at it, I did some more expermients with reconvergence times after a mobility event, and they are roughly as expected -- the network reconverges almost immediately after the link quality estimate has been completed. So it appears that I didn't break anything in that area. Next step: add IPv4 autoconf to ahcpd. I've got a cunning plan, but no ETA yet. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] ANNOUNCE: Babel 0.9
Dear all, You will find version 0.9 of the Babel routing daemon on http://www.pps.jussieu.fr/~jch/software/files/babel-0.9.tar.gz http://www.pps.jussieu.fr/~jch/software/files/babel-0.9.tar.gz.asc For more information about Babel, please see http://www.pps.jussieu.fr/~jch/software/babel/ This version implements a proper configuration language that allows fine-grained specification of input, output and redistribute filters. The flags -4, -x and -c are no longer supported (their functionality is subsumed by the filtering language), so please update your scripts. Enjoy, Juliusz Chroboczek 14 February 2008: babel 0.9 * Implemented a proper configuration language to specify input and output filters and redistribution policies. * Incompatible change: the flags -4, -x and -c are no longer supported. pgpUQOayb6BiC.pgp Description: PGP signature ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] IPv4 autoconfiguration
Dear all, With a lot of help from Julien and Grégoire, I've finally managed to get IPv4 autoconfiguration to work in AHCP. The approach is as follows. An AHCP peer performs stateless autoconfiguration as usual. After it has established IPv6 routing, it uses IPv6 unicast to contact a server that will lease him an IPv4 address, DHCP-style. The stateful algorithm is deployed on the wifi.pps.jussieu.fr network, and has been tested somewhat. In order to use it, you will need Babel 0.8 or later, and the current head of ahcpd (Darcs repository version dated 14 February 20:40 or later). Then, simply run ahcpd and stare in wonder. In order to set up an automatically IPv4 network, you will need a stateful server (fall-back servers are not implemented yet). This must be a machine with a disk. Generate a new ahcp configuration block specifying the IPv6 address of the stateful with the -s flag to ahcp-generate. On the stateful server, you must run ahcpd with the -S flag: ahcpd -S 10.0.0.1 10.0.0.254 /var/lib/ahcp-leases eth1 Please note that this functionality is experimental, and the protocol might yet change in incompatible ways. Juliusz pgpe6x7s0eW0z.pgp Description: PGP signature ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Updated tcpdump
An updated patch for tcpdump, due to Grégoire Henry and Julien Cristau, as well as binary packages for both Debian etch and current testing, are on http://www.pps.jussieu.fr/~jch/software/files/ Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] IPv4 autoconfiguration
>> Is there a way to *disable* IPv4? It's pretty annoying when I connect >> to wifi.pps.jussieu.fr via openvpn to get IPv6 connectivity and get a >> lot of garbage rules in my (IPv4) routing table instead. >-s Do not perform stateful autoconfiguration; the autoconfiguration > process will be finished after stateless autoconfiguration is > done. Note that this won't disable IPv4 if Gabriel already has an IPv4 address on the VPN interface. In addition to disabling stateful autoconf, Gabriel should add some filtering rules to /etc/babel.conf. The most radical solution is in ip 0.0.0.0/0 deny which will reject all IPv4 routes. To allow IPv4 routes to the wifi network only, in ip 192.168.4.0/24 allow in ip 0.0.0.0/0 deny and to just reject the default route and the route to PPS, in ip 0.0.0.0/0 eq 0 deny in ip 134.157.168.0/24 deny Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] IPv4 autoconfiguration
> This works perfectly well, thank you. Last question: > what is an "operationnal interface"? Babel warns me that it can't find > any at startup. It means two things. First, that you're using the very last (and possibly buggy) version of Babel. And second, that you're starting Babel before you up any of your interfaces. The latest versions of Babel check every 30 seconds whether the interfaces you gave it exist and whether they are up or down. This means that you should in principle be able to start Babel very early, and have it automatically detect interfaces that become available later in the boot process (for example because they were created by OpenVPN). The downside of that is that if you make a typo such as babel ::dead:beef etl0 instead of eth0, Babel will accept to run, and wait forever for an etl0 interface to be created. Because of that, it will warn you if none of the interfaces you passed on the command line are usable. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] ANNOUNCE: ahcpd 0.4
Dear all, Ahcpd 0.4 is available from http://www.pps.jussieu.fr/~jch/software/files/ahcpd-0.4.tar.gz http://www.pps.jussieu.fr/~jch/software/files/ahcpd-0.4.tar.gz.asc For more information about ahcpd, please see http://www.pps.jussieu.fr/~jch/software/ahcp/ The main news in this version is support for stateful configuration -- configuration done by contacting a central server. This supports configuration of IPv4 addresses, DHCP-style. Enjoy, Juliusz 17 February 2008: ahcpd 0.4 * Implemented stateful configuration for IPv4. * Tweaked timing to avoid hopping between competing configurations. * Fixed conversion of Babel hello intervals to seconds. pgp9plxF1ZbB3.pgp Description: PGP signature ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] No longer ignoring very bad neighbours
Grégoire and Julien have been complaining about Babel ignoring very lossy links; they claim that links with up to 90% packet loss are useful. (Note that Babel measures packet loss *before* link-level ARQ is applied, so that's not the amount of packet loss you will see if you simply ping a neighbour.) I've just changed the link cost computation on wireless links so that it will consider neighbours even when they loose no more than 11 hellos. This should not change Babel's behaviour when better links are available, but will prevent Babel from discarding links that disappear in a timely manner, which might potentially cause blackholes in some very unlikely topologies. Let me know if you see any new issues. I've installed the new version on alpha and beta; Julien, could you please copy it over to gamma, which I cannot access right now? Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Babel news: automatically redistribute local addresses
Dear all, Julien and myself have just finished implementing redistribution of local addresses. In other words, it is no longer necessary to manually redistribute local addresses, you can ask Babel to do it automatically. Redistribution is not done by default; you will need to specify which addresses to redistribute. If you want all of the local addresses to be redistributed, just specify redistribute local On huponomos, where I'm testing this functionality right now, I say redistribute local ip 2000::/3 redistribute local ip 134.157.168.0/24 redistribute local ip 192.168.4.0/24 which says to redistribute all local addresses as long as they are either globally-routable IPv6 addresses, or IPv4 addresses on either of the PPS and the Wifi prefixes. Of course, all of the filtering predicates are available in a ``redistribute local'' statement (although some don't make a lot of sense), so you can say things such as, for example, redistribute local if eth0 redistribute local metric 256 In principle, it should now be possible to say babel -C 'redistribute local' id interfaces... and have Babel do The Right Thing. The next step I'm planning is to have Babel automatically determine a suitable router-id, so that you can say babel -C 'redistribute local' interfaces... without having to specify a router id. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Babel news: automatically redistribute local addresses
> The next step I'm planning is to have Babel automatically determine > a suitable router-id, so that you can say > > babel -C 'redistribute local' interfaces... > > without having to specify a router id. This is now done. You can say babel -C 'redistribute local' eth1 and Babel will do The Right Thing. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] HEADS UP: Incompatible change
After a little thought, I've made Babel redistribute local addresses by default. If you're not happy with this behaviour, add the following line as the last in your /etc/babel.conf: redistribute local deny Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Fixes to route selection
Dear all, Lilian has found a case in which Babel 0.9 would delay reconvergence by 30 seconds. I've now fixed this case, and reworked the route selection algorithm somewhat; convergence speed is much improved. Since I'd like to release 0.10 pretty soon, I'm very much interested in any data about the behaviour of the current Darcs tree that you may have. Since I'm in a chatty mood, I'll give a few details about the issue. (By the way, Lilian, my analysis of the problem on IRC was completely wrong.) A (proactive) routing protocol has three tasks: - neighbour sensing: measuring link quality between neighbours; - route discovery: discovering the set of available routes; - route selection: choosing a particular route to every destination. In many routing protocols, the three tasks are mixed up. For example, both RIP and B.A.T.M.A.N. mix up neighbour sensing and route discovery, which is why in RIP you cannot tune the hello interval separately from the updte interval. Babel was designed as a modular protocol: the three stages of the protocol are, to the extent possible, independent. Of particular interest is the independence of route selection and route discovery: the protocol remains correct if nodes do not always choose the route with smallest metric, but choose ``worse'' routes under some circumstances (as is usually the case with distance-vector protocols, but not with link-state protocols). This makes it possible to implement route selection policies that choose routes according to criteria richer than just link quality. Now, when I started working on Babel, I had just experimented with OLSR, and found that it has serious problems with route stability: under some circumstances, it flaps between two parallel routes to a given destination. Route flapping is ungood: it can cause packet reordering, and it usually causes jitter (for example due to an extra ARP exchange) and sometimes packet loss. Because of that, Babel's route selection policy tries to promote route stability. The main stability mechanism is a simple form of hysteresis: we don't switch routes unless the new route is significantly better than the old route. (The exact amount of hysteresis used depends on whether we also switch router-id, and is something that needs more experimentation.) The second route stability mechanism is much simpler: a route is regarded with great suspicion unless it has been around for 30 seconds. Unfortunately, this mechanism turned out to be buggy, and to interact badly with some other features of the protocol (notably the feasibility condition), which caused perfectly good routes to be disregarded for 30 seconds in Lilian's network topology. After some thought, I've simply removed the 30 second condition; the only route stability mechanism remaining is hysteresis, which appears to do The Right Thing in practice. In case you want to check the code, all of this happens in route.c, in the functions find_best_route (which finds the candidate route for a given destination) and consider_route (which decides whether to switch to a new, potentially ``better'' route). While I was at it, I reworked some of the constants in the protocol, notably by making it send multi-hop requests and triggered updates more aggressively; this makes the protocol somewhat more chatty, but very slightly so. All together, you should see much faster convergence with 0.10 than with 0.9. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] ANNOUNCE: Babel 0.10
Dear all, I am pleased to announce Babel 0.10, which you will find on http://www.pps.jussieu.fr/~jch/software/files/babel-0.10.tar.gz http://www.pps.jussieu.fr/~jch/software/files/babel-0.10.tar.gz.asc This version will automatically redistribute local addresses; it is no longer necessary to specify them using ``-X''. This is an incompatible change, but you can revert to the previous behaviour by specifying redistribute local deny in your /etc/babel.conf. This version will also automatically adapt to interfaces appearing and disappearing at runtime, which avoids the need to restart Babel when a VPN goes up or down. Some fairly significant improvements have been done to the speed with which Babel selects a new route when a neighbour goes down (as opposed to the case where the local node moves). Many thanks to Lilian for helping me debug that. Finally, Babel can now daemonise itself, which should simplify your init scripts. I strongly recommend upgrading from Babel 0.9 or earlier. Juliusz 11 March 2008: babel 0.10 * Implemented the ability to automatically export local addresses (see the ``local'' keyword in redistribute specifications). This should avoid the need to explicitly specify -X on the command line (Julien Cristau and Juliusz Chroboczek). * INCOMPATIBLE CHANGE: local routes (local interface addresses) are now exported by default. Specify ``redistribute local deny'' to avoid that. * Babel will now automatically choose a router id if none is specified on the command line. * Automatically adapt to interfaces appearing or disappearing at runtime, as is usually the case when running over tunnels or VPNs. * Changed the link quality computation algorithm to not discard very lossy links. * Multi-hop requests will now be forwarded to an unfeasible successor under some circumstances. * Send multi-hop requests more aggressively. * Send requests for a new seqno upon receiving an unfeasible update if it's better than what we have. * No longer consider the age of routes in route selection. * Added ability to run as a daemon. pgpNDnc1BpXQO.pgp Description: PGP signature ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] A few examples of redistribution
I've had a couple of chats over IRC those last days that show that people are confused about the new redistribution statements in Babel 0.10. So here are a few real-world examples. 0. Preliminaries Any routes that you redistribute into Babel must have an explicit protocol attached. If you use another routing daemon, it should do that right. If you install your routes manually, you need to specify ``proto static'' on the ``ip'' command line. So if you used to say # route add default gw 1.2.3.4 you now need to say # ip route add default via 1.2.3.4 proto static You can check whether your current routes can be redistributed into Babel by typing ``ip route show''. If a route has no ``proto'' field, Babel will ignore it. (If it says ``proto 42'', it's a Babel route.) Under no circumstances should you use -X. -X is dangerous, and it will cause persistent routing loops if you are not careful. Instead of -X, you should install a static route and redistribute it cleanly. The static route can of course be a blackhole route; so if you used to say -X 192.168.5.0/24 128 you should say instead # ip route add unreachable 192.168.5.0/24 proto static and then, in babel.conf, redistribute 192.168.5.0/24 le 24 metric 128 1. Ordinary mesh node Pirx only participates in Babel routing, and does not serve as a gateway. It only redistributes its local addresses, and redistributes all of them, so no babel.conf is necessary. 2. Mesh node with a wired link, no redistribution Beta is a mesh node that happens to be attached to an Ethernet. It has a single IPv6 address, but two IPv4 addresses: 192.168.4.26 on the mesh network, and 192.168.1.26 on the Ethernet; it redistributes its IPv6 address, its IPv4 mesh address, but not its Ethernet address. Its babel.conf says: redistribute local ip 192.168.4.0/24 redistribute local ip ::/0 redistribute local deny 3. IPv4 gateway Coloquinte is our Ipv4 gateway. It redistributes its IPv6 address, and a default route to the IPv4 Internet. It does not redistribute its own IPv4 address, which is subsumed by the default route: redistribute local ip ::/0 redistribute local deny redistribute 0.0.0.0/0 le 0 metric 128 The ``le 0'' means that only the default route will be redistributed, which avoids issues if coloquinte were to acquire additional IPv4 routes. 4. Traditional gateway One of my users has a number of pure IPv4 mesh nodes, each of which is on its own /28. The various /28 are disjoint, so there's no need to redistribute local addresses in addition to the /28 routes: redistribute local deny redistribute ip 10.0.0.0/8 le 28 metric 128 5. IPv6 gateway Alpha is similar to Beta, but it additionally participates in RIPng routing and redistributes the default route into the mesh network: redistribute local ip 192.168.4.0/24 redistribute local ip ::/0 redistribute local deny redistribute ip ::/0 le 0 metric 196 Again, ``le 0'' is used to only redistribute the default route; this avoids dumping the whole RIPng routing table of Paris 6 and 7 into the mesh network. 6. Hybrid gateway Huponomos is another IPv6 gateway, but it also plays a role with respect to IPv4 routing. In addition to everything that alpha does, it redistributes its local address in 134.157.168.0/24, as well as a local route to 134.157.168.0/25 (that's not a typo: /25, not /24 -- the /24 is subnetted). It has some other IPv4 addresses, which it does not redistribute. Additionally, it rejects any IPv6 routes that come from coloquinte (2001:41d0:1:6364::1): redistribute local ip ::/0 redistribute local ip 134.157.168.0/24 redistribute local ip 192.168.4.0/24 redistribute local deny redistribute ip ::/0 eq 0 proto 11 metric 128 redistribute ip 134.157.168.0/24 le 25 metric 128 in ip ::/0 le 32 id 2001:41d0:1:6364::1 deny Note that the default IPv6 route is redistributed with metric 128, while alpha redistributes it with the slightly larger metric 196; this is so that traffic from beta, which is a neighbour of both, will flow through huponomos rather than alpha. Hope this helps, Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] A few examples of redistribution
>> The static route can of course be a blackhole route [...] >> # ip route add unreachable 192.168.5.0/24 proto static > If you really want a blackhole, you should rather use: > > # ip route add blackhole 192.168.5.0/24 proto static Sure, I was somewhat unaccurate. But you never actually want a blackhole, unless your network is badly broken. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Babel ignoring tunnel interfaces
I'm receiving e-mail from users complaining that Babel is ignoring their tunnel interfaces. For an interface to be usable by Babel, it must: - support IPv6; - have a link-local IPv6 address. The first point means that you cannot run Babel over e.g. IPIP tunnels; use GRE tunnels instead. Note that this remains true even on a pure IPv4 network -- Babel is a hybrid protocol (IPv4 and IPv6), and Babel routing information is exchanged over IPv6, even in a pure IPv4 network. The second point is more tricky. Linux will autoconfigure a link- local address on broadcast interfaces, but will not necessarily do it on point-to-point interfaces (there are some exceptions). Check if you have a link-local address: $ ip -6 addr show alpha 5: [EMAIL PROTECTED]: mtu 1476 inet6 fe80::d8f0:3587:f850:4a99/128 scope link valid_lft forever preferred_lft forever If you have a line that says ``inet6 fe80::... scope link'', you're fine. If you don't, you'll need to say something like ip -6 addr add (ahcp-generate-address fe80::)/64 dev whatever You'll find the ahcp-generate-address utility in the ahcpd package. All of this is described in Babel's README file. If it's not clear enough, I'll be grateful for any patches. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] ANNOUNCE: Babel 0.11
Dear all, You will find Babel 0.11 on http://www.pps.jussieu.fr/~jch/software/files/babel-0.11.tar.gz http://www.pps.jussieu.fr/~jch/software/files/babel-0.11.tar.gz.asc A lot of small tweaks in this version, but little significant changes. Most notables is a fix for a crash that would happen if an interface with large MTU was added at runtime, and some preliminary moderation of requests. With this version, Babel is mostly feature-complete as far as I am concerned. Still missing is resending of incremental route updates, and more work is needed on the parameters of triggered updates. Juliusz 29 March 2008: babel 0.11 * Implemented sub-second hello and update intervals. * Fixed a bug that could prevent the best route from being selected for extended periods of time. * Implemented protection against out-of-date requests being sent and forwarded when a node loses its sequence number. * INCOMPATIBLE CHANGE: reduced the cost of wired networks down to 96 from 128. * Tweaked the frequency at which a router's seqno increases, to make it more likely that a feasible route will be available when needed. * Implemented garbage collection of old sources. * Implemented coalescing of unicast messages. * Fixed a bug that could cause a crash when a link's MTU changes. * Fixed a bug that could delay noticing that a network is no longer idle when running Babel with the -i flag. * Fixed a bug that could cause incorrect metrics to be advertised when output filtering was used. * Fixed a bug that could cause incorrect link costs to be computed when a neighbour reduces its hello interval. * Fixed some minor issues with the ordering of outgoing messages. pgpglDhEndzWD.pgp Description: PGP signature ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] ANNOUNCE: new Babel branch: inter-process interface
Dear all, Since a few students of mine have volunteered to write a GUI for Babel, I've just branched a version of Babel that has an IPC interface. You'll find it on http://www.pps.jussieu.fr/~jch/software/repos/babel-local-interface This is a Darcs repository, so just run darcs get http://www.pps.jussieu.fr/~jch/software/repos/babel-local-interface In order to have a look at the information provided, just run this version and do telnet ::1 33123 You'll see a line of text for every change in Babel's neighbour and route tables. I'll keep this branch separate from the trunk for the time being, at least until the protocol stabilises. I will doubtless merge it at some point. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Change to local protocol
I've just changed the local interface protocol. First, there is now an initial message. This is just BABEL 0.0 0.0 is the protocol version, and is followed by a list of tokens, currently empty. Second, every message contains a unique identifier for the object it describes. For example, add neighbour 805f7a0 id 2001:660:3301:8063:218:f3ff:fea9:914e address fe80::7c47:b5aa:4669:ac6d if alpha reach e000 rxcost 96 txcost 96 cost 96 which states that this neighbour is uniquely identified by the string 805f7a0. This string does not need to be unique across time, but at a given moment it is unique -- in other words, in the time between ``add neighbour foo'' and ``flush neighbour foo'', the string ``foo'' will only identify this particular neighbour. The unique identifiers should be treated as opaque tokens, and are suitable for using as keys in a hash table. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] ANNOUNCE: babel-0.12
Dear all, Babel 0.12 is now available from http://www.pps.jussieu.fr/~jch/software/files/babel-0.12.tar.gz http://www.pps.jussieu.fr/~jch/software/files/babel-0.12.tar.gz.asc The main feature of this version is that route retractions are resent multiple times, which speeds up the elimination of blackholes in presence of heavy packet loss. Other than that, some minor tweaks to the request forwarding logic and to the ordering of updates, both changes make Babel less noisy with no change to convergence speed. Juliusz 7 April 2008: babel 0.12 * Retractions are now sent multiple times, which should speed-up convergence in presence of packet loss. * Optimised the sending of updates to make them smaller. * Don't forward requests multiple times; this should reduce the noise due to requests with no increase in convergence time. * Fixed a bug that could cause a crash when resending requests. * Added some protection against clock stepping. pgpsqTdoIzCkf.pgp Description: PGP signature ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] VPN temporarily disabled
(This is information local to the Paris network, so I'm writing in French.) Du fait de la récente vulnérabilité OpenSSL dans Debian, le VPN sur huponomos est temporairement désactivé, le temps que je génère une nouvelle CA. Amicalement, Juliusz pgpTtH50cq7Et.pgp Description: PGP signature ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] babel and zeroconf
> delighted to have accidentally encountered babel. Welcome on board. > i was wondering if anyone has had any experience deploying babel > simultaneously with zeroconf (!) on e.g. a truly wireless adhoc > network. Zeroconf is a purely link-local protocol -- it doesn't reach beyond the local link. In a mesh network, the notion of link doesn't really exist, so zeroconf will give mixed results. (The same is true of DHCP, by the way, which is why we have developed our own configuration protocol (AHCP).) More precisely, zeroconf in a mesh network will only allow you to speak to your neighbours. IMHO, the righ solution would be to extend zeroconf to work over a site-local IPv6 prefix, and to extend Babel to route multicast. Let me know if you want to work on the former, and I'll think about the latter. > i always always always immediately switch off delivery of messages > whenever there is no forum gateway to a mailing list. http://lists.alioth.debian.org/pipermail/babel-users/ http://news.gmane.org/gmane.network.routing.babel.user http://www.mail-archive.com/babel-users@lists.alioth.debian.org/ Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] babel and zeroconf
> getting proper WAN-wide name registration and defending is _hard_. Yes, if you want to be distributed. You can always fake it with a centralised server. > it takes about _three years_ to get it right - as no less than three > of us found out for samba. Yeah, but you needed to be bug-compatible with another system. Doing it from scratch would have been easier. > i just did some research on zeroconf a couple of hours ago: it turns > out _again_ to be an extension of DNS which is very ironic given > people's aversion to NetBIOS and "network neighbourhood" for being so > "chatty" AFAIK, Zeroconf was inspired by Appletalk, not NetBIOS. Your point still stands, though, as Appletalk was also criticised for being too chatty. >> In a mesh network, the notion of link doesn't really >> exist, so zeroconf will give mixed results. > ... this i don't follow. you're using terms that have specific > meanings with which i'm not yet familiar, and, as it's an area i > really do need to understand, i'd very much appreciate some pointers / > elaboration. Sure. In traditional (wired) networking, a link is a set of interfaces that can communicate without going through a router. It used to be just a cable, nowadays it's usually a set of cables bridged together. In both IPv4 and IPv6, you usually assume that if a node belongs to the same subnet prefix as you do then it is on the same link, and you may speak to it directly (ignoring unnumbered links and multiple prefixes per link for now). In other words, you encode topology information within the bits of the address. Obviously, this is not the case for mesh networks, where the topology varies over time and does not correspond in any way to the address allocation. > in particular, what does - or doesn't - babel provide for "mesh networks" ? Babel is a routing protocol that, in its basic form, does not make any assumptions about how prefixes map to links. Hence, it will work on any network topology -- wireless mesh, classical wired network --, but might not be optimally efficient. Babel can be made to be efficient on wired networks, but this requires a little bit of per-node configuration. Since most of our nodes are wireless, and at any rate the inefficiency incurred by using out-of-the-box Babel on wired networks is slight, that's satisfactory. The only assumption that Babel makes about the underlying network is that link-local multicast is able to reach all neighbours. Hence, in its current form, it will not work on non-broadcast (NBMA) networks, such as ATM. > mm? *quizzical*. i thought ipv6 didn't do multicasting? IPv6 multicasts just fine. However, non-local multicast requires multicast routers, and Babel doesn't route multicast right now. > the lowest speed network is a digital radio modem, with something > like a 10 mile range (with TCP/IP on it). How does that Simpsons line go again? Mmmh... 800MHz. > the other ones we have yet to specify but candidates include > GPRS/EDGE or maybe 3G, and WIMAX or some other adhoc high speed > networking. What do you mean by ``ad-hoc''? If you're using the term to mean that stations can communicate between themselves, then WiMAX certainly isn't, it's strictly a point-to-multipoint technology. (Which is something that Babel will handle beautifully, by the way.) > please don't ask why all that's needed :) Please do tell! > so i am suddenly extreemely interested in decent and versatile routing > software that can help here! Babel is certainly versatile, and I like to think it's decent. It can deal with multiple interfaces, which appears to be what you are mainly concerned with. But you'll really need to tell us more about the network architecture you're envisioning. Whether Babel or some other technology is best depends on a lot of factors, notably what kind of hand-off times are tolerable, whether you're interested in multi-hop routing, how large is your power budget, and whether you can count on link-layer notifications. > so i will have - some time in the next few weeks - suddenly plenty of > time on my hands to focus on this. and perhaps some funding available > too. Cool. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] babel and zeroconf
> soo... http://wiki.laptop.org/go/Mesh_Network_Details#Experimenting - > they've ... oh. they cheated. they got marvell to do some of the > low-level mesh networking. It was my understanding that OLPC and Marvell collaborated on the job. In particular, I believe that Michail Bletsas invested a lot of work into the mesh implementation. I may be wrong, though. > so, not only am i going to need to merge all the different types of > communications technology together but also i'm going to need to send > certain types of traffic (voice, video, jpeg images) over the > different communications networks, selecting the "best available" one > for the job. (!) That's called policy routing, and there's a lot of published papers on the subject. Babel doesn't do policy routing right now, but if you convince me why it's needed, I'm quite willing to add it. The reason I'm not convinced of the need for policy routing is that there usually the best link for one type of traffic is also the best link for all other ones. There are exceptions, but I'm not sure they're common enough to justify burdening your routing implementation. > yes. ppp over GSM/GPRS; WIMAX; 802.11; radio-modem; all of it has to > be sort-of... merged amorphously. Yes, but. If I read you right, you're not only asking that routing decisions be made depending on the available technologies; you're asking that they be made depending on offered load. In other words, if both the radio modem and GPRS are available, you want the radio modem to be used if the offered load is less than its capacity, but switch to the expensive GPRS link if the offered load increases, e.g. because the user decided to start a video conference. Is that correct, or are you happy with all traffic taking the ``best'' link available at a given time? (Once again, if you need policy routing, it's your task to convince me.) > e.g. if you can transfer _some_ routing information - however slowly - > about the 2-mile-range WIMAX nodes over the 10-mile-range radio-modem, > then you would, i assume, be able to make better routing decisions > than you would if you didn't have the long-range radio connection? Do not worry about the routing traffic -- it's very low rate, on the order of 1 byte per second per node. No need to use third-party announcements (which is the technical term for what you're suggesting). >> notably what kind of hand-off times are tolerable, > walking around inside and outside office buildings, which might cut > things off randomly, but assume decent antenna (4 or 8-way phased > ceramic antenna). Suppose that user walks into a lift, and the WiMAX connection is cut off. Is it okay if the mobile node switches to GPRS after one second? 5 seconds? 15 seconds? >> whether you're interested in multi-hop routing, > yes. Good. > so - like the OLPC thing [except better :) ] assume that it's got to > work without centralised infrastructure, but if centralised > infrastructure is available (e.g. GPRS / 3G or a high-power > fixed-position WIMAX unit that has better range and coverage than the > mobile units) then it should be seamlessly taken advantage of. No problem, we already do that. But see above about policy routing. >> how large is your power budget, > luggable rather than portable. i.e. "big enough" to not have to > worry about :) Good. >> and whether you can count on link-layer notifications. > > does this mean "inter-layer" notifications? i.e. like i hinted at > above, about being able to send notifications over the radio-modem > about the e.g. WIMAX layer? No. Link-layer (or, more generally, cross-layer) notification is about the link layer informing the routing protocol about the link being broken. In other words, you loose WiMAX connectivity, and the WiMAX driver informs the routing daemon that the WiMAX link is down faster than the routing daemon would realise that it's no longer receiving anything over that link. It allows faster convergence, since the routing daemon does not need to explicitly probe the broken link. So it's linked about the point about hand-off above. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] babel and zeroconf
>> That's called policy routing, and there's a lot of published >> papers on the subject. Babel doesn't do policy routing right now, >> but if you convince me why it's needed, I'm quite willing to add >> it. > ... what you're saying is that it's not straightforward to identify / > separate the networks, is that right? Oh, no. The trouble is that in order to perform fully general policy routing, you need to carry multiple times the routing information -- one per policy. > i was kind of naively envisioning that i would be able to just bypass > the routing, for voice, and go direct to e.g. the packet radio modem > interface. In other words, only taking the first hop into account when doing policy routing? Then that's much cheaper. >> (Once again, if you need policy routing, it's your task to convince me.) As far as I can tell -- you haven't identified your usage cases precisely enough to find out if full policy routing is required. So I guess it's best to postpone this decision. > so - a network comprising two WIMAX networks which are geographically > too far apart to be connected together (more than 2 miles) but a few > of the nodes can use GPRS / 3G to get data across between the two, > thus connecting the two networks together. > > ... does that work? Yep. > and, more importantly, is it possible for babel to still maintain a > cohesive virtual network, independent of the link layer(s) being used > to create it? Yep, that's what it was designed to do. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] IPv6 back, still no IPv4
The wifi network at Chevaleret has its global IPv6 route back. Still no IPv4, we're waiting for Julien to send me a certificate request. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Major changes to data structures
I made some major changes to Babel's data structures last night. The new version didn't crash in 24 hours, and I'd be grateful if people try it out before release. There are no user-visible changes, except that the new version uses less memory and lifts all arbitrary constraints (such as the maximum number of routes etc.). It's in the Darcs repository. Please let me know if you crash it. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] IPv4 back up
Thanks to Julien, global IPv4 routing is back up on the Chevaleret network. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Default gateway problem
> I have one problem with babel. I cannot redistribute default gateway > with babel. I tried with redistribute local, redistribute ip > 0.0.0.0/0 with no success. Every kernel route is equipped with a number, the route's protocol, which is ignored by the kernel and only used by routing daemons to decide whether to redistribute the route. The rule is that routing daemons must not redistribute a root with protocol number ``boot'' (3 under Linux), and may redistribute routes with other protocol numbers. So in order to redistribute a route with Babel, you must make sure that it has a protocol number other than ``boot''. This means that rather than saying # route add default gw 1.2.3.4 # ip route add 0.0.0.0/0 via 1.2.3.4 you must say something like # ip route add 0.0.0.0/0 via 1.2.3.4 proto static You may check a route's protocol with the command ``ip route show'': On my desktop machine: $ ip route show 0.0.0.0/0 default via 134.157.168.126 dev eth0 On a Babel router: $ ip route show 0.0.0.0/0 default via 192.168.4.1 dev huponomos proto 42 metric 22 onlink (42 is the protocol number used by Babel.) Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Default gateway problem
Your routing table looks fine. Just to make sure -- you do have a suitable ``redistribute'' statement in /etc/babel.conf ? Something like redistribute 0.0.0.0/0 eq 0 metric 128 Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Default gateway problem
> Thank you for the quick answer. But I still have problem with the > default route. If I look to debug messages, I cannot see default > route. > 172.16.0.2 dev ppp0 proto kernel scope link src 172.16.0.1 > 192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.4 > 10.0.0.0/16 dev eth1 proto kernel scope link src 10.0.5.4 > 169.254.0.0/16 dev eth0 scope link > 127.0.0.0/8 dev lo scope link > default via 10.0.0.1 dev eth1 proto static Fine. > Netlink message: > (msg -> "Add kernel route: dest: :::172.16.0.2/128 gw: :: metric: 65535 > if: ppp0 (proto: 2, type: 1)" 1), > (msg -> "Add kernel route: dest: :::192.168.10.0/120 gw: :: metric: 65535 > if: eth0 (proto: 2, type: 1)" 1), > (msg -> "Add kernel route: dest: :::10.0.0.0/112 gw: :: metric: 65535 if: > eth1 (proto: 2, type: 1)" 1), > (msg -> "" 0), > (msg -> "" 0), > (msg -> "Add kernel route: dest: ::/96 gw: :::10.0.0.1 metric: 65535 if: > eth1 (proto: 4, type: 1)" 1), > (msg -> "" 0), > (msg -> "" 0), > (msg -> "" 0), > (msg -> "" 0), > (msg -> "" 0), > (msg -> "" 0), > (msg -> "" 0), > (msg -> "" 0), > (msg -> "" 0), > (msg -> "" 0), > (msg -> "" 0), That's partly broken. The IPv6-mapped prefix is missing for the default route. And why the deil are the metrics set to infinity? I'm in something of a rush right now, but I've had a look at the code and I don't see how that could happen. Julien, Grégoire, do you have any ideas? Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Default gateway problem
> Thank you for the quick answer. But I still have problem with the > default route. If I look to debug messages, I cannot see default > route. Okay, I can reproduce the bug. It only appears on 64-bit arches, which is why I didn't notice it before. I'll let you know when I have more. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Default gateway problem
It turns out it was not specific to 64-bit machines, but rather to
very recent Linux kernels. The netfilter people have changed the
(mostly undocumented) API once again. Of course, since the API wasn't
documented, they preserved the documented API ;-)
The following patch (committed in the Darcs repository) should re-add
support for exporting default routes on recent Linux kernels.
Juliusz
Sat May 24 01:08:20 CEST 2008 Juliusz Chroboczek <[EMAIL PROTECTED]>
* Fix parsing of kernel route metric on recent kernels.
Recent kernels don't include RTA_PRIORITY when it's 0.
Sat May 24 00:59:40 CEST 2008 Juliusz Chroboczek <[EMAIL PROTECTED]>
* Fix exporting of IPv4 default routes on recent kernels.
Recent kernels don't include RTA_DST in the default route. This fixes
incorrect parsing of such entries. Reported by Robert Lukan.
diff -rN -u old-babel/kernel_netlink.c new-babel/kernel_netlink.c
--- old-babel/kernel_netlink.c 2008-05-24 01:09:31.0 +0200
+++ new-babel/kernel_netlink.c 2008-05-24 01:09:31.0 +0200
@@ -784,8 +784,13 @@
memset(&route->prefix, 0, sizeof(struct in6_addr));
memset(&route->gw, 0, sizeof(struct in6_addr));
route->plen = rtm->rtm_dst_len;
-if(rtm->rtm_family == AF_INET) route->plen += 96;
-route->metric = KERNEL_INFINITY;
+if(rtm->rtm_family == AF_INET) {
+const char zeroes[4] = {0, 0, 0, 0};
+v4tov6(route->prefix, zeroes);
+route->plen += 96;
+}
+
+route->metric = 0;
route->ifindex = 0;
route->proto = rtm->rtm_protocol;
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Default gateway problem
I've received confirmation from Robert that this works. I guess it's time to release 0.13... Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Announce: babel 0.13
Dear all, Version 0.13 of Babel is now available from http://www.pps.jussieu.fr/~jch/software/files/babel-0.13.tar.gz http://www.pps.jussieu.fr/~jch/software/files/babel-0.13.tar.gz.asc For more information about Babel, please see http://www.pps.jussieu.fr/~jch/software/babel/ This version makes all data structures dynamic, which removes all arbitrary limits on Babel's capacity (maximum number of neighbours, of routes, etc.) and reduces memory usage somewhat. It also fixes compatibility with very recent Linux kernels. Enjoy, Juliusz 24 May 2008: babel 0.13 * Removed all arbitrary limits (interfaces, neighbours, routes, xroutes and sources). * Fixed a bug that prevented expiration of stale sources. * Updated the kernel interface to work with recent Linux kernels. * More tweaks to the order in which updates are sent. pgpJTaPzCuEez.pgp Description: PGP signature ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Babel and OpenWRT
To whoever commits Babel into OpenWRT, I have some clean initscripts for Babel 0.13 under OpenWRT. I've sent a copy to Florian, but I'm not sure he'll be the one doing the commit. Please ask me for a copy of the initscript before committing 0.13 into OpenWRT. Thanks, Juliusz pgpvFdEaBer2U.pgp Description: PGP signature ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] ANNOUNCE: babel 0.13
Dear all, Version 0.13 of Babel is now available from http://www.pps.jussieu.fr/~jch/software/files/babel-0.13.tar.gz http://www.pps.jussieu.fr/~jch/software/files/babel-0.13.tar.gz.asc For more information about Babel, please see http://www.pps.jussieu.fr/~jch/software/babel/ This version makes all data structures dynamic, which removes all arbitrary limits on Babel's capacity (maximum number of neighbours, of routes, etc.) and reduces memory usage somewhat. It also fixes compatibility with very recent Linux kernels. Enjoy, Juliusz 24 May 2008: babel 0.13 * Removed all arbitrary limits (interfaces, neighbours, routes, xroutes and sources). * Fixed a bug that prevented expiration of stale sources. * Updated the kernel interface to work with recent Linux kernels. * More tweaks to the order in which updates are sent. pgpL10e4xUMM4.pgp Description: PGP signature ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] ANNOUNCE: ahcpd-0.5
Dear all, Ahcpd-0.5 is now available from http://www.pps.jussieu.fr/~jch/software/files/ahcpd-0.5.tar.gz http://www.pps.jussieu.fr/~jch/software/files/ahcpd-0.5.tar.gz.asc For more informatin about ahcpd, a configuration protocol for mesh networks, please see http://www.pps.jussieu.fr/~jch/software/ahcp/ The main news in this version is that ahcpd should now survive interfaces going up and down or being deleted and created by the kernel. Additionally, ahcpd can now daemonise itself, which greatly simplifies the writing of initscripts. If you intend to commit this version into OpenWRT, please drop me a note, I have some proper initscripts ready. Juliusz Chroboczek 25 May 2008: ahcpd 0.5 * Made ahcpd gracefully survive interfaces going up/down or being renumbered, as usually happens when tunnels or VPNs are started or stopped. * Implemented the ability to run as a daemon. * Implemented the ability to try multiple stateful servers. * Implemented the flag -r, which prevents the routing protocol from being started. pgp3r3nv66LQV.pgp Description: PGP signature ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] ANNOUNCE: OpenWRT (mipsel) packages of babel and ahcpd
Available from http://www.pps.jussieu.fr/~jch/software/files/ as usual. Please make sure to edit the /etc/config/* files after installing. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] query regarding AHCP
> I went through the AHCP link > http://www.pps.jussieu.fr/~jch/software/ahcp/ and found the line > stating that "It is currently able to configure hosts for static > routing, for use of the OLSR protocol, or for use of the Babel > protocol." Does that mean it only supports stating routing and not > adaptive routing? AHCP supports static routing and dynamic routing using either Babel or OLSR. In other words, it will either configure a static route, or configure the babel daemon, or the olsrd daemon. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Babel - bug ?
> I am using default configuration of babel, just -l and -C are added > on both sides. I really dont know if is this a bug, or I am doing > something wrong. But is strange because, everything is working > good. But in third maybe fourth iteration I came to that problem. As > I can see in debug output, metric is 65535. If I restart babel > everything is OK than. The link cost estimation hasn't converged yet. By default, Babel uses a very large hello interval on wired links (see the -H option in the manual page), you may want to reduce it if you want faster convergence. As a rough guide, link state convergence will happen after 3 hello intervals. (Once link state has converged, route convergence will happen faster -- 100 ms per hop is typical.) > Do you have any suggestions for using your protocol over limited > bandwidth connection, or any other suggestion for my case ? Babel should work fine at 38 kbps, even if you reduce the hello interval. One thing you may want to experiment with is the -l flag, which will cause Babel to react immediately to notifications from the link layer (LCP in your case). Since I don't really understand cross-layer notifications, it's marked as experimental in the manual page; let me know how it works for you. > The only thing I am really missing its security, do you have any > plan to implement security in babel. Or is there any easy way I can > do it my self(begginer in C), if you dont plan. Lets say symmetrical > key would be enough, as it is in olsr protocol. What is your attack model? I.e. what are you trying to protect against? If your link is insecure, an attacker may use simpler techniques to poison your network than participating in the routing protocol. It doesn't make much sense to secure Babel if you haven't secured ARP. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Babel local-interface branch updated
Alex, Pejman, (Writing in English, as babel-users is in CC.) I've just brought the babel-local-interface branch up-to-date with the trunk. You may want to run darcs pull. Regards, Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] ahcpd babel wireless mesh network
Hi Bogdan, and sorry for the delay. > After reading the documentation and the readme and the --help to > both ahcpd and babel, I still can't make it work. It looks like you don't understand the syntax of IPv6 addresses. May I recommend that you read http://en.wikipedia.org/wiki/IPv6#Notation > ahcp-generate -p fde6:20f5:c9ac:358: -P babel -n fde6:20f5:c9ac:358:1 -g > 192.168.1.1 > ahcp.dat That should be ahcp-generate -p fde6:20f5:c9ac:358:: -P babel -n fde6:20f5:c9ac:358::1 > ahcp.dat You don't need to specify a static gateway for Babel. (As a side note, ``-g'' only applies to IPv6 routes, as stateless autoconf is not supported for IPv4.) > ahcpd -d 99 -a /tmp/ahcp.dat -S 192.168.1.200 192.168.1.254 /tmp/ahcp-leases > -n -c /tmp/dummy-config.sh wl0 br-lan You should not run ahcp or babel on a bridged interface. You should modify the OpenWRT scripts to make sure not to create a bridge. Which version of OpenWRT are you running ? Whiterussian or Kamikaze ? > the console messages on the server > "creat(unique_id): No such file or directory # mkdir /var/lib Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] autoritative statefull ahcpd question
> In the documentation at line 84 it says "An authoritative peer never > sends AHCP queries", but in the readme at line 69 it says "By > default, the authoritative peers will be configured by AHCP just > like the other ones". All peers get configured from the authoritative data. A non-auth peer will send queries to get the data; an auth peer already has the data, so it doesn't need to send queries. > Why is the chapter 3 from the documentation missing? Because I'm in the process of redesigning ahcp from scratch. The new protocol is much simpler and more modular, but somewhat more chatty. > So do I have to put a "-c /dummy-config.sh" and "-n" to obtain > a statically configured ahcpd authoritative stateful server? Yes. > Is the babel daemon started by ahcpd Yes. > Is the file "/etc/ahcp/ahcp-babel-options" necessary on a gateway > with babel routing? is it created by the ahcpd daemon? No. It's only needed if you want to pass extra options to babel. Normally, it's not needed. > Also is the file "/var/lib/ahcp-unique-id" necessary on > a authoritative stateful ahcpd server that is gatway? is it created > automatically? Yes, it's created automatically. But /var/lib must exist. > although ahcpd does configure strange ipv6 on the network > (::213:e8ff:feec:9a65 on a wireless client aldo the prefix in the > autoritative file is the one in the README) See my previous mail -- you omitted the double colons ``::''. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] ahcpd babel wireless mesh network
>> ahcp-generate -p fde6:20f5:c9ac:358: -P babel -n fde6:20f5:c9ac:358:1 -g >> 192.168.1.1 > ahcp.dat > > That should be > > ahcp-generate -p fde6:20f5:c9ac:358:: -P babel -n fde6:20f5:c9ac:358::1 > > ahcp.dat My bad -- the typo was in the README. All my apologies. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Babel slides
I've got some slides about Babel (in French) for a talk that was finally canceled. Let me know (by private mail) if you want a copy. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] ANNOUNCE: babel 0.14
Dear all, You will find version 0.14 of the Babel routing daemon on http://www.pps.jussieu.fr/~jch/software/files/babel-0.14.tar.gz http://www.pps.jussieu.fr/~jch/software/files/babel-0.14.tar.gz.asc For more information about Babel, please see http://www.pps.jussieu.fr/~jch/software/babel/ Babel 0.14 will automatically notice a bridged interface, print a warning, and disable all wired optimisations. This should get rid of bug reports from people who mistakenly run Babel over the ``lan'' interface in OpenWRT. 0.14 lifts the last remaining artificial limit -- on the number of kernel routes that we're able to parse when redistributing. (Yep, somebody redistributed the whole default-free IPv6 routing table into our RIPng domain -- 0.13 didn't like that very much, but it didn't crash, it just ignored the extra routes.) It also fixes a minor bug that would cause routes to be ignored until the next scheduled update after a redistributed route is retracted. You should not notice the difference unless you're doing some weird things with route redistribution. The default values for the hello and update intervals have been decresed somewhat, and we now use unmodified ETX as the metric on wireless links. Finally, this version is robust against clock stepping if run on a sufficiently recent Linux kernel. You should now be able to step your clock to your heart's content without Babel misbehaving, which is rather important on RTC-less routers. Enjoy, Juliusz 1 July 2008: babel 0.14 * Use POSIX clocks if available to protect against clock stepping. * Made babel use available internal routes straight away when the set of redistributed routes changes. * Lifted the arbitrary limit on the number of kernel routes. * Changed the routing metric used on wireless links to plain ETX. * Bridges are now automatically detected and treated as potential wireless interfaces. * Reduced the default hello interval. pgpdmDGdnQX7R.pgp Description: PGP signature ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Convergence problem
Thanks for the debugging dumps, I'll try to find the time to study them. > I also have one question, is there any way, to add/remove interfaces > when Babel is already running ? Yes, just list all of the possible interfaces on the Babel command line, even if they don't currently exist. Babel will automatically notice when they come into existence, and start running over them. So you run something like babel eth0 ppp0 ppp1 ppp2 ppp3 ppp4 and Babel will notice if any of the above-mentioned interfaces comes into existence. Note that Babel only polls the kernel for new interfaces every 30 seconds. If you add a new interface and want Babel to notice it straight away, you may want to send Babel a SIGUSR2 in order for it to notice it straight away. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Convergence problem
> I am testing Babel on ppp links, over USB/serial. And i have > problem, if I unpluged cable for few seconds, so ppp link is still > up, then I have problems, output logs from both sides are in files > debug.*. I've made a silly typo in 0.14, that will severely break reconvergence in the case when the proactive features don't trigger (by up to 70 seconds). The patch is attached. I'll release 0.15 by tonight, I've got some other minor tweaks to make. Robert, thanks a lot for your help. Juliusz Thu Jul 3 16:25:12 CEST 2008 Juliusz Chroboczek <[EMAIL PROTECTED]> * Fix typo in the computation of the update interval. diff -rN -u old-babel/babel.c new-babel/babel.c --- old-babel/babel.c 2008-07-03 16:25:33.0 +0200 +++ new-babel/babel.c 2008-07-03 16:25:33.0 +0200 @@ -269,7 +269,7 @@ update_interval = MIN(MAX(wireless_hello_interval * 5, wired_hello_interval), 7); -update_interval = MAX(update_interval, 70); +update_interval = MIN(update_interval, 70); if(seqno_interval <= 0) /* This should be slightly less than the self_update_interval */ ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Convergence problem
> Thu Jul 3 16:25:12 CEST 2008 Juliusz Chroboczek <[EMAIL PROTECTED]> > * Fix typo in the computation of the update interval. Sorry, that's complete nonsense. Please don't apply this patch. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Convergence problem
> I am testing Babel on ppp links, over USB/serial. And i have > problem, if I unpluged cable for few seconds, so ppp link is still > up, then I have problems, output logs from both sides are in files > debug.*. But if I wait a little more, so ppp link goes down, and > then I bring it up(ppp) I dont have problems. Okay, I think I found the issue. Your configuration is weird, and there's a case I didn't envision in Babel. The issue is that your implementation of ppp switches link-local addresses on every up/down event. IPv6 link-local addresses are supposed to remain stable, so this is why Babel gets confused by this case. I'll implement a workaround, but you really should try to ensure that your link-local addresses remain stable if possible. Who's adding the link-local addresses here? Is it a bug in your ppp.up scripts, or one in the kernel? FWIW, Babel will recover from this situation, but it will take a long time -- roughly 16 times the hello interval plus 30 seconds, which in your case amounts to over a minute. Here's what's going on on the SuSE side: > Neighbour 2001:1470:fffe:60:20d:b9ff:fe14:c524 at fe80::e0f7:19b6:d257:4ac1 > dev ppp0 reach ff00 rxcost 96 txcost 96. The alix board, with router id c524 (look at the last 4 digits), appears at the link-local address 4ac1. > Neighbour 2001:1470:fffe:60:20d:b9ff:fe14:c524 at fe80::e0f7:19b6:d257:4ac1 > dev ppp0 reach 3fc0 rxcost 65535 txcost 96. The alix board is still there, but it's now been detected as unreachable (rxcost infinity). > Neighbour 2001:1470:fffe:60:20d:b9ff:fe14:c524 at fe80::24ef:89ae:1360:698 > dev ppp0 reach c000 rxcost 96 txcost 65535. > Neighbour 2001:1470:fffe:60:20d:b9ff:fe14:c524 at fe80::e0f7:19b6:d257:4ac1 > dev ppp0 reach 1fe0 rxcost 65535 txcost 96. The alix board appears again, but with a different link-local address 698. Babel fails to notice it's the same board. On the Alix side: > Received ihu 96 for 2001:1470:fffe:60:20d:b9ff:fe14:c524 from > 2001:1470:fffe:1:219:b9ff:fe6d:4ea1 (fe80::1065:9660:282c:d985) 900. Fine, the SuSE machine is saying that it can hear the board again... > Received ihu 65535 for 2001:1470:fffe:60:20d:b9ff:fe14:c524 from > 2001:1470:fffe:1:219:b9ff:fe6d:4ea1 (fe80::1065:9660:282c:d985) 900. ...and then immediately complains that it cannot hear it. In fact, the SuSE machine is sending two distinct IHU messages -- one with metric 96 to the second link-local address, and one with metric infinity to the former one. Unfortunately, as it stands right now, the protocol cannot distinguish between the two. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Convergence problem
> The issue is that your implementation of ppp switches link-local
> addresses on every up/down event. IPv6 link-local addresses are
> supposed to remain stable, so this is why Babel gets confused by this
> case. I'll implement a workaround, but you really should try to
> ensure that your link-local addresses remain stable if possible.
Please try the attached patch, and let me know if it fixes your issue.
Juliusz
Thu Jul 3 17:21:04 CEST 2008 Juliusz Chroboczek <[EMAIL PROTECTED]>
* Protect against duplicate neighbours.
diff -rN -u old-babel/neighbour.c new-babel/neighbour.c
--- old-babel/neighbour.c 2008-07-03 17:21:33.0 +0200
+++ new-babel/neighbour.c 2008-07-03 17:21:33.0 +0200
@@ -48,6 +48,17 @@
return NULL;
}
+struct neighbour *
+find_neighbour_by_id(const unsigned char *id, struct network *net)
+{
+struct neighbour *neigh;
+FOR_ALL_NEIGHBOURS(neigh) {
+if(memcmp(id, neigh->id, 16) == 0 && neigh->network == net)
+return neigh;
+}
+return NULL;
+}
+
void
flush_neighbour(struct neighbour *neigh)
{
@@ -84,6 +95,22 @@
neigh = NULL;
}
}
+
+neigh = find_neighbour_by_id(id, net);
+if(neigh) {
+if((neigh->reach & 0xE000) == 0) {
+/* The other neighbour is probably obsolete. */
+flush_neighbour(neigh);
+neigh = NULL;
+} else {
+fprintf(stderr, "Duplicate neighbour %s (%s and %s)!\n",
+format_address(id),
+format_address(neigh->address),
+format_address(address));
+return NULL;
+}
+}
+
debugf("Creating neighbour %s (%s).\n",
format_address(id), format_address(address));
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] ahcpd network ipv4 problem
> I've kept busy with some exams I hope it went well. > Now my Kamikaze 7.09 Linksys router gives right ipv6-s in the network. Good. > But still dosen't provide ipv4 adresses. > but when i try to ping6 the router from a wireless laptop it prints > "no route to host". Ahcpd won't work until you fix this. Ahcpd uses the Ipv6 routing infrastructure to contact the stateful server. Check if Babel is running, and if your ipv6 routing tables are okay. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Convergence problem
> But problem with convergence is still present, not always but sometimes. I understand that: - the rxcost on the Alix board remains stuck at infinity; - and hence the txcost on the SuSE PC is at infinity too. If so, it looks like an issue with the link quality estimation. I've found one typo in this code, for which I'm attaching a fix; let me know if it fixes your issues. If it doesn't, I'd be glad if you could confirm that the Alix board is receiving the Hellos from the PC when the problem happens (tcpdump should show if you're receiving the Babel packets). Juliusz Mon Jul 7 20:35:55 CEST 2008 Juliusz Chroboczek <[EMAIL PROTECTED]> * Fix typo when handling late hellos. No hello is -1, not 0. diff -rN -u old-babel/neighbour.c new-babel/neighbour.c --- old-babel/neighbour.c 2008-07-07 20:39:36.0 +0200 +++ new-babel/neighbour.c 2008-07-07 20:39:36.0 +0200 @@ -174,7 +174,7 @@ packets during a link outage. Ignore it, but reset the expected seqno. */ neigh->hello_seqno = hello; -hello = 0; +hello = -1; missed_hellos = 0; } rc = 1; ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] Loose ends with Babel
There are a few things that keep nagging me about the current protocol spec and implementation, and that I may decide to fix at some point. This is more of a note to self then a public discussion, but don't hesitate to chime in if you have any comments. 1. The IHU definition is broken Babel identifies routers with router ids, and interfaces with link-local addresses. Link quality is a property of a pair of interfaces, not a pair of routers. The IHU message should be carrying an interface id (a link-local address) rather than a router-id. This is the fundamental reason for the previous issue reported by Robert (the one with multiple link-local addresses). (I'm not so sure about HELLO messages; keeping the router id in them might be a good idea, in order to simplify debugging.) Fixing that will require an incompatible protocol revision. It's definitely a good idea. 2. The handling of idle interfaces is idiosyncratic Idle interfaces (see -i in the manual page) are handled in an idiosyncratic manner, by a bunch of ifs sprinkled throughout the code. It'd be nice to clean up this mess. 3. The handling of down interfaces is idiosyncratic The handling of down interfaces (interfaces that are currently down, or, if -l was specified, that report no link sense) are handled idiosyncratically, by a bunch of ifs throughout the code. I'm not sure this can be fixed, cross-layer indications are notoriously tricky to do in a modular way. 4. The protocol is bloated The protocol currently uses fixed-length 24-byte messages, large enough to contain an IPv6 address. This means its sweet and simple, but makes some messages somewhat larger than they could be. Switching to variable-length messages (smaller for IPv4 than for IPv6) will reduce the size of update messages by 2/3 for pure IPv4 networks, and by 1/3 on mixed-stack networks. I've done a pretty good job of reducing unnecessary update traffic, so I'm not sure that it's really worth the trouble. This, again, will require an incompatible change, and I'm not sure it's a good idea. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] Convergence problem
> It seems that patch fixed the problem. I dont see that kind problem anymore. Excellent news. Let me know if you notice anything else. Thanks a lot for your debugging, Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] FW: Loose ends with Babel
>From my point of view, it would be nice to have shorter massages, >because I am using protocol on very limited bandwidth link, also is >better to have shorter messages anyway. Well, if you're running over low-throughput links, you're probably already doing link-layer compression (PPP BSD or Deflate compression, most likely), so encoding Babel messages in a more compact manner will buy you very little. I'm really not convinced either way, I guess we'll need more experience and larger deployments in order to know. Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
[Babel-users] ANNOUNCE: babel 0.15
Dear all, Babel 0.15 is now available on http://www.pps.jussieu.fr/~jch/software/files/babel-0.15.tar.gz http://www.pps.jussieu.fr/~jch/software/files/babel-0.15.tar.gz.asc For more information about Babel, please see http://www.pps.jussieu.fr/~jch/software/babel/ This version fixes a rather unpleasant bug that could cause link quality to remain stuck at infinity under some circumstances. It also recovers faster when a neighbour has the bad taste to change its link-local address (e.g. when running some implementations of PPP) and further improves scalability when redistributing massive amounts of external routes. Juliusz 8 July 2008: babel 0.15: * Fixed a bug that could break link-quality estimation on yo-yo links. * Protect against duplicate neighbour ids on the same interface. * More tweaks to improve scaling with the number of kernel routes. * Tweaked the default update interval. pgppblgrJFpqQ.pgp Description: PGP signature ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
Re: [Babel-users] FW: Loose ends with Babel
> From my point of view, it would be nice to have shorter massages, > because I am using protocol on very limited bandwidth link, Speaking about that, Robert, perhaps you could tell us more about your setup? You appear to be doing unusual stuff (I have trouble imagining why you'd prefer PPP over serial to an Ethernet link). > also is better to have shorter messages anyway. I'll expand about that a little. In Babel, I distinguish between messages and packets. A message is always 24 bytes long, and can carry one route, IPv4 or IPv6. A packet consists of an 8-byte header followed with an arbitrary number of messages followed by an optional cryptographic signature (not implemented at the current time). Now 24 bytes for an IPv4 route is overkill; it could fit in 8 bytes. If you're compressing your PPP link, you don't care -- the extra data are mostly zeroes, and will compress beautifully. What's more, Babel sends reachability data at very large intervals (there are other mechanisms that ensure that the routing is mostly up-to-date usually, and that even when it isn't, the network keeps working, although not optimally). The alternative would be to encode the Babel protocol as ``type-length-value'' triples. This would make it more complex, more difficult to parse, but would save quite a bit of space for IPv4 routes. I'm not sure if it's worth my while; we'll only know when we deploy larger Babel networks. Regards, Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users
