From owner-freebsd-current Sun Aug 30 14:07:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA06202 for freebsd-current-outgoing; Sun, 30 Aug 1998 14:07:02 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from tim.xenologics.com (tim.xenologics.com [194.77.5.24]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA06193 for ; Sun, 30 Aug 1998 14:06:53 -0700 (PDT) (envelope-from seggers@semyam.dinoco.de) Received: (from uucp@localhost) by tim.xenologics.com (8.8.5/8.8.8) with UUCP id XAA13020; Sun, 30 Aug 1998 23:02:15 +0200 (MET DST) Received: from semyam.dinoco.de (semyam.dinoco.de [127.0.0.1]) by semyam.dinoco.de (8.9.1/8.8.8) with ESMTP id WAA02656; Sun, 30 Aug 1998 22:55:30 +0200 (CEST) (envelope-from seggers@semyam.dinoco.de) Message-Id: <199808302055.WAA02656@semyam.dinoco.de> To: Kris Kennaway Cc: freebsd-current@FreeBSD.ORG, seggers@semyam.dinoco.de Subject: Re: IPFW showing extra lines In-reply-to: Your message of "Sun, 30 Aug 1998 12:25:38 +0930." Date: Sun, 30 Aug 1998 22:55:28 +0200 From: Stefan Eggers Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 00000 0 0 deny ip from any to any > > Specifically, ipfw -at l now shows a total of 1024 lines, whereas I > should only have about 15 firewall rules set up. The socket options handling code was renovated lately and totally restructured removing the need for mbuf's there. Taking a hard look at where it might fail I think it's a line in sooptcopyout in sys/kern/uipc_socket.c causing this. The length of the result is only copied into its rightful place if the buffer for the result is too small. Sound's weird, doesn't it? That can explain the problem you have with ipfw. It not only outputs the rules the kernel gave back but also a lot more reading junk from uninitialised memory as the length it gets back is the length of the buffer ipfw allocated and not the length of the result. In this case it seems to be freshly allocated memory filled with zero by the OS resulting in these zero rules. Thus I think the fix is to always set the result length which I expect the attached patch (TOTALLY UNTESTED!!!) to do. It's a little bit too late for me to test it today (about an hour till midnight) but maybe someone else can say if I'm on the right track or not. Stefan. USE AT YOUR OWN RISK! GUARANTEED TO BE TOTALLY UNTESTED. NOT EVEN TRIED IF THE RESULT COMPILES. Index: uipc_socket.c =================================================================== RCS file: /usr2/FreeBSD/CVSROOT/src/sys/kern/uipc_socket.c,v retrieving revision 1.43 diff -u -2 -2 -r1.43 uipc_socket.c --- uipc_socket.c 1998/08/23 03:06:59 1.43 +++ uipc_socket.c 1998/08/30 20:38:47 @@ -1067,46 +1067,46 @@ int sooptcopyout(sopt, buf, len) struct sockopt *sopt; void *buf; size_t len; { int error; size_t valsize; error = 0; /* * Documented get behavior is that we always return a value, * possibly truncated to fit in the user's buffer. * We leave the correct length in sopt->sopt_valsize, * to be copied out in getsockopt(). Note that this * interface is not idempotent; the entire answer must * generated ahead of time. */ valsize = len; if (sopt->sopt_valsize < valsize) { valsize = sopt->sopt_valsize; - sopt->sopt_valsize = len; } + sopt->sopt_valsize = len; if (sopt->sopt_val != 0) { if (sopt->sopt_p != 0) error = copyout(buf, sopt->sopt_val, valsize); else bcopy(buf, sopt->sopt_val, valsize); } return error; } int sogetopt(so, sopt) struct socket *so; struct sockopt *sopt; { int error, optval; struct linger l; struct timeval tv; error = 0; if (sopt->sopt_level != SOL_SOCKET) { if (so->so_proto && so->so_proto->pr_ctloutput) { return ((*so->so_proto->pr_ctloutput) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message