Re: your mail

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

On Tue, Nov 08, 2011 at 04:22:46PM -0700, Andrew Collins wrote:
> I'm working on an embedded NetBSD product, and I've hit two issues
> with the networking stack that I'm curious about.
> 
> The first question is related to ether_output's route lookups.  In
> cases where a route has RTF_GATEWAY is set, and there is no rt_gwroute
> or rt_gwroute isn't RTF_UP, a route lookup is done, and after
> obtaining a usable route for the gateway the rt_ifp is checked against
> the current ifp to make sure the route is on the same interface we're
> trying to send from.  What I find odd is that this is *not* done for
> cases where we find a usable rt_gwroute right off the bat, and in
> practice, I see certain situations where a cloned route on another
> interface is picked up for rt_gwroute, then used during the ARP
> request for the gateway.  It ends up sort of working, because
> arpresolve uses the current ifp to make the ARP request so it gets
> sent out the right interface, but we end up in this weird situation
> where we have a route on a different ifp holding information about a
> link level address for a host off of our ifp.  Is there a reason that
> rt_gwroute isn't checked to ensure rt_ifp == ifp even when we don't do
> a lookup?

How does one reproduce this situation where rt_gwroute->rt_ifp != ifp?

> The second question is related to PPP.  I'm running into a case where
> packets getting sent to a local address are actually sent out on the
> wire for PPP devices.  For example:
> 
> pppoe1: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1492
>         inet 192.168.150.1 -> 192.168.149.1 netmask 0xff000000
> 
> If I ping 192.168.150.1, I actually see packets getting emitted on the
> wire where the src addr == dst addr.  Is this espected behavior?

What does 'route -n get 192.168.150.1' say?

Dave

-- 
David Young             OJC Technologies is now Pixo
dyoung%pixotech.com@localhost     Urbana, IL   (217) 344-0444 x24