August 2008 - Bird-users

New commands for OSPF
by Ondrej Zajicek 27 Aug '08

27 Aug '08

Hello I implemented two CLI commands for OSPF giving nice informative (and still machine parsable) representation of OSPF network graph (based on datas from the LSA database). The first command (show ospf topology) shows routers, networks and stub networks, The second command (show ospf state) shows also external routes and area-external networks and routers propagated by given area boundary router. The patch and examples of output are attached (if you wonder why there are so many external routes, that is because i didn't realized that if i import local routes to OSPF, i get them as external routes even when they are already here as stub networks). If you have some better ideas for command names and keywords (especially 'state' command and 'xrouter' and 'xnetwork' keyword) i would like to change that. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago(a)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."

1 0

Some minor bugfixes
by Ondrej Zajicek 27 Aug '08

27 Aug '08

Hello Hera are some minor bugfixes: 1) Missing newline. 2) Check for buffer overflow was too eager. 3) Fix for strcpy (instead of the rejected Debian patch). -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago(a)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."

1 0

Even more patches
by Ondrej Zajicek 25 Aug '08

25 Aug '08

[ The first email does not come, resending. Is there some problem with mailing list? ] Hello First patch fixes bug causing reconfigure completely not work on OSPF. Second patch fixes endianity problem in debug message. Next three patches are from Debian package of bird. Maybe you already know them. The last one is needed to be able to compile bird on recent system, it is rather large, so i do not attached it. it is here: ftp://varda.crfreenet.org/users/santiago/misc/000_update_config_guess_sub.p… -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago(a)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."

4 11

Re: Some patches
by Ondrej Zajicek 25 Aug '08

25 Aug '08

On Mon, Aug 25, 2008 at 11:49:21AM +0200, Martin Mares wrote: > The /30 networks can be considered point-to-point links in some cases, > so we maintain the address of the other end in the same way as we do > for unnumbered P-t-P networks. Hmm, but perhaps there is some another bug: ath0 up (index=4) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 192.168.31.18/30 (Primary, broadcast 192.168.31.19, opposite 192.168.31.19, scope site) opposite should be 192.168.31.17 Hmm #define ipa_opposite(x) _MI(_I(x) ^ 1) - this is correct for /31 ptp links (that are valid according to RFC 3021), but not for /30 ptp links. There should be ^ 3 ? -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago(a)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."

2 2

Re: Some patches
by Ondrej Zajicek 25 Aug '08

25 Aug '08

On Mon, Aug 25, 2008 at 10:44:17AM +0200, Martin Mares wrote: > > The second patch causes that 'Invalid broadcast address' error is reported > > only once for an interface and not during every interface scan. > > I wonder: do we need to read the broadcast address set by ifconfig at all? > It tends to be unreliable and I have never seen a system where the broadcast > address is not set to the last address in the subnet. If the broadcast address set using ifconfig is misconfigured, the canonical one (last address in the subnet) still works? BTW, what is the reason for this (from netlink.c:380): if (i->ifa_prefixlen == BITS_PER_IP_ADDRESS - 2) ifa.opposite = ipa_opposite(ifa.ip); ? AFAIK /30 mask does not need special handling. - Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago(a)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."

2 1

Re: Bug in OSPF
by Ondrej Zajicek 25 Aug '08

25 Aug '08

On Mon, Aug 25, 2008 at 10:47:44AM +0200, Martin Mares wrote: > I would very much like to avoid including anything in asm/... and especially > using HZ. The proper way to get HZ is to call sysconf(_SC_CLK_TCK). This > should be portable to all POSIX systems. I supposed this variant to be linux 2.4 specific workaround and clock_gettime() to be the portable one. The code has more linux-specific assumtions (like that time_t is 32bit integer). > Anyway, is there any problem in using time() as previously, but detect > timewarps? There are two ways to do it - the first one keeps 'now' variable monotonic (using time() and detecting timewarps), the second keeps current time in 'now' variable and fixes its users (like event loop) to not suppose monotonicity. IMHO the first way does not have any advantages, 'now' variable wouldn't have no well defined meaning, the second way is unnecessary hard. Although later i found that some parts of bird suppose that 'now' contains real time (some user outputs printing and password validity check) i think it is more easy to fix these. For example when route appears, it gets timestamp that is printed using 'show route'. Timestamp might be relative monotonic time and during print i can compute the time of route appearance by using current time() and offset between monotonic timers. This will show correct time even when system tiwe was broken during route appearance. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago(a)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."

