From owner-freebsd-questions Thu Apr 9 21:02:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA23639 for freebsd-questions-outgoing; Thu, 9 Apr 1998 21:02:12 -0700 (PDT) (envelope-from owner-freebsd-questions@FreeBSD.ORG) Received: from awfulhak.org (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA23485 for ; Thu, 9 Apr 1998 21:01:49 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.org (8.8.8/8.8.7) with ESMTP id AAA29907; Fri, 10 Apr 1998 00:51:43 +0100 (BST) (envelope-from brian@gate.lan.awfulhak.org) Message-Id: <199804092351.AAA29907@awfulhak.org> X-Mailer: exmh version 2.0.1 12/23/97 To: Glenn Rogers cc: freebsd-questions@FreeBSD.ORG Subject: Re: PPP memory leak & port numbers In-reply-to: Your message of "Thu, 09 Apr 1998 11:52:46 CDT." <2.2.32.19980409165246.006772b4@astrocorp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Apr 1998 00:51:43 +0100 From: Brian Somers Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I don't know much about pppd, but (user-)ppp will allow you to send LCP ECHO LQRs (if you enable LQR and the peer rejects it, ppp uses ECHO LQRs instead). Running in -ddial mode should result in what you're looking for, and you won't get any dodgy udp sockets jumping up out of nowhere :-) Make sure you've got the latest ppp (http://www.FreeBSD.org/~brian) though - older versions have a broken LQR implementation. > We have a protocol stack embedded into our product which is based on BSD 4.2. > We also have FreeBSD release 2.2.5 on CD ROM. > > Here is the story. > > 1) The CISCO 2509 router/terminal server does not initiate the LCP negotiation > to bring up the PPP link. If the PPP link is up and running and the CISCO > is power cycled, IP traffic stops. We think PPP is up and CISCO thinks > the link is down. The response I got from CISCO tech support was to monitor > the DTR line and restart the link if the line drops. Because we didn't wire > that DTR line in, we can't detect the event. > > 2) To fix the problem, I have added a watch dog timer to periodically send > LCP echo requests to determine if the device is alive. If the echo responses are > not returned, I am calling lcp_close() and restarting the link. > > 3) If the PPP link goes down and then up again enough times, eventually > a call to allocate memory to open a socket fails. This leak is somehow > related to the info displayed by the 'netstat' command. > > After the PPP link is up, netstat displays the following. > > Active Internet connections (including servers) > Proto Recv-Q Send-Q Local Address Foreign Address (state) > tcp 0 0 *.23 *.* LISTEN > udp 0 0 *.* *.* > udp 0 0 *.161 *.* > > When the link goes down (lcp_close() was called), one more entry is displayed > when the 'netstat' command is issued as follows. > > Active Internet connections (including servers) > Proto Recv-Q Send-Q Local Address Foreign Address (state) > tcp 0 0 *.23 *.* LISTEN > udp 0 0 *.* *.* > udp 0 0 *.* *.* > udp 0 0 *.161 *.* > > When the link comes back up one more entry is displayed > when the 'netstat' command is issued as follows. > > Active Internet connections (including servers) > Proto Recv-Q Send-Q Local Address Foreign Address (state) > tcp 0 0 *.23 *.* LISTEN > udp 0 0 *.* *.* > udp 0 0 *.* *.* > udp 0 0 *.* *.* > udp 0 0 *.161 *.* > > This is displaying a 'Local Address' of *.*. > The code that prints this info is displaying * for the port number > when the port value passed to inetprint() is zero. > (inetprint() is in the file inet.c) > > My question is... > There are places in the code where port values of zero are accepted. > Why does the code allow port values of zero when RFC1700 and much older > RFC739 has allways defined port number zero as 'Reserved' ??? > > Thank you, > Glenn Rogers [.....] -- Brian , , Don't _EVER_ lose your sense of humour.... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message