The following reply was made to PR kern/34164; it has been noted by GNATS.

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