BUG: udp socket, getsockopt + setsockopt

Josh Horvath Josh_Horvath-AJH051 at email.mot.com
Wed Jan 30 03:58:59 EST 2002

This is just a guess, but is SO_RCVLOWAT getting set somewhere?  The receive
call will block until it gets the number of bytes set with this option.  I
think it defaults to 1, so it should normally return when any data is
available on the socket.  But if it has been bumped up to a big number, it
might account for the behavior you're seeing.


David Ashley wrote:
> I've found a very strange bug in linux ppc 2.4.17, I think. I'm pulling
> udp packets off the LAN and reading them in a user space program. They come
> in sets of about 60k bytes all together, then pause for a while. I only can
> read the first 48k successfully, then they get lost.
> If I have a setsockopt call on the socket, setting SO_RCVBUF to 65535,
> then I don't lose any data. But if I do a getsockopt beforehand on
> SO_RCVBUF, it reports 65535. Without the setsockopt I get the packet loss,
> with it I don't lose any. It is strange because the value doesn't appear
> to be changing.
> What can be causing this mysterious behaviour?
> -Dave

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

More information about the Linuxppc-embedded mailing list