From owner-freebsd-pf@FreeBSD.ORG Sun Mar 6 05:00:21 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1199D16A4CE for ; Sun, 6 Mar 2005 05:00:21 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85EA343D31 for ; Sun, 6 Mar 2005 05:00:20 +0000 (GMT) (envelope-from jsimola@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so979458wri for ; Sat, 05 Mar 2005 21:00:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=F8GCH63o1bvS5brSsvUzUO+nvP+psc3ld4CXpZBlu95iebvEl830qopc8Ouu/reFbO5W5DrViG5qvSR/Mj2nmPfNycKasCfuQ/J9WaIDbcZRxjIycphJOVUKLEiHbZdoijvaGcbcThg9R0EWbXhihIj02uP5c6XW/U51Bq2iwuI= Received: by 10.54.34.25 with SMTP id h25mr15162wrh; Sat, 05 Mar 2005 21:00:19 -0800 (PST) Received: by 10.54.39.34 with HTTP; Sat, 5 Mar 2005 21:00:18 -0800 (PST) Message-ID: <8eea040805030521005347c44e@mail.gmail.com> Date: Sat, 5 Mar 2005 21:00:18 -0800 From: Jon Simola To: freebsd-pf@freebsd.org In-Reply-To: <62956.81.30.200.207.1110031162.squirrel@81.30.200.207> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <62956.81.30.200.207.1110031162.squirrel@81.30.200.207> Subject: Re: pfsync + pfflowd + flow-tools (ifconfig maxupd)? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jon@abccomm.com List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2005 05:00:21 -0000 On Sat, 5 Mar 2005 08:59:22 -0500 (EST), vsavichev@wesleyan.edu wrote: > does it mean i have to set syncif iface on FreeBSD if i want > to change maxupd parameter? After applying a patch, man ifconfig doesn't > show any trace of maxupd parameter presented (apart it is there ...). Once you've applied the CARP patch, you can set the maxupd for the pfsync interface, but you are correct that the man page makes no mention of that. I suspect it's merely an oversight, as the working code is more important than the minor documentation required. People playing with unofficially released code should be used to minimal docs and reading the source to find out what really goes on. > Does syncif post any additional workload on iface? Apart to change maxupd > i'm not really in a need to syncif for a moment. All the PF and CARP docs suggest a dedicated interface for pfsync, mostly due to security issues. The most common implementation I would assume is a pair of firewalls each with 3 interfaces (internal, external, and sync connected via a xover cable). -- Jon Simola Systems Administrator ABC Communications From owner-freebsd-pf@FreeBSD.ORG Sun Mar 6 06:08:32 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 196CF16A4CE for ; Sun, 6 Mar 2005 06:08:32 +0000 (GMT) Received: from hotmail.com (bay24-f18.bay24.hotmail.com [64.4.18.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BEAF43D39 for ; Sun, 6 Mar 2005 06:08:31 +0000 (GMT) (envelope-from segr@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 5 Mar 2005 22:08:31 -0800 Message-ID: Received: from 204.9.110.182 by by24fd.bay24.hotmail.msn.com with HTTP; Sun, 06 Mar 2005 06:08:31 GMT X-Originating-IP: [204.9.110.182] X-Originating-Email: [segr@hotmail.com] X-Sender: segr@hotmail.com In-Reply-To: <20050305222000.GC26999@insomnia.benzedrine.cx> From: "Stephane Raimbault" To: daniel@benzedrine.cx Date: Sat, 05 Mar 2005 23:08:31 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 06 Mar 2005 06:08:31.0451 (UTC) FILETIME=[EC062AB0:01C52212] cc: freebsd-pf@freebsd.org Subject: Re: nat / rdr timeouts? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2005 06:08:32 -0000 Thanks for the response... my debug output is below. >From: Daniel Hartmeier >To: Stephane Raimbault >CC: freebsd-pf@freebsd.org >Subject: Re: nat / rdr timeouts? >Date: Sat, 5 Mar 2005 23:20:00 +0100 > >On Sat, Mar 05, 2005 at 02:57:56PM -0700, Stephane Raimbault wrote: > > > I cvsup'd RELENG_5 and recompiled the kernel and I'm seeing the same > > results. Do I need to recompile any other parts of the system? > >No, that's it. > > > Do we believe I've stumbled onto a bug of pf... or is this some sort of > > anti-DoS feature? > >The default limit on number of states is 10,000. If further packets try >to create state, they are dropped. But it doesn't look like you're >hitting that. > >Enable debug loggin (pfctl -xm), reproduce the problem, then check >/var/log/messages for anything from pf. > Mar 5 23:17:56 lb1-dev kernel: pf: BAD state: TCP 10.0.11.16:80 204.9.110.170:80 204.9.110.139:1372 [lo=665532303 high=665590223 win=57920 modulator=0 wscale=0] [lo=2263179419 high=2263237339 win=57920 modulator=0 wscale=0] 9:9 S seq=669705236 ack=2263179419 len=0 ackskew=0 pkts=5:4 dir=in,fwd Mar 5 23:17:56 lb1-dev kernel: pf: State failure on: 1 | 5 Mar 5 23:17:59 lb1-dev kernel: pf: BAD state: TCP 10.0.11.16:80 204.9.110.170:80 204.9.110.139:1372 [lo=665532303 high=665590223 win=57920 modulator=0 wscale=0] [lo=2263179419 high=2263237339 win=57920 modulator=0 wscale=0] 9:9 S seq=669705236 ack=2263179419 len=0 ackskew=0 pkts=5:4 dir=in,fwd Mar 5 23:17:59 lb1-dev kernel: pf: State failure on: 1 | 5 Mar 5 23:18:02 lb1-dev kernel: pf: BAD state: TCP 10.0.11.16:80 204.9.110.170:80 204.9.110.139:1372 [lo=665532303 high=665590223 win=57920 modulator=0 wscale=0] [lo=2263179419 high=2263237339 win=57920 modulator=0 wscale=0] 9:9 S seq=669705236 ack=2263179419 len=0 ackskew=0 pkts=5:4 dir=in,fwd Mar 5 23:18:02 lb1-dev kernel: pf: State failure on: 1 | 5 Mar 5 23:18:05 lb1-dev kernel: pf: BAD state: TCP 10.0.11.16:80 204.9.110.170:80 204.9.110.139:1372 [lo=665532303 high=665590223 win=57920 modulator=0 wscale=0] [lo=2263179419 high=2263237339 win=57920 modulator=0 wscale=0] 9:9 S seq=669705236 ack=2263179419 len=0 ackskew=0 pkts=5:4 dir=in,fwd Mar 5 23:18:05 lb1-dev kernel: pf: State failure on: 1 | 5 Mar 5 23:18:09 lb1-dev kernel: pf: BAD state: TCP 10.0.11.16:80 204.9.110.170:80 204.9.110.139:1372 [lo=665532303 high=665590223 win=57920 modulator=0 wscale=0] [lo=2263179419 high=2263237339 win=57920 modulator=0 wscale=0] 9:9 S seq=669705236 ack=2263179419 len=0 ackskew=0 pkts=5:4 dir=in,fwd Mar 5 23:18:09 lb1-dev kernel: pf: State failure on: 1 | 5 Mar 5 23:18:12 lb1-dev kernel: pf: BAD state: TCP 10.0.11.16:80 204.9.110.170:80 204.9.110.139:1372 [lo=665532303 high=665590223 win=57920 modulator=0 wscale=0] [lo=2263179419 high=2263237339 win=57920 modulator=0 wscale=0] 9:9 S seq=669705236 ack=2263179419 len=0 ackskew=0 pkts=5:4 dir=in,fwd Mar 5 23:18:12 lb1-dev kernel: pf: State failure on: 1 | 5 Mar 5 23:18:18 lb1-dev kernel: pf: BAD state: TCP 10.0.11.16:80 204.9.110.170:80 204.9.110.139:1372 [lo=665532303 high=665590223 win=57920 modulator=0 wscale=0] [lo=2263179419 high=2263237339 win=57920 modulator=0 wscale=0] 9:9 S seq=669705236 ack=2263179419 len=0 ackskew=0 pkts=5:4 dir=in,fwd Mar 5 23:18:18 lb1-dev kernel: pf: State failure on: 1 | 5 >Also quote pfctl -vvss output after the problem, as well as pfctl -si, >please. > # pfctl -vvss No ALTQ support in kernel ALTQ related functions disabled self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2561 FIN_WAIT_2:FIN_WAIT_2 [32585757 + 57920] wscale 0 [4030666851 + 57920] wscale 0 age 00:00:57, expires in 00:00:33, 5:4 pkts, 363:508 bytes id: 422a29420000033f creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3073 FIN_WAIT_2:FIN_WAIT_2 [280614368 + 57920] wscale 0 [871170019 + 57920] wscale 0 age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes id: 422a294200000368 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1546 FIN_WAIT_2:FIN_WAIT_2 [318290820 + 57920] wscale 0 [3755105029 + 57920] wscale 0 age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes id: 422a294200000349 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3347 FIN_WAIT_2:FIN_WAIT_2 [1140076597 + 57920] wscale 0 [4121153694 + 57920] wscale 0 age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes id: 422a29420000031b creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2836 FIN_WAIT_2:FIN_WAIT_2 [2909277378 + 57920] wscale 0 [448910790 + 57920] wscale 0 age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes id: 422a294200000370 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2327 FIN_WAIT_2:FIN_WAIT_2 [2987561263 + 57920] wscale 0 [4146806117 + 57920] wscale 0 age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes id: 422a294200000318 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2329 FIN_WAIT_2:FIN_WAIT_2 [1833281301 + 57920] wscale 0 [1053857949 + 57920] wscale 0 age 00:00:59, expires in 00:00:32, 5:4 pkts, 363:508 bytes id: 422a294200000327 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1818 FIN_WAIT_2:FIN_WAIT_2 [2636697734 + 57920] wscale 0 [2763808572 + 57920] wscale 0 age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes id: 422a294200000353 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4380 FIN_WAIT_2:FIN_WAIT_2 [1563439928 + 57920] wscale 0 [2156220237 + 57920] wscale 0 age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes id: 422a294200000375 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3613 FIN_WAIT_2:FIN_WAIT_2 [4269333757 + 57920] wscale 0 [28302277 + 57920] wscale 0 age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes id: 422a294200000325 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2334 FIN_WAIT_2:FIN_WAIT_2 [4236319117 + 57920] wscale 0 [756984446 + 57920] wscale 0 age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes id: 422a294200000376 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1570 FIN_WAIT_2:FIN_WAIT_2 [1467784327 + 57920] wscale 0 [1805572515 + 57920] wscale 0 age 00:00:50, expires in 00:00:40, 5:4 pkts, 363:508 bytes id: 422a294200000389 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2854 FIN_WAIT_2:FIN_WAIT_2 [1264223110 + 57920] wscale 0 [3114805151 + 57920] wscale 0 age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes id: 422a294200000380 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2599 FIN_WAIT_2:FIN_WAIT_2 [2493007175 + 57920] wscale 0 [4071674965 + 57920] wscale 0 age 00:00:58, expires in 00:00:33, 5:4 pkts, 363:508 bytes id: 422a29420000033b creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4647 FIN_WAIT_2:FIN_WAIT_2 [1519840616 + 57920] wscale 0 [1155588281 + 57920] wscale 0 age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes id: 422a294200000351 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2600 FIN_WAIT_2:FIN_WAIT_2 [3829938788 + 57920] wscale 0 [2288730060 + 57920] wscale 0 age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes id: 422a294200000346 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1323 FIN_WAIT_2:FIN_WAIT_2 [3299837026 + 57920] wscale 0 [571661919 + 57920] wscale 0 age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes id: 422a29420000037f creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4139 FIN_WAIT_2:FIN_WAIT_2 [2936258233 + 57920] wscale 0 [3552485098 + 57920] wscale 0 age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes id: 422a29420000034d creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1069 FIN_WAIT_2:FIN_WAIT_2 [3429734760 + 57920] wscale 0 [1047686037 + 57920] wscale 0 age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes id: 422a294200000350 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1582 FIN_WAIT_2:FIN_WAIT_2 [2239408408 + 57920] wscale 0 [792523365 + 57920] wscale 0 age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes id: 422a294200000356 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1839 FIN_WAIT_2:FIN_WAIT_2 [1084975327 + 57920] wscale 0 [3468075791 + 57920] wscale 0 age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes id: 422a29420000035c creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4402 FIN_WAIT_2:FIN_WAIT_2 [1734033910 + 57920] wscale 0 [4212345601 + 57920] wscale 0 age 00:00:57, expires in 00:00:33, 5:4 pkts, 363:508 bytes id: 422a29420000033c creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3636 FIN_WAIT_2:FIN_WAIT_2 [1247559674 + 57920] wscale 0 [3855641134 + 57920] wscale 0 age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes id: 422a29420000036c creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4917 FIN_WAIT_2:FIN_WAIT_2 [2579269706 + 57920] wscale 0 [2765039414 + 57920] wscale 0 age 00:00:57, expires in 00:00:33, 5:4 pkts, 363:508 bytes id: 422a294200000340 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1334 FIN_WAIT_2:FIN_WAIT_2 [1322299975 + 57920] wscale 0 [4143165048 + 57920] wscale 0 age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes id: 422a294200000352 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1593 FIN_WAIT_2:FIN_WAIT_2 [3145580381 + 57920] wscale 0 [1476283631 + 57920] wscale 0 age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes id: 422a294200000345 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2361 TIME_WAIT:TIME_WAIT [1651992099 + 57344] wscale 0 [1675199900 + 57345] wscale 0 age 00:00:53, expires in 00:00:37, 2:1 pkts, 100:60 bytes id: 422a294200000377 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3132 FIN_WAIT_2:FIN_WAIT_2 [54760795 + 57920] wscale 0 [685586651 + 57920] wscale 0 age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes id: 422a29420000032a creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3388 FIN_WAIT_2:FIN_WAIT_2 [1740195130 + 57920] wscale 0 [2837513788 + 57920] wscale 0 age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes id: 422a294200000330 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4668 FIN_WAIT_2:FIN_WAIT_2 [4153305444 + 57920] wscale 0 [3657625607 + 57920] wscale 0 age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes id: 422a294200000362 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2110 FIN_WAIT_2:FIN_WAIT_2 [1680438376 + 57920] wscale 0 [4124389714 + 57920] wscale 0 age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes id: 422a29420000032b creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4927 FIN_WAIT_2:FIN_WAIT_2 [3926918789 + 57920] wscale 0 [1578868844 + 57920] wscale 0 age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes id: 422a29420000032f creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2369 FIN_WAIT_2:FIN_WAIT_2 [3264887916 + 57920] wscale 0 [1040383065 + 57920] wscale 0 age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes id: 422a294200000373 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3138 FIN_WAIT_2:FIN_WAIT_2 [3668537022 + 57920] wscale 0 [4070704551 + 57920] wscale 0 age 00:00:51, expires in 00:00:40, 5:4 pkts, 363:508 bytes id: 422a294200000384 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4677 FIN_WAIT_2:FIN_WAIT_2 [4255514426 + 57920] wscale 0 [2108554394 + 57920] wscale 0 age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes id: 422a29420000031e creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1351 FIN_WAIT_2:FIN_WAIT_2 [650459315 + 57920] wscale 0 [3007417138 + 57920] wscale 0 age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes id: 422a29420000035d creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4935 FIN_WAIT_2:FIN_WAIT_2 [2640203207 + 57920] wscale 0 [1946606900 + 57920] wscale 0 age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes id: 422a29420000031d creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1864 FIN_WAIT_2:FIN_WAIT_2 [302555830 + 57920] wscale 0 [4259092904 + 57920] wscale 0 age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes id: 422a29420000035a creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4936 FIN_WAIT_2:FIN_WAIT_2 [3747285884 + 57920] wscale 0 [1707501039 + 57920] wscale 0 age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes id: 422a294200000364 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4426 FIN_WAIT_2:FIN_WAIT_2 [4052825702 + 57920] wscale 0 [1998932217 + 57920] wscale 0 age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes id: 422a29420000036a creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4429 FIN_WAIT_2:FIN_WAIT_2 [2963041429 + 57920] wscale 0 [2854499682 + 57920] wscale 0 age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes id: 422a294200000328 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4941 FIN_WAIT_2:FIN_WAIT_2 [363310172 + 57920] wscale 0 [1840047747 + 57920] wscale 0 age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes id: 422a294200000331 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1871 FIN_WAIT_2:FIN_WAIT_2 [1551203117 + 57920] wscale 0 [1422169461 + 57920] wscale 0 age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes id: 422a294200000329 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3152 FIN_WAIT_2:FIN_WAIT_2 [1387806479 + 57920] wscale 0 [1346138440 + 57920] wscale 0 age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes id: 422a294200000320 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4944 FIN_WAIT_2:FIN_WAIT_2 [2112290315 + 57920] wscale 0 [3096897628 + 57920] wscale 0 age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes id: 422a29420000037e creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3921 FIN_WAIT_2:FIN_WAIT_2 [2276016873 + 57920] wscale 0 [2659410744 + 57920] wscale 0 age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes id: 422a294200000333 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4692 FIN_WAIT_2:FIN_WAIT_2 [4210818300 + 57920] wscale 0 [3178408136 + 57920] wscale 0 age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes id: 422a294200000319 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4696 FIN_WAIT_2:FIN_WAIT_2 [3697003529 + 57920] wscale 0 [1024494100 + 57920] wscale 0 age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes id: 422a294200000336 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1116 FIN_WAIT_2:FIN_WAIT_2 [2568047902 + 57920] wscale 0 [2313094524 + 57920] wscale 0 age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes id: 422a294200000383 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1372 FIN_WAIT_2:FIN_WAIT_2 [2263179419 + 57920] wscale 0 [665532303 + 57920] wscale 0 age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes id: 422a29420000035b creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1119 FIN_WAIT_2:FIN_WAIT_2 [3415385225 + 57920] wscale 0 [1370230622 + 57920] wscale 0 age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes id: 422a294200000382 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3938 FIN_WAIT_2:FIN_WAIT_2 [3603803766 + 57920] wscale 0 [276202704 + 57920] wscale 0 age 00:00:50, expires in 00:00:40, 5:4 pkts, 363:508 bytes id: 422a294200000386 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4456 FIN_WAIT_2:FIN_WAIT_2 [48494854 + 57920] wscale 0 [1301768752 + 57920] wscale 0 age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes id: 422a29420000032e creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2153 FIN_WAIT_2:FIN_WAIT_2 [2753680443 + 57920] wscale 0 [557071720 + 57920] wscale 0 age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes id: 422a29420000031f creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4714 FIN_WAIT_2:FIN_WAIT_2 [1504808638 + 57920] wscale 0 [2927860233 + 57920] wscale 0 age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes id: 422a29420000033a creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3693 FIN_WAIT_2:FIN_WAIT_2 [416273073 + 57920] wscale 0 [4216442984 + 57920] wscale 0 age 00:01:00, expires in 00:00:30, 5:4 pkts, 363:508 bytes id: 422a294200000312 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2159 FIN_WAIT_2:FIN_WAIT_2 [617626453 + 57920] wscale 0 [3344368062 + 57920] wscale 0 age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes id: 422a294200000321 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3951 FIN_WAIT_2:FIN_WAIT_2 [2792267335 + 57920] wscale 0 [997036292 + 57920] wscale 0 age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes id: 422a294200000379 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2673 FIN_WAIT_2:FIN_WAIT_2 [4169187362 + 57920] wscale 0 [2600215828 + 57920] wscale 0 age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes id: 422a294200000332 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3698 FIN_WAIT_2:FIN_WAIT_2 [4173377263 + 57920] wscale 0 [113027635 + 57920] wscale 0 age 00:00:55, expires in 00:00:36, 5:4 pkts, 363:508 bytes id: 422a294200000355 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2169 FIN_WAIT_2:FIN_WAIT_2 [3490211889 + 57920] wscale 0 [2950876502 + 57920] wscale 0 age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes id: 422a29420000037c creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2937 FIN_WAIT_2:FIN_WAIT_2 [978963795 + 57920] wscale 0 [1899890588 + 57920] wscale 0 age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes id: 422a294200000354 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4473 FIN_WAIT_2:FIN_WAIT_2 [20706720 + 57920] wscale 0 [308909836 + 57920] wscale 0 age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes id: 422a294200000315 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3706 FIN_WAIT_2:FIN_WAIT_2 [1571667015 + 57920] wscale 0 [3670251619 + 57920] wscale 0 age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes id: 422a294200000381 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4732 FIN_WAIT_2:FIN_WAIT_2 [558353217 + 57920] wscale 0 [1843229679 + 57920] wscale 0 age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes id: 422a294200000339 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1150 FIN_WAIT_2:FIN_WAIT_2 [69371452 + 57920] wscale 0 [2527043649 + 57920] wscale 0 age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes id: 422a29420000034e creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4738 FIN_WAIT_2:FIN_WAIT_2 [3004764914 + 57920] wscale 0 [3140248529 + 57920] wscale 0 age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes id: 422a29420000035f creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1155 FIN_WAIT_2:FIN_WAIT_2 [1742408037 + 57920] wscale 0 [217529573 + 57920] wscale 0 age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes id: 422a294200000359 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4996 FIN_WAIT_2:FIN_WAIT_2 [3353863411 + 57920] wscale 0 [2037795993 + 57920] wscale 0 age 00:00:57, expires in 00:00:33, 5:4 pkts, 363:508 bytes id: 422a29420000033d creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2438 FIN_WAIT_2:FIN_WAIT_2 [2363515767 + 57920] wscale 0 [940185069 + 57920] wscale 0 age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes id: 422a29420000037a creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2440 FIN_WAIT_2:FIN_WAIT_2 [1512264113 + 57920] wscale 0 [1583872006 + 57920] wscale 0 age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes id: 422a294200000326 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3977 FIN_WAIT_2:FIN_WAIT_2 [3375214689 + 57920] wscale 0 [3340380428 + 57920] wscale 0 age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes id: 422a294200000338 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2442 FIN_WAIT_2:FIN_WAIT_2 [366541085 + 57920] wscale 0 [4229618380 + 57920] wscale 0 age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes id: 422a294200000365 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2955 FIN_WAIT_2:FIN_WAIT_2 [3023032248 + 57920] wscale 0 [2714578033 + 57920] wscale 0 age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes id: 422a29420000037b creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1676 FIN_WAIT_2:FIN_WAIT_2 [2143584703 + 57920] wscale 0 [2632152330 + 57920] wscale 0 age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes id: 422a294200000334 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2957 FIN_WAIT_2:FIN_WAIT_2 [3376655763 + 57920] wscale 0 [1962882777 + 57920] wscale 0 age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes id: 422a29420000034a creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2959 FIN_WAIT_2:FIN_WAIT_2 [2381496694 + 57920] wscale 0 [3907940618 + 57920] wscale 0 age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes id: 422a29420000036e creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2193 FIN_WAIT_2:FIN_WAIT_2 [1147009346 + 57920] wscale 0 [652578834 + 57920] wscale 0 age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes id: 422a29420000031c creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1173 FIN_WAIT_2:FIN_WAIT_2 [3847048096 + 57920] wscale 0 [4202192232 + 57920] wscale 0 age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes id: 422a294200000367 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2966 FIN_WAIT_2:FIN_WAIT_2 [1704883050 + 57920] wscale 0 [397640671 + 57920] wscale 0 age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes id: 422a29420000034b creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1176 FIN_WAIT_2:FIN_WAIT_2 [2908611795 + 57920] wscale 0 [1143955128 + 57920] wscale 0 age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes id: 422a29420000034f creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3225 TIME_WAIT:TIME_WAIT [4053421973 + 57344] wscale 0 [1116197573 + 57345] wscale 0 age 00:00:57, expires in 00:00:33, 2:1 pkts, 100:60 bytes id: 422a294200000344 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3227 FIN_WAIT_2:FIN_WAIT_2 [3697384915 + 57920] wscale 0 [4194776544 + 57920] wscale 0 age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes id: 422a294200000323 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4764 FIN_WAIT_2:FIN_WAIT_2 [3426015243 + 57920] wscale 0 [3468954857 + 57920] wscale 0 age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes id: 422a29420000031a creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2721 FIN_WAIT_2:FIN_WAIT_2 [3210917859 + 57920] wscale 0 [501355691 + 57920] wscale 0 age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes id: 422a29420000035e creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2214 FIN_WAIT_2:FIN_WAIT_2 [2024368372 + 57920] wscale 0 [1315702046 + 57920] wscale 0 age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes id: 422a29420000032d creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2983 FIN_WAIT_2:FIN_WAIT_2 [3207150264 + 57920] wscale 0 [2168442372 + 57920] wscale 0 age 00:00:57, expires in 00:00:33, 5:4 pkts, 363:508 bytes id: 422a294200000342 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4263 FIN_WAIT_2:FIN_WAIT_2 [46597085 + 57920] wscale 0 [4061701497 + 57920] wscale 0 age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes id: 422a29420000032c creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2984 FIN_WAIT_2:FIN_WAIT_2 [785309605 + 57920] wscale 0 [178732332 + 57920] wscale 0 age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes id: 422a294200000335 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4265 FIN_WAIT_2:FIN_WAIT_2 [1077034523 + 57920] wscale 0 [508685133 + 57920] wscale 0 age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes id: 422a294200000347 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2474 FIN_WAIT_2:FIN_WAIT_2 [3579823839 + 57920] wscale 0 [3186549033 + 57920] wscale 0 age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes id: 422a294200000317 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3501 FIN_WAIT_2:FIN_WAIT_2 [830389565 + 57920] wscale 0 [3726843152 + 57920] wscale 0 age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes id: 422a294200000366 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4785 FIN_WAIT_2:FIN_WAIT_2 [2419913039 + 57920] wscale 0 [2289781021 + 57920] wscale 0 age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes id: 422a294200000348 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3511 FIN_WAIT_2:FIN_WAIT_2 [2249296099 + 57920] wscale 0 [2932871839 + 57920] wscale 0 age 00:00:50, expires in 00:00:40, 5:4 pkts, 363:508 bytes id: 422a294200000385 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4794 FIN_WAIT_2:FIN_WAIT_2 [3411371868 + 57920] wscale 0 [2783458838 + 57920] wscale 0 age 00:00:50, expires in 00:00:40, 5:4 pkts, 363:508 bytes id: 422a294200000387 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4539 FIN_WAIT_2:FIN_WAIT_2 [1104604839 + 57920] wscale 0 [2842567409 + 57920] wscale 0 age 00:00:57, expires in 00:00:33, 5:4 pkts, 363:508 bytes id: 422a29420000033e creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3519 FIN_WAIT_2:FIN_WAIT_2 [3740703471 + 57920] wscale 0 [87932817 + 57920] wscale 0 age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes id: 422a294200000374 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3521 FIN_WAIT_2:FIN_WAIT_2 [2968103458 + 57920] wscale 0 [3601469586 + 57920] wscale 0 age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes id: 422a294200000316 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2249 FIN_WAIT_2:FIN_WAIT_2 [482606504 + 57920] wscale 0 [2208108060 + 57920] wscale 0 age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes id: 422a294200000372 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1994 FIN_WAIT_2:FIN_WAIT_2 [39371535 + 57920] wscale 0 [3193833702 + 57920] wscale 0 age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes id: 422a294200000314 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4818 FIN_WAIT_2:FIN_WAIT_2 [1810505629 + 57920] wscale 0 [2489348362 + 57920] wscale 0 age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes id: 422a294200000371 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1238 FIN_WAIT_2:FIN_WAIT_2 [1759844756 + 57920] wscale 0 [1414167188 + 57920] wscale 0 age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes id: 422a294200000378 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2262 FIN_WAIT_2:FIN_WAIT_2 [837001507 + 57920] wscale 0 [3660905760 + 57920] wscale 0 age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes id: 422a29420000037d creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3030 FIN_WAIT_2:FIN_WAIT_2 [2939379438 + 57920] wscale 0 [2989656088 + 57920] wscale 0 age 00:00:50, expires in 00:00:40, 5:4 pkts, 363:508 bytes id: 422a294200000388 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4566 FIN_WAIT_2:FIN_WAIT_2 [36874042 + 57920] wscale 0 [1489690186 + 57920] wscale 0 age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes id: 422a29420000036d creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3033 FIN_WAIT_2:FIN_WAIT_2 [894623290 + 57920] wscale 0 [1705678299 + 57920] wscale 0 age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes id: 422a294200000324 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4058 FIN_WAIT_2:FIN_WAIT_2 [3593573975 + 57920] wscale 0 [4218672704 + 57920] wscale 0 age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes id: 422a294200000322 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1499 FIN_WAIT_2:FIN_WAIT_2 [3353910087 + 57920] wscale 0 [2313641214 + 57920] wscale 0 age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes id: 422a294200000361 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1244 FIN_WAIT_2:FIN_WAIT_2 [2144658656 + 57920] wscale 0 [3510611502 + 57920] wscale 0 age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes id: 422a294200000360 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3551 FIN_WAIT_2:FIN_WAIT_2 [3266650438 + 57920] wscale 0 [1463919518 + 57920] wscale 0 age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes id: 422a29420000036b creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4064 FIN_WAIT_2:FIN_WAIT_2 [480151856 + 57920] wscale 0 [111602781 + 57920] wscale 0 age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes id: 422a29420000034c creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3041 FIN_WAIT_2:FIN_WAIT_2 [3790883218 + 57920] wscale 0 [1635610553 + 57920] wscale 0 age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes id: 422a294200000337 creatorid: 0f363004 self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2786 FIN_WAIT_2:FIN_WAIT_2 [1503037157 + 57920] wscale 0 [2999158633 + 57920] wscale 0 age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes id: 422a294200000358 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4837 FIN_WAIT_2:FIN_WAIT_2 [3904040791 + 57920] wscale 0 [1708743304 + 57920] wscale 0 age 00:00:57, expires in 00:00:33, 5:4 pkts, 363:508 bytes id: 422a294200000343 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3561 FIN_WAIT_2:FIN_WAIT_2 [760186488 + 57920] wscale 0 [3036802596 + 57920] wscale 0 age 00:01:00, expires in 00:00:31, 5:4 pkts, 363:508 bytes id: 422a294200000313 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1258 FIN_WAIT_2:FIN_WAIT_2 [283551952 + 57920] wscale 0 [2454096152 + 57920] wscale 0 age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes id: 422a29420000036f creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4590 FIN_WAIT_2:FIN_WAIT_2 [1656348739 + 57920] wscale 0 [1476131618 + 57920] wscale 0 age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes id: 422a294200000363 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1785 FIN_WAIT_2:FIN_WAIT_2 [378495766 + 57920] wscale 0 [449574348 + 57920] wscale 0 age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes id: 422a294200000357 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4601 FIN_WAIT_2:FIN_WAIT_2 [3216638735 + 57920] wscale 0 [2886955349 + 57920] wscale 0 age 00:00:54, expires in 00:00:37, 5:4 pkts, 363:508 bytes id: 422a294200000369 creatorid: 0f363004 self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4093 FIN_WAIT_2:FIN_WAIT_2 [3263818736 + 57920] wscale 0 [2611351584 + 57920] wscale 0 age 00:00:57, expires in 00:00:33, 5:4 pkts, 363:508 bytes id: 422a294200000341 creatorid: 0f363004 # pfctl -si No ALTQ support in kernel ALTQ related functions disabled Status: Enabled for 0 days 08:31:15 Debug: Misc Hostid: 0x0f363004 State Table Total Rate current entries 0 searches 49637 1.6/s inserts 906 0.0/s removals 906 0.0/s Counters match 42759 1.4/s bad-offset 0 0.0/s fragment 0 0.0/s short 0 0.0/s normalize 0 0.0/s memory 0 0.0/s I might of run the pfctl -si to late after the test... I re-ran the test and when I got the symptoms again I rerans the pfctl -si output: # pfctl -si No ALTQ support in kernel ALTQ related functions disabled Status: Enabled for 0 days 08:33:18 Debug: Misc Hostid: 0x0f363004 State Table Total Rate current entries 53 searches 50837 1.7/s inserts 959 0.0/s removals 906 0.0/s Counters match 43534 1.4/s bad-offset 0 0.0/s fragment 0 0.0/s short 0 0.0/s normalize 0 0.0/s memory 0 0.0/s >Daniel Thank you, Stephane. _________________________________________________________________ Designer Mail isn't just fun to send, it's fun to receive. Use special stationery, fonts and colors. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. From owner-freebsd-pf@FreeBSD.ORG Sun Mar 6 20:42:09 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B714F16A4CE for ; Sun, 6 Mar 2005 20:42:09 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34AD843D1D for ; Sun, 6 Mar 2005 20:42:09 +0000 (GMT) (envelope-from jarthel@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so940651rng for ; Sun, 06 Mar 2005 12:42:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=OpAHS6x04OpRAPS4nKeMzRVEuHxkuSEG8HH1VDOahmB4GxjYEqJvGWuCyUc/sKHDriQ21w/jZUmbjTryqKoSfGb6xZ7q022+CHEbHhwkULELQ+7K62ezRK6g9OLDkHz259vSVjwSUpeq0ru40DkjiZyqNCLUrJR9sJCJ7B8/EXY= Received: by 10.38.22.11 with SMTP id 11mr113632rnv; Sun, 06 Mar 2005 12:42:08 -0800 (PST) Received: by 10.38.151.8 with HTTP; Sun, 6 Mar 2005 12:42:08 -0800 (PST) Message-ID: Date: Mon, 7 Mar 2005 07:42:08 +1100 From: Jayel Villamin To: freebsd-pf@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: PC dns request is getting blocked X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Jayel Villamin List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2005 20:42:09 -0000 pf.conf contents ===================== ###### #macros #interfaces ext_if = "tun0" egwene_if = "xl1" elayne_if = "xl2" loopback_if = "lo0" #private networks private_net = "{ 192.168.0.0/16, 172.16.0.0/12, 127.0.0.0/8, 10.0.0.0/8, 0.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24, 204.152.64.0/23, 224.0.0.0/3 }" #network services icmp_types = "echoreq" ext_out_udp_ports = "{ domain, ntp }" ext_in_tcp_ports_from = "{ ftp-data, 1066 }" ext_in_tcp_ports_to = "{ ssh, auth, 19979,19969 }" ext_in_apache = "19989" egwene_in_udp_ports = "{ domain, ntp }" egwene_in_tcp_ports = "{ socks, 19999, 19985:19989, 6881:6889, 5900:5909, https, ssh, pop3, smtp }" egwene_out_tcp_ports = "{ 19975:19979, 19999 }" egwene_out_home_lan_services = "{ 19985:19989, 5900:5909 }" elayne_in_udp_ports = "{ domain, ntp }" elayne_in_tcp_ports = "{ socks, 19999, 19985:19989, 6881:6889, 5900:5909, https, ssh, nntp }" elayne_out_tcp_ports = "{ 19975:19979, 19999 }" elayne_out_home_lan_services = "{ 19985:19989, 5900:5909 }" #specific PCs nynaeve = "127.0.0.1/32" nynaeve_nic2 = "192.168.1.1/32" nynaeve_nic3 = "192.168.2.1/32" egwene = "192.168.1.2/32" rand = "192.168.1.3/32" elayne = "192.168.2.2/32" ###### #pf options set limit { frags 10000, states 10000 } set loginterface $ext_if set optimization normal set block-policy drop ####### #scrub packets scrub all fragment reassemble ###### #nat and redirection nat on $ext_if from $egwene_if:network to any -> ($ext_if) nat on $ext_if from $elayne_if:network to any -> ($ext_if) rdr on $ext_if proto tcp from any to ($ext_if) port www -> $nynaeve port 19989 ###### #rules block log all pass quick on $loopback_if all block in quick on $ext_if from $private_net to any block out quick on $ext_if from any to $private_net pass out quick on $ext_if inet proto udp from ($ext_if) to any port $ext_out_udp_ports keep state pass out quick on $ext_if inet proto tcp from ($ext_if) to any flags S/SA keep state pass in quick on $ext_if inet proto tcp from any port $ext_in_tcp_ports_from to ($ext_if) keep state pass in quick on $ext_if inet proto tcp from any to ($ext_if) port $ext_in_tcp_ports_to flags S/SA keep state pass in quick on $ext_if inet proto tcp from any to 127.0.0.1 port $ext_in_apache flags S/SA synproxy state pass in quick on $egwene_if inet proto udp from $egwene_if:network to $nynaeve_nic2 port $egwene_in_udp_ports keep state pass in quick on $egwene_if inet proto tcp from $egwene_if:network to any port $egwene_in_tcp_ports flags S/SA keep state pass out quick on $egwene_if inet proto tcp from $egwene_if:network to any port $egwene_out_tcp_ports flags S/SA keep state pass out quick on $egwene_if inet proto tcp from $elayne_if:network to $egwene_if:network port $egwene_out_home_lan_services flags S/SA keep state pass in quick on $egwene_if inet proto tcp from $nynaeve_nic2 port = socks to $egwene_if:network pass out quick on $elayne_if inet proto udp from $elayne_if:network to $nynaeve_nic3 port $elayne_in_udp_ports keep state pass in quick on $elayne_if inet proto tcp from $elayne_if:network to any port $elayne_in_tcp_ports flags S/SA keep state pass out quick on $elayne_if inet proto tcp from $elayne_if:network to any port $elayne_out_tcp_ports keep state pass out quick on $elayne_if inet proto tcp from $egwene_if:network to $elayne_if:network port $elayne_out_home_lan_services flags S/SA keep state pass in quick on $elayne_if inet proto tcp from $nynaeve_nic3 port = socks to $elayne_if:network #allow pings to go out pass out quick on $ext_if inet proto icmp from ($ext_if) to any icmp-type $icmp_types keep state pass in quick on $egwene_if inet proto icmp from $egwene_if:network to any icmp-type $icmp_types keep state pass in quick on $elayne_if inet proto icmp from $elayne_if:network to any icmp-type $icmp_types keep state #allow VNC coming in from outside world pass out quick on $egwene_if inet proto tcp from $nynaeve_nic2 to $egwene port = 5900 flags S/SA keep state pass out quick on $egwene_if inet proto tcp from $nynaeve_nic2 to $rand port = 5901 flags S/SA keep state pass out quick on $elayne_if inet proto tcp from $nynaeve_nic3 to $elayne port = 5905 flags S/SA keep state ============================= As can be seen above, "egwene" and "elayne" section have similar config except for interface and ip addresses. I have a 3rd PC which is connected to the "elayne section" and has a fresh install of Windows XP. This 3rd PC has been configured as: IP = 192.168.2.2 gateway = 192.168.2.1 dns = 192.168.2.1. Every time I run "tcpdump -i pflog0", the 3rd PC DNS requests is blocked. The output is something like: elayne.wot.blackjack > nynaeve_nic3.domain I can ping 192.168.1.1 and 192.168.2.1 and I can VNC from the 3rd PC to a 2nd PC in the network so this 3rd PC is connected to the network. I am not sure if only DNS request is the problem. I have a 2nd PC also running Windows XP and using: IP =192.168.1.2 gateway = 192.168.1.1 DNS = 192.168.1.1 This PC has no problems whatsoever with connecting to the internet and it has no problems with DNS queries. I then changed the 3rd PC's IP to 192.168.1.3 (using the same gateway and DNS server as the 2nd PC) and then proceed to connect the cat5 cable to the same switch where the 2nd PC is connected. Since the 2nd PC has no internet connection problems, it is safe to assume that the 3rd PC's DNS request won't be blocked. Well after running tcpdump again, DNS queries from the 3rd PC with the new IP is still getting blocked. As another test, I turn off the 3rd PC and changed the IP of the 2nd PC to 192.168.1.3 which is the same IP as the 3rd PC. Since DNS request from the 3rd PC is getting blocked, I am expecting that DNS request from the 3nd PC will be blocked now. Guess what? No problems at all. I know that somehow, WindowsXP is caching DNS that has been queried before. So when I tested it, I went to sites (e.g. www.bbc.co.uk or www.excite.com or www.yahoo.com or www.excite.co.jp) I haven't visited yet. Could the network card on the 3rd PC be faulty? But as I said above, I can ping 192.168.1.1 and 192.168.2.1 from the 3rd PC. And VNC from the 3rd PC to the 2nd PC is not a problem. Any help is appreciated. Thank you for the replies. From owner-freebsd-pf@FreeBSD.ORG Mon Mar 7 11:03:23 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02D4816A4CE for ; Mon, 7 Mar 2005 11:03:23 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCFF043D53 for ; Mon, 7 Mar 2005 11:03:22 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j27B3MKL038880 for ; Mon, 7 Mar 2005 11:03:22 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j27B3MBf038874 for pf@freebsd.org; Mon, 7 Mar 2005 11:03:22 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 7 Mar 2005 11:03:22 GMT Message-Id: <200503071103.j27B3MBf038874@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: pf@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2005 11:03:23 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- p [2005/02/17] kern/77645 pf pfctl panices the system when interface r 1 problem total. Non-critical problems From owner-freebsd-pf@FreeBSD.ORG Mon Mar 7 12:35:57 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FF0B16A4CE; Mon, 7 Mar 2005 12:35:57 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 310FE43D2F; Mon, 7 Mar 2005 12:35:57 +0000 (GMT) (envelope-from mlaier@FreeBSD.org) Received: from freefall.freebsd.org (mlaier@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j27CZvSv053485; Mon, 7 Mar 2005 12:35:57 GMT (envelope-from mlaier@freefall.freebsd.org) Received: (from mlaier@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j27CZurG053481; Mon, 7 Mar 2005 12:35:56 GMT (envelope-from mlaier) Date: Mon, 7 Mar 2005 12:35:56 GMT From: Max Laier Message-Id: <200503071235.j27CZurG053481@freefall.freebsd.org> To: harry@schmalzbauer.de, mlaier@FreeBSD.org, pf@FreeBSD.org Subject: Re: kern/77645: pfctl panices the system when interface renaming is used X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2005 12:35:57 -0000 Synopsis: pfctl panices the system when interface renaming is used State-Changed-From-To: patched->closed State-Changed-By: mlaier State-Changed-When: Mon Mar 7 12:34:58 GMT 2005 State-Changed-Why: This has been committed to RELENG_5 some time ago already. It should no longer be a problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=77645 From owner-freebsd-pf@FreeBSD.ORG Tue Mar 8 00:28:43 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB8E216A4CE for ; Tue, 8 Mar 2005 00:28:42 +0000 (GMT) Received: from hotmail.com (bay24-f20.bay24.hotmail.com [64.4.18.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5878143D5E for ; Tue, 8 Mar 2005 00:28:42 +0000 (GMT) (envelope-from segr@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 7 Mar 2005 16:28:42 -0800 Message-ID: Received: from 204.9.110.182 by by24fd.bay24.hotmail.msn.com with HTTP; Tue, 08 Mar 2005 00:28:41 GMT X-Originating-IP: [204.9.110.182] X-Originating-Email: [segr@hotmail.com] X-Sender: segr@hotmail.com In-Reply-To: From: "Stephane Raimbault" To: segr@hotmail.com, daniel@benzedrine.cx Date: Mon, 07 Mar 2005 17:28:41 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 08 Mar 2005 00:28:42.0176 (UTC) FILETIME=[C7E53400:01C52375] cc: freebsd-pf@freebsd.org Subject: Re: nat / rdr timeouts? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 00:28:43 -0000 Okay, I setup an OpenBSD 3.6 box with pf today as a test and I can not replicate the problem with OpenBSD. In fact, running the ab test returned MUCH beter results in terms of times to return the page and according to top the cpu barely budged when running the test on the openbsd pf box. However running top on the freebsd pf box I clearly see a spike in cpu traffic as the cpu idle drops to 0% for a second. I'm currently running RELENG_5 on the freebsd box from this weekend... are there some debugging stuff turned on in the kernel that would explain the performance diffrence? I tried to replicate the test as closely as possible however there are some subtle diffrences in my test. OpenBSD test PowerBook laptop (running ab) to an IP on the local network (openbsd ext interface (vlan0)) thru to the same openbsd box int interface (vlan1) to the web servers (10.0.11.16 and 10.0.11.17). FreeBSD Test IBM server running freebsd (ab) to an IP on it's local network (freebsd ext interface (em0) thru to the same freebsd box int interface (em1) to the web severs (10.0.11.16 and 10.0.11.17). network wise it should be pretty much the same. The only thing that came to mind, maybe it's because the powerbook is a better box then the IBM server running freebsd ? but then seeing the CPU idle time and comparing the Freebsd +pf and the OpenBSD +pf being so diffrent... I ponder my question. Hope this makes sense. Let me know if there is any other data I can provide ? Thanks, Stephane. >From: "Stephane Raimbault" >To: daniel@benzedrine.cx >CC: freebsd-pf@freebsd.org >Subject: Re: nat / rdr timeouts? >Date: Sat, 05 Mar 2005 23:08:31 -0700 > >Thanks for the response... my debug output is below. > >>From: Daniel Hartmeier >>To: Stephane Raimbault >>CC: freebsd-pf@freebsd.org >>Subject: Re: nat / rdr timeouts? >>Date: Sat, 5 Mar 2005 23:20:00 +0100 >> >>On Sat, Mar 05, 2005 at 02:57:56PM -0700, Stephane Raimbault wrote: >> >> > I cvsup'd RELENG_5 and recompiled the kernel and I'm seeing the same >> > results. Do I need to recompile any other parts of the system? >> >>No, that's it. >> >> > Do we believe I've stumbled onto a bug of pf... or is this some sort of >> > anti-DoS feature? >> >>The default limit on number of states is 10,000. If further packets try >>to create state, they are dropped. But it doesn't look like you're >>hitting that. >> >>Enable debug loggin (pfctl -xm), reproduce the problem, then check >>/var/log/messages for anything from pf. >> > >Mar 5 23:17:56 lb1-dev kernel: pf: BAD state: TCP 10.0.11.16:80 >204.9.110.170:80 204.9.110.139:1372 [lo=665532303 high=665590223 win=57920 >modulator=0 wscale=0] [lo=2263179419 high=2263237339 win=57920 modulator=0 >wscale=0] 9:9 S seq=669705236 ack=2263179419 len=0 ackskew=0 pkts=5:4 >dir=in,fwd >Mar 5 23:17:56 lb1-dev kernel: pf: State failure on: 1 | 5 >Mar 5 23:17:59 lb1-dev kernel: pf: BAD state: TCP 10.0.11.16:80 >204.9.110.170:80 204.9.110.139:1372 [lo=665532303 high=665590223 win=57920 >modulator=0 wscale=0] [lo=2263179419 high=2263237339 win=57920 modulator=0 >wscale=0] 9:9 S seq=669705236 ack=2263179419 len=0 ackskew=0 pkts=5:4 >dir=in,fwd >Mar 5 23:17:59 lb1-dev kernel: pf: State failure on: 1 | 5 >Mar 5 23:18:02 lb1-dev kernel: pf: BAD state: TCP 10.0.11.16:80 >204.9.110.170:80 204.9.110.139:1372 [lo=665532303 high=665590223 win=57920 >modulator=0 wscale=0] [lo=2263179419 high=2263237339 win=57920 modulator=0 >wscale=0] 9:9 S seq=669705236 ack=2263179419 len=0 ackskew=0 pkts=5:4 >dir=in,fwd >Mar 5 23:18:02 lb1-dev kernel: pf: State failure on: 1 | 5 >Mar 5 23:18:05 lb1-dev kernel: pf: BAD state: TCP 10.0.11.16:80 >204.9.110.170:80 204.9.110.139:1372 [lo=665532303 high=665590223 win=57920 >modulator=0 wscale=0] [lo=2263179419 high=2263237339 win=57920 modulator=0 >wscale=0] 9:9 S seq=669705236 ack=2263179419 len=0 ackskew=0 pkts=5:4 >dir=in,fwd >Mar 5 23:18:05 lb1-dev kernel: pf: State failure on: 1 | 5 >Mar 5 23:18:09 lb1-dev kernel: pf: BAD state: TCP 10.0.11.16:80 >204.9.110.170:80 204.9.110.139:1372 [lo=665532303 high=665590223 win=57920 >modulator=0 wscale=0] [lo=2263179419 high=2263237339 win=57920 modulator=0 >wscale=0] 9:9 S seq=669705236 ack=2263179419 len=0 ackskew=0 pkts=5:4 >dir=in,fwd >Mar 5 23:18:09 lb1-dev kernel: pf: State failure on: 1 | 5 >Mar 5 23:18:12 lb1-dev kernel: pf: BAD state: TCP 10.0.11.16:80 >204.9.110.170:80 204.9.110.139:1372 [lo=665532303 high=665590223 win=57920 >modulator=0 wscale=0] [lo=2263179419 high=2263237339 win=57920 modulator=0 >wscale=0] 9:9 S seq=669705236 ack=2263179419 len=0 ackskew=0 pkts=5:4 >dir=in,fwd >Mar 5 23:18:12 lb1-dev kernel: pf: State failure on: 1 | 5 >Mar 5 23:18:18 lb1-dev kernel: pf: BAD state: TCP 10.0.11.16:80 >204.9.110.170:80 204.9.110.139:1372 [lo=665532303 high=665590223 win=57920 >modulator=0 wscale=0] [lo=2263179419 high=2263237339 win=57920 modulator=0 >wscale=0] 9:9 S seq=669705236 ack=2263179419 len=0 ackskew=0 pkts=5:4 >dir=in,fwd >Mar 5 23:18:18 lb1-dev kernel: pf: State failure on: 1 | 5 > > > >>Also quote pfctl -vvss output after the problem, as well as pfctl -si, >>please. >> > ># pfctl -vvss >No ALTQ support in kernel >ALTQ related functions disabled >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2561 >FIN_WAIT_2:FIN_WAIT_2 > [32585757 + 57920] wscale 0 [4030666851 + 57920] wscale 0 > age 00:00:57, expires in 00:00:33, 5:4 pkts, 363:508 bytes > id: 422a29420000033f creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3073 >FIN_WAIT_2:FIN_WAIT_2 > [280614368 + 57920] wscale 0 [871170019 + 57920] wscale 0 > age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes > id: 422a294200000368 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1546 >FIN_WAIT_2:FIN_WAIT_2 > [318290820 + 57920] wscale 0 [3755105029 + 57920] wscale 0 > age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes > id: 422a294200000349 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3347 >FIN_WAIT_2:FIN_WAIT_2 > [1140076597 + 57920] wscale 0 [4121153694 + 57920] wscale 0 > age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes > id: 422a29420000031b creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2836 >FIN_WAIT_2:FIN_WAIT_2 > [2909277378 + 57920] wscale 0 [448910790 + 57920] wscale 0 > age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes > id: 422a294200000370 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2327 >FIN_WAIT_2:FIN_WAIT_2 > [2987561263 + 57920] wscale 0 [4146806117 + 57920] wscale 0 > age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes > id: 422a294200000318 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2329 >FIN_WAIT_2:FIN_WAIT_2 > [1833281301 + 57920] wscale 0 [1053857949 + 57920] wscale 0 > age 00:00:59, expires in 00:00:32, 5:4 pkts, 363:508 bytes > id: 422a294200000327 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1818 >FIN_WAIT_2:FIN_WAIT_2 > [2636697734 + 57920] wscale 0 [2763808572 + 57920] wscale 0 > age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes > id: 422a294200000353 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4380 >FIN_WAIT_2:FIN_WAIT_2 > [1563439928 + 57920] wscale 0 [2156220237 + 57920] wscale 0 > age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes > id: 422a294200000375 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3613 >FIN_WAIT_2:FIN_WAIT_2 > [4269333757 + 57920] wscale 0 [28302277 + 57920] wscale 0 > age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes > id: 422a294200000325 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2334 >FIN_WAIT_2:FIN_WAIT_2 > [4236319117 + 57920] wscale 0 [756984446 + 57920] wscale 0 > age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes > id: 422a294200000376 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1570 >FIN_WAIT_2:FIN_WAIT_2 > [1467784327 + 57920] wscale 0 [1805572515 + 57920] wscale 0 > age 00:00:50, expires in 00:00:40, 5:4 pkts, 363:508 bytes > id: 422a294200000389 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2854 >FIN_WAIT_2:FIN_WAIT_2 > [1264223110 + 57920] wscale 0 [3114805151 + 57920] wscale 0 > age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes > id: 422a294200000380 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2599 >FIN_WAIT_2:FIN_WAIT_2 > [2493007175 + 57920] wscale 0 [4071674965 + 57920] wscale 0 > age 00:00:58, expires in 00:00:33, 5:4 pkts, 363:508 bytes > id: 422a29420000033b creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4647 >FIN_WAIT_2:FIN_WAIT_2 > [1519840616 + 57920] wscale 0 [1155588281 + 57920] wscale 0 > age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes > id: 422a294200000351 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2600 >FIN_WAIT_2:FIN_WAIT_2 > [3829938788 + 57920] wscale 0 [2288730060 + 57920] wscale 0 > age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes > id: 422a294200000346 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1323 >FIN_WAIT_2:FIN_WAIT_2 > [3299837026 + 57920] wscale 0 [571661919 + 57920] wscale 0 > age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes > id: 422a29420000037f creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4139 >FIN_WAIT_2:FIN_WAIT_2 > [2936258233 + 57920] wscale 0 [3552485098 + 57920] wscale 0 > age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes > id: 422a29420000034d creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1069 >FIN_WAIT_2:FIN_WAIT_2 > [3429734760 + 57920] wscale 0 [1047686037 + 57920] wscale 0 > age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes > id: 422a294200000350 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1582 >FIN_WAIT_2:FIN_WAIT_2 > [2239408408 + 57920] wscale 0 [792523365 + 57920] wscale 0 > age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes > id: 422a294200000356 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1839 >FIN_WAIT_2:FIN_WAIT_2 > [1084975327 + 57920] wscale 0 [3468075791 + 57920] wscale 0 > age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes > id: 422a29420000035c creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4402 >FIN_WAIT_2:FIN_WAIT_2 > [1734033910 + 57920] wscale 0 [4212345601 + 57920] wscale 0 > age 00:00:57, expires in 00:00:33, 5:4 pkts, 363:508 bytes > id: 422a29420000033c creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3636 >FIN_WAIT_2:FIN_WAIT_2 > [1247559674 + 57920] wscale 0 [3855641134 + 57920] wscale 0 > age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes > id: 422a29420000036c creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4917 >FIN_WAIT_2:FIN_WAIT_2 > [2579269706 + 57920] wscale 0 [2765039414 + 57920] wscale 0 > age 00:00:57, expires in 00:00:33, 5:4 pkts, 363:508 bytes > id: 422a294200000340 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1334 >FIN_WAIT_2:FIN_WAIT_2 > [1322299975 + 57920] wscale 0 [4143165048 + 57920] wscale 0 > age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes > id: 422a294200000352 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1593 >FIN_WAIT_2:FIN_WAIT_2 > [3145580381 + 57920] wscale 0 [1476283631 + 57920] wscale 0 > age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes > id: 422a294200000345 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2361 >TIME_WAIT:TIME_WAIT > [1651992099 + 57344] wscale 0 [1675199900 + 57345] wscale 0 > age 00:00:53, expires in 00:00:37, 2:1 pkts, 100:60 bytes > id: 422a294200000377 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3132 >FIN_WAIT_2:FIN_WAIT_2 > [54760795 + 57920] wscale 0 [685586651 + 57920] wscale 0 > age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes > id: 422a29420000032a creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3388 >FIN_WAIT_2:FIN_WAIT_2 > [1740195130 + 57920] wscale 0 [2837513788 + 57920] wscale 0 > age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes > id: 422a294200000330 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4668 >FIN_WAIT_2:FIN_WAIT_2 > [4153305444 + 57920] wscale 0 [3657625607 + 57920] wscale 0 > age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes > id: 422a294200000362 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2110 >FIN_WAIT_2:FIN_WAIT_2 > [1680438376 + 57920] wscale 0 [4124389714 + 57920] wscale 0 > age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes > id: 422a29420000032b creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4927 >FIN_WAIT_2:FIN_WAIT_2 > [3926918789 + 57920] wscale 0 [1578868844 + 57920] wscale 0 > age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes > id: 422a29420000032f creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2369 >FIN_WAIT_2:FIN_WAIT_2 > [3264887916 + 57920] wscale 0 [1040383065 + 57920] wscale 0 > age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes > id: 422a294200000373 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3138 >FIN_WAIT_2:FIN_WAIT_2 > [3668537022 + 57920] wscale 0 [4070704551 + 57920] wscale 0 > age 00:00:51, expires in 00:00:40, 5:4 pkts, 363:508 bytes > id: 422a294200000384 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4677 >FIN_WAIT_2:FIN_WAIT_2 > [4255514426 + 57920] wscale 0 [2108554394 + 57920] wscale 0 > age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes > id: 422a29420000031e creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1351 >FIN_WAIT_2:FIN_WAIT_2 > [650459315 + 57920] wscale 0 [3007417138 + 57920] wscale 0 > age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes > id: 422a29420000035d creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4935 >FIN_WAIT_2:FIN_WAIT_2 > [2640203207 + 57920] wscale 0 [1946606900 + 57920] wscale 0 > age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes > id: 422a29420000031d creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1864 >FIN_WAIT_2:FIN_WAIT_2 > [302555830 + 57920] wscale 0 [4259092904 + 57920] wscale 0 > age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes > id: 422a29420000035a creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4936 >FIN_WAIT_2:FIN_WAIT_2 > [3747285884 + 57920] wscale 0 [1707501039 + 57920] wscale 0 > age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes > id: 422a294200000364 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4426 >FIN_WAIT_2:FIN_WAIT_2 > [4052825702 + 57920] wscale 0 [1998932217 + 57920] wscale 0 > age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes > id: 422a29420000036a creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4429 >FIN_WAIT_2:FIN_WAIT_2 > [2963041429 + 57920] wscale 0 [2854499682 + 57920] wscale 0 > age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes > id: 422a294200000328 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4941 >FIN_WAIT_2:FIN_WAIT_2 > [363310172 + 57920] wscale 0 [1840047747 + 57920] wscale 0 > age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes > id: 422a294200000331 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1871 >FIN_WAIT_2:FIN_WAIT_2 > [1551203117 + 57920] wscale 0 [1422169461 + 57920] wscale 0 > age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes > id: 422a294200000329 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3152 >FIN_WAIT_2:FIN_WAIT_2 > [1387806479 + 57920] wscale 0 [1346138440 + 57920] wscale 0 > age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes > id: 422a294200000320 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4944 >FIN_WAIT_2:FIN_WAIT_2 > [2112290315 + 57920] wscale 0 [3096897628 + 57920] wscale 0 > age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes > id: 422a29420000037e creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3921 >FIN_WAIT_2:FIN_WAIT_2 > [2276016873 + 57920] wscale 0 [2659410744 + 57920] wscale 0 > age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes > id: 422a294200000333 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4692 >FIN_WAIT_2:FIN_WAIT_2 > [4210818300 + 57920] wscale 0 [3178408136 + 57920] wscale 0 > age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes > id: 422a294200000319 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4696 >FIN_WAIT_2:FIN_WAIT_2 > [3697003529 + 57920] wscale 0 [1024494100 + 57920] wscale 0 > age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes > id: 422a294200000336 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1116 >FIN_WAIT_2:FIN_WAIT_2 > [2568047902 + 57920] wscale 0 [2313094524 + 57920] wscale 0 > age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes > id: 422a294200000383 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1372 >FIN_WAIT_2:FIN_WAIT_2 > [2263179419 + 57920] wscale 0 [665532303 + 57920] wscale 0 > age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes > id: 422a29420000035b creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1119 >FIN_WAIT_2:FIN_WAIT_2 > [3415385225 + 57920] wscale 0 [1370230622 + 57920] wscale 0 > age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes > id: 422a294200000382 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3938 >FIN_WAIT_2:FIN_WAIT_2 > [3603803766 + 57920] wscale 0 [276202704 + 57920] wscale 0 > age 00:00:50, expires in 00:00:40, 5:4 pkts, 363:508 bytes > id: 422a294200000386 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4456 >FIN_WAIT_2:FIN_WAIT_2 > [48494854 + 57920] wscale 0 [1301768752 + 57920] wscale 0 > age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes > id: 422a29420000032e creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2153 >FIN_WAIT_2:FIN_WAIT_2 > [2753680443 + 57920] wscale 0 [557071720 + 57920] wscale 0 > age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes > id: 422a29420000031f creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4714 >FIN_WAIT_2:FIN_WAIT_2 > [1504808638 + 57920] wscale 0 [2927860233 + 57920] wscale 0 > age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes > id: 422a29420000033a creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3693 >FIN_WAIT_2:FIN_WAIT_2 > [416273073 + 57920] wscale 0 [4216442984 + 57920] wscale 0 > age 00:01:00, expires in 00:00:30, 5:4 pkts, 363:508 bytes > id: 422a294200000312 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2159 >FIN_WAIT_2:FIN_WAIT_2 > [617626453 + 57920] wscale 0 [3344368062 + 57920] wscale 0 > age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes > id: 422a294200000321 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3951 >FIN_WAIT_2:FIN_WAIT_2 > [2792267335 + 57920] wscale 0 [997036292 + 57920] wscale 0 > age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes > id: 422a294200000379 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2673 >FIN_WAIT_2:FIN_WAIT_2 > [4169187362 + 57920] wscale 0 [2600215828 + 57920] wscale 0 > age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes > id: 422a294200000332 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3698 >FIN_WAIT_2:FIN_WAIT_2 > [4173377263 + 57920] wscale 0 [113027635 + 57920] wscale 0 > age 00:00:55, expires in 00:00:36, 5:4 pkts, 363:508 bytes > id: 422a294200000355 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2169 >FIN_WAIT_2:FIN_WAIT_2 > [3490211889 + 57920] wscale 0 [2950876502 + 57920] wscale 0 > age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes > id: 422a29420000037c creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2937 >FIN_WAIT_2:FIN_WAIT_2 > [978963795 + 57920] wscale 0 [1899890588 + 57920] wscale 0 > age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes > id: 422a294200000354 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4473 >FIN_WAIT_2:FIN_WAIT_2 > [20706720 + 57920] wscale 0 [308909836 + 57920] wscale 0 > age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes > id: 422a294200000315 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3706 >FIN_WAIT_2:FIN_WAIT_2 > [1571667015 + 57920] wscale 0 [3670251619 + 57920] wscale 0 > age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes > id: 422a294200000381 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4732 >FIN_WAIT_2:FIN_WAIT_2 > [558353217 + 57920] wscale 0 [1843229679 + 57920] wscale 0 > age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes > id: 422a294200000339 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1150 >FIN_WAIT_2:FIN_WAIT_2 > [69371452 + 57920] wscale 0 [2527043649 + 57920] wscale 0 > age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes > id: 422a29420000034e creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4738 >FIN_WAIT_2:FIN_WAIT_2 > [3004764914 + 57920] wscale 0 [3140248529 + 57920] wscale 0 > age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes > id: 422a29420000035f creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1155 >FIN_WAIT_2:FIN_WAIT_2 > [1742408037 + 57920] wscale 0 [217529573 + 57920] wscale 0 > age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes > id: 422a294200000359 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4996 >FIN_WAIT_2:FIN_WAIT_2 > [3353863411 + 57920] wscale 0 [2037795993 + 57920] wscale 0 > age 00:00:57, expires in 00:00:33, 5:4 pkts, 363:508 bytes > id: 422a29420000033d creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2438 >FIN_WAIT_2:FIN_WAIT_2 > [2363515767 + 57920] wscale 0 [940185069 + 57920] wscale 0 > age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes > id: 422a29420000037a creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2440 >FIN_WAIT_2:FIN_WAIT_2 > [1512264113 + 57920] wscale 0 [1583872006 + 57920] wscale 0 > age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes > id: 422a294200000326 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3977 >FIN_WAIT_2:FIN_WAIT_2 > [3375214689 + 57920] wscale 0 [3340380428 + 57920] wscale 0 > age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes > id: 422a294200000338 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2442 >FIN_WAIT_2:FIN_WAIT_2 > [366541085 + 57920] wscale 0 [4229618380 + 57920] wscale 0 > age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes > id: 422a294200000365 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2955 >FIN_WAIT_2:FIN_WAIT_2 > [3023032248 + 57920] wscale 0 [2714578033 + 57920] wscale 0 > age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes > id: 422a29420000037b creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1676 >FIN_WAIT_2:FIN_WAIT_2 > [2143584703 + 57920] wscale 0 [2632152330 + 57920] wscale 0 > age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes > id: 422a294200000334 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2957 >FIN_WAIT_2:FIN_WAIT_2 > [3376655763 + 57920] wscale 0 [1962882777 + 57920] wscale 0 > age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes > id: 422a29420000034a creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2959 >FIN_WAIT_2:FIN_WAIT_2 > [2381496694 + 57920] wscale 0 [3907940618 + 57920] wscale 0 > age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes > id: 422a29420000036e creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2193 >FIN_WAIT_2:FIN_WAIT_2 > [1147009346 + 57920] wscale 0 [652578834 + 57920] wscale 0 > age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes > id: 422a29420000031c creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1173 >FIN_WAIT_2:FIN_WAIT_2 > [3847048096 + 57920] wscale 0 [4202192232 + 57920] wscale 0 > age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes > id: 422a294200000367 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2966 >FIN_WAIT_2:FIN_WAIT_2 > [1704883050 + 57920] wscale 0 [397640671 + 57920] wscale 0 > age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes > id: 422a29420000034b creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1176 >FIN_WAIT_2:FIN_WAIT_2 > [2908611795 + 57920] wscale 0 [1143955128 + 57920] wscale 0 > age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes > id: 422a29420000034f creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3225 >TIME_WAIT:TIME_WAIT > [4053421973 + 57344] wscale 0 [1116197573 + 57345] wscale 0 > age 00:00:57, expires in 00:00:33, 2:1 pkts, 100:60 bytes > id: 422a294200000344 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3227 >FIN_WAIT_2:FIN_WAIT_2 > [3697384915 + 57920] wscale 0 [4194776544 + 57920] wscale 0 > age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes > id: 422a294200000323 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4764 >FIN_WAIT_2:FIN_WAIT_2 > [3426015243 + 57920] wscale 0 [3468954857 + 57920] wscale 0 > age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes > id: 422a29420000031a creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2721 >FIN_WAIT_2:FIN_WAIT_2 > [3210917859 + 57920] wscale 0 [501355691 + 57920] wscale 0 > age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes > id: 422a29420000035e creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2214 >FIN_WAIT_2:FIN_WAIT_2 > [2024368372 + 57920] wscale 0 [1315702046 + 57920] wscale 0 > age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes > id: 422a29420000032d creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2983 >FIN_WAIT_2:FIN_WAIT_2 > [3207150264 + 57920] wscale 0 [2168442372 + 57920] wscale 0 > age 00:00:57, expires in 00:00:33, 5:4 pkts, 363:508 bytes > id: 422a294200000342 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4263 >FIN_WAIT_2:FIN_WAIT_2 > [46597085 + 57920] wscale 0 [4061701497 + 57920] wscale 0 > age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes > id: 422a29420000032c creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2984 >FIN_WAIT_2:FIN_WAIT_2 > [785309605 + 57920] wscale 0 [178732332 + 57920] wscale 0 > age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes > id: 422a294200000335 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4265 >FIN_WAIT_2:FIN_WAIT_2 > [1077034523 + 57920] wscale 0 [508685133 + 57920] wscale 0 > age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes > id: 422a294200000347 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2474 >FIN_WAIT_2:FIN_WAIT_2 > [3579823839 + 57920] wscale 0 [3186549033 + 57920] wscale 0 > age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes > id: 422a294200000317 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3501 >FIN_WAIT_2:FIN_WAIT_2 > [830389565 + 57920] wscale 0 [3726843152 + 57920] wscale 0 > age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes > id: 422a294200000366 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4785 >FIN_WAIT_2:FIN_WAIT_2 > [2419913039 + 57920] wscale 0 [2289781021 + 57920] wscale 0 > age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes > id: 422a294200000348 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3511 >FIN_WAIT_2:FIN_WAIT_2 > [2249296099 + 57920] wscale 0 [2932871839 + 57920] wscale 0 > age 00:00:50, expires in 00:00:40, 5:4 pkts, 363:508 bytes > id: 422a294200000385 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4794 >FIN_WAIT_2:FIN_WAIT_2 > [3411371868 + 57920] wscale 0 [2783458838 + 57920] wscale 0 > age 00:00:50, expires in 00:00:40, 5:4 pkts, 363:508 bytes > id: 422a294200000387 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4539 >FIN_WAIT_2:FIN_WAIT_2 > [1104604839 + 57920] wscale 0 [2842567409 + 57920] wscale 0 > age 00:00:57, expires in 00:00:33, 5:4 pkts, 363:508 bytes > id: 422a29420000033e creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3519 >FIN_WAIT_2:FIN_WAIT_2 > [3740703471 + 57920] wscale 0 [87932817 + 57920] wscale 0 > age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes > id: 422a294200000374 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3521 >FIN_WAIT_2:FIN_WAIT_2 > [2968103458 + 57920] wscale 0 [3601469586 + 57920] wscale 0 > age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes > id: 422a294200000316 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2249 >FIN_WAIT_2:FIN_WAIT_2 > [482606504 + 57920] wscale 0 [2208108060 + 57920] wscale 0 > age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes > id: 422a294200000372 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1994 >FIN_WAIT_2:FIN_WAIT_2 > [39371535 + 57920] wscale 0 [3193833702 + 57920] wscale 0 > age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes > id: 422a294200000314 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4818 >FIN_WAIT_2:FIN_WAIT_2 > [1810505629 + 57920] wscale 0 [2489348362 + 57920] wscale 0 > age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes > id: 422a294200000371 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1238 >FIN_WAIT_2:FIN_WAIT_2 > [1759844756 + 57920] wscale 0 [1414167188 + 57920] wscale 0 > age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes > id: 422a294200000378 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2262 >FIN_WAIT_2:FIN_WAIT_2 > [837001507 + 57920] wscale 0 [3660905760 + 57920] wscale 0 > age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes > id: 422a29420000037d creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3030 >FIN_WAIT_2:FIN_WAIT_2 > [2939379438 + 57920] wscale 0 [2989656088 + 57920] wscale 0 > age 00:00:50, expires in 00:00:40, 5:4 pkts, 363:508 bytes > id: 422a294200000388 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4566 >FIN_WAIT_2:FIN_WAIT_2 > [36874042 + 57920] wscale 0 [1489690186 + 57920] wscale 0 > age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes > id: 422a29420000036d creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3033 >FIN_WAIT_2:FIN_WAIT_2 > [894623290 + 57920] wscale 0 [1705678299 + 57920] wscale 0 > age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes > id: 422a294200000324 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4058 >FIN_WAIT_2:FIN_WAIT_2 > [3593573975 + 57920] wscale 0 [4218672704 + 57920] wscale 0 > age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes > id: 422a294200000322 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1499 >FIN_WAIT_2:FIN_WAIT_2 > [3353910087 + 57920] wscale 0 [2313641214 + 57920] wscale 0 > age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes > id: 422a294200000361 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1244 >FIN_WAIT_2:FIN_WAIT_2 > [2144658656 + 57920] wscale 0 [3510611502 + 57920] wscale 0 > age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes > id: 422a294200000360 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3551 >FIN_WAIT_2:FIN_WAIT_2 > [3266650438 + 57920] wscale 0 [1463919518 + 57920] wscale 0 > age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes > id: 422a29420000036b creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4064 >FIN_WAIT_2:FIN_WAIT_2 > [480151856 + 57920] wscale 0 [111602781 + 57920] wscale 0 > age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes > id: 422a29420000034c creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3041 >FIN_WAIT_2:FIN_WAIT_2 > [3790883218 + 57920] wscale 0 [1635610553 + 57920] wscale 0 > age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes > id: 422a294200000337 creatorid: 0f363004 >self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2786 >FIN_WAIT_2:FIN_WAIT_2 > [1503037157 + 57920] wscale 0 [2999158633 + 57920] wscale 0 > age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes > id: 422a294200000358 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4837 >FIN_WAIT_2:FIN_WAIT_2 > [3904040791 + 57920] wscale 0 [1708743304 + 57920] wscale 0 > age 00:00:57, expires in 00:00:33, 5:4 pkts, 363:508 bytes > id: 422a294200000343 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3561 >FIN_WAIT_2:FIN_WAIT_2 > [760186488 + 57920] wscale 0 [3036802596 + 57920] wscale 0 > age 00:01:00, expires in 00:00:31, 5:4 pkts, 363:508 bytes > id: 422a294200000313 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1258 >FIN_WAIT_2:FIN_WAIT_2 > [283551952 + 57920] wscale 0 [2454096152 + 57920] wscale 0 > age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes > id: 422a29420000036f creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4590 >FIN_WAIT_2:FIN_WAIT_2 > [1656348739 + 57920] wscale 0 [1476131618 + 57920] wscale 0 > age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes > id: 422a294200000363 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1785 >FIN_WAIT_2:FIN_WAIT_2 > [378495766 + 57920] wscale 0 [449574348 + 57920] wscale 0 > age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes > id: 422a294200000357 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4601 >FIN_WAIT_2:FIN_WAIT_2 > [3216638735 + 57920] wscale 0 [2886955349 + 57920] wscale 0 > age 00:00:54, expires in 00:00:37, 5:4 pkts, 363:508 bytes > id: 422a294200000369 creatorid: 0f363004 >self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4093 >FIN_WAIT_2:FIN_WAIT_2 > [3263818736 + 57920] wscale 0 [2611351584 + 57920] wscale 0 > age 00:00:57, expires in 00:00:33, 5:4 pkts, 363:508 bytes > id: 422a294200000341 creatorid: 0f363004 > > > ># pfctl -si >No ALTQ support in kernel >ALTQ related functions disabled >Status: Enabled for 0 days 08:31:15 Debug: Misc > >Hostid: 0x0f363004 > >State Table Total Rate > current entries 0 > searches 49637 1.6/s > inserts 906 0.0/s > removals 906 0.0/s >Counters > match 42759 1.4/s > bad-offset 0 0.0/s > fragment 0 0.0/s > short 0 0.0/s > normalize 0 0.0/s > memory 0 0.0/s > > >I might of run the pfctl -si to late after the test... I re-ran the test >and when I got the symptoms again I rerans the pfctl -si output: > ># pfctl -si >No ALTQ support in kernel >ALTQ related functions disabled >Status: Enabled for 0 days 08:33:18 Debug: Misc > >Hostid: 0x0f363004 > >State Table Total Rate > current entries 53 > searches 50837 1.7/s > inserts 959 0.0/s > removals 906 0.0/s >Counters > match 43534 1.4/s > bad-offset 0 0.0/s > fragment 0 0.0/s > short 0 0.0/s > normalize 0 0.0/s > memory 0 0.0/s > > >>Daniel > >Thank you, >Stephane. > >_________________________________________________________________ >Designer Mail isn't just fun to send, it's fun to receive. Use special >stationery, fonts and colors. >http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines > Start enjoying all the benefits of MSN® Premium right now and get the >first two months FREE*. > >_______________________________________________ >freebsd-pf@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-pf >To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" _________________________________________________________________ Powerful Parental Controls Let your child discover the best the Internet has to offer. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. From owner-freebsd-pf@FreeBSD.ORG Tue Mar 8 00:42:50 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91F8516A4CE for ; Tue, 8 Mar 2005 00:42:50 +0000 (GMT) Received: from hotmail.com (bay24-f18.bay24.hotmail.com [64.4.18.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id E020643D5F for ; Tue, 8 Mar 2005 00:42:49 +0000 (GMT) (envelope-from segr@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 7 Mar 2005 16:42:49 -0800 Message-ID: Received: from 204.9.110.182 by by24fd.bay24.hotmail.msn.com with HTTP; Tue, 08 Mar 2005 00:42:49 GMT X-Originating-IP: [204.9.110.182] X-Originating-Email: [segr@hotmail.com] X-Sender: segr@hotmail.com In-Reply-To: From: "Stephane Raimbault" To: segr@hotmail.com, daniel@benzedrine.cx Date: Mon, 07 Mar 2005 17:42:49 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 08 Mar 2005 00:42:49.0615 (UTC) FILETIME=[C10221F0:01C52377] cc: freebsd-pf@freebsd.org Subject: Re: nat / rdr timeouts? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 00:42:50 -0000 Actually... let me eat my words a bit... I forgot I was debugging on the freebsd - pf box... I set it back to pfctl -x urgent and the performance is as good as the openbsd box again... however still that timeout problem. Sorry ... hit send too fast apparently. Thanks for the help, Stephane. >From: "Stephane Raimbault" >To: segr@hotmail.com, daniel@benzedrine.cx >CC: freebsd-pf@freebsd.org >Subject: Re: nat / rdr timeouts? >Date: Mon, 07 Mar 2005 17:28:41 -0700 > >Okay, I setup an OpenBSD 3.6 box with pf today as a test and I can not >replicate the problem with OpenBSD. > >In fact, running the ab test returned MUCH beter results in terms of times >to return the page and according to top the cpu barely budged when running >the test on the openbsd pf box. However running top on the freebsd pf box >I clearly see a spike in cpu traffic as the cpu idle drops to 0% for a >second. > > >I'm currently running RELENG_5 on the freebsd box from this weekend... are >there some debugging stuff turned on in the kernel that would explain the >performance diffrence? > >I tried to replicate the test as closely as possible however there are some >subtle diffrences in my test. > >OpenBSD test > >PowerBook laptop (running ab) to an IP on the local network (openbsd ext >interface (vlan0)) thru to the same openbsd box int interface (vlan1) to >the web servers (10.0.11.16 and 10.0.11.17). > >FreeBSD Test > >IBM server running freebsd (ab) to an IP on it's local network (freebsd ext >interface (em0) thru to the same freebsd box int interface (em1) to the web >severs (10.0.11.16 and 10.0.11.17). > >network wise it should be pretty much the same. The only thing that came >to mind, maybe it's because the powerbook is a better box then the IBM >server running freebsd ? but then seeing the CPU idle time and comparing >the Freebsd +pf and the OpenBSD +pf being so diffrent... I ponder my >question. > > >Hope this makes sense. Let me know if there is any other data I can >provide ? > >Thanks, >Stephane. > >>From: "Stephane Raimbault" >>To: daniel@benzedrine.cx >>CC: freebsd-pf@freebsd.org >>Subject: Re: nat / rdr timeouts? >>Date: Sat, 05 Mar 2005 23:08:31 -0700 >> >>Thanks for the response... my debug output is below. >> >>>From: Daniel Hartmeier >>>To: Stephane Raimbault >>>CC: freebsd-pf@freebsd.org >>>Subject: Re: nat / rdr timeouts? >>>Date: Sat, 5 Mar 2005 23:20:00 +0100 >>> >>>On Sat, Mar 05, 2005 at 02:57:56PM -0700, Stephane Raimbault wrote: >>> >>> > I cvsup'd RELENG_5 and recompiled the kernel and I'm seeing the same >>> > results. Do I need to recompile any other parts of the system? >>> >>>No, that's it. >>> >>> > Do we believe I've stumbled onto a bug of pf... or is this some sort >>>of >>> > anti-DoS feature? >>> >>>The default limit on number of states is 10,000. If further packets try >>>to create state, they are dropped. But it doesn't look like you're >>>hitting that. >>> >>>Enable debug loggin (pfctl -xm), reproduce the problem, then check >>>/var/log/messages for anything from pf. >>> >> >>Mar 5 23:17:56 lb1-dev kernel: pf: BAD state: TCP 10.0.11.16:80 >>204.9.110.170:80 204.9.110.139:1372 [lo=665532303 high=665590223 win=57920 >>modulator=0 wscale=0] [lo=2263179419 high=2263237339 win=57920 modulator=0 >>wscale=0] 9:9 S seq=669705236 ack=2263179419 len=0 ackskew=0 pkts=5:4 >>dir=in,fwd >>Mar 5 23:17:56 lb1-dev kernel: pf: State failure on: 1 | 5 >>Mar 5 23:17:59 lb1-dev kernel: pf: BAD state: TCP 10.0.11.16:80 >>204.9.110.170:80 204.9.110.139:1372 [lo=665532303 high=665590223 win=57920 >>modulator=0 wscale=0] [lo=2263179419 high=2263237339 win=57920 modulator=0 >>wscale=0] 9:9 S seq=669705236 ack=2263179419 len=0 ackskew=0 pkts=5:4 >>dir=in,fwd >>Mar 5 23:17:59 lb1-dev kernel: pf: State failure on: 1 | 5 >>Mar 5 23:18:02 lb1-dev kernel: pf: BAD state: TCP 10.0.11.16:80 >>204.9.110.170:80 204.9.110.139:1372 [lo=665532303 high=665590223 win=57920 >>modulator=0 wscale=0] [lo=2263179419 high=2263237339 win=57920 modulator=0 >>wscale=0] 9:9 S seq=669705236 ack=2263179419 len=0 ackskew=0 pkts=5:4 >>dir=in,fwd >>Mar 5 23:18:02 lb1-dev kernel: pf: State failure on: 1 | 5 >>Mar 5 23:18:05 lb1-dev kernel: pf: BAD state: TCP 10.0.11.16:80 >>204.9.110.170:80 204.9.110.139:1372 [lo=665532303 high=665590223 win=57920 >>modulator=0 wscale=0] [lo=2263179419 high=2263237339 win=57920 modulator=0 >>wscale=0] 9:9 S seq=669705236 ack=2263179419 len=0 ackskew=0 pkts=5:4 >>dir=in,fwd >>Mar 5 23:18:05 lb1-dev kernel: pf: State failure on: 1 | 5 >>Mar 5 23:18:09 lb1-dev kernel: pf: BAD state: TCP 10.0.11.16:80 >>204.9.110.170:80 204.9.110.139:1372 [lo=665532303 high=665590223 win=57920 >>modulator=0 wscale=0] [lo=2263179419 high=2263237339 win=57920 modulator=0 >>wscale=0] 9:9 S seq=669705236 ack=2263179419 len=0 ackskew=0 pkts=5:4 >>dir=in,fwd >>Mar 5 23:18:09 lb1-dev kernel: pf: State failure on: 1 | 5 >>Mar 5 23:18:12 lb1-dev kernel: pf: BAD state: TCP 10.0.11.16:80 >>204.9.110.170:80 204.9.110.139:1372 [lo=665532303 high=665590223 win=57920 >>modulator=0 wscale=0] [lo=2263179419 high=2263237339 win=57920 modulator=0 >>wscale=0] 9:9 S seq=669705236 ack=2263179419 len=0 ackskew=0 pkts=5:4 >>dir=in,fwd >>Mar 5 23:18:12 lb1-dev kernel: pf: State failure on: 1 | 5 >>Mar 5 23:18:18 lb1-dev kernel: pf: BAD state: TCP 10.0.11.16:80 >>204.9.110.170:80 204.9.110.139:1372 [lo=665532303 high=665590223 win=57920 >>modulator=0 wscale=0] [lo=2263179419 high=2263237339 win=57920 modulator=0 >>wscale=0] 9:9 S seq=669705236 ack=2263179419 len=0 ackskew=0 pkts=5:4 >>dir=in,fwd >>Mar 5 23:18:18 lb1-dev kernel: pf: State failure on: 1 | 5 >> >> >> >>>Also quote pfctl -vvss output after the problem, as well as pfctl -si, >>>please. >>> >> >># pfctl -vvss >>No ALTQ support in kernel >>ALTQ related functions disabled >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2561 >>FIN_WAIT_2:FIN_WAIT_2 >> [32585757 + 57920] wscale 0 [4030666851 + 57920] wscale 0 >> age 00:00:57, expires in 00:00:33, 5:4 pkts, 363:508 bytes >> id: 422a29420000033f creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3073 >>FIN_WAIT_2:FIN_WAIT_2 >> [280614368 + 57920] wscale 0 [871170019 + 57920] wscale 0 >> age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes >> id: 422a294200000368 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1546 >>FIN_WAIT_2:FIN_WAIT_2 >> [318290820 + 57920] wscale 0 [3755105029 + 57920] wscale 0 >> age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes >> id: 422a294200000349 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3347 >>FIN_WAIT_2:FIN_WAIT_2 >> [1140076597 + 57920] wscale 0 [4121153694 + 57920] wscale 0 >> age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes >> id: 422a29420000031b creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2836 >>FIN_WAIT_2:FIN_WAIT_2 >> [2909277378 + 57920] wscale 0 [448910790 + 57920] wscale 0 >> age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes >> id: 422a294200000370 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2327 >>FIN_WAIT_2:FIN_WAIT_2 >> [2987561263 + 57920] wscale 0 [4146806117 + 57920] wscale 0 >> age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes >> id: 422a294200000318 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2329 >>FIN_WAIT_2:FIN_WAIT_2 >> [1833281301 + 57920] wscale 0 [1053857949 + 57920] wscale 0 >> age 00:00:59, expires in 00:00:32, 5:4 pkts, 363:508 bytes >> id: 422a294200000327 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1818 >>FIN_WAIT_2:FIN_WAIT_2 >> [2636697734 + 57920] wscale 0 [2763808572 + 57920] wscale 0 >> age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes >> id: 422a294200000353 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4380 >>FIN_WAIT_2:FIN_WAIT_2 >> [1563439928 + 57920] wscale 0 [2156220237 + 57920] wscale 0 >> age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes >> id: 422a294200000375 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3613 >>FIN_WAIT_2:FIN_WAIT_2 >> [4269333757 + 57920] wscale 0 [28302277 + 57920] wscale 0 >> age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes >> id: 422a294200000325 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2334 >>FIN_WAIT_2:FIN_WAIT_2 >> [4236319117 + 57920] wscale 0 [756984446 + 57920] wscale 0 >> age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes >> id: 422a294200000376 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1570 >>FIN_WAIT_2:FIN_WAIT_2 >> [1467784327 + 57920] wscale 0 [1805572515 + 57920] wscale 0 >> age 00:00:50, expires in 00:00:40, 5:4 pkts, 363:508 bytes >> id: 422a294200000389 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2854 >>FIN_WAIT_2:FIN_WAIT_2 >> [1264223110 + 57920] wscale 0 [3114805151 + 57920] wscale 0 >> age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes >> id: 422a294200000380 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2599 >>FIN_WAIT_2:FIN_WAIT_2 >> [2493007175 + 57920] wscale 0 [4071674965 + 57920] wscale 0 >> age 00:00:58, expires in 00:00:33, 5:4 pkts, 363:508 bytes >> id: 422a29420000033b creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4647 >>FIN_WAIT_2:FIN_WAIT_2 >> [1519840616 + 57920] wscale 0 [1155588281 + 57920] wscale 0 >> age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes >> id: 422a294200000351 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2600 >>FIN_WAIT_2:FIN_WAIT_2 >> [3829938788 + 57920] wscale 0 [2288730060 + 57920] wscale 0 >> age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes >> id: 422a294200000346 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1323 >>FIN_WAIT_2:FIN_WAIT_2 >> [3299837026 + 57920] wscale 0 [571661919 + 57920] wscale 0 >> age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes >> id: 422a29420000037f creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4139 >>FIN_WAIT_2:FIN_WAIT_2 >> [2936258233 + 57920] wscale 0 [3552485098 + 57920] wscale 0 >> age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes >> id: 422a29420000034d creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1069 >>FIN_WAIT_2:FIN_WAIT_2 >> [3429734760 + 57920] wscale 0 [1047686037 + 57920] wscale 0 >> age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes >> id: 422a294200000350 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1582 >>FIN_WAIT_2:FIN_WAIT_2 >> [2239408408 + 57920] wscale 0 [792523365 + 57920] wscale 0 >> age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes >> id: 422a294200000356 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1839 >>FIN_WAIT_2:FIN_WAIT_2 >> [1084975327 + 57920] wscale 0 [3468075791 + 57920] wscale 0 >> age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes >> id: 422a29420000035c creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4402 >>FIN_WAIT_2:FIN_WAIT_2 >> [1734033910 + 57920] wscale 0 [4212345601 + 57920] wscale 0 >> age 00:00:57, expires in 00:00:33, 5:4 pkts, 363:508 bytes >> id: 422a29420000033c creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3636 >>FIN_WAIT_2:FIN_WAIT_2 >> [1247559674 + 57920] wscale 0 [3855641134 + 57920] wscale 0 >> age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes >> id: 422a29420000036c creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4917 >>FIN_WAIT_2:FIN_WAIT_2 >> [2579269706 + 57920] wscale 0 [2765039414 + 57920] wscale 0 >> age 00:00:57, expires in 00:00:33, 5:4 pkts, 363:508 bytes >> id: 422a294200000340 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1334 >>FIN_WAIT_2:FIN_WAIT_2 >> [1322299975 + 57920] wscale 0 [4143165048 + 57920] wscale 0 >> age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes >> id: 422a294200000352 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1593 >>FIN_WAIT_2:FIN_WAIT_2 >> [3145580381 + 57920] wscale 0 [1476283631 + 57920] wscale 0 >> age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes >> id: 422a294200000345 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2361 >>TIME_WAIT:TIME_WAIT >> [1651992099 + 57344] wscale 0 [1675199900 + 57345] wscale 0 >> age 00:00:53, expires in 00:00:37, 2:1 pkts, 100:60 bytes >> id: 422a294200000377 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3132 >>FIN_WAIT_2:FIN_WAIT_2 >> [54760795 + 57920] wscale 0 [685586651 + 57920] wscale 0 >> age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes >> id: 422a29420000032a creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3388 >>FIN_WAIT_2:FIN_WAIT_2 >> [1740195130 + 57920] wscale 0 [2837513788 + 57920] wscale 0 >> age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes >> id: 422a294200000330 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4668 >>FIN_WAIT_2:FIN_WAIT_2 >> [4153305444 + 57920] wscale 0 [3657625607 + 57920] wscale 0 >> age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes >> id: 422a294200000362 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2110 >>FIN_WAIT_2:FIN_WAIT_2 >> [1680438376 + 57920] wscale 0 [4124389714 + 57920] wscale 0 >> age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes >> id: 422a29420000032b creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4927 >>FIN_WAIT_2:FIN_WAIT_2 >> [3926918789 + 57920] wscale 0 [1578868844 + 57920] wscale 0 >> age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes >> id: 422a29420000032f creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2369 >>FIN_WAIT_2:FIN_WAIT_2 >> [3264887916 + 57920] wscale 0 [1040383065 + 57920] wscale 0 >> age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes >> id: 422a294200000373 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3138 >>FIN_WAIT_2:FIN_WAIT_2 >> [3668537022 + 57920] wscale 0 [4070704551 + 57920] wscale 0 >> age 00:00:51, expires in 00:00:40, 5:4 pkts, 363:508 bytes >> id: 422a294200000384 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4677 >>FIN_WAIT_2:FIN_WAIT_2 >> [4255514426 + 57920] wscale 0 [2108554394 + 57920] wscale 0 >> age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes >> id: 422a29420000031e creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1351 >>FIN_WAIT_2:FIN_WAIT_2 >> [650459315 + 57920] wscale 0 [3007417138 + 57920] wscale 0 >> age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes >> id: 422a29420000035d creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4935 >>FIN_WAIT_2:FIN_WAIT_2 >> [2640203207 + 57920] wscale 0 [1946606900 + 57920] wscale 0 >> age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes >> id: 422a29420000031d creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1864 >>FIN_WAIT_2:FIN_WAIT_2 >> [302555830 + 57920] wscale 0 [4259092904 + 57920] wscale 0 >> age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes >> id: 422a29420000035a creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4936 >>FIN_WAIT_2:FIN_WAIT_2 >> [3747285884 + 57920] wscale 0 [1707501039 + 57920] wscale 0 >> age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes >> id: 422a294200000364 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4426 >>FIN_WAIT_2:FIN_WAIT_2 >> [4052825702 + 57920] wscale 0 [1998932217 + 57920] wscale 0 >> age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes >> id: 422a29420000036a creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4429 >>FIN_WAIT_2:FIN_WAIT_2 >> [2963041429 + 57920] wscale 0 [2854499682 + 57920] wscale 0 >> age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes >> id: 422a294200000328 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4941 >>FIN_WAIT_2:FIN_WAIT_2 >> [363310172 + 57920] wscale 0 [1840047747 + 57920] wscale 0 >> age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes >> id: 422a294200000331 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1871 >>FIN_WAIT_2:FIN_WAIT_2 >> [1551203117 + 57920] wscale 0 [1422169461 + 57920] wscale 0 >> age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes >> id: 422a294200000329 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3152 >>FIN_WAIT_2:FIN_WAIT_2 >> [1387806479 + 57920] wscale 0 [1346138440 + 57920] wscale 0 >> age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes >> id: 422a294200000320 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4944 >>FIN_WAIT_2:FIN_WAIT_2 >> [2112290315 + 57920] wscale 0 [3096897628 + 57920] wscale 0 >> age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes >> id: 422a29420000037e creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3921 >>FIN_WAIT_2:FIN_WAIT_2 >> [2276016873 + 57920] wscale 0 [2659410744 + 57920] wscale 0 >> age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes >> id: 422a294200000333 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4692 >>FIN_WAIT_2:FIN_WAIT_2 >> [4210818300 + 57920] wscale 0 [3178408136 + 57920] wscale 0 >> age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes >> id: 422a294200000319 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4696 >>FIN_WAIT_2:FIN_WAIT_2 >> [3697003529 + 57920] wscale 0 [1024494100 + 57920] wscale 0 >> age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes >> id: 422a294200000336 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1116 >>FIN_WAIT_2:FIN_WAIT_2 >> [2568047902 + 57920] wscale 0 [2313094524 + 57920] wscale 0 >> age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes >> id: 422a294200000383 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1372 >>FIN_WAIT_2:FIN_WAIT_2 >> [2263179419 + 57920] wscale 0 [665532303 + 57920] wscale 0 >> age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes >> id: 422a29420000035b creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1119 >>FIN_WAIT_2:FIN_WAIT_2 >> [3415385225 + 57920] wscale 0 [1370230622 + 57920] wscale 0 >> age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes >> id: 422a294200000382 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3938 >>FIN_WAIT_2:FIN_WAIT_2 >> [3603803766 + 57920] wscale 0 [276202704 + 57920] wscale 0 >> age 00:00:50, expires in 00:00:40, 5:4 pkts, 363:508 bytes >> id: 422a294200000386 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4456 >>FIN_WAIT_2:FIN_WAIT_2 >> [48494854 + 57920] wscale 0 [1301768752 + 57920] wscale 0 >> age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes >> id: 422a29420000032e creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2153 >>FIN_WAIT_2:FIN_WAIT_2 >> [2753680443 + 57920] wscale 0 [557071720 + 57920] wscale 0 >> age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes >> id: 422a29420000031f creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4714 >>FIN_WAIT_2:FIN_WAIT_2 >> [1504808638 + 57920] wscale 0 [2927860233 + 57920] wscale 0 >> age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes >> id: 422a29420000033a creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3693 >>FIN_WAIT_2:FIN_WAIT_2 >> [416273073 + 57920] wscale 0 [4216442984 + 57920] wscale 0 >> age 00:01:00, expires in 00:00:30, 5:4 pkts, 363:508 bytes >> id: 422a294200000312 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2159 >>FIN_WAIT_2:FIN_WAIT_2 >> [617626453 + 57920] wscale 0 [3344368062 + 57920] wscale 0 >> age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes >> id: 422a294200000321 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3951 >>FIN_WAIT_2:FIN_WAIT_2 >> [2792267335 + 57920] wscale 0 [997036292 + 57920] wscale 0 >> age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes >> id: 422a294200000379 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2673 >>FIN_WAIT_2:FIN_WAIT_2 >> [4169187362 + 57920] wscale 0 [2600215828 + 57920] wscale 0 >> age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes >> id: 422a294200000332 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3698 >>FIN_WAIT_2:FIN_WAIT_2 >> [4173377263 + 57920] wscale 0 [113027635 + 57920] wscale 0 >> age 00:00:55, expires in 00:00:36, 5:4 pkts, 363:508 bytes >> id: 422a294200000355 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2169 >>FIN_WAIT_2:FIN_WAIT_2 >> [3490211889 + 57920] wscale 0 [2950876502 + 57920] wscale 0 >> age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes >> id: 422a29420000037c creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2937 >>FIN_WAIT_2:FIN_WAIT_2 >> [978963795 + 57920] wscale 0 [1899890588 + 57920] wscale 0 >> age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes >> id: 422a294200000354 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4473 >>FIN_WAIT_2:FIN_WAIT_2 >> [20706720 + 57920] wscale 0 [308909836 + 57920] wscale 0 >> age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes >> id: 422a294200000315 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3706 >>FIN_WAIT_2:FIN_WAIT_2 >> [1571667015 + 57920] wscale 0 [3670251619 + 57920] wscale 0 >> age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes >> id: 422a294200000381 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4732 >>FIN_WAIT_2:FIN_WAIT_2 >> [558353217 + 57920] wscale 0 [1843229679 + 57920] wscale 0 >> age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes >> id: 422a294200000339 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1150 >>FIN_WAIT_2:FIN_WAIT_2 >> [69371452 + 57920] wscale 0 [2527043649 + 57920] wscale 0 >> age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes >> id: 422a29420000034e creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4738 >>FIN_WAIT_2:FIN_WAIT_2 >> [3004764914 + 57920] wscale 0 [3140248529 + 57920] wscale 0 >> age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes >> id: 422a29420000035f creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1155 >>FIN_WAIT_2:FIN_WAIT_2 >> [1742408037 + 57920] wscale 0 [217529573 + 57920] wscale 0 >> age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes >> id: 422a294200000359 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4996 >>FIN_WAIT_2:FIN_WAIT_2 >> [3353863411 + 57920] wscale 0 [2037795993 + 57920] wscale 0 >> age 00:00:57, expires in 00:00:33, 5:4 pkts, 363:508 bytes >> id: 422a29420000033d creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2438 >>FIN_WAIT_2:FIN_WAIT_2 >> [2363515767 + 57920] wscale 0 [940185069 + 57920] wscale 0 >> age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes >> id: 422a29420000037a creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2440 >>FIN_WAIT_2:FIN_WAIT_2 >> [1512264113 + 57920] wscale 0 [1583872006 + 57920] wscale 0 >> age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes >> id: 422a294200000326 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3977 >>FIN_WAIT_2:FIN_WAIT_2 >> [3375214689 + 57920] wscale 0 [3340380428 + 57920] wscale 0 >> age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes >> id: 422a294200000338 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2442 >>FIN_WAIT_2:FIN_WAIT_2 >> [366541085 + 57920] wscale 0 [4229618380 + 57920] wscale 0 >> age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes >> id: 422a294200000365 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2955 >>FIN_WAIT_2:FIN_WAIT_2 >> [3023032248 + 57920] wscale 0 [2714578033 + 57920] wscale 0 >> age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes >> id: 422a29420000037b creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1676 >>FIN_WAIT_2:FIN_WAIT_2 >> [2143584703 + 57920] wscale 0 [2632152330 + 57920] wscale 0 >> age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes >> id: 422a294200000334 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2957 >>FIN_WAIT_2:FIN_WAIT_2 >> [3376655763 + 57920] wscale 0 [1962882777 + 57920] wscale 0 >> age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes >> id: 422a29420000034a creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2959 >>FIN_WAIT_2:FIN_WAIT_2 >> [2381496694 + 57920] wscale 0 [3907940618 + 57920] wscale 0 >> age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes >> id: 422a29420000036e creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2193 >>FIN_WAIT_2:FIN_WAIT_2 >> [1147009346 + 57920] wscale 0 [652578834 + 57920] wscale 0 >> age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes >> id: 422a29420000031c creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1173 >>FIN_WAIT_2:FIN_WAIT_2 >> [3847048096 + 57920] wscale 0 [4202192232 + 57920] wscale 0 >> age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes >> id: 422a294200000367 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2966 >>FIN_WAIT_2:FIN_WAIT_2 >> [1704883050 + 57920] wscale 0 [397640671 + 57920] wscale 0 >> age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes >> id: 422a29420000034b creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1176 >>FIN_WAIT_2:FIN_WAIT_2 >> [2908611795 + 57920] wscale 0 [1143955128 + 57920] wscale 0 >> age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes >> id: 422a29420000034f creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3225 >>TIME_WAIT:TIME_WAIT >> [4053421973 + 57344] wscale 0 [1116197573 + 57345] wscale 0 >> age 00:00:57, expires in 00:00:33, 2:1 pkts, 100:60 bytes >> id: 422a294200000344 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3227 >>FIN_WAIT_2:FIN_WAIT_2 >> [3697384915 + 57920] wscale 0 [4194776544 + 57920] wscale 0 >> age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes >> id: 422a294200000323 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4764 >>FIN_WAIT_2:FIN_WAIT_2 >> [3426015243 + 57920] wscale 0 [3468954857 + 57920] wscale 0 >> age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes >> id: 422a29420000031a creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2721 >>FIN_WAIT_2:FIN_WAIT_2 >> [3210917859 + 57920] wscale 0 [501355691 + 57920] wscale 0 >> age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes >> id: 422a29420000035e creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2214 >>FIN_WAIT_2:FIN_WAIT_2 >> [2024368372 + 57920] wscale 0 [1315702046 + 57920] wscale 0 >> age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes >> id: 422a29420000032d creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2983 >>FIN_WAIT_2:FIN_WAIT_2 >> [3207150264 + 57920] wscale 0 [2168442372 + 57920] wscale 0 >> age 00:00:57, expires in 00:00:33, 5:4 pkts, 363:508 bytes >> id: 422a294200000342 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4263 >>FIN_WAIT_2:FIN_WAIT_2 >> [46597085 + 57920] wscale 0 [4061701497 + 57920] wscale 0 >> age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes >> id: 422a29420000032c creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2984 >>FIN_WAIT_2:FIN_WAIT_2 >> [785309605 + 57920] wscale 0 [178732332 + 57920] wscale 0 >> age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes >> id: 422a294200000335 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4265 >>FIN_WAIT_2:FIN_WAIT_2 >> [1077034523 + 57920] wscale 0 [508685133 + 57920] wscale 0 >> age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes >> id: 422a294200000347 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2474 >>FIN_WAIT_2:FIN_WAIT_2 >> [3579823839 + 57920] wscale 0 [3186549033 + 57920] wscale 0 >> age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes >> id: 422a294200000317 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3501 >>FIN_WAIT_2:FIN_WAIT_2 >> [830389565 + 57920] wscale 0 [3726843152 + 57920] wscale 0 >> age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes >> id: 422a294200000366 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4785 >>FIN_WAIT_2:FIN_WAIT_2 >> [2419913039 + 57920] wscale 0 [2289781021 + 57920] wscale 0 >> age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes >> id: 422a294200000348 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3511 >>FIN_WAIT_2:FIN_WAIT_2 >> [2249296099 + 57920] wscale 0 [2932871839 + 57920] wscale 0 >> age 00:00:50, expires in 00:00:40, 5:4 pkts, 363:508 bytes >> id: 422a294200000385 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4794 >>FIN_WAIT_2:FIN_WAIT_2 >> [3411371868 + 57920] wscale 0 [2783458838 + 57920] wscale 0 >> age 00:00:50, expires in 00:00:40, 5:4 pkts, 363:508 bytes >> id: 422a294200000387 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4539 >>FIN_WAIT_2:FIN_WAIT_2 >> [1104604839 + 57920] wscale 0 [2842567409 + 57920] wscale 0 >> age 00:00:57, expires in 00:00:33, 5:4 pkts, 363:508 bytes >> id: 422a29420000033e creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3519 >>FIN_WAIT_2:FIN_WAIT_2 >> [3740703471 + 57920] wscale 0 [87932817 + 57920] wscale 0 >> age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes >> id: 422a294200000374 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3521 >>FIN_WAIT_2:FIN_WAIT_2 >> [2968103458 + 57920] wscale 0 [3601469586 + 57920] wscale 0 >> age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes >> id: 422a294200000316 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2249 >>FIN_WAIT_2:FIN_WAIT_2 >> [482606504 + 57920] wscale 0 [2208108060 + 57920] wscale 0 >> age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes >> id: 422a294200000372 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1994 >>FIN_WAIT_2:FIN_WAIT_2 >> [39371535 + 57920] wscale 0 [3193833702 + 57920] wscale 0 >> age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes >> id: 422a294200000314 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4818 >>FIN_WAIT_2:FIN_WAIT_2 >> [1810505629 + 57920] wscale 0 [2489348362 + 57920] wscale 0 >> age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes >> id: 422a294200000371 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1238 >>FIN_WAIT_2:FIN_WAIT_2 >> [1759844756 + 57920] wscale 0 [1414167188 + 57920] wscale 0 >> age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes >> id: 422a294200000378 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:2262 >>FIN_WAIT_2:FIN_WAIT_2 >> [837001507 + 57920] wscale 0 [3660905760 + 57920] wscale 0 >> age 00:00:51, expires in 00:00:39, 5:4 pkts, 363:508 bytes >> id: 422a29420000037d creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3030 >>FIN_WAIT_2:FIN_WAIT_2 >> [2939379438 + 57920] wscale 0 [2989656088 + 57920] wscale 0 >> age 00:00:50, expires in 00:00:40, 5:4 pkts, 363:508 bytes >> id: 422a294200000388 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4566 >>FIN_WAIT_2:FIN_WAIT_2 >> [36874042 + 57920] wscale 0 [1489690186 + 57920] wscale 0 >> age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes >> id: 422a29420000036d creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:3033 >>FIN_WAIT_2:FIN_WAIT_2 >> [894623290 + 57920] wscale 0 [1705678299 + 57920] wscale 0 >> age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes >> id: 422a294200000324 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4058 >>FIN_WAIT_2:FIN_WAIT_2 >> [3593573975 + 57920] wscale 0 [4218672704 + 57920] wscale 0 >> age 00:00:59, expires in 00:00:31, 5:4 pkts, 363:508 bytes >> id: 422a294200000322 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1499 >>FIN_WAIT_2:FIN_WAIT_2 >> [3353910087 + 57920] wscale 0 [2313641214 + 57920] wscale 0 >> age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes >> id: 422a294200000361 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:1244 >>FIN_WAIT_2:FIN_WAIT_2 >> [2144658656 + 57920] wscale 0 [3510611502 + 57920] wscale 0 >> age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes >> id: 422a294200000360 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3551 >>FIN_WAIT_2:FIN_WAIT_2 >> [3266650438 + 57920] wscale 0 [1463919518 + 57920] wscale 0 >> age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes >> id: 422a29420000036b creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:4064 >>FIN_WAIT_2:FIN_WAIT_2 >> [480151856 + 57920] wscale 0 [111602781 + 57920] wscale 0 >> age 00:00:55, expires in 00:00:35, 5:4 pkts, 363:508 bytes >> id: 422a29420000034c creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3041 >>FIN_WAIT_2:FIN_WAIT_2 >> [3790883218 + 57920] wscale 0 [1635610553 + 57920] wscale 0 >> age 00:00:58, expires in 00:00:32, 5:4 pkts, 363:508 bytes >> id: 422a294200000337 creatorid: 0f363004 >>self tcp 10.0.11.17:80 <- 204.9.110.170:80 <- 204.9.110.139:2786 >>FIN_WAIT_2:FIN_WAIT_2 >> [1503037157 + 57920] wscale 0 [2999158633 + 57920] wscale 0 >> age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes >> id: 422a294200000358 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4837 >>FIN_WAIT_2:FIN_WAIT_2 >> [3904040791 + 57920] wscale 0 [1708743304 + 57920] wscale 0 >> age 00:00:57, expires in 00:00:33, 5:4 pkts, 363:508 bytes >> id: 422a294200000343 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:3561 >>FIN_WAIT_2:FIN_WAIT_2 >> [760186488 + 57920] wscale 0 [3036802596 + 57920] wscale 0 >> age 00:01:00, expires in 00:00:31, 5:4 pkts, 363:508 bytes >> id: 422a294200000313 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1258 >>FIN_WAIT_2:FIN_WAIT_2 >> [283551952 + 57920] wscale 0 [2454096152 + 57920] wscale 0 >> age 00:00:53, expires in 00:00:37, 5:4 pkts, 363:508 bytes >> id: 422a29420000036f creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4590 >>FIN_WAIT_2:FIN_WAIT_2 >> [1656348739 + 57920] wscale 0 [1476131618 + 57920] wscale 0 >> age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes >> id: 422a294200000363 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:1785 >>FIN_WAIT_2:FIN_WAIT_2 >> [378495766 + 57920] wscale 0 [449574348 + 57920] wscale 0 >> age 00:00:54, expires in 00:00:36, 5:4 pkts, 363:508 bytes >> id: 422a294200000357 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4601 >>FIN_WAIT_2:FIN_WAIT_2 >> [3216638735 + 57920] wscale 0 [2886955349 + 57920] wscale 0 >> age 00:00:54, expires in 00:00:37, 5:4 pkts, 363:508 bytes >> id: 422a294200000369 creatorid: 0f363004 >>self tcp 10.0.11.16:80 <- 204.9.110.170:80 <- 204.9.110.139:4093 >>FIN_WAIT_2:FIN_WAIT_2 >> [3263818736 + 57920] wscale 0 [2611351584 + 57920] wscale 0 >> age 00:00:57, expires in 00:00:33, 5:4 pkts, 363:508 bytes >> id: 422a294200000341 creatorid: 0f363004 >> >> >> >># pfctl -si >>No ALTQ support in kernel >>ALTQ related functions disabled >>Status: Enabled for 0 days 08:31:15 Debug: Misc >> >>Hostid: 0x0f363004 >> >>State Table Total Rate >> current entries 0 >> searches 49637 1.6/s >> inserts 906 0.0/s >> removals 906 0.0/s >>Counters >> match 42759 1.4/s >> bad-offset 0 0.0/s >> fragment 0 0.0/s >> short 0 0.0/s >> normalize 0 0.0/s >> memory 0 0.0/s >> >> >>I might of run the pfctl -si to late after the test... I re-ran the test >>and when I got the symptoms again I rerans the pfctl -si output: >> >># pfctl -si >>No ALTQ support in kernel >>ALTQ related functions disabled >>Status: Enabled for 0 days 08:33:18 Debug: Misc >> >>Hostid: 0x0f363004 >> >>State Table Total Rate >> current entries 53 >> searches 50837 1.7/s >> inserts 959 0.0/s >> removals 906 0.0/s >>Counters >> match 43534 1.4/s >> bad-offset 0 0.0/s >> fragment 0 0.0/s >> short 0 0.0/s >> normalize 0 0.0/s >> memory 0 0.0/s >> >> >>>Daniel >> >>Thank you, >>Stephane. >> >>_________________________________________________________________ >>Designer Mail isn't just fun to send, it's fun to receive. Use special >>stationery, fonts and colors. >>http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines >> Start enjoying all the benefits of MSN® Premium right now and get the >>first two months FREE*. >> >>_______________________________________________ >>freebsd-pf@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-pf >>To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > _________________________________________________________________ Take charge with a pop-up guard built on patented Microsoft® SmartScreen Technology http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. From owner-freebsd-pf@FreeBSD.ORG Tue Mar 8 00:52:15 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF91416A4CE for ; Tue, 8 Mar 2005 00:52:14 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C80943D5A for ; Tue, 8 Mar 2005 00:52:14 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.209] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1D8SxJ-0007Pa-00; Tue, 08 Mar 2005 01:52:13 +0100 Received: from [84.128.142.56] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1D8SxI-0001Ud-00; Tue, 08 Mar 2005 01:52:13 +0100 From: Max Laier To: freebsd-pf@freebsd.org Date: Tue, 8 Mar 2005 01:52:05 +0100 User-Agent: KMail/1.7.2 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4222114.KWxldEHC5O"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200503080152.11837.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 Subject: Re: nat / rdr timeouts? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 00:52:15 -0000 --nextPart4222114.KWxldEHC5O Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 08 March 2005 01:28, Stephane Raimbault wrote: > Okay, I setup an OpenBSD 3.6 box with pf today as a test and I can not > replicate the problem with OpenBSD. > > In fact, running the ab test returned MUCH beter results in terms of times > to return the page and according to top the cpu barely budged when running > the test on the openbsd pf box. However running top on the freebsd pf box > I clearly see a spike in cpu traffic as the cpu idle drops to 0% for a > second. > > > I'm currently running RELENG_5 on the freebsd box from this weekend... are > there some debugging stuff turned on in the kernel that would explain the > performance diffrence? > > I tried to replicate the test as closely as possible however there are so= me > subtle diffrences in my test. > > OpenBSD test > > PowerBook laptop (running ab) to an IP on the local network (openbsd ext > interface (vlan0)) thru to the same openbsd box int interface (vlan1) to > the web servers (10.0.11.16 and 10.0.11.17). > > FreeBSD Test > > IBM server running freebsd (ab) to an IP on it's local network (freebsd e= xt > interface (em0) thru to the same freebsd box int interface (em1) to the w= eb > severs (10.0.11.16 and 10.0.11.17). > > network wise it should be pretty much the same. The only thing that came > to mind, maybe it's because the powerbook is a better box then the IBM > server running freebsd ? but then seeing the CPU idle time and comparing > the Freebsd +pf and the OpenBSD +pf being so diffrent... I ponder my > question. > > > Hope this makes sense. Let me know if there is any other data I can > provide ? I don't fully understand how your setup looks like. Where are you running = ab=20 from? Is there a dedicated box you run it on or are you running it on/from= =20 the redirecting box itself? Could you get the following setup realized: /----- OpenBSD ----\ WWW_1 | | / WWW_2 ab Client ---+ +-----+- ... | | \ WWW_N \----- FreeBSD ----/ It does not matter (too much) how the gateways are connected to the client = and=20 the servers, what matters is that the client and the servers are the same f= or=20 both tests. I suspect that (if you were running ab from the FreeBSD server= )=20 you discovered a bug in FreeBSD's socket/tcp code much rather than in pf. = =20 Please let me know if I misunderstood something and explain your test setup= =20 with a bit more detail. Thanks a lot in advance. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart4222114.KWxldEHC5O Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCLPc7XyyEoT62BG0RAsrSAJ41D1dxIiOsQwMEo2pbK99IcG5hswCfWmeZ NTiCF0pUiiz7fzdbTcl9yVI= =eY3L -----END PGP SIGNATURE----- --nextPart4222114.KWxldEHC5O-- From owner-freebsd-pf@FreeBSD.ORG Tue Mar 8 01:22:18 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A746316A4CE for ; Tue, 8 Mar 2005 01:22:18 +0000 (GMT) Received: from atlas.spiretech.com (atlas.spiretech.com [207.173.200.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CE9143D3F for ; Tue, 8 Mar 2005 01:22:18 +0000 (GMT) (envelope-from fbsd-pf@shelton.ca) Received: from [192.168.0.110] (ben.shelton.ca [207.173.201.46]) (authenticated) by atlas.spiretech.com (8.11.6/8.11.6) with ESMTP id j281MHV28603 for ; Mon, 7 Mar 2005 17:22:17 -0800 Message-ID: <422CFE40.40703@shelton.ca> Date: Mon, 07 Mar 2005 17:22:08 -0800 From: Ben Shelton User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: pf choices X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 01:22:18 -0000 Hello, When researching firewall choices for a pretty large-scale (1.1Gbit max) connection, I initially had thought OpenBSD was the best choice because... well OpenBSD seems to be the default choice for PC-based firewalling. Then I reconsidered and chose FreeBSD for its support of the hardware (dual EM64T xeons, 2x dual gigabit cards), especially with the finer-grained locking, which I thought might help a bit with the load sharing across the cards. Initially I ran ipfw and it worked OK but there were little niggles about it, and recently switched to pf and have been quite happy. It doesn't seem quite as efficient, it runs about 5-10% higher interrupt load under top. I still have some tweaking to do too, so I can probably lower that, but the way pf splits out rules which (IMHO) really should be aggregated means there are >100k state entries most of the heavy hours, which obviously is not incredibly easy for anything to handle. I've wondered about a couple things here though: Is FreeBSD pretty optimal for using as a firewall in our situation, especially on that hardware? Might OpenBSD actually perform better with its "native" filtering solution? I have no real attachment to any particular platform here. I have to say pf is much nicer from a user standpoint than ipfw, the tools are very clean, it's nice to not have the firewall drop all states when reloading a ruleset, etc. I think I'd like to continue using pf, it's just the OS it sits on top of that's the variable I'd like to get set. Thanks for any comments. Ben From owner-freebsd-pf@FreeBSD.ORG Tue Mar 8 03:02:11 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADAFA16A4CE for ; Tue, 8 Mar 2005 03:02:11 +0000 (GMT) Received: from hotmail.com (bay24-f6.bay24.hotmail.com [64.4.18.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0133B43D5E for ; Tue, 8 Mar 2005 03:02:10 +0000 (GMT) (envelope-from segr@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 7 Mar 2005 19:02:10 -0800 Message-ID: Received: from 204.9.110.182 by by24fd.bay24.hotmail.msn.com with HTTP; Tue, 08 Mar 2005 03:02:09 GMT X-Originating-IP: [204.9.110.182] X-Originating-Email: [segr@hotmail.com] X-Sender: segr@hotmail.com In-Reply-To: <200503080152.11837.max@love2party.net> From: "Stephane Raimbault" To: max@love2party.net, freebsd-pf@freebsd.org Date: Mon, 07 Mar 2005 20:02:09 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 08 Mar 2005 03:02:10.0339 (UTC) FILETIME=[38635F30:01C5238B] Subject: Re: nat / rdr timeouts? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 03:02:11 -0000 >From: Max Laier >To: freebsd-pf@freebsd.org >CC: "Stephane Raimbault" , daniel@benzedrine.cx >Subject: Re: nat / rdr timeouts? >Date: Tue, 8 Mar 2005 01:52:05 +0100 > >On Tuesday 08 March 2005 01:28, Stephane Raimbault wrote: > > Okay, I setup an OpenBSD 3.6 box with pf today as a test and I can not > > replicate the problem with OpenBSD. > > > > In fact, running the ab test returned MUCH beter results in terms of >times > > to return the page and according to top the cpu barely budged when >running > > the test on the openbsd pf box. However running top on the freebsd pf >box > > I clearly see a spike in cpu traffic as the cpu idle drops to 0% for a > > second. > > > > > > I'm currently running RELENG_5 on the freebsd box from this weekend... >are > > there some debugging stuff turned on in the kernel that would explain >the > > performance diffrence? > > > > I tried to replicate the test as closely as possible however there are >some > > subtle diffrences in my test. > > > > OpenBSD test > > > > PowerBook laptop (running ab) to an IP on the local network (openbsd ext > > interface (vlan0)) thru to the same openbsd box int interface (vlan1) to > > the web servers (10.0.11.16 and 10.0.11.17). > > > > FreeBSD Test > > > > IBM server running freebsd (ab) to an IP on it's local network (freebsd >ext > > interface (em0) thru to the same freebsd box int interface (em1) to the >web > > severs (10.0.11.16 and 10.0.11.17). > > > > network wise it should be pretty much the same. The only thing that >came > > to mind, maybe it's because the powerbook is a better box then the IBM > > server running freebsd ? but then seeing the CPU idle time and >comparing > > the Freebsd +pf and the OpenBSD +pf being so diffrent... I ponder my > > question. > > > > > > Hope this makes sense. Let me know if there is any other data I can > > provide ? > >I don't fully understand how your setup looks like. Where are you running >ab >from? Is there a dedicated box you run it on or are you running it on/from >the redirecting box itself? Could you get the following setup realized: > > /----- OpenBSD ----\ WWW_1 > | | / WWW_2 >ab Client ---+ +-----+- ... > | | \ WWW_N > \----- FreeBSD ----/ > I don't know why I didn't setup my test like this in the first place... it was pretty easy for me to set this up... Anyhow I've set this up now. And now that I have re run the tests... may I say "ARGH!" :) So yes... same problem when running the test on the OpenBSD + pf then I was getting on the FreeBSD + pf. But so what does this mean... I'm hitting a bug on my FreeBSD box I'm running the ab test from? >It does not matter (too much) how the gateways are connected to the client >and >the servers, what matters is that the client and the servers are the same >for >both tests. I suspect that (if you were running ab from the FreeBSD >server) >you discovered a bug in FreeBSD's socket/tcp code much rather than in pf. >Please let me know if I misunderstood something and explain your test setup >with a bit more detail. > >Thanks a lot in advance. > > > >-- >/"\ Best regards, | mlaier@freebsd.org >\ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet >/ \ ASCII Ribbon Campaign | Against HTML Mail and News ><< attach3 >> _________________________________________________________________ Don't just Search. Find! http://search.sympatico.msn.ca/default.aspx The new MSN Search! Check it out! From owner-freebsd-pf@FreeBSD.ORG Tue Mar 8 05:08:07 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9991216A4CE for ; Tue, 8 Mar 2005 05:08:07 +0000 (GMT) Received: from hotmail.com (bay24-f17.bay24.hotmail.com [64.4.18.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BED243D31 for ; Tue, 8 Mar 2005 05:08:07 +0000 (GMT) (envelope-from segr@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 7 Mar 2005 21:08:07 -0800 Message-ID: Received: from 204.9.110.182 by by24fd.bay24.hotmail.msn.com with HTTP; Tue, 08 Mar 2005 05:08:06 GMT X-Originating-IP: [204.9.110.182] X-Originating-Email: [segr@hotmail.com] X-Sender: segr@hotmail.com In-Reply-To: From: "Stephane Raimbault" To: segr@hotmail.com, max@love2party.net, freebsd-pf@freebsd.org Date: Mon, 07 Mar 2005 22:08:06 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 08 Mar 2005 05:08:07.0142 (UTC) FILETIME=[D0980060:01C5239C] Subject: Re: nat / rdr timeouts? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 05:08:07 -0000 Okay, a bit of a Summary. I was originally running ab on a 4.9 system... however, it seems like there was a problem with that as mentioned by Max. I ran ab from a 5.2.1 system and didn't have any problems. I could rack up the connections till I ran up to 10K states since that limit is set to that. so no problem there. I even cvsup'd back to 5.3-RELEASE-p5 and still no problems. So there is no problem according to my benchmark test.... This still goes back to why I originally was doing this.... I'm currently running 4.9 + natd doing something similar with port 80. I have no problems, however load on the box is quite a bit more then I like. 5.3 + pf seems to be the solution as the load is much lower during my testing... Some time ago I had tried 5.3 + pf in the production environment, however a few users were getting time outs to port 80... and it seemed like these few were behind corportate firewalls, where a few users were accessing the site at the same time from behind the same IP. This led me to my ab test which "seemed" to duplicate the problem. I'm at a loss now... the only thing I can think of is testing 5.3+pf in the production environment and see what happens... does anyone have any thoughts? Thanks, Stephane. >From: "Stephane Raimbault" >To: max@love2party.net, freebsd-pf@freebsd.org >Subject: Re: nat / rdr timeouts? >Date: Mon, 07 Mar 2005 20:02:09 -0700 > > > >>From: Max Laier >>To: freebsd-pf@freebsd.org >>CC: "Stephane Raimbault" , daniel@benzedrine.cx >>Subject: Re: nat / rdr timeouts? >>Date: Tue, 8 Mar 2005 01:52:05 +0100 >> >>On Tuesday 08 March 2005 01:28, Stephane Raimbault wrote: >> > Okay, I setup an OpenBSD 3.6 box with pf today as a test and I can not >> > replicate the problem with OpenBSD. >> > >> > In fact, running the ab test returned MUCH beter results in terms of >>times >> > to return the page and according to top the cpu barely budged when >>running >> > the test on the openbsd pf box. However running top on the freebsd pf >>box >> > I clearly see a spike in cpu traffic as the cpu idle drops to 0% for a >> > second. >> > >> > >> > I'm currently running RELENG_5 on the freebsd box from this weekend... >>are >> > there some debugging stuff turned on in the kernel that would explain >>the >> > performance diffrence? >> > >> > I tried to replicate the test as closely as possible however there are >>some >> > subtle diffrences in my test. >> > >> > OpenBSD test >> > >> > PowerBook laptop (running ab) to an IP on the local network (openbsd >>ext >> > interface (vlan0)) thru to the same openbsd box int interface (vlan1) >>to >> > the web servers (10.0.11.16 and 10.0.11.17). >> > >> > FreeBSD Test >> > >> > IBM server running freebsd (ab) to an IP on it's local network (freebsd >>ext >> > interface (em0) thru to the same freebsd box int interface (em1) to the >>web >> > severs (10.0.11.16 and 10.0.11.17). >> > >> > network wise it should be pretty much the same. The only thing that >>came >> > to mind, maybe it's because the powerbook is a better box then the IBM >> > server running freebsd ? but then seeing the CPU idle time and >>comparing >> > the Freebsd +pf and the OpenBSD +pf being so diffrent... I ponder my >> > question. >> > >> > >> > Hope this makes sense. Let me know if there is any other data I can >> > provide ? >> >>I don't fully understand how your setup looks like. Where are you running >>ab >>from? Is there a dedicated box you run it on or are you running it >>on/from >>the redirecting box itself? Could you get the following setup realized: >> >> /----- OpenBSD ----\ WWW_1 >> | | / WWW_2 >>ab Client ---+ +-----+- ... >> | | \ WWW_N >> \----- FreeBSD ----/ >> > >I don't know why I didn't setup my test like this in the first place... it >was pretty easy for me to set this up... Anyhow I've set this up now. > >And now that I have re run the tests... may I say "ARGH!" :) > >So yes... same problem when running the test on the OpenBSD + pf then I was >getting on the FreeBSD + pf. But so what does this mean... I'm hitting a >bug on my FreeBSD box I'm running the ab test from? > >>It does not matter (too much) how the gateways are connected to the client >>and >>the servers, what matters is that the client and the servers are the same >>for >>both tests. I suspect that (if you were running ab from the FreeBSD >>server) >>you discovered a bug in FreeBSD's socket/tcp code much rather than in pf. >>Please let me know if I misunderstood something and explain your test >>setup >>with a bit more detail. >> >>Thanks a lot in advance. >> >> >> >>-- >>/"\ Best regards, | mlaier@freebsd.org >>\ / Max Laier | ICQ #67774661 >> X http://pf4freebsd.love2party.net/ | mlaier@EFnet >>/ \ ASCII Ribbon Campaign | Against HTML Mail and News >><< attach3 >> > >_________________________________________________________________ >Don't just Search. Find! http://search.sympatico.msn.ca/default.aspx The >new MSN Search! Check it out! > >_______________________________________________ >freebsd-pf@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-pf >To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" _________________________________________________________________ Take charge with a pop-up guard built on patented Microsoft® SmartScreen Technology http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. From owner-freebsd-pf@FreeBSD.ORG Thu Mar 10 17:37:05 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C87F816A4D2 for ; Thu, 10 Mar 2005 17:37:05 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B74343D31 for ; Thu, 10 Mar 2005 17:37:05 +0000 (GMT) (envelope-from mclone@gmail.com) Received: by rproxy.gmail.com with SMTP id g11so964097rne for ; Thu, 10 Mar 2005 09:37:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=gUKfQYJ27rO/FXNJS1ocKqAgu2Ql5N7Z7zR25v+GTG5HwrPrAIhFLsJKyLrmFgXkbUKOZajOUfJ5u+z6u5LnrI48rAQeR9fT93MEl36EzdtHZD6Yenztzlthaur90yqkRie5poRwLA732RXJapE0Wd2+obRutI+8oT2kWi7ILjk= Received: by 10.11.120.7 with SMTP id s7mr85182cwc; Thu, 10 Mar 2005 09:37:03 -0800 (PST) Received: by 10.11.98.7 with HTTP; Thu, 10 Mar 2005 09:37:03 -0800 (PST) Message-ID: <451cb301050310093753511884@mail.gmail.com> Date: Thu, 10 Mar 2005 19:37:03 +0200 From: McLone To: jon@abccomm.com, freebsd-pf@freebsd.org In-Reply-To: <8eea040805030521005347c44e@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <62956.81.30.200.207.1110031162.squirrel@81.30.200.207> <8eea040805030521005347c44e@mail.gmail.com> Subject: Re: pfsync + pfflowd + flow-tools (ifconfig maxupd)? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: McLone List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 17:37:05 -0000 On Sat, 5 Mar 2005 21:00:18 -0800, Jon Simola wrote: > All the PF and CARP docs suggest a dedicated interface for pfsync, > mostly due to security issues. The most common implementation I would > assume is a pair of firewalls each with 3 interfaces (internal, > external, and sync connected via a xover cable). one can do tunneling, right? -- wbr, |\ _,,,---,,_ dog bless ya! ` Zzz /,`.-'`' -. ;-;;,_ McLone at GMail dot com |,4- ) )-,_. ,\ ( `'-' net- and *BSD admin '---''(_/--' `-'\_) ...sorry for translit From owner-freebsd-pf@FreeBSD.ORG Fri Mar 11 12:11:15 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC24616A4CE for ; Fri, 11 Mar 2005 12:11:15 +0000 (GMT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 5222C43D48 for ; Fri, 11 Mar 2005 12:11:14 +0000 (GMT) (envelope-from emanuel.strobl@gmx.net) Received: (qmail invoked by alias); 11 Mar 2005 12:11:13 -0000 Received: from flb.schmalzbauer.de (EHLO cale.flintsbach.schmalzbauer.de) (62.245.232.135) by mail.gmx.net (mp029) with SMTP; 11 Mar 2005 13:11:13 +0100 X-Authenticated: #301138 From: Emanuel Strobl To: Max Laier Date: Fri, 11 Mar 2005 13:10:58 +0100 User-Agent: KMail/1.7.2 References: <20050212061756.GF4769@kt-is.co.kr> <200502211557.17818@harrymail> <200502211924.10327.max@love2party.net> In-Reply-To: <200502211924.10327.max@love2party.net> X-Birthday: 10/06/72 X-CelPhone: +49 173 9967781 X-Tel: +49 89 18947781 X-Country: Germany X-Address: Munich, 80686 X-OS: FreeBSD MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4478696.7dMTX5mPKO"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200503111311.03343@harrymail> X-Y-GMX-Trusted: 0 cc: pf@freebsd.org cc: stable@freebsd.org Subject: Return-icmp doesn't work [Was: Re: Recent panics caused by pf] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 12:11:15 -0000 --nextPart4478696.7dMTX5mPKO Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Montag, 21. Februar 2005 19:24 schrieb Max Laier: > On Monday 21 February 2005 15:57, Harald Schmalzbauer wrote: > > Am Sonntag, 20. Februar 2005 19:10 schrieb Max Laier: > > > /me slaps self ... [...] > > I tested your patch against RELENG_5 and the panic with "pfctl -Fall" > > seems to be solved. > > But I have another problem with renamed interfaces and pf: > > The following rule can't be loaded (error: routeto: unknown interface > > SDSL) "pass in on SDSL reply-to (SDSL $sdsl_gw) proto tcp from any to > > $mta port 25" [...] > > And there are more oddities with pf and FreeBSD: > > block return doesn't work. At least for TCP connections I don't get a > > reset back instead it times out. > > Also return-icmp (13) doesn't work. > > Hum?!? ... Are you sure about this? I am pretty confident that it works. > I'll have to test to make sure ... later that week/next week. Keep me > posted in case you find something. I'm on the firewall again and verified that block return works for tcp-rst,= =20 but not for return-icmp (with or without code), it seems packets just get=20 droped, regardless for which protocol (tested UDP, ICMP, TCP). Then I have another problem which may be a design problem. I am multihomed and have several pass reply-to rules. So far things are=20 working fine but block return doesn't! Of course, the return gets over the= =20 default route, so what I needed is a block return route-to or something lik= e=20 that. Do you know any detour how this could be achieved? Thanks, =2DHarry > > > Thanks, > > > > > > -Harry (P.S.: Emanuel and Harry are the same persons (me) the gmx addre= ss > > is just a fake identity for mailing lists) > > okay ... you see us perplexed ;) --nextPart4478696.7dMTX5mPKO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCMYrXBylq0S4AzzwRAk2iAJ9KziRQ3Sozowy2fMYCpabq8cBr9gCcCWSK cgbuNryralw4Z3WvsAwLSDQ= =OIic -----END PGP SIGNATURE----- --nextPart4478696.7dMTX5mPKO-- From owner-freebsd-pf@FreeBSD.ORG Fri Mar 11 12:50:58 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 275C016A4CF for ; Fri, 11 Mar 2005 12:50:58 +0000 (GMT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id C912F43D48 for ; Fri, 11 Mar 2005 12:50:56 +0000 (GMT) (envelope-from emanuel.strobl@gmx.net) Received: (qmail invoked by alias); 11 Mar 2005 12:50:55 -0000 Received: from flb.schmalzbauer.de (EHLO cale.flintsbach.schmalzbauer.de) (62.245.232.135) by mail.gmx.net (mp020) with SMTP; 11 Mar 2005 13:50:55 +0100 X-Authenticated: #301138 From: Emanuel Strobl To: freebsd-stable@freebsd.org Date: Fri, 11 Mar 2005 13:50:47 +0100 User-Agent: KMail/1.7.2 References: <20050212061756.GF4769@kt-is.co.kr> <200502211924.10327.max@love2party.net> <200503111311.03343@harrymail> In-Reply-To: <200503111311.03343@harrymail> X-Birthday: 10/06/72 X-CelPhone: +49 173 9967781 X-Tel: +49 89 18947781 X-Country: Germany X-Address: Munich, 80686 X-OS: FreeBSD MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2763250.1f29yxMuzH"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200503111350.52724@harrymail> X-Y-GMX-Trusted: 0 cc: stable@freebsd.org cc: pf@freebsd.org Subject: Re: Return-icmp doesn't work [Was: Re: Recent panics caused by pf] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 12:50:58 -0000 --nextPart2763250.1f29yxMuzH Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Freitag, 11. M=E4rz 2005 13:10 schrieb Emanuel Strobl: > I'm on the firewall again and verified that block return works for tcp-rs= t, > but not for return-icmp (with or without code), it seems packets just get > droped, regardless for which protocol (tested UDP, ICMP, TCP). Sorry for the noise, it's my mistake, ping doesn't show me the error messag= e.=20 I think I can remember that the last time I created/tested a ruleset (with= =20 4.6) I got detaild error messages like "telnet: connect to address 82.135.28.195: Destination Host Unreachable" but now I just get=20 "telnet: connect to address 82.135.28.195: Connection refused" without the error report. Is it possible that in former times these ICMP error messages were printed = on=20 the console which now the kernel doesn't anymore? > > Then I have another problem which may be a design problem. > I am multihomed and have several pass reply-to rules. So far things are > working fine but block return doesn't! Of course, the return gets over the > default route, so what I needed is a block return route-to or something > like that. > Do you know any detour how this could be achieved? This problem is still unsolved :( Thnaks, =2DHarry > > Thanks, > > -Harry > > > > Thanks, > > > > > > > > > -Harry (P.S.: Emanuel and Harry are the same persons (me) the gmx > > > address is just a fake identity for mailing lists) > > > > okay ... you see us perplexed ;) --nextPart2763250.1f29yxMuzH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCMZQsBylq0S4AzzwRAhdNAJwMOPgSOuDpXREjcI0ryPZrKgM06gCcD+C5 h3zMRkKHi7Aqs/4ZVDnSZy4= =6RHR -----END PGP SIGNATURE----- --nextPart2763250.1f29yxMuzH-- From owner-freebsd-pf@FreeBSD.ORG Fri Mar 11 13:52:13 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC3BD16A4CE; Fri, 11 Mar 2005 13:52:13 +0000 (GMT) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 969E943D46; Fri, 11 Mar 2005 13:52:12 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) j2BDqDtR031123 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Fri, 11 Mar 2005 14:52:13 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.3/8.12.10/Submit) id j2BDqDGB031566; Fri, 11 Mar 2005 14:52:13 +0100 (MET) Date: Fri, 11 Mar 2005 14:52:12 +0100 From: Daniel Hartmeier To: Emanuel Strobl Message-ID: <20050311135212.GA30653@insomnia.benzedrine.cx> References: <20050212061756.GF4769@kt-is.co.kr> <200502211924.10327.max@love2party.net> <200503111311.03343@harrymail> <200503111350.52724@harrymail> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503111350.52724@harrymail> User-Agent: Mutt/1.5.6i cc: stable@freebsd.org cc: freebsd-stable@freebsd.org cc: pf@freebsd.org Subject: Re: Return-icmp doesn't work [Was: Re: Recent panics caused by pf] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 13:52:13 -0000 On Fri, Mar 11, 2005 at 01:50:47PM +0100, Emanuel Strobl wrote: > > Then I have another problem which may be a design problem. > > I am multihomed and have several pass reply-to rules. So far things are > > working fine but block return doesn't! Of course, the return gets over the > > default route, so what I needed is a block return route-to or something > > like that. > > Do you know any detour how this could be achieved? > > This problem is still unsolved :( The idea is that you can use reply-to on block rules for this purpose: block return-rst in on wi0 reply-to (wi0 10.1.1.1) inet proto tcp all This is valid syntax and pfctl loads the rule, but the functionality is not implemented in kernel yet, i.e. the reply-to option is simply ignored. The problem is that return-icmp uses the stack's icmp_error(), which doesn't take an argument to override a route lookup. And duplicating the function would be ugly due to its size. It's on the to-do list, but it's been sitting there for a while already. Daniel From owner-freebsd-pf@FreeBSD.ORG Fri Mar 11 15:19:40 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7351B16A4CE for ; Fri, 11 Mar 2005 15:19:40 +0000 (GMT) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 3976143D5A for ; Fri, 11 Mar 2005 15:19:39 +0000 (GMT) (envelope-from emanuel.strobl@gmx.net) Received: (qmail invoked by alias); 11 Mar 2005 15:19:38 -0000 Received: from flb.schmalzbauer.de (EHLO cale.flintsbach.schmalzbauer.de) (62.245.232.135) by mail.gmx.net (mp029) with SMTP; 11 Mar 2005 16:19:38 +0100 X-Authenticated: #301138 From: Emanuel Strobl To: freebsd-stable@freebsd.org Date: Fri, 11 Mar 2005 16:19:27 +0100 User-Agent: KMail/1.7.2 References: <20050212061756.GF4769@kt-is.co.kr> <200503111350.52724@harrymail> <20050311135212.GA30653@insomnia.benzedrine.cx> In-Reply-To: <20050311135212.GA30653@insomnia.benzedrine.cx> X-Birthday: 10/06/72 X-CelPhone: +49 173 9967781 X-Tel: +49 89 18947781 X-Country: Germany X-Address: Munich, 80686 X-OS: FreeBSD MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart15213773.FH3rC2mMoY"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200503111619.34188@harrymail> X-Y-GMX-Trusted: 0 cc: pf@freebsd.org cc: stable@freebsd.org Subject: Re: Return-icmp doesn't work [Was: Re: Recent panics caused by pf] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 15:19:40 -0000 --nextPart15213773.FH3rC2mMoY Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Freitag, 11. M=E4rz 2005 14:52 schrieb Daniel Hartmeier: > On Fri, Mar 11, 2005 at 01:50:47PM +0100, Emanuel Strobl wrote: > > > Then I have another problem which may be a design problem. > > > I am multihomed and have several pass reply-to rules. So far things a= re > > > working fine but block return doesn't! Of course, the return gets over > > > the default route, so what I needed is a block return route-to or > > > something like that. > > > Do you know any detour how this could be achieved? > > > > This problem is still unsolved :( > > The idea is that you can use reply-to on block rules for this purpose: > > block return-rst in on wi0 reply-to (wi0 10.1.1.1) inet proto tcp all > > This is valid syntax and pfctl loads the rule, but the functionality is > not implemented in kernel yet, i.e. the reply-to option is simply > ignored. Thanks, I tried a very similar rule and after that the box vanished. I went on location (the box paniced but didn't reboot) and installed a=20 console-server so I can access the box from here and currently I'm baking a= =20 debug kernel. I'll notify you if I have a trace! Thnaks, =2DHarry > > The problem is that return-icmp uses the stack's icmp_error(), which > doesn't take an argument to override a route lookup. And duplicating the > function would be ugly due to its size. It's on the to-do list, but it's > been sitting there for a while already. > > Daniel > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" --nextPart15213773.FH3rC2mMoY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCMbcGBylq0S4AzzwRAnx+AJ4r4Jlg2NqYAslTyAs+PCuEUrIjhwCgjGZK L2Ju2kJ5qZUFn3WAhnY/HJk= =x7cD -----END PGP SIGNATURE----- --nextPart15213773.FH3rC2mMoY-- From owner-freebsd-pf@FreeBSD.ORG Fri Mar 11 16:12:47 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AAF1116A4CF for ; Fri, 11 Mar 2005 16:12:47 +0000 (GMT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id DE96843D67 for ; Fri, 11 Mar 2005 16:12:45 +0000 (GMT) (envelope-from emanuel.strobl@gmx.net) Received: (qmail invoked by alias); 11 Mar 2005 16:12:44 -0000 Received: from flb.schmalzbauer.de (EHLO cale.flintsbach.schmalzbauer.de) (62.245.232.135) by mail.gmx.net (mp022) with SMTP; 11 Mar 2005 17:12:44 +0100 X-Authenticated: #301138 From: Emanuel Strobl To: freebsd-stable@freebsd.org Date: Fri, 11 Mar 2005 17:12:31 +0100 User-Agent: KMail/1.7.2 References: <20050212061756.GF4769@kt-is.co.kr> <20050311135212.GA30653@insomnia.benzedrine.cx> <200503111619.34188@harrymail> In-Reply-To: <200503111619.34188@harrymail> X-Birthday: 10/06/72 X-CelPhone: +49 173 9967781 X-Tel: +49 89 18947781 X-Country: Germany X-Address: Munich, 80686 X-OS: FreeBSD MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2978066.9Jq981rKZl"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200503111712.36310@harrymail> X-Y-GMX-Trusted: 0 cc: stable@freebsd.org cc: pf@freebsd.org Subject: pf panic trace [Was: Re: Return-icmp doesn't work] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 16:12:47 -0000 --nextPart2978066.9Jq981rKZl Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Freitag, 11. M=E4rz 2005 16:19 schrieb Emanuel Strobl: > Am Freitag, 11. M=E4rz 2005 14:52 schrieb Daniel Hartmeier: > > block return-rst in on wi0 reply-to (wi0 10.1.1.1) inet proto tcp all > > > > This is valid syntax and pfctl loads the rule, but the functionality is > > not implemented in kernel yet, i.e. the reply-to option is simply > > ignored. > > Thanks, I tried a very similar rule and after that the box vanished. > I went on location (the box paniced but didn't reboot) and installed a > console-server so I can access the box from here and currently I'm baking= a > debug kernel. > I'll notify you if I have a trace! Here's the original panic message (the non debug kernel) with 5.4-PRE one w= eek=20 old: =46atal trap 12: page fault while in kernel mode fault virtual address =3D 0xc fault code =3D supervisor read, page not pre instruction pointer =3D 0x8:0xc05ac722 stack pointer =3D 0x10:0xcc6919ac frame pointer =3D 0x10:0xcc6919e0 code segment =3D base 0x0, limit 0xfffff, type =3D DPL 0, pres 1, def32 1, gran processor eflags =3D interrupt enabled, resume, IO current process =3D 34 (swi1: net) trap number =3D 12 panic: page fault Uptime: 1d1h20m33s GEOM_MIRROR: Device web: provider mirror/web destroyed. GEOM_MIRROR: Device web destroyed. =2E.. The machine didn't reboot! The following rule panickes the machine: block return-icmp(13) in on $SDSL route-to ($SDSL $sdsl_gw) from any to=20 $sdsl_net Here's the trace from 5.4-PRE today: panic: m_copym, offset > size of mbuf chain KDB: stack backtrace: panic(c076ab9a,c174d500,100,cc694a30,0) at panic+0x13c m_copym(c1621b00,5dc,5c8,1,14) at m_copym+0x1c7 ip_fragment(c1642010,cc694a74,5dc,6,f01) at ip_fragment+0x168 pf_route(cc694bf0,c1a10d20,1,c1585000,0) at pf_route+0x767 pf_test(1,c1585000,cc694bf0,0,c17554e0) at pf_test+0x7b1 pf_check_in(0,cc694bf0,c1585000,1,0) at pf_check_in+0x48 pfil_run_hooks(c07f3e60,cc694c9c,c1585000,1,0) at pfil_run_hooks+0x15b ip_input(c1621b00,0,c076e621,e6,c07f3f20) at ip_input+0x20f netisr_processqueue(cc694cd8,246,c07c8ee0,2,c1508d40) at=20 netisr_processqueue+0x15 swi_net(0,0,c0762ddc,269,0) at swi_net+0x8d ithread_loop(c1526300,cc694d48,c0762bbd,30e,0) at ithread_loop+0x1ff fork_exit(c0560640,c1526300,cc694d48) at fork_exit+0xa9 fork_trampoline() at fork_trampoline+0x8 =2D-- trap 0x1, eip =3D 0, esp =3D 0xcc694d7c, ebp =3D 0 --- If you need more info, on http://www.schmalzbauer.de/statics/phobos you can= =20 find dmesg and the whole pf.conf Thanks, =2DHarry > > Thnaks, > > -Harry > > > The problem is that return-icmp uses the stack's icmp_error(), which > > doesn't take an argument to override a route lookup. And duplicating the > > function would be ugly due to its size. It's on the to-do list, but it's > > been sitting there for a while already. > > > > Daniel > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.or= g" --nextPart2978066.9Jq981rKZl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCMcN0Bylq0S4AzzwRAr5YAJ9l0V7Mqau4piVN+QxJJPRj63bOqACcDTKd YzejycTbQzxPdCJUhZNH8Pk= =ejaK -----END PGP SIGNATURE----- --nextPart2978066.9Jq981rKZl-- From owner-freebsd-pf@FreeBSD.ORG Sat Mar 12 05:07:46 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96FAB16A4CE for ; Sat, 12 Mar 2005 05:07:46 +0000 (GMT) Received: from ns.kt-is.co.kr (ns.kt-is.co.kr [211.218.149.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFC8243D2D for ; Sat, 12 Mar 2005 05:07:45 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: from michelle.kt-is.co.kr (ns2.kt-is.co.kr [220.76.118.193]) (authenticated bits=128) by ns.kt-is.co.kr (8.12.10/8.12.10) with ESMTP id j2C56eAh083984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 12 Mar 2005 14:06:41 +0900 (KST) Received: from michelle.kt-is.co.kr (localhost.kt-is.co.kr [127.0.0.1]) by michelle.kt-is.co.kr (8.13.1/8.13.1) with ESMTP id j2C57TYN061578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Mar 2005 14:07:29 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.kt-is.co.kr (8.13.1/8.13.1/Submit) id j2C57MnM061577; Sat, 12 Mar 2005 14:07:22 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Sat, 12 Mar 2005 14:07:22 +0900 From: Pyun YongHyeon To: Emanuel Strobl Message-ID: <20050312050722.GC60892@kt-is.co.kr> References: <20050212061756.GF4769@kt-is.co.kr> <20050311135212.GA30653@insomnia.benzedrine.cx> <200503111619.34188@harrymail> <200503111712.36310@harrymail> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline In-Reply-To: <200503111712.36310@harrymail> User-Agent: Mutt/1.4.2.1i X-Filter-Version: 1.11a (ns.kt-is.co.kr) cc: pf@freebsd.org Subject: Re: pf panic trace [Was: Re: Return-icmp doesn't work] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2005 05:07:46 -0000 --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Mar 11, 2005 at 05:12:31PM +0100, Emanuel Strobl wrote: > Am Freitag, 11. M?rz 2005 16:19 schrieb Emanuel Strobl: > > Am Freitag, 11. M?rz 2005 14:52 schrieb Daniel Hartmeier: > > > block return-rst in on wi0 reply-to (wi0 10.1.1.1) inet proto tcp all > > > > > > This is valid syntax and pfctl loads the rule, but the functionality is > > > not implemented in kernel yet, i.e. the reply-to option is simply > > > ignored. > > > > Thanks, I tried a very similar rule and after that the box vanished. > > I went on location (the box paniced but didn't reboot) and installed a > > console-server so I can access the box from here and currently I'm baking a > > debug kernel. > > I'll notify you if I have a trace! > > Here's the original panic message (the non debug kernel) with 5.4-PRE one week > old: > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xc > fault code = supervisor read, page not pre > instruction pointer = 0x8:0xc05ac722 > stack pointer = 0x10:0xcc6919ac > frame pointer = 0x10:0xcc6919e0 > code segment = base 0x0, limit 0xfffff, type > = DPL 0, pres 1, def32 1, gran > processor eflags = interrupt enabled, resume, IO > current process = 34 (swi1: net) > trap number = 12 > panic: page fault > Uptime: 1d1h20m33s > GEOM_MIRROR: Device web: provider mirror/web destroyed. > GEOM_MIRROR: Device web destroyed. > ... > The machine didn't reboot! > > > The following rule panickes the machine: > block return-icmp(13) in on $SDSL route-to ($SDSL $sdsl_gw) from any to > $sdsl_net > > Here's the trace from 5.4-PRE today: > panic: m_copym, offset > size of mbuf chain > KDB: stack backtrace: > panic(c076ab9a,c174d500,100,cc694a30,0) at panic+0x13c > m_copym(c1621b00,5dc,5c8,1,14) at m_copym+0x1c7 > ip_fragment(c1642010,cc694a74,5dc,6,f01) at ip_fragment+0x168 > pf_route(cc694bf0,c1a10d20,1,c1585000,0) at pf_route+0x767 > pf_test(1,c1585000,cc694bf0,0,c17554e0) at pf_test+0x7b1 > pf_check_in(0,cc694bf0,c1585000,1,0) at pf_check_in+0x48 > pfil_run_hooks(c07f3e60,cc694c9c,c1585000,1,0) at pfil_run_hooks+0x15b > ip_input(c1621b00,0,c076e621,e6,c07f3f20) at ip_input+0x20f > netisr_processqueue(cc694cd8,246,c07c8ee0,2,c1508d40) at > netisr_processqueue+0x15 > swi_net(0,0,c0762ddc,269,0) at swi_net+0x8d > ithread_loop(c1526300,cc694d48,c0762bbd,30e,0) at ithread_loop+0x1ff > fork_exit(c0560640,c1526300,cc694d48) at fork_exit+0xa9 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xcc694d7c, ebp = 0 --- > > If you need more info, on http://www.schmalzbauer.de/statics/phobos you can > find dmesg and the whole pf.conf > Hmm, Max and I had seen these kind of traces when pf porting was in progress. But now I believe we fixed all possible cases. I can't sure but your trace indicates there is a bug in ip_fragment(). If a packet already set IP_MF flag in ip header, we would get invalid ip_off in fragmented packet. And it seems that there is another bug in pf. Since ip_fragment() can change passed mbuf, we should not use saved copy of it. Untested patch for CURRENT attached. -- Regards, Pyun YongHyeon http://www.kr.freebsd.org/~yongari | yongari@freebsd.org --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ip_output.patch" --- sys/netinet/ip_output.c.orig Tue Mar 1 20:57:14 2005 +++ sys/netinet/ip_output.c Sat Mar 12 13:50:54 2005 @@ -959,7 +959,7 @@ } m->m_len = mhlen; /* XXX do we need to add ip->ip_off below ? */ - mhip->ip_off = ((off - hlen) >> 3) + ip->ip_off; + mhip->ip_off = ((off - hlen) >> 3) + (ip->ip_off & ~IP_MF); if (off + len >= ip->ip_len) { /* last fragment */ len = ip->ip_len - off; m->m_flags |= M_LASTFRAG; --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pf.route.patch" --- sys/contrib/pf/net/pf.c.orig Tue Feb 22 10:30:53 2005 +++ sys/contrib/pf/net/pf.c Sat Mar 12 12:42:37 2005 @@ -5421,7 +5421,6 @@ goto bad; } - m1 = m0; #ifdef __FreeBSD__ /* * XXX: is cheaper + less error prone than own function @@ -5430,6 +5429,7 @@ NTOHS(ip->ip_off); error = ip_fragment(ip, &m0, ifp->if_mtu, ifp->if_hwassist, sw_csum); #else + m1 = m0; error = ip_fragment(m0, ifp, ifp->if_mtu); #endif if (error) { @@ -5439,10 +5439,14 @@ goto bad; } +#ifdef __FreeBSD__ + for (; m0; m0 = m1) { +#else for (m0 = m1; m0; m0 = m1) { +#endif m1 = m0->m_nextpkt; - m0->m_nextpkt = 0; #ifdef __FreeBSD__ + m0->m_nextpkt = NULL; if (error == 0) { PF_UNLOCK(); error = (*ifp->if_output)(ifp, m0, sintosa(dst), @@ -5450,6 +5454,7 @@ PF_LOCK(); } else #else + m0->m_nextpkt = 0; if (error == 0) error = (*ifp->if_output)(ifp, m0, sintosa(dst), NULL); --T4sUOijqQbZv57TR--