Re: refactoring ip_output() and the L2 _output()

[David Young <dyoung%pobox.com@localhost>]

On Sat, Feb 02, 2013 at 06:15:12PM +1100, Darren Reed wrote:
> David Young wrote:
> >...
> >
> >It's funny that we get into ether_output() with an rtentry that's
> >not even usable.  I'm not sure how that happens.  I will have to
> >look more carefully at what ip_output() is doing.
> >
> >                        if ((rt0 = rt = rtalloc1(dst, 1)) != NULL) {
> >                                rt->rt_refcnt--;
> >                                if (rt->rt_ifp != ifp)
> >                                        return (*rt->rt_ifp->if_output)
> >                                                        (ifp, m0, dst, rt);
> >                        } else
> >senderr(EHOSTUNREACH);
> >                }
> >
> >Yikes!  To call rt->rt_ifp's output routine with a different ifp is not
> >advisable, is it?  ISTR finding a bug in carp(4) involving a similar
> >pattern, ifpX->if_output(ifqY, ...).
> ...
> 
> If both bge0 and bge1 are on the same subnet then a route out
> of either can be used to transmit out either.
> 
> So if bge0's IP is 1.1.1.1 and bge1 is 1.1.1.2 and I want to
> reach 1.1.1.3, a cached route might point to bge0 however the
> kernel could just as easily decide to use bge1 (maybe bge0 is
> down.)
> 
> So in places where you have, for example:
> +            return ip_hresolv_output(rt->rt_ifp, m, dst, rt);
> 
> you should replace the "rt->rt_ifp" with just "ifp".

How is it that we're getting into ether_output() with !RTF_UP routes
to begin with?  Is it that bge0 is down but its routes haven't been
withdrawn yet?

It seems to me that inconsistencies in the routing lead to this
strange code in ether_output().  We could actually prolong
ether_output()'s dithering about which ifp to use forever.

Dave

-- 
David Young
dyoung%pobox.com@localhost    Urbana, IL    (217) 721-9981