Date: Sat, 15 Nov 97 13:31:29 -0800 From: "Studded" <Studded@dal.net> To: "Alex Nash" <nash@Mcs.Net> Cc: "FreeBSD Stable List" <FreeBSD-Stable@FreeBSD.ORG> Subject: Re: Serious problem with ipfw in 11/10 Snap Message-ID: <199711152131.NAA01650@mail.san.rr.com>
next in thread | raw e-mail | index | archive | help
On Fri, 14 Nov 1997 19:42:01 -0600 (CST), Alex Nash wrote: >On Fri, 14 Nov 1997, Studded wrote: > >> >This code hasn't changed on the 2.2 branch since August 23. The same >> >code that's in 2.2.5 is in the 11/10 snap (that you claim is broken) and >> >the 11/11 snap (that you claim is fixed). >> >> Ok, I'll take your word for that, > >It's simple to check for yourself by typing: [instructions snipped] I should have mentioned that I'm not a programmer, although I was aware of the steps you outlined, and tried doing some digging on my own. I kept finding new places where ipfw was referenced, and I figured out pretty fast that I was in over my head. >> but I'm still at a loss as to >> how the problem could have occurred. FWIW, I rm -r /usr/obj/* and >> /usr/src/* before I make the world, then ftp the ...-SNAP/src/* tree to >> make sure I've got everything fresh. If you're telling me the code hasn't >> changed, then something else has either changed, or is vulnerable to >> change, since I used the same procedures I always do. > >If you have a copy of the CVS tree handy, look at CVSROOT/commitlogs/sys. >I looked for changes on the 2.2 branch between 11/10 and 11/11, and saw: > > - APM & BT848 changes (I assume neither apply to your server) > - ep driver fixes (merged from -current) > >I'm currently running ipfw with the ep driver before the above fixes, and >everything works fine. Therefore I think we can rule out the ep driver >as fixing whatever problem you saw (assuming you use the ep driver, of >course). Actually we do use the ep driver on that machine. However if the ep driver had remained unchanged for more than a week or two prior to that fix being included, you're right, it can't be the problem. >> More detail on the problem in case it's useful. >> >> 1. The rule appeared as 00000 deny ip from any to any >> 2. That rule, and only that rule persisted after a flush. >> 3. IPFW was able to load my usual (well-tested) rc.firewall script just >> fine, but none of the rules in it mattered because the 00000 rule was >> always parsed first. > >It shouldn't be possible to generate a rule with #0 since that has a >special meaning to the kernel -- that is, insert this rule after the >highest numbered rule. I looked at the code, but can't see any way that >this could happen. > >Just out of curiosity, did you also see the 65535 deny all rule? I had to get a copy of the log where the tech was explaining the problem to me, and according to him, when he did a flush the only rule present was 00000 deny ip from any to any. I asked him to double-check, and he copied it exactly. >If >not, it may indicate that ipfw's rules were damaged by a memory overwrite. I'm not sure what that means. >This rule's number is set at boot time in the kernel by: > > deny.fw_number = (u_short)-1; > >Furthermore it is (theoretically) impossible to delete this entry. > >If you didn't see this rule, then something very unexpected has happened. I would agree with you there. :) >> Please understand, I'm not trying to point the finger of blame at >> anyone. I simply would like to be sure that this problem can't take >> anyone else by surprise. > >Fair enough, but please use the resources above and exercise >restraint before saying things like: Ah, yes, well, my apologies. I was trying to convey that the person who owns the hardware and bandwidth was very frustrated with the situation, and it was rolling downhill. I do appreciate your time in helping to track this problem down. I have a test system with a similar configuration, if there is something I can do to help, let me know. Doug *** Proud operator, designer and maintainer of the world's largest *** Internet Relay Chat server. 4,168 clients and still growing. :-) *** Try spider.dal.net on ports 6662-4 (Powered by FreeBSD) *** Part of the DALnet IRC network ***
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711152131.NAA01650>