From owner-freebsd-pf@FreeBSD.ORG Wed Mar 29 19:14:26 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org 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 4E2D716A41F for ; Wed, 29 Mar 2006 19:14:26 +0000 (UTC) (envelope-from nejc@skoberne.net) Received: from svarun.infrax.si (svarun.infrax.si [193.77.158.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFC6443D64 for ; Wed, 29 Mar 2006 19:14:12 +0000 (GMT) (envelope-from nejc@skoberne.net) Received: from localhost (localhost [127.0.0.1]) by svarun.infrax.si (Postfix) with ESMTP id 866F4DA8D1; Wed, 29 Mar 2006 21:14:00 +0200 (CEST) Received: from svarun.infrax.si ([127.0.0.1]) by localhost (Svarun.infrax.si [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58267-04; Wed, 29 Mar 2006 21:13:59 +0200 (CEST) Received: from [192.168.100.93] (d04m-213-44-58-64.d4.club-internet.fr [213.44.58.64]) by svarun.infrax.si (Postfix) with ESMTP id 8545EDA8D2; Wed, 29 Mar 2006 21:13:58 +0200 (CEST) Message-ID: <442ADC6C.2030202@skoberne.net> Date: Wed, 29 Mar 2006 21:13:48 +0200 From: Nejc Skoberne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: freebsd-pf@freebsd.org Content-Type: multipart/mixed; boundary="------------000407020305010306020505" X-Virus-Scanned: amavisd-new at infrax.si X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: i4-dev Subject: Mysterious packet loss X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 29 Mar 2006 19:14:26 -0000 This is a multi-part message in MIME format. --------------000407020305010306020505 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Hi folks, today I said "enough is enough" and I started debugging the slowness of a business application, which is developed by our company. It's a multitier application, written in Delphi and offering (currently) two types of protocols for client-server connection: HTTP (which I am using) and DCOM. Me and my company are from Slovenia, but currently I am in France on a study exchange programme and I have set up an internet access via WiFi provider. So the problem was that I could not work normally with my client of the business application because there were long delays in the actions (click a button and then wait 10 secs to refresh something). In the beginning I was sure that our devel team invented a wonderful new bug, but they said they didn't mess with anything that would compromise the performance. Oh, the topology: _____________ _____________ | | | | | My notebook | ( ( ( ( ( ( ( | WiFi AP | (I know nothing about this, |_____________| |_____________| I just know it's there) || || || || || ______||_____ | | | gateway | (I know nothing about this, |_____________| I just know it's there) || || {INTERNET} || || ______||_____ | | | FBSD5.3 + pf| (I administer this sweetie) |_____________| || || || || ______||_____ | | | W2003 + IIS | |_____________| So a custom port 7361 TCP is forwarded by FBSD box to the internal W2003 server, where sits the IIS listening for new connections. I fired up Ethereal (on my notebook), set up a "host fbsd.gw.box" filter and then tried to start using my client. Not everything worked as it should - here I was losing the packets somewhere and they had to be retransmitted: 4 0.083165 192.168.100.93 193.77.xxx.yyy TCP 2066 > yyyy [PSH, ACK] Seq=1 Ack=1 Win=34000 Len=273 TSV=2950 TSER=0 5 0.181871 193.77.xxx.yyy 192.168.100.93 TCP [TCP Previous segment lost] yyyy > 2066 [FIN, PSH, ACK] Seq=90 Ack=274 Win=17407 Len=224 TSV=5488810 TSER=2950 6 0.181929 192.168.100.93 193.77.xxx.yyy TCP [TCP Dup ACK 3#1] 2066 > yyyy [ACK] Seq=274 Ack=1 Win=34000 Len=0 TSV=2951 TSER=0 SLE=90 SRE=315 7 3.356332 193.77.xxx.yyy 192.168.100.93 TCP [TCP Retransmission] yyyy > 2066 [FIN, PSH, ACK] Seq=1 Ack=274 Win=17407 Len=313 TSV=5488842 TSER=2951 8 3.356418 192.168.100.93 193.77.xxx.yyy TCP 2066 > yyyy [ACK] Seq=274 Ack=315 Win=33687 Len=0 TSV=2982 TSER=5488842 Every now and then my client tried with SYN packets but the 3-second timeout occured (not only once), which is the main reason of unresponsiveness of the client (I think): 191 13.475742 192.168.100.93 193.77.xxx.yyy TCP 2179 > yyyy [ACK] Seq=396 Ack=272 Win=33730 Len=0 TSV=11950 TSER=5497809 192 13.475942 192.168.100.93 193.77.xxx.yyy TCP 2179 > yyyy [FIN, ACK] Seq=396 Ack=272 Win=33730 Len=0 TSV=11950 TSER=5497809 193 13.476830 192.168.100.93 193.77.xxx.yyy TCP 2180 > yyyy [SYN] Seq=0 Ack=0 Win=32768 Len=0 MSS=1360 TSV=0 TSER=0 194 13.535734 193.77.xxx.yyy 192.168.100.93 TCP yyyy > 2179 [ACK] Seq=272 Ack=397 Win=17285 Len=0 TSV=5497809 TSER=11950 195 16.446292 192.168.100.93 193.77.xxx.yyy TCP 2180 > yyyy [SYN] Seq=0 Ack=0 Win=32768 Len=0 MSS=1360 TSV=0 TSER=0 196 22.454917 192.168.100.93 193.77.xxx.yyy TCP 2180 > yyyy [SYN] Seq=0 Ack=0 Win=32768 Len=0 MSS=1360 TSV=0 TSER=0 197 22.515197 193.77.xxx.yyy 192.168.100.93 TCP yyyy > 2180 [SYN, ACK] Seq=0 Ack=1 Win=17680 Len=0 MSS=1440 TSV=0 TSER=0 198 22.515266 192.168.100.93 193.77.xxx.yyy TCP 2180 > yyyy [ACK] Seq=1 Ack=1 Win=34000 Len=0 TSV=12040 TSER=0 Well, then I thought "okay, it must be my wireless link; it can be just too unreliable and it loses packets in transit; darn, I knew I should subscribe to ADSL". But I didnt' have my peace and I tried to ethereal also some other TCP sessions with some services which FBSD box runs (SMTP, HTTP by Apache, IMAP), but these worked very well, there was absolutely no packet loss! The first thing I tried (luckily) was disabling the Apache, and changing the port forwarding to W2003 server on the FBSD box as follows ($Maja = local W2003 server): rdr pass on $UntrustInterface proto tcp from any to any port 7361 -> $Maja port 7361 I changed to: rdr pass on $UntrustInterface proto tcp from any to any port 80 -> $Maja port 7361 and ran "pfctl -f /etc/pf.conf". I tried the client again AND IT WORKED LIKE A CHARM! I couldn't believe what I was seeing; why would a different port on FBSD box influence the packet loss? After some further research I realized that if the port on FBSD box which is forwarded to local W2003 server (still port 7361) is >= 1100, packets just get lost. Mysteriously. I switched a few times between 1099 and 1100 and it was always the same: if 1099, ti worked without ANY packet loss and if it was 1100, the work was almost impossible. OK, tu sum up: is it possible that pf does some weird things to packets if their destination port is >= 1100? Is there anything I can provide you with? Any debug output, just anything? I'd be really glad to understand what is actually going on here. Thanks for your time. Bye, --------------000407020305010306020505--