On Tue, 18 May 2004 11:54:03 -0400, Christos Zoulas <christos@zoulas.com> wrote:
> 
> On May 18, 11:51am, erplefoo@gmail.com (Sean Davis) wrote:
> -- Subject: Re: fxp0: can't handle af118
> 
> | I'm seeing the same thing with tl(4):
> | May 18 11:45:31 eros /netbsd: tl1: can't handle af8
> |
> | I am also using a catch-all return-rst rule...
> |
> | It appears to stem from sys/net/if_ethersubr.c (revision 1.114) line 462-465:
> |   462    default:
> |   463       printf("%s: can't handle af%d\n", ifp->if_xname,
> |   464          dst->sa_family);
> |   465       senderr(EAFNOSUPPORT);
> |
> | if the address family is broken, but different, for fxp, it sounds
> | like it's not getting set somewhere and a value from elsewhere is
> | leaking in, or something similar. I'll see if I can figure out what,
> | but it's been ages since I've looked through the ethernet code.
> |
> | -Sean
> 
> 
> I think the code that is broken is the code that prepares the dst packet
> somewhere in ip_nat or ip_fil.
> 
> christos
> 
> 

Sounds probable to me. I don't see the address family being set
anywhere in the rst-returning code in ip_fil_netbsd.c, but I also
don't see that function referencing the socket directly, so I think
the problem is before that routine somewhere... this merits further
investigation... I can live without the ability to return-rst, but
it's pretty clear to me that something is hosed somewhere around here.
Not to mention the "HOT FIX/KLUDGE" I see that "is gonna be a problem"
on "non-crappy network hardware"... I hope my thunderlan chips are
just crappy enough that they're not affected :-P

-Sean