1 0

Bug in OSPF
by Ondrej Zajicek 25 Aug '08

25 Aug '08

Hello After some time i looked again on bug in OSPF that i met before: "Sometimes the link between two routers hangs. Bird reports for example ptp/exstart at one side and ptp/exchange at the other side. Or full/ptp at one side and nothing at the other side." I observed three cases: 1) first node stuck in init/ptp, second node don't even see first node as neighbour. According to tcpdump, first node don't send hello packets. 2) first node (192.168.36.130) stuck in loading/ptp tcpdump: ... 11:54:38.126821 IP 192.168.36.130 > 224.0.0.5: OSPFv2, Hello (1), length: 48 11:54:38.127048 IP 192.168.36.2 > 224.0.0.5: OSPFv2, Hello (1), length: 48 11:54:39.126493 IP 192.168.36.130 > 224.0.0.5: OSPFv2, Hello (1), length: 48 11:54:39.128045 IP 192.168.36.2 > 224.0.0.5: OSPFv2, Hello (1), length: 48 11:54:38.127613 IP 192.168.36.130 > 192.168.36.2: OSPFv2, LS-Request (3), length: 36 11:54:38.129563 IP 192.168.36.2 > 192.168.36.130: OSPFv2, LS-Update (4), length: 88 11:54:38.131034 IP 192.168.36.130 > 192.168.36.2: OSPFv2, LS-Ack (5), length: 44 11:54:39.126067 IP 192.168.36.130 > 192.168.36.2: OSPFv2, LS-Request (3), length: 36 11:54:39.129339 IP 192.168.36.2 > 192.168.36.130: OSPFv2, LS-Update (4), length: 88 11:54:39.130246 IP 192.168.36.130 > 192.168.36.2: OSPFv2, LS-Ack (5), length: 44 11:54:40.125492 IP 192.168.36.2 > 224.0.0.5: OSPFv2, Hello (1), length: 48 11:54:40.126112 IP 192.168.36.130 > 224.0.0.5: OSPFv2, Hello (1), length: 48 11:54:40.126615 IP 192.168.36.130 > 192.168.36.2: OSPFv2, LS-Request (3), length: 36 11:54:40.127747 IP 192.168.36.2 > 192.168.36.130: OSPFv2, LS-Update (4), length: 88 11:54:40.129674 IP 192.168.36.130 > 192.168.36.2: OSPFv2, LS-Ack (5), length: 44 11:54:41.126490 IP 192.168.36.130 > 224.0.0.5: OSPFv2, Hello (1), length: 48 11:54:41.128826 IP 192.168.36.2 > 224.0.0.5: OSPFv2, Hello (1), length: 48 11:54:41.126068 IP 192.168.36.130 > 192.168.36.2: OSPFv2, LS-Request (3), length: 36 11:54:41.129284 IP 192.168.36.2 > 192.168.36.130: OSPFv2, LS-Update (4), length: 88 11:54:41.130056 IP 192.168.36.130 > 192.168.36.2: OSPFv2, LS-Ack (5), length: 44 ... 3) first node (192.168.36.130) oscillating between loading/ptp and exstart/ptp We can see, that first node also don't send hello packets. tcpdump: 14:24:07.822578 IP 192.168.37.130 > 224.0.0.5: OSPFv2, Hello (1), length: 48 14:24:07.823062 IP 192.168.37.130 > 192.168.36.130: OSPFv2, Database Description (2), length: 32 14:24:07.823588 IP 192.168.36.130 > 192.168.37.130: OSPFv2, Database Description (2), length: 32 14:24:08.824388 IP 192.168.37.130 > 192.168.36.130: OSPFv2, Database Description (2), length: 32 14:24:08.825092 IP 192.168.36.130 > 192.168.37.130: OSPFv2, Database Description (2), length: 692 14:24:08.825660 IP 192.168.36.130 > 192.168.37.130: OSPFv2, LS-Request (3), length: 60 14:24:08.826215 IP 192.168.37.130 > 224.0.0.5: OSPFv2, Hello (1), length: 48 14:24:08.827254 IP 192.168.37.130 > 192.168.36.130: OSPFv2, Database Description (2), length: 692 14:24:08.829550 IP 192.168.36.130 > 192.168.37.130: OSPFv2, Database Description (2), length: 32 14:24:09.822583 IP 192.168.37.130 > 224.0.0.5: OSPFv2, Hello (1), length: 48 14:24:09.822828 IP 192.168.37.130 > 192.168.36.130: OSPFv2, Database Description (2), length: 32 14:24:09.823636 IP 192.168.36.130 > 192.168.37.130: OSPFv2, Database Description (2), length: 32 14:24:10.820982 IP 192.168.37.130 > 192.168.36.130: OSPFv2, Database Description (2), length: 32 14:24:10.821474 IP 192.168.37.130 > 224.0.0.5: OSPFv2, Hello (1), length: 48 14:24:10.821816 IP 192.168.36.130 > 192.168.37.130: OSPFv2, Database Description (2), length: 692 14:24:10.822213 IP 192.168.36.130 > 192.168.37.130: OSPFv2, LS-Request (3), length: 60 14:24:10.823820 IP 192.168.37.130 > 192.168.36.130: OSPFv2, Database Description (2), length: 692 14:24:10.824445 IP 192.168.36.130 > 192.168.37.130: OSPFv2, Database Description (2), length: 32 14:24:11.822592 IP 192.168.37.130 > 224.0.0.5: OSPFv2, Hello (1), length: 48 14:24:11.822836 IP 192.168.37.130 > 192.168.36.130: OSPFv2, Database Description (2), length: 32 14:24:11.823629 IP 192.168.36.130 > 192.168.37.130: OSPFv2, Database Description (2), length: 32 14:24:12.821025 IP 192.168.37.130 > 192.168.36.130: OSPFv2, Database Description (2), length: 32 I assume that the problem is in timer handling code, which breaks during system time change (for example by agressive NTP daemon). When i manually fiddled with system time, i often triggered the problem. Here are two patches to fix this problem. First patch si probably better but don't work on linux 2.4.x. Second patch should work on it. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago(a)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."

