ioFTPD General New releases, comments, questions regarding the latest version of ioFTPD. |
12-22-2003, 06:16 AM
|
#1
|
Member
Join Date: Jul 2003
Posts: 53
|
550 PORT command failed..?
hi there, i have strange problem.
i have configured my io on second machine exactly as on the first one, bot in the second machine i simply can't fxp to. Every time i've got this message: 550 PORT command failed: An attempt was made to access a socket in a way forbidden by its access permissions.
The user dont have F or f flags. Any sugestion?
Thanks for any idea.
|
|
|
12-22-2003, 10:12 AM
|
#2
|
Posse Member
Ultimate Scripter ioFTPD Administrator
Join Date: Dec 2002
Posts: 1,956
|
That's an OS error, not an io error.
The OS denies io the use of the port it tries to use.
Try using other ports in ioftpd.ini (Ports = x-y)
|
|
|
12-22-2003, 01:44 PM
|
#3
|
Member
Join Date: Jul 2003
Posts: 53
|
thanks for advise, changing ports=x-y dont help me, but when i change service port from 444 to another one, everything works fine. hrrmm strange, becouse Serv-U ftp works on 444 just fine
But anyways io rules!
|
|
|
12-22-2003, 05:35 PM
|
#4
|
Disabled
FlashFXP Registered User ioFTPD Administrator
Join Date: Dec 2001
Posts: 2,230
|
Ports < 1024 are reserved for administrators.
|
|
|
12-23-2003, 03:59 AM
|
#5
|
Member
Join Date: Jul 2003
Posts: 53
|
I'm running site site on windows 2k (there is port 444 just fine) and the second one is on Windows 2k3 standard. I tryed to change Ports to another then default 1024-2048. But FXP upload still dont work, only the change of service port helps I still can't understand how it is possible that Serv-U works on the port 444, strange, isn't it? LOL
|
|
|
12-23-2003, 08:27 PM
|
#6
|
Member
FlashFXP Registered User ioFTPD Foundation User
Join Date: Jan 2003
Posts: 59
|
Running the site itself or PASV ports on 1024 is not a good idea.
Move it away from this port # (up much higher) and ensure the PASV range doesnt cross over the site access port #
Use 1200-2200 or something, as ports round 1024 are often used by the OS.
Your particular problem is usually caused by a user without administrative rights trying to write raw sockets or lock exclusive addresses (not sure which ioftpd would be doing to cause this error).
If you already have admin rights then To fix this, you will need to
Open Control Panel | Administrative Tools | Local Security Policy, select Local Policies and then User Rights Assignment from the tree "Act as part of OS" should be the second entry on the right hand pane of the control Panel. Add the user account for ioftpd to this list.
|
|
|
12-25-2003, 10:24 AM
|
#7
|
Posse Member
Ultimate Scripter ioFTPD Administrator
Join Date: Dec 2002
Posts: 1,956
|
Do u start ioftpd.exe as an administrator user ?
a normal user can't open ports < 1024, as dark mentionned.
|
|
|
12-25-2003, 01:00 PM
|
#8
|
Member
Join Date: Jul 2003
Posts: 53
|
yeah as user in local admins group. but its ok already, the local policy settings helps. thanks richto
|
|
|
12-07-2004, 05:17 PM
|
#9
|
Member
FlashFXP Registered User ioFTPD Foundation User
Join Date: Jan 2003
Posts: 59
|
On Windows 2003 this is a bug that is fixed in release candidate 1 for SP1:
Smart TCP port allocation
When a TCP peer initiates a TCP connection termination and the connection termination completes, the TCP connection enters the TIME WAIT state. Once the TIME WAIT state is reached, TCP must wait twice the maximum segment lifetime (MSL) before a connection with the same set of socket addresses can be created. The set of socket addresses consist of the combination of the source and destination IP addresses and source and destination TCP ports. The MSL is the maximum amount of time a TCP segment can exist in an internetwork, and its recommended value is 120 seconds. This delay prevents a new connectionâs TCP segments that are using the same set of socket addresses from being confused with duplicated TCP segments of the old connection.
The TCP port for a connection in the TIME WAIT state is considered an available port and can be assigned for use by an application. This can lead to the following situation:
1.
An application requests any available TCP port.
2.
TCP/IP assigns a TCP port to use for the application socket.
3.
The application attempts to open a socket with a specific destination IP address.
4.
The application establishes a TCP connection and sends data.
5.
The application terminates the TCP connection.
6.
TCP/IP places the application's TCP connection in the TIME WAIT state until twice the MSL has passed.
7.
The same application requests another available TCP port.
8.
TCP/IP assigns a TCP port to use for the application socket. Because the port for the connection in the TIME WAIT state is considered open, it can be chosen as the next port to assign to the requesting application.
9.
Assuming that TCP/IP assigns the same TCP port number, the application attempts to open a socket with the same destination IP address.
10.
Because the connection is using the same set of socket addresses as the connection in the TIME WAIT state, TCP/IP indicates an error to the application.
You can mitigate this situation through the following:
⢠Setting the MaxFreeTWTcbs registry entry at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Servic es\Tcpip\Parameters (REG_DWORD type) to a lower value. The value of MaxFreeTWTcbs controls the number of connections that can be in the TIME WAIT state. Once this number is exceeded, the oldest connection is automatically removed from the TIME WAIT state.
⢠Setting the TcpTimedWaitDelay registry entry at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Servic es\Tcpip\Parameters (REG_DWORD type) to a lower value. The value of TcpTimedWaitDelay determines the length of time that a connection stays in the TIME WAIT state.
However, lowering the value of these registry entries is contrary to the original design of TCP and the MSL.
For more information about these registry entries, see Microsoft Windows Server 2003 TCP/IP Implementation Details.
To prevent an application from creating a connection with the same set of socket addresses of a connection that is in a TIME WAIT state, TCP/IP in Windows Server 2003 SP1 has implemented a smart TCP port allocation algorithm. When an application requests any available TCP port, TCP/IP first attempts to find an available port that does not correspond to a connection in the TIME WAIT state. If a port cannot be found, then it picks any available port.
This new behavior makes it much more unlikely that an application will be assigned a TCP port that is in the TIME WAIT state when connecting to the same destination. You no longer need to modify the values of the MaxFreeTWTcbs and TcpTimedWaitDelay registry entries.
|
|
|
Thread Tools |
|
Display Modes |
Rate This Thread |
Linear Mode
|
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -5. The time now is 09:22 AM.
|