Date: Sun, 16 Nov 1997 16:05:54 -0600 (CST) From: Alex Nash <nash@Mcs.Net> To: Robert N Watson <rnw@andrew.cmu.edu> Cc: Studded <Studded@dal.net>, FreeBSD Stable List <FreeBSD-Stable@FreeBSD.ORG> Subject: Re: Serious problem with ipfw in 11/10 Snap Message-ID: <Pine.BSF.3.95.971116153205.516A-100000@Mercury.mcs.net> In-Reply-To: <Pine.SOL.3.95L.971116133300.1754A-100000@apriori.cc.cmu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 16 Nov 1997, Robert N Watson wrote: > Make sure you installed a revised ipfw. Something changed there, I think, > as when I switched from 2.2.2 to stable a few weeks ago on my servers, I > ran into exactly the same problem. A rule 00000 existed that denied all > packets, and the ipfw delete call did not work (gave a interface error of > some kind -- probably sctl, but don't recall). Since I could not insert > any rules before it, I could not bring the network up. Fortunately, the > machine had a floppy drive, so I did a buildworld on our build machine, > stuck the new ipfw on a floppy, and took it on over. The moral really was > that if you're going to make the leap to stable, do it for everything and > not just the kernel. :) In particular, make sure that the /usr/include > stuff is installed before building ipfw. > > With a new ipfw, the problem magically went away. I may have been > misinterpreting both the symptoms and the solution, but I just thought I'd > note that I had had a similar problem in a similar situation, and that a > rebuild and update of includes and ipfw fixed it. I think you may have hit the problem right on the head -- all this time I was assuming that Doug upgraded from a somewhat recent SNAP to an up-to-the-minute snap, but it looks like that assumption was very wrong. Here's what happened: Between 2.2.2 and 2.2.5, I made a fix for PR 4209 which allowed ipfw to work with long interface names. Unfortunately, it was not possible to fix this problem without breaking compatibility between the old ipfw util and the new kernel. I posted a warning to this effect to the -stable list just before the commit: http://www.freebsd.org/cgi/search.cgi?words=nash+AND+ipfw&max=25&sort=score&source=freebsd-stable&docnum=2 I deliberately changed the interface structure so that the new kernel would reject configuration attempts from the old userland ipfw util -- the results of which would have been a disaster if went unchecked. That's why you got the interface error and none of your rules were in effect. For future reference, if anyone finds themselves in a similar situation (that being a new kernel and old userland), you can fix it by: 1. Copy /usr/src/sys/netinet/ip_fw.h to /usr/include/netinet (or make install in /usr/src/include) 2. cd /usr/src/sbin/ipfw 3. make && make install This will install an updated version of ipfw that will talk to the new kernel. Alex
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.971116153205.516A-100000>