Possible FTP helper bug…
-
Yes, it all works properly with 1.0-SNAPSHOT-09-04-06.
Interestingly, as I'm sure you're well aware, in the cvstrac timeline, I count about 4 commits that all reference the FTP helper between the two snapshots. Something in those changes must be affecting it's operation.
Thanks again!!
-
So you are having trouble with VPN + FTP basically?
-
Nope, no VPN involved, just FTP.
I did notice that those changes did reference VPN, so it does seem odd that they are affecting just regular FTP over the Internet, so maybe it's not those. But some change between those 2 snapshots is certainly affecting FTP. Sorry I know that is a little vague, but I can't point to anything in particular that could be causing it.
Thanks again!
-
Then I really don't know. We only changed code related to incoming FTP + reflection recently. Nothing else, unfortunately.
Trouble is FTP is working perfectly fine for me outgoing.
-
Not sure what client you're using, but I noticed with SmartFTP which I was using it automatically falls back to PASSIVE if ACTIVE doesn't work. So I didn't notice the problem at first. But when I added items to the Queue they wouldn't download, because the queue section doesn't have the fallback feature, and was just trying ACTIVE mode. So then I tested with CLI ftp on Linux, so I could limit the mode to one or the other and then I noticed that for sure ACTIVE mode wasn't working. I confirmed this behind 2 different pfSense firewalls both running the 09-06-06, and that behind a third pfSense box @ 09-04-06 that it worked.
All these firewalls have very "stock" settings. Pretty much simply using the stock settings with a few NATed services.
-
Using a FTP client (FreeBSD's):
226 Directory send OK.
ftp> passive off
Passive mode: off; fallback to active mode: off.
ftp> get rawrite.exe
local: rawrite.exe remote: rawrite.exe
200 EPRT command successful. Consider using EPSV.
150 Opening BINARY mode data connection for rawrite.exe (36064 bytes).
100% || 36064 57.35 KB/s 00:00 ETA
226 File send OK.
36064 bytes received in 00:00 (47.58 KB/s)
ftp> passive on
Passive mode: on; fallback to active mode: off.
ftp> get rawrite.exe
local: rawrite.exe remote: rawrite.exe
229 Entering Extended Passive Mode (|||53759|)
150 Opening BINARY mode data connection for rawrite.exe (36064 bytes).
100% || 36064 71.84 KB/s 00:00 ETA
226 File send OK.
36064 bytes received in 00:00 (58.50 KB/s)
ftp> passive auto
Passive mode: on; fallback to active mode: on.
ftp> get rawrite.exe
local: rawrite.exe remote: rawrite.exe
229 Entering Extended Passive Mode (|||59392|)
150 Opening BINARY mode data connection for rawrite.exe (36064 bytes).
100% |*************************************| 36064 71.25 KB/s 00:00 ETA
226 File send OK.
36064 bytes received in 00:00 (58.18 KB/s)
ftp> -
Well, I don't know what to say. It was certainly a problem on my systems until I went back to the aforementioned snapshot. Strange. I'll try re-updating to the latest snapshot to see if something funny happened the last time. But it seems odd that the same "funny" thing would happen on 2 different machines.
Thanks for your attention to this anyway! 8)
-
Okay, I reapplied the 09-06-06 snapshot and like clockwork the problem resurfaced. I don't know what it is, but for me FTP ACTIVE mode really doesn't work with this snapshot. :( I'll just go back to 09-04-06 for now…
Thanks!
-
Indeed there was a bug, if you did not have a vpn defined, it would not have installed the rule.
Issue these commands from a shell to test:
/etc/rc.conf_mount_rw
fetch -o /etc/inc/ http://www.pfsense.com/~sullrich/filter.inc
/etc/rc.filter_configure -
Should I reapply 09-06-06 first??
- Oops, duh, since it's not a problem in 04 I guess I should…sorry for the stupid question...off to update and apply! *
-
Yep.
-
Oops, missed your reply before my edit…
Anyway, reapplied 09-06-06 and then followed your directions and voila!! It works!! Awesome!! You rock!! :D
Thanks!! 8)