Date: Fri, 4 Apr 1997 23:14:07 +1000 (EST) From: proff@suburbia.net To: darrenr@cyber.com.au (Darren Reed) Cc: darrenr@cyber.com.au, hackers@freebsd.org Subject: Re: IP Filter in -current. Message-ID: <19970404131408.7412.qmail@suburbia.net> In-Reply-To: <199704040736.RAA23038@plum.cyber.com.au> from Darren Reed at "Apr 4, 97 05:36:09 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> Someone should give this guy a labotamy if he's the one who came up
> with the "include every other include file in this include file" idea.
>
> > Use of TAILQ's for handling ifaddr chains.
>
> Is this consistent with NetBSD ?
I'm not sure, but it wasn't consistent with ipfilter :)
Note that the below is a not production; I haven't as yet isolated
the FreeBSD_version when these changes were introduced (so use
>=2).
--- /usr/src/contrib/ipfilter/ip_nat.c Fri Apr 4 13:07:54 1997
+++ ip_nat.c Thu Apr 3 05:02:24 1997
@@ -10,8 +12,8 @@
static char rcsid[] = "$Id: ip_nat.c,v 2.0.2.8 1997/04/02 12:23:23 darrenr Exp $";
#endif
+#ifdef IPFILTER_LKM
+#define ACTUALLY_LKM_NOT_KERNEL
#endif
#if !defined(_KERNEL) && !defined(KERNEL)
@@ -27,6 +27,7 @@
#include <sys/time.h>
#include <sys/file.h>
#include <sys/ioctl.h>
+#include <sys/fcntl.h>
#include <sys/uio.h>
#include <sys/protosw.h>
#include <sys/socket.h>
@@ -42,7 +43,12 @@
# include <sys/kmem.h>
#endif
+#ifdef __FreeBSD__
+# include <sys/queue.h>
+#endif
+
#include <net/if.h>
+#include <net/if_var.h>
#ifdef sun
#include <net/af.h>
#endif
@@ -425,15 +431,22 @@
#else
struct ifaddr *ifa;
struct sockaddr_in *sin;
-
+# if __FreeBSD__ >= 2
+ ifa = TAILQ_FIRST(&ifp->if_addrhead);
+# else
ifa = ifp->if_addrlist;
+# endif
# if BSD < 199306
sin = (struct sockaddr_in *)&ifa->ifa_addr;
# else
sin = (struct sockaddr_in *)ifa->ifa_addr;
while (sin && ifa &&
sin->sin_family != AF_INET) {
+# if __FreeBSD__ >=2
+ ifa = TAILQ_NEXT(ifa, ifa_link);
+# else
ifa = ifa->ifa_next;
+# endif
sin = (struct sockaddr_in *)ifa->ifa_addr;
}
if (!ifa)
>
> > VOP_LOCK() in lite2 takes three arguments.
>
> 3 instead of 4 or 3 instead of 2 ?
Three instead of one :)
I'm still not clear if I'm using the correct locking arguments.
mln_ipl.c uses this construct:
VOP_LOCK(nd.ni_vp);
Which i've turned into:
VOP_LOCK(nd.ni_vp, LK_INTERLOCK|LK_SHARED, curproc);
Although I feel:
VOP_LOCK(nd.ni_vp, 0, curproc);
is a more direct translation.
This code is only called when the module is unloaded by hand, and so
far all the module unloading has been courtesy of panic, so testing
opportunities have been limited :)
> > At run-time it seems to panic quickly if logging is going on and
> > ipmon isn't there to read the log device.
>
> heh...I guess you'll be able to track this bug then :)
I actually strongly suspect my initial views on this were wrong.
The problem doesn't seem to lay with the log buffer filling, but
with the connection state following code, which seems to crash
after a certain period of time (memory?).
Cheers,
Julian.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970404131408.7412.qmail>