NetBSD Problem Report #34164

From root@Acrys.COM  Tue Aug  8 17:12:55 2006
Return-Path: <root@Acrys.COM>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id 2440463B8C3
	for <gnats-bugs@gnats.NetBSD.org>; Tue,  8 Aug 2006 17:12:55 +0000 (UTC)
Message-Id: <20060808155513.1429F404B@satan.acrys.com>
Date: Tue,  8 Aug 2006 17:55:12 +0200 (CEST)
From: kardel@netbsd.org
Reply-To: kardel@netbsd.org
To: gnats-bugs@NetBSD.org
Subject: unconnected ippp? interfaces hang onto pakets to be send
X-Send-Pr-Version: 3.95

>Number:         34164
>Category:       kern
>Synopsis:       unconnected ippp? interfaces hang onto pakets to be send
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    martin
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Aug 08 17:15:00 +0000 2006
>Closed-Date:    Wed Mar 29 10:08:28 +0000 2017
>Last-Modified:  Wed Mar 29 10:08:28 +0000 2017
>Originator:     Frank Kardel
>Release:        NetBSD 3.99.24
>Organization:
>Environment:
System: NetBSD system 3.99.24 NetBSD 3.99.24 (xxx_ISDN) #1: Tue Aug 8 14:34:44 MEST 2006 kardel@pip.kardel.name:/fs/WD1500ADFD-0-g/IC35L120AVV207-0-e/src/NetBSD/tc-merge/src/sys/arch/i386/compile/obj.i386/SATAN_ISDN i386
Architecture: i386
Machine: i386
>Description:
	Ingredients:
		- ISDN enabled kernel
		- isdnd configured for ipppX interfaces with dialin-reaction=accept, dialout-type=normal
		- routed configured to do RIP on these interfeaces (default unless you configure against it)
	Observations:
		- as long as no connection exists RIP pakets pile up on the ipppX interfaces (they are UP)
		- mbuf storage is depleted
		- at the end a panic lurks in the drain code -> reboot - repeat from start
		- ifconfig ipppX down releases all queued pakets
		- RIP is not necessary, ICMP ECHO will do too, as probably will others also

>How-To-Repeat:
	Setup like in the description.
	ipppX gets a fixed address
	start isdnd
	fire pakets to the others side and see sthem being stuck in internet tx (MBUFTRACE).

>Fix:
	avoid sending pakets while UP but not connected.

>Release-Note:

>Audit-Trail:
From: Frank Kardel <kardel@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/34164: unconnected ippp? interfaces hang onto pakets to
 be send
Date: Tue, 08 Aug 2006 19:26:28 +0200

 Additional datapoint: ping -f -c 1000 <ipaddr> manage to queue 256 mbufs 
 at the interface before being out
 of sendbuffer space.
 Does it make sense to queue so many pakets(mbufs)?

 Frank

From: Pavel Cahyna <pavel@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/34164: unconnected ippp? interfaces hang onto pakets to be send
Date: Tue, 8 Aug 2006 19:50:34 +0200

 On Tue, Aug 08, 2006 at 05:30:02PM +0000, Frank Kardel wrote:
 > The following reply was made to PR kern/34164; it has been noted by GNATS.
 > 
 > From: Frank Kardel <kardel@netbsd.org>
 > To: gnats-bugs@netbsd.org
 > Cc: 
 > Subject: Re: kern/34164: unconnected ippp? interfaces hang onto pakets to
 >  be send
 > Date: Tue, 08 Aug 2006 19:26:28 +0200
 > 
 >  Additional datapoint: ping -f -c 1000 <ipaddr> manage to queue 256 mbufs 
 >  at the interface before being out
 >  of sendbuffer space.
 >  Does it make sense to queue so many pakets(mbufs)?

 isn't it because of

 $ sysctl net.inet.ip.ifq.maxlen
 net.inet.ip.ifq.maxlen = 256

From: Frank Kardel <kardel@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: kern/34164: unconnected ippp? interfaces hang onto pakets to
 be send
