On Tue, Sep 22, 2009 at 02:08:40PM +0200, KORN Andras wrote:
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
Could you send me shell commands that sets these routes?
Sure. Just prepend 'ip ro add' and append 'table 3' to each line, like this:
ip ro add 172.18.68.254/32 dev tap5 scope link src 172.18.32.254 table 3 ip ro add 10.10.107.0/24 via 172.18.68.254 dev tap5 src 172.18.32.254 table 3
That i tried but doesn't work for me: rb1:~# ip a a 10.0.0.1/32 dev eth0 rb1:~# ip r a 10.0.1.1/32 dev eth0 scope link src 10.0.0.1 table 3 rb1:~# ip r a 10.0.2.0/24 via 10.0.1.1 dev eth0 src 10.0.0.1 table 3 RTNETLINK answers: No such process
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)
BIRD expects that interface uses either 'standard' network address, or address with /32 mask and specified peer address (configured with 'ip address add IP1 peer IP2 dev DEV' or similarly using ifconfig and pointopoint). In both cases there should not be this warning as this warning means that Hello message was ignored.
OK, I will retry with this kind of peer setup, but I think I can't test anything meaningfully while my routes cause a segfault.
I think that both problems are related. If you use: ip addr add dev tap5 172.18.32.254/32 peer 172.18.68.254 instead of ip addr add dev tap5 172.18.32.254/32 ip ro add 172.18.68.254/32 dev tap5 scope link src 172.18.32.254 table 3 then i expect that both problems would disappear. Of course, we should also fix that segfault anyway. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."