3 2

Some patches
by Ondrej Zajicek 25 Aug '08

25 Aug '08

Hello Bird sometimes reported 'bird: nl_parse_link: Malformed message received'. The cause is that bird asynchronously received netlink packet from wireless driver about some wireless event on its link layer. In that case bird shouldn't complain. This is fixed by the first patch. The second patch causes that 'Invalid broadcast address' error is reported only once for an interface and not during every interface scan. BTW, the behavior of the automatic OSPF password ID selection looks very strange to me. If i have several interfaces and one passord for each, then each password gets different ID based on position in config file. This is bug or feature? This looks almost useless to me and i think that automatic IDs might start with 1 for each interface. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago(a)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."

4 4

Bugs related to ptp links
by Ondrej Zajicek 25 Aug '08

25 Aug '08

The code generating LSAs for ptp ospf links is buggy. The current behavior is that it generates ptp link if there is a full/ptp neighbor and stub link if there isn't. According to RFC 2328, the correct behavior is to generate stub link in both cases (in the first case together with ptp link). And because of buggy detection of unnumbered networks, for numbered networks the code creates stub links with 0.0.0.0/32. The first patch corrects this behavior, but i am not sure what is the best behavior for unnumbered (ptp-address) networks. The code contains variable ptp_unnumbered_stub_lsa that determines whether unnumbered ptp links should generate stub links. If enabled, stub links are generated regardless there is a full/ptp neighbor. The second patch makes ospf dump more informative. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago(a)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."

2 2

Bugs related to ptp links
by Ondrej Zajicek 24 Aug '08

24 Aug '08

[ The first email does not come, resending. ] Hello The code generating LSAs for ptp ospf links is buggy. The current behavior is that it generates ptp link if there is a full/ptp neighbor and stub link if there isn't. According to RFC 2328, the correct behavior is to generate stub link in both cases (in the first case together with ptp link). And because of buggy detection of unnumbered networks, for numbered networks the code creates stub links with 0.0.0.0/32. The first patch corrects this behavior, but i am not sure what is the best behavior for unnumbered (ptp-address) networks. The code contains variable ptp_unnumbered_stub_lsa that determines whether unnumbered ptp links should generate stub links. If enabled, stub links are generated regardless there is a full/ptp neighbor. The second patch makes an ospf dump more informative. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago(a)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."

1 0