[EMAIL PROTECTED] wrote:
> 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?
I have some vague recollection that routing daemons sometimes delete the
interface routes (that are created as a result of an ipif; the kernel
doesn't prevent this), and that as a result we needed to be able to
recreate those interface routes with a route add command. But I think
that was for non-point2point interfaces. In any case, I just tested and
I can't add such a route.
>
> 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.
For the unnumbered case we should never compare with ipif_lcl_addr since
that is by definition assigned to some other ipif, and we want to match
that ipif.
In any case, there is only one line to check UNNUMBERED, so that isn't
the root cause of the complexity of the function.
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
