From owner-freebsd-questions Sun Feb 28 18: 7:28 1999 Delivered-To: freebsd-questions@freebsd.org Received: from mailhub.scl.ameslab.gov (mailhub.scl.ameslab.gov [147.155.137.127]) by hub.freebsd.org (Postfix) with ESMTP id 606DF153C0 for ; Sun, 28 Feb 1999 18:07:11 -0800 (PST) (envelope-from ghelmer@scl.ameslab.gov) Received: from demios.ether.scl.ameslab.gov ([147.155.137.54]) by mailhub.scl.ameslab.gov with esmtp (Exim 1.90 #1) id 10HI7F-0001ag-00; Sun, 28 Feb 1999 20:07:29 -0600 Date: Sun, 28 Feb 1999 20:06:53 -0600 From: Guy Helmer To: + + Cc: freebsd-questions@freebsd.org Subject: Re: natd locks up? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 28 Feb 1999, + + wrote: > >> After spending several hours browsing mailing list archives about natd > >> problems, I've determined that my problem seems to be unique. Simply > >> put, natd doesn't even get far enough to start listening on its > >> assigned port (8668 in my stock 2.2.7 setup, as defined in > >> /etc/services). After executing natd (usually in the form of natd -u > >> -n fxp0, although I've also through -p 8668 in there for kicks), > >> netstat -a doesn't show natd or port 8668 anywhere! (the output is > >> indentical to the output prior to running natd, as confirmed by diff). > >> Stranger still, natd seems to be locked up pretty hard - the only way > >> to get rid of it is kill -9 (regular kill has no effect). > >> /var/log/alias.log is always empty, and using -v for natd never prints > >> any text to the console whatsoever. > > > >Have you rebuilt your kernel with IPFIREWALL and IPDIVERT options? > > I'm running the stock 2.2.7 kernel, no sources are installed on my > system (the hard drive is too small). How can I check the options the > kernel was compiled with? You would need to either check the config file (/sys/i386/conf/GENERIC, if you had kernel sources installed) or lookup the file in CVS on the web: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/conf/GENERIC?rev=1.77.2.25 The options IPFIREWALL and IPDIVERT are not used in the GENERIC configuration, so your ip firewall support is probably being loaded via the ipfw lkm. Looking at the Makefile for the ipfw LKM module, IPDIVERT isn't defined, so you'll apparently need to unpack the kernel sources, configure, and build your own kernel with the options IPFIREWALL and IPDIVERT to get natd working. > Secondly, I did think of that, but all of the relevant stuff in the > handbook about setting up a firewall seemed to assume that those > options were compiled in by default in the generic kernel. It seemed > that this was confirmed by the fact that ipfw rules work just fine > (I've played around with allowing and denying different hosts quite a > bit), and it *appears* that the divert rules work fine as well, at > least according to the accounting information displayed by "ipfw > show". Hmm, this illustrates an inconsistency which I had not noticed before. netinet/ip_fw.c will allow divert rules to be defined even if option IPDIVERT is not used, but the code in netinet/ip_input.c that would divert the packet is not compiled in unless option IPDIVERT is used. There ought to be some code in ip_fw.c:check_ipfw_struct to watch for this case and throw an error if someone tries to use a divert rule w/o the IPDIVERT option. I'll try to remember to file a PR on this tomorrow. Guy Guy Helmer, Ph.D. Candidate, Iowa State University Dept. of Computer Science Research Assistant, Ames Laboratory --- ghelmer@scl.ameslab.gov Research Assistant, Dept. of Computer Science --- ghelmer@cs.iastate.edu http://www.cs.iastate.edu/~ghelmer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message