July 2005 - Bird-users - Mailing Lists

[Patch] Basic fixes for 64 bit platforms
by Jacek Konieczny 25 Jul '05

25 Jul '05

Hello, I have installed bird on my new 64-bit (Opteron-based) router. And it crashed as soon as I tried "show route" command via "birdc". I checked the compilation logs and found out that the bird code makes a Very Bad Assumption (sizeof(int)>=sizeof(void*)) in several places. On AMD64 and several other 64-bit platforms pointers are 64 bit long, but "int" is still 32-bit and not enough to hold a pointer value. I made a patch (attached) which fixes all the bugs which were detected by the compiler (complaining about integer/pointer size mismatch). Greets, Jacek

2 1

bird daemon not closing stdin, stdout and stderr
by Roberto Moreda 24 Jul '05

24 Jul '05

Hi, again. I've found something that make bird fail in situations like when a "kidled" daemon kills the processes attached to a tty. When bird goes on daemon mode (not -d flag) it doesn't close the standard file descriptors (in, out and err), so the proccess continues "attached" to the tty. When kidled calls fuser to send signals to the processes attached to the tty, bird is killed. Regards. Roberto -- Roberto Moreda Allenta Consulting UNIX, Linux & Security Services

1 0

[PATCH] bug freeing dbdes on iface MTU change
by Roberto Moreda 22 Jul '05

22 Jul '05

Hi. I have found a bug that fires up using OSPF when I change an interface MTU (see patch attached). On freeing the ospf_packet with the old link database description we must use mb_free, not rfree. There's any new fixes on OSPF waiting for bird 1.0.12 :-) Regards. Roberto -- Roberto Moreda Allenta Consulting UNIX, Linux & Security Services

1 1

OSPF fails after birdc "configure"
by Roberto Moreda 18 Jul '05

18 Jul '05

Hi! Using bird for OSPF I've found that after two fast and consecutive configuration reloads (using birdc, command "configure") the md5 authentication fails, logging something like that: 18-07-2005 16:21:16 <ERR> Bad OSPF packet from 192.168.1.20 - authentification failed 18-07-2005 16:21:16 <ERR> Bad OSPF packet from 192.168.2.20 - authentification failed ... As side effect the bird process on other OSPF nodes die with signal 11 (!) All works again if bird is restarted on the reconfigured node and on the others who died. The password config section on the ospf protocol defined is something like: ... interface "tun*" { authentication cryptographic; passwords { password "verysecretindeed"; }; }; ... Do you any issues on stability of bird using birdc to reload configuration and such? Thanks in advance. Roberto -- Roberto Moreda Allenta Consulting UNIX, Linux & Security Services

1 1

Little bug in documentation
by Roberto Moreda 11 Jul '05

11 Jul '05

Hi. I think there's a little bug in the documentation of the import_control function. In the nest/proto-hooks.c file, source of the published documentation, the "Result" is: "-1 if the route has to be accepted, 1 if rejected and 0 if it should be passed to the filters." Looking at the code this is not true: 1 means accepted and -1 not accepted. Regards and keep up the good work :-) Roberto PS: I found that investigating some problem related with rip protocol "forced" routes... probably more on this in a little while :-) -- Roberto Moreda Allenta Consulting UNIX, Linux & Security Services

2 3

OSPF problem
by Eric Leblond 08 Jul '05

08 Jul '05

Hi bird people, A client of mine has some problem with OSPF protocol. The setup is as follow : GW --- VPN1 \ \___VPN2 VPN1 and VPN2 are cisco running OSPF and GW is a linux GW. OSPF is here to have dynamic route to VPN clients which can connect to VPN1 or VPN2 (load balancing) OSPF is working fine but after some times, it seems that some route are not added correctly. For exemple, VPN1 announces a new route but GW still has a route to VPN2. A bird reload is enough to have the correct route imported. The configuration of OSPF is as follow : protocol ospf VPN { import filter vpn_net; export filter my_exports; export where source = RTS_STATIC; area 0.0.0.0 { interface "eth2" { cost 10; hello 10; priority 0; retransmit 4; neighbors { 192.126.9.4 eligible; 192.126.9.5; }; authentication cryptographic; password "Password"; type broadcast; }; }; } Is this a configuration problem ? BR, -- Éric Leblond, eleblond(a)inl.fr Téléphone : 01 44 89 46 40, Fax : 01 44 89 45 01 INL, http://www.inl.fr

1 0

Exporting only one network via RIP
by Roberto Suarez Soto 04 Jul '05

04 Jul '05

Hi, I'm testing bird, using RIP, and I've stumbled on a problem. It seems that it wants to export every route that comes via RIP, while I only want to export one. I'll explain. We've got two boxes: box A is a firewall, and gives Internet access to a LAN behind it (directly attached to a box's ethernet) that we'll call network 1; bird is installed here. Box B is also a firewall, but gives Internet access to several networks; let's call them networks 2, 3 and 4; we're using Quagga in this one. They are connected via IPSec in transport mode, and the real communication goes through a GRE tunnel. Bird is set to use this tunnel to propagate routes between the two points. The aim of this is to have a failsafe link: both extremes have a static route with lower priority defined in bird's configuration, so if Internet connectivity is lost they rely on a point-to-point link (more expensive). But when there is normal connectivity, box A will transmit the route to network 1 via RIP, and box B will transmit the routes to networks 2, 3 and 4 via RIP too. This is also done to ease maintenance: when there is another network behind box B, we just have to add it to RIP and it propagates to box A, connecting all networks. There are other circumstances that motivate this use of RIP, but they don't matter right now :-) So, the ideal situation would be that bird on box A transmitted the route to network 1 via RIP, and that it imported the routes to network 2, 3 and 4 via RIP too. But what happens is that it exports the route to network 1 ... and to whatever route it receives via RIP. This means that box A is exporting via RIP the routes to networks 1, 2, 3 and 4, while only network 1 is its "own" route (because it has a IP in that network). This is the configuration that I have in RIP: protocol rip { preference 200; interface "tun00rg" { mode multicast; }; authentication none; import where source = RTS_RIP; export filter { if net ~ 172.16.10.0/24 then accept; else reject; }; period 10; garbage time 45; timeout time 15; } Network 1 is 172.16.10.0/24. I think that maybe I'm missing something in how filters work, or what's the behaviour of "import" and "export", but I've tried all combinations and I'm a bit lost :-) Am I doing something wrong? Is this some bug/feature of bird that I'm not aware of? Am I just not using the right filters? I've put just the configuration of RIP, but I can put the rest of the configuration file, and even tcpdump captures of the RIP transmissions. Ask freely. Thanks in advance :-) -- Roberto Suarez Soto Allenta Consulting robe(a)allenta.com www.allenta.com

1 0