Date: Wed, 29 Mar 2006 21:13:48 +0200 From: Nejc Skoberne <nejc@skoberne.net> To: freebsd-pf@freebsd.org Cc: i4-dev <i4-dev@lists.infrax.si> Subject: Mysterious packet loss Message-ID: <442ADC6C.2030202@skoberne.net>
next in thread | raw e-mail | index | archive | help
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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?442ADC6C.2030202>