Matt Sonnentag
Basic Pleskian
Environment - VPS box (Media Temple), Centos 5.6, Plesk 8.6, CSF firewall w/lfd - latest yum updates from art, dag and base
We have been having a strange problem with ftp timing out the I hop someone can shed some light on for me. The issue is that we have a mac running Transmit that stays connected for extended periods of time, the owner of the mac - who is paying for the server btw, would like to not have to login over and over. Apparently, prior to updates and install of the firewall this was not an issue - so somewhere in that work we managed to make this problem happen.
To resolve, we upped the timeouts on proftpd in the config file to:
<Global>
DefaultRoot ~ psacln
AllowOverwrite on
TimeoutLogin 300
TimeoutNoTransfer 28800
TimeoutIdle 0
PassivePorts 30000 35000
DebugLevel 5
</Global>
Which basically keeps them connected for a day without a transfer. Probably not the best practice, but wth.
Anyway, this doesn't work - it seems as if something else is nixing the connection somewhere. As you can see we have debuglevel 5 set and are getting copious feedback in our /var/log/secure file and we are actually testing this on a Win7 box with Filezilla installed.
What we see is the client and the server doing a NOOP / keepalive dance for 30 minutes. We see the transactions on both ends in the /var/log/secure file and Filezillas log display. The two boxes happily chat for the 30 minutes and then we stop seeing any traffic from the server as noted in the following logs:
From the server:
Jun 8 11:46:54 clientsrv proftpd[11689]: clientsrv.com (209.169.208.194[209.169.208.194]) - dispatching PRE_CMD command 'NOOP' to mod_tls
Jun 8 11:46:54 clientsrv proftpd[11689]: clientsrv.com (209.169.208.194[209.169.208.194]) - dispatching PRE_CMD command 'NOOP' to mod_core
Jun 8 11:46:54 clientsrv proftpd[11689]: clientsrv.com (209.169.208.194[209.169.208.194]) - dispatching PRE_CMD command 'NOOP' to mod_core
Jun 8 11:46:54 clientsrv proftpd[11689]: clientsrv.com (209.169.208.194[209.169.208.194]) - dispatching CMD command 'NOOP' to mod_core
Jun 8 11:46:54 clientsrv proftpd[11689]: clientsrv.com (209.169.208.194[209.169.208.194]) - dispatching LOG_CMD command 'NOOP' to mod_log
Jun 8 11:56:50 clientsrv proftpd: Deprecated pam_stack module called from service "proftpd"
Jun 8 11:56:50 clientsrv proftpd: pam_env(proftpd:setcred): Unable to open config file: /etc/security/pam_env.conf: No such file or directory
Jun 8 11:56:50 clientsrv proftpd: Deprecated pam_stack module called from service "proftpd"
Jun 8 11:56:50 clientsrv proftpd: pam_succeed_if(proftpd:session): error retrieving information about user 0
Jun 8 11:56:50 clientsrv proftpd: pam_unix(proftpd:session): session closed for user xxxxman
Jun 8 11:56:50 clientsrv proftpd[11689]: clientsrv.com (209.169.208.194[209.169.208.194]) - FTP session closed.
From the PC:
10:45:54 Response: 257 "/" is the current directory
10:46:24 Status: Sending keep-alive command
10:46:24 Command: PWD
10:46:24 Response: 257 "/" is the current directory
10:46:54 Status: Sending keep-alive command
10:46:54 Command: NOOP
10:46:54 Response: 200 NOOP command successful
10:56:50 Error: Disconnected from server: ECONNABORTED - Connection aborted
So, I am not sure what happens after 10:46:54. It seems that something is going on with the server and it is having trouble extending the session. I have researched all of those FTP related errors in secure log and gotten nowhere. I am suspecting that some sort of communication is happening on the server and the firewall might be blocking it.
Note: we do have passive ports configed in the fwall and everything seems to work properly other than the extended timeout. Also verifyed that scoreboard is there and being written to, and tried a number of different configs for pam and proftpd.
My theory at this point is that proftpd (managed by pamd) needs to go and check its config to update the timeout or perhaps the scoreboard file (using the network??) and is getting blocked by the firewall. My next troubleshooting step is to go through this process again and see if we can monitor dropped packets in the firewall as well.
Any thoughts or help would be much appreciated.
Just a quick followup:
I enabled CSF watch mode and logged everything related to the servers IP as well as my own and this yielded no additional information at all.
We have been having a strange problem with ftp timing out the I hop someone can shed some light on for me. The issue is that we have a mac running Transmit that stays connected for extended periods of time, the owner of the mac - who is paying for the server btw, would like to not have to login over and over. Apparently, prior to updates and install of the firewall this was not an issue - so somewhere in that work we managed to make this problem happen.
To resolve, we upped the timeouts on proftpd in the config file to:
<Global>
DefaultRoot ~ psacln
AllowOverwrite on
TimeoutLogin 300
TimeoutNoTransfer 28800
TimeoutIdle 0
PassivePorts 30000 35000
DebugLevel 5
</Global>
Which basically keeps them connected for a day without a transfer. Probably not the best practice, but wth.
Anyway, this doesn't work - it seems as if something else is nixing the connection somewhere. As you can see we have debuglevel 5 set and are getting copious feedback in our /var/log/secure file and we are actually testing this on a Win7 box with Filezilla installed.
What we see is the client and the server doing a NOOP / keepalive dance for 30 minutes. We see the transactions on both ends in the /var/log/secure file and Filezillas log display. The two boxes happily chat for the 30 minutes and then we stop seeing any traffic from the server as noted in the following logs:
From the server:
Jun 8 11:46:54 clientsrv proftpd[11689]: clientsrv.com (209.169.208.194[209.169.208.194]) - dispatching PRE_CMD command 'NOOP' to mod_tls
Jun 8 11:46:54 clientsrv proftpd[11689]: clientsrv.com (209.169.208.194[209.169.208.194]) - dispatching PRE_CMD command 'NOOP' to mod_core
Jun 8 11:46:54 clientsrv proftpd[11689]: clientsrv.com (209.169.208.194[209.169.208.194]) - dispatching PRE_CMD command 'NOOP' to mod_core
Jun 8 11:46:54 clientsrv proftpd[11689]: clientsrv.com (209.169.208.194[209.169.208.194]) - dispatching CMD command 'NOOP' to mod_core
Jun 8 11:46:54 clientsrv proftpd[11689]: clientsrv.com (209.169.208.194[209.169.208.194]) - dispatching LOG_CMD command 'NOOP' to mod_log
Jun 8 11:56:50 clientsrv proftpd: Deprecated pam_stack module called from service "proftpd"
Jun 8 11:56:50 clientsrv proftpd: pam_env(proftpd:setcred): Unable to open config file: /etc/security/pam_env.conf: No such file or directory
Jun 8 11:56:50 clientsrv proftpd: Deprecated pam_stack module called from service "proftpd"
Jun 8 11:56:50 clientsrv proftpd: pam_succeed_if(proftpd:session): error retrieving information about user 0
Jun 8 11:56:50 clientsrv proftpd: pam_unix(proftpd:session): session closed for user xxxxman
Jun 8 11:56:50 clientsrv proftpd[11689]: clientsrv.com (209.169.208.194[209.169.208.194]) - FTP session closed.
From the PC:
10:45:54 Response: 257 "/" is the current directory
10:46:24 Status: Sending keep-alive command
10:46:24 Command: PWD
10:46:24 Response: 257 "/" is the current directory
10:46:54 Status: Sending keep-alive command
10:46:54 Command: NOOP
10:46:54 Response: 200 NOOP command successful
10:56:50 Error: Disconnected from server: ECONNABORTED - Connection aborted
So, I am not sure what happens after 10:46:54. It seems that something is going on with the server and it is having trouble extending the session. I have researched all of those FTP related errors in secure log and gotten nowhere. I am suspecting that some sort of communication is happening on the server and the firewall might be blocking it.
Note: we do have passive ports configed in the fwall and everything seems to work properly other than the extended timeout. Also verifyed that scoreboard is there and being written to, and tried a number of different configs for pam and proftpd.
My theory at this point is that proftpd (managed by pamd) needs to go and check its config to update the timeout or perhaps the scoreboard file (using the network??) and is getting blocked by the firewall. My next troubleshooting step is to go through this process again and see if we can monitor dropped packets in the firewall as well.
Any thoughts or help would be much appreciated.
Just a quick followup:
I enabled CSF watch mode and logged everything related to the servers IP as well as my own and this yielded no additional information at all.
Last edited: