Hello, I got in touch with bird after your great presentation at the ripe meeting. I like to use bird on small embeded WLAN routers like the linksys WRT54g, running OpenWRT kamikaze, a uLibc linux system. I've spent several days in getting my configuration running. From today on, it does work (more ore less) and I'd like to describe my problems. I started with bird 1.1.4 (and today 1.1.5) - both birds have the same problem. I cross-compiled bird for uLibc mipsel myself. bird 1.1.5 is only 390252 bytes large (striped, compiled without CFLAG -g); bird 1.1.4 was a bit smaller. Because free flash storage is a problem on these plattforms, I did not use the birdc control program. Instead, I configured bird with log stderr all; debug protocols all; and I started bird with /usr/sbin/bird -c /etc/bird.conf -s /tmp/bird.ctl -d & on both routers. This way I could see what's going on. Bird told it was learning the routes (from OSPF between the two embeded routers), but they did not appear in the kernel routing table. I even used strace and ltrace and saw that bird did not do any system- or library-calls for setting routes. The debug output has not told me why. Unfortunately, bird does only listen on unix sockets. With 256k free "disk" space I could not install birdc, because it depends on libncurses. libncurses is 258343 bytes large. Wrapper programs like socat are also too big. It would be nice if birdc could be used to speak over tcp to the remote system's bird.. Today I copied libncurses and birdc to /tmp (ramfs) and symlinked libncurses to /usr/lib. After this, I was able to use birdc and saw what's going on. linux kernel routing table: # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.25.193.248 * 255.255.255.248 U 0 0 0 br-wlan50LINK 10.25.193.128 10.25.193.64 255.255.255.248 UG 0 0 0 br-lan 10.25.190.248 * 255.255.255.248 U 0 0 0 br-wlan24LINK 10.25.193.144 10.25.193.65 255.255.255.248 UG 0 0 0 br-lan 10.25.193.224 * 255.255.255.240 U 0 0 0 br-wlan24USER 10.25.193.0 * 255.255.255.128 U 0 0 0 br-lan bird> sh ro 10.0.0.0/8 via 10.25.193.254 on br-wlan50LINK [ospf1 12:57] E2 (150/10/10000) 10.25.193.224/28 dev br-wlan24USER [direct1 12:56] (240) 10.25.190.248/29 dev br-wlan24LINK [direct1 12:56] (240) dev br-wlan24LINK [ospf1 12:57] I (150/20) 10.25.193.248/29 dev br-wlan50LINK [direct1 12:56] (240) dev br-wlan50LINK [ospf1 12:57] I (150/10) 192.168.1.0/24 via 10.25.193.254 on br-wlan50LINK [ospf1 12:57] IA (150/20) 127.0.0.0/8 dev lo [direct1 12:56] (240) 10.25.193.0/24 dev lo [static1 12:56] (1000) 10.25.193.0/25 dev br-lan [direct1 12:56] (240) 10.25.190.0/24 via 10.25.193.254 on br-wlan50LINK [ospf1 12:57] E2 (150/10/10000) 10.25.190.0/25 via 10.25.193.254 on br-wlan50LINK [ospf1 12:57] E2 (150/10/10000) -> as you can see, the kernel did not learn the routes from the ospf neighbor (10.25.193.254) like 10/8, 10.25.190.0/25, etc. "sh protocols" shows that all protocols are running. I assumed that "sh ro" should tell me also about kernel routes - but it doesn't. Here's the solution: bird> disable kernel1 kernel1: disabled bird> enable kernel1 kernel1: enabled bird> show route 0.0.0.0/0 via 10.25.193.254 on br-wlan50LINK [ospf1 13:03] E2 (150/20/10000) 192.168.99.0/24 via 10.25.193.254 on br-wlan50LINK [ospf1 13:03] E2 (150/20/10000) 10.0.0.0/8 via 10.25.193.254 on br-wlan50LINK [ospf1 12:57] E2 (150/10/10000) 10.25.193.224/28 dev br-wlan24USER [direct1 12:56] (240) 10.25.190.248/29 dev br-wlan24LINK [direct1 12:56] (240) dev br-wlan24LINK [ospf1 12:57] I (150/20) 10.25.193.248/29 dev br-wlan50LINK [direct1 12:56] (240) dev br-wlan50LINK [ospf1 12:57] I (150/10) 192.168.1.0/24 via 10.25.193.254 on br-wlan50LINK [ospf1 12:57] IA (150/20) 127.0.0.0/8 dev lo [direct1 12:56] (240) 10.25.193.0/24 dev lo [static1 12:56] (1000) 10.25.193.0/25 dev br-lan [direct1 12:56] (240) 10.25.193.128/29 via 10.25.193.64 on br-lan [kernel1 13:02] (10) 10.25.190.0/24 via 10.25.193.254 on br-wlan50LINK [ospf1 12:57] E2 (150/10/10000) 10.25.190.0/25 via 10.25.193.254 on br-wlan50LINK [ospf1 12:57] E2 (150/10/10000) 10.25.193.144/29 via 10.25.193.65 on br-lan [kernel1 13:02] (10) and now the linux kernel routing table looks like this: # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.25.193.248 * 255.255.255.248 U 0 0 0 br-wlan50LINK 10.25.193.128 10.25.193.64 255.255.255.248 UG 0 0 0 br-lan 10.25.190.248 * 255.255.255.248 U 0 0 0 br-wlan24LINK 10.25.193.144 10.25.193.65 255.255.255.248 UG 0 0 0 br-lan 10.25.193.224 * 255.255.255.240 U 0 0 0 br-wlan24USER 10.25.190.0 10.25.193.254 255.255.255.128 UG 0 0 0 br-wlan50LINK 10.25.193.0 * 255.255.255.128 U 0 0 0 br-lan 10.25.190.0 10.25.193.254 255.255.255.0 UG 0 0 0 br-wlan50LINK 192.168.1.0 10.25.193.254 255.255.255.0 UG 0 0 0 br-wlan50LINK 192.168.99.0 10.25.193.254 255.255.255.0 UG 0 0 0 br-wlan50LINK 10.25.193.0 * 255.255.255.0 U 0 0 0 lo 10.0.0.0 10.25.193.254 255.0.0.0 UG 0 0 0 br-wlan50LINK default 10.25.193.254 0.0.0.0 UG 0 0 0 br-wlan50LINK Ok, that's fine now. But I cannot do this without manually disable-/enableing protocol kernel1 via birdc. Do you have any ideas what causes this problem? As you can see, it's beautiful with bird to set up two direct paths to the same ospf neighbor: the first is a the primary wlan link on 5GHz with high ospf priority and the second is a backup wlan link on 2.4GHz with lower ospf priority If 5GHz fails, the 2.4GHz link is used, at both sides. Btw, when do you expect bird's ospf will learn the NSSA (not-so-stubby area) feature? Regards, - Thomas PS: I'm not subscribed to the mailing-list yet. ----- End forwarded message -----