From owner-freebsd-current Mon Aug 31 02:23:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA18112 for freebsd-current-outgoing; Mon, 31 Aug 1998 02:23:18 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from burka.carrier.kiev.ua (burka.carrier.kiev.ua [193.193.193.107]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA18090 for ; Mon, 31 Aug 1998 02:23:14 -0700 (PDT) (envelope-from archer@grape.carrier.kiev.ua) Received: from kozlik.carrier.kiev.ua (kozlik.carrier.kiev.ua [193.193.193.111]) by burka.carrier.kiev.ua (8.9.0/8.Who.Cares) with ESMTP id MAA19344; Mon, 31 Aug 1998 12:22:10 +0300 (EEST) Received: (from uucp@localhost) by kozlik.carrier.kiev.ua (8.9.0/8.9.0/8.Who.Cares) with UUCP id MAA14385; Mon, 31 Aug 1998 12:21:37 +0300 (EEST) Received: (from archer@localhost) by grape.carrier.kiev.ua (8.9.1/8.8.8) id MAA00403; Mon, 31 Aug 1998 12:02:50 +0300 (EEST) (envelope-from archer) Message-ID: <19980831120249.58455@carrier.kiev.ua> Date: Mon, 31 Aug 1998 12:02:49 +0300 From: Alexander Litvin To: Stefan Eggers Cc: current@FreeBSD.ORG Subject: Re: IPFW showing extra lines Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e X-Newsgroups: grape.freebsd.current In-Reply-To: <199808302055.WAA02656@semyam.dinoco.de> Organization: Lucky Grape Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <199808302055.WAA02656@semyam.dinoco.de> you wrote: >> Specifically, ipfw -at l now shows a total of 1024 lines, whereas I >> should only have about 15 firewall rules set up. SE> The socket options handling code was renovated lately and totally SE> restructured removing the need for mbuf's there. SE> Taking a hard look at where it might fail I think it's a line in SE> sooptcopyout in sys/kern/uipc_socket.c causing this. The length of SE> the result is only copied into its rightful place if the buffer for SE> the result is too small. Sound's weird, doesn't it? SE> That can explain the problem you have with ipfw. It not only outputs SE> the rules the kernel gave back but also a lot more reading junk from SE> uninitialised memory as the length it gets back is the length of the SE> buffer ipfw allocated and not the length of the result. In this case SE> it seems to be freshly allocated memory filled with zero by the OS SE> resulting in these zero rules. SE> Thus I think the fix is to always set the result length which I expect SE> the attached patch (TOTALLY UNTESTED!!!) to do. It's a little bit too SE> late for me to test it today (about an hour till midnight) but maybe SE> someone else can say if I'm on the right track or not. Well, I'm not anywhere near expert, but manpage for getsockopt says: The parameters optval and optlen are used to access option values for setsockopt(). For getsockopt() they identify a buffer in which the value for the requested option(s) are to be returned. For getsockopt(), optlen is a value-result parameter, initially containing the size of the buffer pointed to by optval, and modified on return to indicate the actual size of the value returned. But, if sopt->sopt_valsize (read: optlen in getsockopt(2)) is less than the actual size of data which sooptcopyout() is asked to copy, the code copies optlen bytes of data. It is correct, as optlen is the size of the buffer. But also in such situation, sooptcopyout() modifies optlen to be the (larger) size of the data which sooptcopyout() was asked to copy. Either code or manpage is wrong. SE> Stefan. --- Q: How many Zen masters does it take to screw in a light bulb? A: None. The Universe spins the bulb, and the Zen master stays out of the way. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message