Debug.pfftpproxy=1 to enable LAN to WAN FTP
-
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 2013is 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".
-
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".
This works perfectly fine with SpeedCommander, Total Commander and FlashFXP (both active and passive mode). Sorry, but FF is braindead FTP "client".
Active:
Connect to: (04.07.2013 11:53:54) hostname=dd-wrt.com username=anonymous startdir=/others/eko/BrainSlayer-V24-preSP2/2013/05-27-2013-r21676/ dd-wrt.com=83.141.4.210 220 Welcome to DD-WRT FTP service. USER anonymous 331 Please specify the password. PASS *********** 230 Login successful. SYST 215 UNIX Type: L8 FEAT 211-Features: EPRT EPSV MDTM PASV REST STREAM SIZE TVFS UTF8 211 End HELP SITE 214-The following commands are recognized. ABOR ACCT ALLO APPE CDUP CWD DELE EPRT EPSV FEAT HELP LIST MDTM MKD MODE NLST NOOP OPTS PASS PASV PORT PWD QUIT REIN REST RETR RMD RNFR RNTO SITE SIZE SMNT STAT STOR STOU STRU SYST TYPE USER XCUP XCWD XMKD XPWD XRMD 214 Help OK. OPTS UTF8 ON 200 Always in UTF8 mode. CWD /others/eko/BrainSlayer-V24-preSP2/2013/05-27-2013-r21676/ 250 Directory successfully changed. Connect ok! PWD 257 "/others/eko/BrainSlayer-V24-preSP2/2013/05-27-2013-r21676" Get directory TYPE A 200 Switching to ASCII mode. PORT 10,0,0,1,222,174 200 PORT command successful. Consider using PASV. LIST 150 Here comes the directory listing. Download Waiting for server... 226 Directory send OK.Passive:
Connect to: (04.07.2013 11:54:32) hostname=dd-wrt.com username=anonymous startdir=/others/eko/BrainSlayer-V24-preSP2/2013/05-27-2013-r21676/ dd-wrt.com=83.141.4.210 220 Welcome to DD-WRT FTP service. USER anonymous 331 Please specify the password. PASS *********** 230 Login successful. SYST 215 UNIX Type: L8 FEAT 211-Features: EPRT EPSV MDTM PASV REST STREAM SIZE TVFS UTF8 211 End HELP SITE 214-The following commands are recognized. ABOR ACCT ALLO APPE CDUP CWD DELE EPRT EPSV FEAT HELP LIST MDTM MKD MODE NLST NOOP OPTS PASS PASV PORT PWD QUIT REIN REST RETR RMD RNFR RNTO SITE SIZE SMNT STAT STOR STOU STRU SYST TYPE USER XCUP XCWD XMKD XPWD XRMD 214 Help OK. OPTS UTF8 ON 200 Always in UTF8 mode. CWD /others/eko/BrainSlayer-V24-preSP2/2013/05-27-2013-r21676/ 250 Directory successfully changed. Connect ok! PWD 257 "/others/eko/BrainSlayer-V24-preSP2/2013/05-27-2013-r21676" Get directory TYPE A 200 Switching to ASCII mode. PASV 227 Entering Passive Mode (83,141,4,210,241,176) LIST 150 Here comes the directory listing. Download Waiting for server... 226 Directory send OK.On that note, I must say pf/BSD does pretty impressive job here. Using active FTP from behind NAT has been just plain impossible with Linux/iptables-based firewalls.
-
Sorry, but FF is braindead FTP "client".
Sure, but it used to work with Firefox. Plus it works behind all of the other Firewalls/Routers I have tested (Checkpoint, ASA, some D-Link device, DD-WRT, AVM Fritz…)
It's not only Firefox, Chrome does not work either.
I don't really care, but the average surfer/user will. So I posted a way how to reproduce the issue for debugging purposes. -
Yeah, FF, Chrome, IE, Safari and any other mainsteam browser are all braindead FTP clients. I'd suggest to take your issue with the browser developers. As for debugging, no debugging is possible without a session transcript (as posted above) - good luck getting anything like that from the browser - or some wireshark sniffing.
-
On that note, I must say pf/BSD does pretty impressive job here. Using active FTP from behind NAT has been just plain impossible with Linux/iptables-based firewalls.
modprobe ip_conntrack_ftp;)
-
modprobe ip_conntrack_ftp;)
That does not really work (well or at all) with about half of FTP servers out there (a.k.a. waste of time).
-
Yeah, FF, Chrome, IE, Safari and any other mainsteam browser are all braindead FTP clients. I'd suggest to take your issue with the browser developers. As for debugging, no debugging is possible without a session transcript (as posted above) - good luck getting anything like that from the browser - or some wireshark sniffing.
Well I already did put a lot of effort into debugging this problem if you look at post #11. If I find the time, I'll do that again with the lastest snapshots. For now I can only describe how to easily reproduce the issue for debugging purposes.
-
The easiest way to get a session capture from the firewall itself is this:
# pkg_add -r tcpflow # rehash # tcpflow -c -i em0 port 21Get a capture from the LAN NIC, and the WAN NIC
-
Better to capture the whole traffic to the (otherwise unused) destination ip.
Because the traffic shouldn'd use port 21 (neither src and dst) for data and that's the problem. -
It depends on which bit you're having an issue with.
tcpflow would show NAT/port translation errors a lot easier than digging through an entire capture. tcpflow prints out the plain text exchange between the client and server without having to dig through a binary capture; It gives you something you can just copy/paste as others have done earlier in this thread from FTP clients that actually work properly.
Getting all of the traffic to/from the target server would help find other issues (such as connections going to the wrong port).
-
But you don't see if server really connect from port 1234 to client port 2345 and the router expect this.
-
Yes, but as I said, a different problem entirely. They are both helpful but in different ways.
-
I also had problems with ftp connections being very hit & miss since upgrading to 2.1. Setting this got it working again.