Date: Tue, 08 Aug 2006 20:18:13 +0200

 Pavel Cahyna wrote:

 > >  Does it make sense to queue so many pakets(mbufs)?
 > 
 > isn't it because of
 > 
 > $ sysctl net.inet.ip.ifq.maxlen
 > net.inet.ip.ifq.maxlen = 256
 > 
 >  
 >
 good observation.
 So I got 4 interfaces being capable of keep ifq.maxlen
 mbufs when not connected. How does this relate to
 the maximum number of mbufs? In that scenario it was
 very easy to run out of mbufs.
 Is 256 too high ? Should the maximum number of mbufs
 be scaled with the number of interfaces. Or should
 we just ignore this and I set ifq.maxlen to 32 on my system
 and be done with?

 Frank

Responsible-Changed-From-To: kern-bug-people->martin
Responsible-Changed-By: martin@netbsd.org
Responsible-Changed-When: Tue, 08 Aug 2006 21:14:43 +0000
Responsible-Changed-Why:
I'll deal with it


From: Martin Husemann <martin@duskware.de>
To: Frank Kardel <kardel@netbsd.org>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/34164: unconnected ippp? interfaces hang onto pakets to be send
Date: Tue, 8 Aug 2006 23:13:03 +0200

 On Tue, Aug 08, 2006 at 08:18:13PM +0200, Frank Kardel wrote:
 > So I got 4 interfaces being capable of keep ifq.maxlen
 > mbufs when not connected.

 This only makes sense for interfaces that have a chance of establishing
 the isdn connection while keeping the packet in the queue.

 We probably should:

  - tell the kernel about the incoming/outgoing nature of such interfaces
    and have it drop packets right away for incoming-only ones
  - have isdnd tell the interface about connection failures so the
    interface can flush the queue and maybe limit it to fewer packets
    untill the next successfull connection

 Just out of curiosity:
 With dialout-type=normal, why isn't the connection established in your case?
 Is the remote site rejecting the call?

 Martin

From: Frank Kardel <kardel@netbsd.org>
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/34164: unconnected ippp? interfaces hang onto pakets to
 be send
Date: Tue, 08 Aug 2006 23:25:29 +0200

 Martin Husemann wrote:

 >On Tue, Aug 08, 2006 at 08:18:13PM +0200, Frank Kardel wrote:
 >  
 >
 >>So I got 4 interfaces being capable of keep ifq.maxlen
 >>mbufs when not connected.
 >>    
 >>
 >
 >This only makes sense for interfaces that have a chance of establishing
 >the isdn connection while keeping the packet in the queue.
 >
 >We probably should:
 >
 > - tell the kernel about the incoming/outgoing nature of such interfaces
 >   and have it drop packets right away for incoming-only ones
 >  
 >
 ok

 > - have isdnd tell the interface about connection failures so the
 >   interface can flush the queue and maybe limit it to fewer packets
 >   untill the next successfull connection
 >
 >  
 >
 how about queueing only when the first paket triggered a connection 
 establishment
 and drop pakets while not connected/establishing the connection if that 
 can be determined.
 That should take care of the cases above.

 >Just out of curiosity:
 >With dialout-type=normal, why isn't the connection established in your case?
 >Is the remote site rejecting the call?
 >  
 >
 I checked again and direction is "in" so these are true incoming ones. I got
 confused by the dialin-reaction and dialout-type parameters. Sorry about 
 that.

 >Martin
 >  
 >
 Frank

From: Martin Husemann <martin@duskware.de>
To: Frank Kardel <kardel@netbsd.org>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/34164: unconnected ippp? interfaces hang onto pakets to be send
Date: Tue, 8 Aug 2006 23:30:59 +0200

 On Tue, Aug 08, 2006 at 11:25:29PM +0200, Frank Kardel wrote:
 > how about queueing only when the first paket triggered a connection 
 > establishment
 > and drop pakets while not connected/establishing the connection if that 
 > can be determined.

 Yes, that would be equivalent, but I think the event flow in this case is
 asynchronous, so we won't know this inside the kernel imediately.

 Martin

State-Changed-From-To: open->closed
State-Changed-By: kardel@NetBSD.org
State-Changed-When: Wed, 29 Mar 2017 10:08:28 +0000
State-Changed-Why:
timeout - ISDN becomes a local installation legacy in All IP world - closed by submitter (me)


>Unformatted:
 		Also seen in NetBSD 3.0

Home	PR Database Search