From owner-freebsd-hackers Thu Jun 20 11:46:37 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA00465 for hackers-outgoing; Thu, 20 Jun 1996 11:46:37 -0700 (PDT) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA00458 for ; Thu, 20 Jun 1996 11:46:33 -0700 (PDT) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id MAA10546; Thu, 20 Jun 1996 12:46:19 -0600 Date: Thu, 20 Jun 1996 12:46:19 -0600 From: Nate Williams Message-Id: <199606201846.MAA10546@rocky.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? In-Reply-To: <199606201803.UAA19421@allegro.lemis.de> References: <199606201803.UAA19421@allegro.lemis.de> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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