[Xorp-users] Bugs? recursive malloc, fib2mrib doesn't update nexthop vif, and PIM RP never initiates a Register-Stop

[Pavlin Radoslavov]

> > Interesting. Could you send me the "route add/change/delete" commands
> > how to replicate the problem.
> 
> I added debugging code in routing_socket_utils.cc to show the netmask value.
> 
> I used route add command to add AAAA:BBBB:fad:dead:bee8::/77 prefix
> route. After that, zebra deleted AAAA:BBBB:10a::/64 route, but the
> routing socket sends a netmask with masklen /77, which I believe is
> what's left from my route add command.
> 
> %route -n add -inet6 AAAA:BBBB:fad:dead:bee8:: -prefixlen 77
> fe80::2e0:81ff:fe02:fa52%em0
> add net AAAA:BBBB:fad:dead:bee8::: gateway fe80::2e0:81ff:fe02:fa52%em0
> 
> [ 2006/08/25 10:40:44  ERROR xorp_fea:18632 FEA +512
> routing_socket_utils.cc rtm_get_to_fte_cfg ] RTM type: 1 prefix
> AAAA:BBBB:fad:dead:bee8:: mask ffff:ffff:ffff:ffff:fff8:0:603:600
> masklen 77 nexthop fe80::2e0:81ff:fe02:fa52
> [ 2006/08/25 10:44:03  ERROR xorp_fea:18632 FEA +512
> routing_socket_utils.cc rtm_get_to_fte_cfg ] RTM type: 2 prefix
> AAAA:BBBB:10a:: mask :: masklen 77 nexthop fe80::2e0:81ff:fe02:fa52
> [ 2006/08/25 10:44:03 WARNING xorp_fib2mrib XrlFib2mribTarget ]
> Handling method for fea_fib_client/0.1/delete_route6 failed:
> XrlCmdError 102 Command failed Cannot delete route for
> AAAA:BBBB:10a::/77: no such route
> [ 2006/08/25 10:44:03  ERROR xorp_fea:18632 FEA +550 xrl_fti.cc
> send_fib_client_route_change_cb ] Error sending route change to
> fib2mrib: 102 Command failed Cannot delete route for
> AAAA:BBBB:10a::/77: no such route
> [ 2006/08/25 10:44:04  ERROR xorp_fea:18632 FEA +512
> routing_socket_utils.cc rtm_get_to_fte_cfg ] RTM type: 1 prefix
> AAAA:BBBB:10a:: mask :: masklen 64 nexthop fe80::2e0:81ff:fe02:fa52
> 
> So based on this observation, it seems that the kernel only gives good
> netmask value in n * 32bits boundary.

After some investigation, your observation seems correct, though I
haven't tried to find/confirm the exact boundary (i.e., whether it
is 8 bit or 32 bit).

Sometimes the "struct sockaddr *" pointer to the netmask data might
not contain the whole mask (i.e., the octets with zero at the end).
Hence, we need to copy the mask to a "sockaddr_in6" storage that
has been zeroed in advance, and then calculate the network mask.
This solution is derived from the FreeBSD-6.1 route(8) source code
(inside file route.c, function routename()).

I just committed a fix to CVS:

Revision  Changes                               Path
1.36      +7 -3;  commitid: 17c1944f600ac7ea6;  xorp/fea/routing_socket_utils.cc

Please let me know if you still have the masklen problem.

Thanks,
Pavlin