In some mail I received from Jason Thorpe, sie wrote
> 
> On Mon, 12 Jan 1998 13:18:08 +0100 
>  ws@tools.de (Wolfgang Solfrank) wrote:
> 
>  > The problem is that you cannot be sure that the mbuf does have MLEN/MHLEN
>  > at the address pointer to by mh_data (and thus returned by the mtod macro).
>  > The mh_data pointer might have been incremented beyond its initial value.
>  > Hell, it even might have been setup with an offset to allow later insertion
>  > of a header in front of the data placed into it initially.
> 
> Won't M_TRAILINGSPACE() give this to you?

Good one :)  Makes the patch simpler :)  Revised patch below.

Thanks,
Darren

*** uipc_mbuf.c.orig	Tue Jan 13 09:07:58 1998
--- uipc_mbuf.c	Tue Jan 13 09:08:03 1998
***************
*** 710,716 ****
  		m = m->m_next;
  	}
  	while (len > 0) {
! 		mlen = min (m->m_len - off, len);
  		bcopy(cp, off + mtod(m, caddr_t), (unsigned)mlen);
  		cp += mlen;
  		len -= mlen;
--- 710,721 ----
  		m = m->m_next;
  	}
  	while (len > 0) {
! 		int tlen = M_TRAILINGSPACE(m);
! 
! 		mlen = m->m_len - off;
! 		if ((tlen > 0) && (len > mlen))
! 			m->m_len += min(tlen, len - mlen);
! 		mlen = min(m->m_len - off, len);
  		bcopy(cp, off + mtod(m, caddr_t), (unsigned)mlen);
  		cp += mlen;
  		len -= mlen;

p.s. was made using freebsd uipc_mbuf.c :/