Date: Wed, 27 Oct 2004 16:23:14 +0100 From: David Haworth <dave@zinc.org.uk> To: FreeBSD-gnats-submit@FreeBSD.org Subject: kern/73202: IPF causing major tcp problems with 3rd party apps (apache, exim etc) Message-ID: <E1CMpdq-0002b4-BF@zinc.org.uk> Resent-Message-ID: <200410271530.i9RFUN03070776@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 73202 >Category: kern >Synopsis: IPF causing major tcp problems with 3rd party apps (apache, exim etc) >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Oct 27 15:30:22 GMT 2004 >Closed-Date: >Last-Modified: >Originator: David Haworth >Release: FreeBSD 5.3-RELEASE i386 >Organization: >Environment: System: FreeBSD zinc.org.uk 5.3-RELEASE FreeBSD 5.3-RELEASE #2: Mon Oct 25 23:17:28 BST 2004 root@zinc.org.uk:/usr/obj/usr/src/sys/ZINC i386 >Description: Server was running 5.1-stable, I cvsupped to 5.3-Release, configured a custom kernel (generic plus all three firewalls, some power management devices, ipsec), rebuilt world (make buildworld;make buildkernel;make installkernel;reboot;mergemaster -p;make installworld;mergemaster;reboot) and sshd back into the machine. I then started checking the server to make sure everything was alright and I immediately found major problems, apache and courier weren't working properly, exim seemed to be working intermittantly. example with apache: I could see the processes running, no errors logged, and it was logging requests, but was sending back no data. exim was spawnign new processes for inbound mail, but the processes were stalled, and doing nothing. yet, sshd worked fine (thankfully), as did bind9 from ports (compiled previous to the upgrade). having read UPDATING, I remembered the comment about the upgrade to gcc 3.4.2 and that some apps may have to be recompiled. this made sense in light of sshd, so I recompiled my major apps, and then the apps they depend on, but to no avail. I eventually determined it to be a network issue. using tethereal, I could see a http connection come in, the three way handshake would be completed (syn, synack, ack) and then the server would simply stop responding. the client would keep retrying until it gave up. the server process was obviously getting the request (ie the apache logging and the exim process spawning) but could not reply for some reason. I recompiled a new kernel, with only ipf of the firewalls in and installed and rebooted. no effect. I then compiled a kernel with none of the firewalls in and rebooted without a firewall. the machine worked fine and all process transmitted data to their clients. >How-To-Repeat: >Fix: I used a workaround, rather than a fix. I had wanted to transition to pf anyway and this forced my hand. I loaded pf up as a kernel module and configured it to match the older ipf config. the machine reacts as one would expect and I am experiencing no further problems. as this box is a colocated server in production, I can't go back and keep trying new kernels and options to see if there is a problem, but this seemed like a possible show-stopper for others so I thought it worth flagging. dave >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1CMpdq-0002b4-BF>