Hello all,
Hopefully you can help me with this.
I have Red Hat 7.3 which I have several different services running off of (Apache, MySQL, etc). This is just for home use, but my girlfriend uses it to transfer files to her boss. I also have WU-FTP server setup on this box. I have a firewall and since my gilfriends boss liked using Passive mode to download, I setup 3 ports 13005-13007 for him to do that through my firewall, along with the basic ports 20 and 21. Just like every problem that ever occurs, things worked great in the past. Suddenly, today when he was trying to download some projects my girlfriend did for him, he kept getting this error:
"425 Can't open passive connection: Address already in use.
Passive mode refused."
Here is a copy of my ftpaccess file:
# This file was generated by the KDE wu-ftpd configurator.
# (c) 2000 by Bernhard Rosenkränzer (bero@redhat.com)
class all real *
timeout data 2
timeout accept 0
noretrieve
loginfails 5
private no
email root@localhost
banner /etc/ftpbanner.msg
greeting terse
message /welcome.msg LOGIN
message .message CWD=*
readme README* LOGIN
readme README* CWD=*
chmod no anonymous,guest
delete no anonymous
overwrite no anonymous
rename no anonymous
passwd-check rfc822 warn
log transfers anonymous,guest,real inbound
log transfers anonymous,guest,real outbound
passive address 24.175.53.xxx 0.0.0.0/0
passive ports 0.0.0.0/0 13005 13020
pasv-allow all 0.0.0.0/0
port-allow all 0.0.0.0/0
It never used to happen and I didn't do anything that I can think of to edit the "ftpaccess" file. So, I decided that it was a timeout issue with the ports. I decided to open a few more up, 13005-13020, more than enough Passive ports, in my opinion. Then I tested it out from another box and after abut 15 files it does the same thing. When I did a "netstat" it showed all my Passive ports as in the TIME_WAIT status. After a few minutes they would all clear and I would be able to download another 15, and so on...
Here's the "netstat" output:
Proto Local Address Foreign Address State
tcp 10.10.10.21:13010 ai.x25.net:38145 TIME_WAIT
tcp 10.10.10.21:ftp ai.x25.net:38112 ESTABLISHED
tcp 10.10.10.21:13018 ai.x25.net:38140 TIME_WAIT
tcp 10.10.10.21:13013 ai.x25.net:38143 TIME_WAIT
tcp 10.10.10.21:13017 ai.x25.net:38142 TIME_WAIT
tcp 10.10.10.21:13014 ai.x25.net:38137 TIME_WAIT
tcp 10.10.10.21:13016 ai.x25.net:38136 TIME_WAIT
tcp 10.10.10.21:13011 ai.x25.net:38139 TIME_WAIT
tcp 10.10.10.21:13012 ai.x25.net:38138 TIME_WAIT
tcp 10.10.10.21:13009 ai.x25.net:38133 TIME_WAIT
tcp 10.10.10.21:13019 ai.x25.net:38132 TIME_WAIT
tcp 10.10.10.21:13005 ai.x25.net:38135 TIME_WAIT
tcp 10.10.10.21:13015 ai.x25.net:38134 TIME_WAIT
tcp 10.10.10.21:13020 ai.x25.net:38129 TIME_WAIT
tcp 10.10.10.21:13007 ai.x25.net:38128 TIME_WAIT
tcp 10.10.10.21:13006 ai.x25.net:38131 TIME_WAIT
tcp 10.10.10.21:13008 ai.x25.net:38130 TIME_WAIT
tcp 10.10.10.21:ssh 10.10.10.50:2021 ESTABLISHED
After some research I found out that the TIME_WAIT status is used to allow time for any ACK or FIN packets for that socket to reach heir destination before totally destroying the connection. Unfortunely, in my case it seems that the time period is too long and causes the boss to get error messages (bosses don't like errors). So, again, I did some more research and found that you can change the value of this TIME_WAIT, if you go to the file /proc/sys/net/ipv4/tcp_tw_recycle. So I tried to cahnge the TIME_WAIT recycle time to 30 sec by putting in 30000 (it is measured in 1/100ths of a sec) but I keep getting the follwing error when I try to save it in pico:
"[ Error writing to tcp_tw_recycle: Invalid argument ]"
It won't even let me save ANY changes. I am logged in as root, and the Privs say I should be able to write to it.
SO......... Long story short, I need to know how I can reduce the TIME_WAIT on my system. Like I said earlier in this thesis, it just started happening and has never been a problem before. PLEASE help me out if you know of anywhere, or anything about this problem. If you've made it this far in this past, then thanks for checkig it out and helping a fellow Computer guy in need.
Burke
Hopefully you can help me with this.
I have Red Hat 7.3 which I have several different services running off of (Apache, MySQL, etc). This is just for home use, but my girlfriend uses it to transfer files to her boss. I also have WU-FTP server setup on this box. I have a firewall and since my gilfriends boss liked using Passive mode to download, I setup 3 ports 13005-13007 for him to do that through my firewall, along with the basic ports 20 and 21. Just like every problem that ever occurs, things worked great in the past. Suddenly, today when he was trying to download some projects my girlfriend did for him, he kept getting this error:
"425 Can't open passive connection: Address already in use.
Passive mode refused."
Here is a copy of my ftpaccess file:
# This file was generated by the KDE wu-ftpd configurator.
# (c) 2000 by Bernhard Rosenkränzer (bero@redhat.com)
class all real *
timeout data 2
timeout accept 0
noretrieve
loginfails 5
private no
email root@localhost
banner /etc/ftpbanner.msg
greeting terse
message /welcome.msg LOGIN
message .message CWD=*
readme README* LOGIN
readme README* CWD=*
chmod no anonymous,guest
delete no anonymous
overwrite no anonymous
rename no anonymous
passwd-check rfc822 warn
log transfers anonymous,guest,real inbound
log transfers anonymous,guest,real outbound
passive address 24.175.53.xxx 0.0.0.0/0
passive ports 0.0.0.0/0 13005 13020
pasv-allow all 0.0.0.0/0
port-allow all 0.0.0.0/0
It never used to happen and I didn't do anything that I can think of to edit the "ftpaccess" file. So, I decided that it was a timeout issue with the ports. I decided to open a few more up, 13005-13020, more than enough Passive ports, in my opinion. Then I tested it out from another box and after abut 15 files it does the same thing. When I did a "netstat" it showed all my Passive ports as in the TIME_WAIT status. After a few minutes they would all clear and I would be able to download another 15, and so on...
Here's the "netstat" output:
Proto Local Address Foreign Address State
tcp 10.10.10.21:13010 ai.x25.net:38145 TIME_WAIT
tcp 10.10.10.21:ftp ai.x25.net:38112 ESTABLISHED
tcp 10.10.10.21:13018 ai.x25.net:38140 TIME_WAIT
tcp 10.10.10.21:13013 ai.x25.net:38143 TIME_WAIT
tcp 10.10.10.21:13017 ai.x25.net:38142 TIME_WAIT
tcp 10.10.10.21:13014 ai.x25.net:38137 TIME_WAIT
tcp 10.10.10.21:13016 ai.x25.net:38136 TIME_WAIT
tcp 10.10.10.21:13011 ai.x25.net:38139 TIME_WAIT
tcp 10.10.10.21:13012 ai.x25.net:38138 TIME_WAIT
tcp 10.10.10.21:13009 ai.x25.net:38133 TIME_WAIT
tcp 10.10.10.21:13019 ai.x25.net:38132 TIME_WAIT
tcp 10.10.10.21:13005 ai.x25.net:38135 TIME_WAIT
tcp 10.10.10.21:13015 ai.x25.net:38134 TIME_WAIT
tcp 10.10.10.21:13020 ai.x25.net:38129 TIME_WAIT
tcp 10.10.10.21:13007 ai.x25.net:38128 TIME_WAIT
tcp 10.10.10.21:13006 ai.x25.net:38131 TIME_WAIT
tcp 10.10.10.21:13008 ai.x25.net:38130 TIME_WAIT
tcp 10.10.10.21:ssh 10.10.10.50:2021 ESTABLISHED
After some research I found out that the TIME_WAIT status is used to allow time for any ACK or FIN packets for that socket to reach heir destination before totally destroying the connection. Unfortunely, in my case it seems that the time period is too long and causes the boss to get error messages (bosses don't like errors). So, again, I did some more research and found that you can change the value of this TIME_WAIT, if you go to the file /proc/sys/net/ipv4/tcp_tw_recycle. So I tried to cahnge the TIME_WAIT recycle time to 30 sec by putting in 30000 (it is measured in 1/100ths of a sec) but I keep getting the follwing error when I try to save it in pico:
"[ Error writing to tcp_tw_recycle: Invalid argument ]"
It won't even let me save ANY changes. I am logged in as root, and the Privs say I should be able to write to it.
SO......... Long story short, I need to know how I can reduce the TIME_WAIT on my system. Like I said earlier in this thesis, it just started happening and has never been a problem before. PLEASE help me out if you know of anywhere, or anything about this problem. If you've made it this far in this past, then thanks for checkig it out and helping a fellow Computer guy in need.
Burke