(none)

[Andrew Collins]

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?

if ((rt->rt_flags & RTF_GATEWAY) && dst->sa_family != AF_NS) {
if (rt->rt_gwroute == NULL)
goto lookup;
if (((rt = rt->rt_gwroute)->rt_flags & RTF_UP) == 0) {
rtfree(rt); rt = rt0;
lookup: rt->rt_gwroute = rtalloc1(rt->rt_gateway, 1);
if ((rt = rt->rt_gwroute) == NULL)
senderr(EHOSTUNREACH);
/* the "G" test below also prevents rt == rt0 */
if ((rt->rt_flags & RTF_GATEWAY) ||
(rt->rt_ifp != ifp)) {
rt->rt_refcnt--;
rt0->rt_gwroute = NULL;
senderr(EHOSTUNREACH);
}
}
}

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?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Andrew Collins
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?

Post by Andrew Collins
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
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