Subject: Re: [netatalk-admins] Bug? in 4.4BSD kernel code
From: Julian Elischer (julian@whistle.com)
Date: Thu Aug 07 1997 - 00:24:54 EDT
Julian Elischer wrote:
>
> As the porter of the netatalk code to freebsd
> I'll take a look later today..
> I also have some bug-fixes I need to add
> so I'll be in the code anyhow.
>
> julian
>
Ok I've had a look..
the dstaddr (also known as the broadaddr) contains
the address of the other end of the point-to-point link
As we are not a point to point link, this is nominally the
broadcast address instead.
however the broadcast address is known on atalk
so it's not needed as such.
in any case I think that I tried leaving this as
the real broadcast value and it failed to work during route
intialisation.
nothing should be using it that I know of during normal
operation however. If we star supporting P2P links for atalk
then of course we should do it better..
I'll look at it more later however.
> On Tue, 5 Aug 1997, Bill Studenmund wrote:
>
> > For another network project, I was staring at at_control.c in NetBSD, and
> > noticed what looks like a bug. I checked out both the FreeBSD and the
> > netatalk/sys/netatalk a_control.c files, and the questionable code is
> > there too.
> >
> > Basically, when we go to set up a new AppleTalk address, we initialize the
> > at_ifaddr and link it into the address lists. Then, ifdef BSD4_4, we set
> > up the pointers in the ifaddr structure.
> >
> > My question is why we set the ifaddr's ifa_dstaddr to point to the
> > at_ifaddr's NORMAL address, when the at_ifaddr has an AppleTalk
> > destination address structure?
> >
> > The code in question is line 185 of netatalk/sys/netatalk/at_control.c. I
> > think the (struct sockaddr *)&aa->aa_addr should be &aa->aa_dstaddr.
> >
> > Or am I missing something?
> >
> > Take care,
> >
> > Bill
> >
> >
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:26:01 EST