cvs commit: ports/net/netatalk Makefile distinfo pkg-plist

Robert Watson rwatson at
Sat Jan 8 22:11:33 PST 2005

On Sun, 9 Jan 2005, Joe Marcus Clarke wrote:

> > > >   Modified files:
> > > >     net/netatalk         Makefile distinfo pkg-plist
> > > >   Log:
> > > >   Update to 2.0.2.
> > > 
> > > 	Is PR kern/4184 still an issue with this version update?
> > 
> > Good question.  The aarp.c patch is no longer needed, but it looks like
> > the ddp_output.c patch applies.  I have never had a report of netatalk
> > working or not working on an Alpha, so I'm not sure if this patch really
> > fixes anything or not.
> > 
> > I'm adding rwatson to the Cc since he was the last to touch the netatalk
> > code, and could probably give a more informed opinion.

I currently don't have an AppleTalk network up and available for testing
other than in fairly trivial ways, so don't have too informed an opinion,
especially for the AppleTalk phase issue. 

The first patch in the PR appears already to have been applied. 

The second patch sounds like a a reaosnable problem diagnosis; the mbuf
handling in this part of the netatalk is pretty sloppy and should be
rewritten.  In particular, there are a number of assumptions about headers
fitting into available mbuf space without run-time or compile-time
checking (for example, that struct elaphdr fits in an mbuf).  However, I'm
not quite sure I agree with the solution presented in the PR: presumably
the problem is that some piece of code receives this mbuf and makes poor
assumptions about its layout in mbufs, and fails to perform a necessary
m_pullup()?  Seeing m_pull() with MHLEN/m.pkthdr.len suggests that the
requirements for alignment and layout aren't fully known, such that this
is a workaround rather than a solution.  It's a pity the PR doesn't
indicate what piece of code it is that stumbles over the mbuf later. 

I think I'm not in a position to take immediate action on this one -- it
would be interesting to know if we could find someone with an active and
complex AppleTalk network who could give this code a spin on a system
where alignment is more of an issue and let us know what happens. 
Otherwise I'd be tempted to suspend the PR as "not currently in a position
to do something about this".

Robert N M Watson

More information about the cvs-all mailing list