ftp problem

[Mark Atkinson]

On 01/06/10 09:57, M. Keith Thompson wrote:
> The states and tcpdump are with scrub turned off.  I tried that and it
> did not change things.
>
> Unsuccessful:
>
> self tcp xxx.yyy.15.125:21<- vvv.zzz.226.92:50187       TIME_WAIT:TIME_WAIT
> self tcp xxx.yyy.15.125:20<- vvv.zzz.226.92:59433       FIN_WAIT_2:FIN_WAIT_2
> self tcp xxx.yyy.15.125:20<- vvv.zzz.226.92:59434       FIN_WAIT_2:FIN_WAIT_2
>
> Successful:
> self tcp xxx.yyy.15.125:21<- vvv.zzz.226.92:50188       FIN_WAIT_2:FIN_WAIT_2
> self tcp xxx.yyy.15.125:20<- vvv.zzz.226.92:59435       FIN_WAIT_2:FIN_WAIT_2
>
> On Wed, Jan 6, 2010 at 11:23 AM, Peter Maxwell<peter at allicient.co.uk>  wrote:
>> 2010/1/6 M. Keith Thompson<m.keith.thompson at gmail.com>:
>>> I have a very screwy problem.  I have a pure-ftp server running pf on
>>> FreeBSD 7.0.  For the most part the server works fine; users upload
>>> and download multi-megabyte files daily.  However, I have one client
>>> (HP-UX) that can not get files larger that 98K.  If I turn off pf, it
>>> works fine.  The pflog does not show any packets from the IP that does
>>> not work.  I am totally lost; any ideas?
>>
>>
>> Off the top of my head: packet normalisation/scrub directives, the
>> other one would be to post your ruleset and a tcpdump of the session
>> so folk have something to work with.
>>
>> Also, what happens to the FTP data and control connections - do they
>> just stall or are the RSTs, etc?  What does your state table show?


The ftp server is sending FIN on the data connection after the first PSH 
of data.  It would be interesting to see the before and after contents 
of the ftp command channel if you could repeat only the first failed 
transfer with the dump using '-s 0 -X' tcpdump flags.


11:40:30.476375 IP (tos 0x8, ttl  64, id 13412, offset 0, flags [DF],
proto: TCP (6), length: 757) xxx.yyy.15.125.ftp-data >
vvv.zzz.226.92.59433: P 1:706(705) ack 1 win 33026 <nop,nop,timestamp
1091991329 31321002>
11:40:30.476386 IP (tos 0x8, ttl  64, id 13413, offset 0, flags [DF],
proto: TCP (6), length: 52) xxx.yyy.15.125.ftp-data >
vvv.zzz.226.92.59433: F, cksum 0x3a26 (correct), 706:706(0) ack 1 win
33026 <nop,nop,timestamp 1091991329 31321002>