Hi Peter, I've found the error. The packet has been blocked at the other firewall. I've fixed them and it's now correct.
Thanks so much, Mark On 4/27/06, IMS <[EMAIL PROTECTED]> wrote: > Thanks Peter.. > > I've checked.. My client hasn't changed anything.. > (including me too..) > > I've some wondering case.. > My firewall have 3 networks (3 eth. card).. inhouse, staging, internet > inhouse couldn't use passive ftp to staging.. > but staging could use passive ftp to internet > > my pf log didn't return any error.. > > I use WsFTP as my ftp client > I found error log.. > > ************************************************************ > SYST > 215 Windows_NT > Host type (S): Microsoft NT > PASV > 227 Entering Passive Mode (192,168,202,1,214,231) > connecting to 192.168.202.1:55015 > - - > connecting to 192.168.202.1:55015 > ! Connection failed 192.168.202.1 - connection refused > ! connect: error 0 > PORT 192,168,1,181,18,61 > 200 PORT command successful. > LIST > ************************************************************ > > (192.168.202.1 is ip address of my firewall 's staging network) > > It's means that there is an error when ftp client try to connect > to ftp-proxy.. > > but there is no error log from pf.. > T.T > > Any idea???.. > > Thanks, > Mark > > > On 4/27/06, Peter N. M. Hansteen <[EMAIL PROTECTED]> wrote: > > IMS <[EMAIL PROTECTED]> writes: > > > > > I'm quite sure that I didn't change any things in my > > > box.. > > > > > > So I turn back to use old machine.. but my client > > > still couldn't use passive ftp.. > > > > If you really did not change anything, it sounds like your client is > > getting bit by changes made elsewhere in the path from your client to > > the ftp servers in question. > > > > On the other hand, we have had cases (using ftpsesame on OpenBSD 3.7) > > where passive ftp stopped working apparently due to memory starvation on > > the filtering gateway. After killing a pftop which had lost its > > controlling terminal due to a reboot of a putty.exe equipped machine > > elsewhere, it all started working again in that particular case. Given > > the stability of the platform running putty.exe, this has happened more > > than once. > > > > -- > > Peter N. M. Hansteen, member of the first RFC 1149 implementation team > > http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ > > "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" > > 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 > > seconds. > > > > >
