Subject: Re: fxp0: can't handle af118
To: Christos Zoulas <firstname.lastname@example.org>
From: Sean Davis <email@example.com>
Date: 05/18/2004 12:15:56
On Tue, 18 May 2004 11:54:03 -0400, Christos Zoulas <firstname.lastname@example.org> wrote:
> On May 18, 11:51am, email@example.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.
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