Date: Sun, 30 Aug 1998 22:55:28 +0200 From: Stefan Eggers <seggers@semyam.dinoco.de> To: Kris Kennaway <kkennawa@physics.adelaide.edu.au> Cc: freebsd-current@FreeBSD.ORG, seggers@semyam.dinoco.de Subject: Re: IPFW showing extra lines Message-ID: <199808302055.WAA02656@semyam.dinoco.de> In-Reply-To: Your message of "Sun, 30 Aug 1998 12:25:38 %2B0930." <Pine.OSF.3.90.980830122148.1270A-100000@mercury>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808302055.WAA02656>