From owner-freebsd-questions Thu Apr 9 09:53:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA07825 for freebsd-questions-outgoing; Thu, 9 Apr 1998 09:53:49 -0700 (PDT) (envelope-from owner-freebsd-questions@FreeBSD.ORG) Received: from astro.astrocorp.com ([206.147.28.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA07802 for ; Thu, 9 Apr 1998 09:53:37 -0700 (PDT) (envelope-from grogers@astrocorp.com) Received: from glenn.astrocorp.com (glenn.astrocorp.com [206.147.28.31]) by astro.astrocorp.com (8.8.5/8.8.5) with SMTP id LAA17129 for ; Thu, 9 Apr 1998 11:49:28 -0500 Message-Id: <2.2.32.19980409165246.006772b4@astrocorp.com> X-Sender: grogers@astrocorp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 09 Apr 1998 11:52:46 -0500 To: freebsd-questions@FreeBSD.ORG From: Glenn Rogers Subject: PPP memory leak & port numbers Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 ********************************** * Glenn Rogers * * Firmware Development Engineer * * Astrocom Corporation * * 2700 Summer Street N.E. * * Minneapolis, MN 55413-2820 * * Phone: (612) 378-7800/617-2465 * * FAX: (612) 378-1070 * * e-mail: grogers@astrocorp.com * ********************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message