From owner-freebsd-hackers  Sat Jun 22 09:03:28 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id JAA14914
          for hackers-outgoing; Sat, 22 Jun 1996 09:03:28 -0700 (PDT)
Received: from diablo.ppp.de (diablo.ppp.de [193.141.101.34])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA14905
          for <hackers@FreeBSD.ORG>; Sat, 22 Jun 1996 09:03:25 -0700 (PDT)
Received: from allegro.lemis.de by diablo.ppp.de with smtp
	(Smail3.1.28.1 #1) id m0uXV94-000Qb4C; Sat, 22 Jun 96 18:02 MET DST
From: grog@lemis.de (Greg Lehey)
Organisation: LEMIS, Schellnhausen 2, 36325 Feldatal, Germany
Phone: +49-6637-919123
Fax:   +49-6637-919122
Received: (grog@localhost) by allegro.lemis.de (8.6.9/8.6.9) 
	id NAA14679; Sat, 22 Jun 1996 13:16:27 +0200
Message-Id: <199606221116.NAA14679@allegro.lemis.de>
Subject: Re: IP question: who should return ENOBUFS?
To: helg@tav.kiev.ua (Oleg N Panashchenko)
Date: Sat, 22 Jun 1996 13:16:26 +0200 (MET DST)
Cc: hackers@FreeBSD.ORG (FreeBSD Hackers)
In-Reply-To: <199606211703.UAA04703@tav.kiev.ua> from "Oleg N Panashchenko" at Jun 21, 96 08:03:23 pm
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Oleg N Panashchenko writes:
>
> In article <199606201803.UAA19421@allegro.lemis.de> you wrote:
>: 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
>
> I have seen exactly the same behaviour with Digiboard driver.
> There was reliable way to reproduce it:
>
> ping -f any.non-local.host
>
> And see nothing except of 'No buffer space available' until restarting
> the interface.

Yup.  That's the problem.

> Adding a call of linesw[].l_start() in appropriate place in driver code
> closed the problem.

I'd consider that a workaround.  We need to change the congestion
avoidance algorithm to something that works.  In the meantime, this
"bug fix" in ip_output must be removed.

Greg