Hello Andy,

This may be due to 'minimum packet sizes', ethernet stipulates that
frames/packets can't be less than a certain size, so network layers have to
pad out packets to the required minimum length.
I don't know off-hand if UDP headers include the length of the packet but it
looks like these network layers are using the actual network packet minus
the UDP header to determine the length of the data.
I have generally found that using 'recvfrom()' always reads complete
datagrams (assuming you provide a big enough buffer), so I don't think you
will find 'recvfrom' returning one datagram plus half another.

Alternatively 'ioctl()' might count the address as part of the data before
you read it.

What length does 'recvfrom()' actually return?

Regards

Roger
----------
>From: Andy Finnell <andyf@vei.net>
>To: NetBSD/mac68k <port-mac68k@netbsd.org>
>Subject: ioctl(), UDP sockets, bytes pending
>Date: Fri, Oct 15, 1999, 2:32 pm
>

>When doing some distributed OS homework, I noticed that ioctl() doesn't
>properly return the number of bytes pending on a UDP socket.  I send
>only one 40 bytes UDP packet to my server, my server ( actually a bridge
>program ) then uses ioctl() to determine that amount of bytes pending. 
>Instead of coming back with 40 bytes, it comes back with 56 bytes.  I
>can also reproduce this behaviour with IRIX 6.5.  Any ideas of what's
>going on?
>
>I'm using NetBSD 1.4 with a Quadra 700, 68/2gig.
>
>Thanks,
>
> -andy