Date: Thu, 20 Jun 1996 12:46:19 -0600 From: Nate Williams <nate@sri.MT.net> To: grog@lemis.de (Greg Lehey) Cc: hackers@freebsd.org (FreeBSD Hackers), davidg@FreeBS.org Subject: Re: IP question: who should return ENOBUFS? Message-ID: <199606201846.MAA10546@rocky.sri.MT.net> In-Reply-To: <199606201803.UAA19421@allegro.lemis.de> References: <199606201803.UAA19421@allegro.lemis.de>
next in thread | previous in thread | raw e-mail | index | archive | help
I Cc'd David on this since I'm not sure he reads hackers, and he's
responsible for the piece of code in question.
> I've just spent a fair amount of time trying to figure out why our
> ISDN software jams up if it can't establish a connection. The
> symptoms are that if you can't establish a connection before a certain
> number of packets have been sent, the whole interface just returns:
>
> === root@freebie (/dev/ttyp0) /sys/netinet 11 -> ping 192.109.197.38
> PING 192.109.197.38 (192.109.197.38): 56 data bytes
> ping: sendto: No buffer space available
> ping: wrote 192.109.197.38 64 chars, ret=-1
> ping: sendto: No buffer space available
....
. After a bit more investigation, I found this code in
> ip_output.c:
>
> /*
> * Verify that we have any chance at all of being able to queue
> * the packet or packet fragments
> */
> if ((ifp->if_snd.ifq_len + ip->ip_len / ifp->if_mtu + 1) >=
> ifp->if_snd.ifq_maxlen) {
> error = ENOBUFS;
> goto bad;
> }
>
> I think this is bogus. It's not present in the BSD/OS version, so I
> assume it was added in FreeBSD. The problem is, it gives you no
> possibility of recovery: the queue is full and stays that way. Can
> anybody give me an idea of why it's there, when the interface is
> perfectly capable of looking after itself?
Here's the log messages when David made the change.
----------------------------
revision 1.3
date: 1994/08/01 12:01:45; author: davidg; state: Exp; lines: +10 -0
fixed bug where large amounts of unidirectional UDP traffic would fill
the interface output queue and further udp packets would be fragmented
and only partially sent - keeping the output queue full and jamming the
network, but not actually getting any real work done (because you can't
send just 'part' of a udp packet - if you fragment it, you must send
the whole thing). The fix involves adding a check to make sure that the
output queue has sufficient space for all of the fragments.
Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606201846.MAA10546>