Debug.pfftpproxy=1 to enable LAN to WAN FTP
-
I confirm the same with:
2.1-RC0 (amd64) built on Sun Jun 9 21:31:32 EDT 2013 FreeBSD 8.3-RELEASE-p8
Some FTP sites are fine (although seemingly slower to list directories than the March 18th build I was running yesterday) - the DD-WRT is definitely broken though. Setting debug.pfftpproxy=1 seems to fix it.
-
I think Ermal's change a month ago makes the FTP connection change the source port on the outside interface. But as you can see in my firewall log, the changed source port is not added to the state table. Thus the firewall code blocks it and passive FTP does not work.
When turning off the FTP proxy, the source port is known by the state table and the connection works. -
Some FTP sites are fine (although seemingly slower to list directories than the March 18th build I was running yesterday)
Same here. Superslow FTP browsing while debug.pfftpproxy=0
-
I have the same problem on 2.0.2, impossible to handle big files through ftp with default debug.pfftpproxy value.
-
So has anyone entered a bug for this or had acknowledgement from any devs (apart from jimp here)? It's a fairly big deal-breaker. I have a fairly simple setup here and see it on some sites.
-
gogol.. why did you delete your reply - I was fortunate enough to catch it and it solved all my problems (including slow to connect issues I've had for 18 months!!)
-
gogol.. why did you delete your reply - I was fortunate enough to catch it and it solved all my problems (including slow to connect issues I've had for 18 months!!)
I wasn't sure!
I am still encountering some problems (slow now and then), but it goes better. Disabling it works better for me.
For anyone who wants to try this is what I did:Under System>Advanced>Firewall/Nat check under TFTP proxy you LAN interface and click Save
Under System>Advanced>System Tunables set debug.pfftp.proxy to "default" valueMore on this in this article
-
I just noticed I haven't had any connections from a few people on my local FTP server in a while, so I started looking into it. Passive connections were working fine but I haven't had an active connection work since 6/2/13 when I must have done a firmware upgrade (2.1 RC0 x64). I changed debug.pfftpproxy to 1 and applied it and instantly active connections began working again for these people. Something changed with the ftp proxy (I'd say in May) which kept active connections from working. Sorry I don't have much more info at this time.
-
Any news on this issue?
-
I am workign on solving this.
-
Great, thank you :D
-
Please try with tomorrows snapshots.
-
HI
Flashed 2.1RC0 from 2. Juli.
It is not better , connecting and dir list and filetrasnfer is slow as hell. That means it "hangs" VERY often between the FTP commands.. Without proxy it is superfast. -
Get ones from today ones :)
-
2.1-RC0 (i386) built on Wed Jul 3 15:44:09 EDT 2013
is still broken. After trying FTP through the ALIX I tested with, it became unresponsive and seems to have crashed completely. Unfortunately it's in our DC on a recently broken KVM Switch, so I have no Console output.
-
Tested it with build from 3. Juli.
FTP transfer hangs / stutter on the commands RETR and MLSD in FileZilla.
-
I still have debug.pfftp.proxy=1 in system tunables with July 3 build. Default value does not work for me.
-
Can you please be more specific on what does not work?
-
@ermal:
Can you please be more specific on what does not work?
You have got a PM
-
@ermal:
Can you please be more specific on what does not work?
How to reproduce:
Just setup a fresh pfSense install, plug one (Win 7) device behind it and open a freshly installed Firefox. Key inftp://dd-wrt.com/others/eko/BrainSlayer-V24-preSP2/2013/05-27-2013-r21676/
and wait for "425 Failed to estabilsh connection".