1.1.3 segfaults on seeing certain routes
KORN Andras
korn-birdusers at elan.rulez.org
Mon Sep 21 13:39:56 CEST 2009
Hi,
Background: I'm completely new to BIRD. I have five locations connected via
OpenVPN in a full mesh, using Linux 2.6 routers, and I thought I'd try
dynamic instead of static routing. At first I just wanted to see how/what
BIRD would do, so I set it to use kernel routing table 3 which I don't use
for policy routing. I copied the contents of my other routing tables into
table 3 and fired up bird, which promptly segfaulted.
gdb shows:
#0 0x00007ffff7901210 in strlen () from /lib/libc.so.6
#1 0x000000000043fe3c in bvsnprintf (buf=0x7fffffffdab0 "via 172.18.68.254 on ", size=999999979, fmt=0x441b2b "s", args=0x7fffffffd960) at printf.c:232
#2 0x000000000044071c in bsprintf (buf=0x7fffffffdab0 "via 172.18.68.254 on ", fmt=0x441b20 "via %I on %s") at printf.c:372
#3 0x0000000000403b67 in rt_format_via (e=0x683300, via=0x7fffffffdab0 "via 172.18.68.254 on ") at /tmp/bird-1.1.3/nest/rt-table.c:1052
#4 0x0000000000401ded in rte_trace (p=0x6771c0, e=0x683300, dir=62, msg=0x4419af "added [best]") at /tmp/bird-1.1.3/nest/rt-table.c:142
#5 0x0000000000402b17 in rte_trace_in (flag=2, p=0x6771c0, e=0x683300, msg=0x4419af "added [best]") at /tmp/bird-1.1.3/nest/rt-table.c:150
#6 0x00000000004027bb in rte_recalculate (table=0x674640, net=0x682118, p=0x6771c0, src=0x6771c0, new=0x683300, tmpa=0x0) at /tmp/bird-1.1.3/nest/rt-table.c:436
#7 0x0000000000402d8a in rte_update (table=0x674640, net=0x682118, p=0x6771c0, src=0x6771c0, new=0x683300) at /tmp/bird-1.1.3/nest/rt-table.c:633
#8 0x0000000000439b61 in krt_learn_announce_update (p=0x6771c0, e=0x6830f0) at krt.c:283
#9 0x000000000043a039 in krt_learn_prune (p=0x6771c0) at krt.c:386
#10 0x000000000043a9ae in krt_prune (p=0x6771c0) at krt.c:677
#11 0x000000000043aaea in krt_scan (t=0x67fa60) at krt.c:729
#12 0x000000000043723e in tm_shot () at io.c:355
#13 0x0000000000438d80 in io_loop () at io.c:1260
#14 0x000000000043c5c3 in main (argc=4, argv=0x7fffffffe008) at main.c:471
The following routes are sufficient (but maybe not all of them necessary) to
reproduce the segfault:
# ip ro sh table 3
172.18.68.254 dev tap5 scope link src 172.18.32.254
10.10.107.0/24 via 172.18.68.254 dev tap5 src 172.18.32.254
192.168.12.0/22 via 172.18.68.254 dev tap5 src 172.18.32.254
172.18.64.0/20 via 172.18.68.254 dev tap5 src 172.18.32.254
The bird config reads as follows:
log stderr all;
router id 172.18.32.254;
debug protocols all;
protocol direct {
interface "tap1", "tap2", "tap3", "tap5";
}
protocol kernel {
learn; # Learn all alien routes from the kernel
persist; # Don't remove routes on bird shutdown
scan time 10; # Scan kernel routing table every 20 seconds
export all; # Default is export none
kernel table 3; # Kernel table to synchronize with (default: main)
}
protocol device {
scan time 10; # Scan interfaces every 10 seconds
}
protocol static {
}
protocol ospf vpn {
tick 2;
area 0 {
interface "tap1", "tap2", "tap3", "tap5" {
password "secretsecretsecr";
dead 20;
type pointopoint;
authentication cryptographic;
};
};
}
Additionally, when running with an empty table 3 on one of the neighbours of
this router, it logged messages like:
21-09-2009 12:55:08 <WARN> Received HELLO packet address (172.18.32.254) is inconsistent with the primary address of interface tap4.
It indeed is inconsistent, because all tap interfaces have the same address
on each router (specific to the router, with a /32 mask), and I use host
routes to make them visible on the other end; effectively, my tap links are
point to point. This works perfectly for static routing; I hope BIRD's
warning doesn't mean that it ignores that Hello message...?
Andras
--
Andras Korn <korn at elan.rulez.org> - <http://chardonnay.math.bme.hu/~korn/>
Everybody wants to go to heaven, but nobody wants to die.
More information about the Bird-users
mailing list