I ran into a question about the ipif_lookup_interface{_v6} functions
that would apply when tunnels/ppp interfaces are encountered.
the ipif_lookup_interface* functions are only called from the
'route add' and 'route delete' paths, and in those cases, a command
like
# route add <rt_dst> <nexthop>
results in the execution of some wrong-sounding code
(line numbers from ipif_lookup_interface):
5991 if ((ipif->ipif_flags & IPIF_POINTOPOINT) &&
5992 (ipif->ipif_lcl_addr == if_addr) &&
5993 (ipif->ipif_pp_dst_addr == dst)) {
5994 /*
wrong-sounding because we should really be checking if nexthop is
the ipif_pp_dst_addr on IPIF_POINTOPOINT interfaces.
As Jim Carlson points out, the comments at 5978-5981 are completely
counter to what the code above actually does, and it looks like this
"usually" works (when there are no POINTOPOINT interfaces with local
address == rt_dst, remote address == nexthop) because the code drops
down to ipif_lookup_addr{_v6} which then does the right thing.
Is there some corner case being addressed by lines 5991-5994?
Jim pointed out that this code dates to:
> D 1.53.1.1 96/09/25 20:32:57 comay 141 140 00691/00491/03342
> MRs:
> COMMENTS:
> Merged changes between child workspace "/export3/comay/on297-vlsm" and
> parent workspace "/ws/on297-clone".
David: do you remember the details of what this was trying to do?
Along the same lines, are there any subtle reasons why
ipif_lookup_addr{_v6} look at the IPIF_UNNUMBERED flag at all?
That code could be vastly simplified by just checking for
IPIF_POINTOPOINT.
--Sowmini
_______________________________________________
networking-discuss mailing list
[email protected]
