[Solved] 550 PORT command failed..?

[PaJa]

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.

[Mouton]

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)

[PaJa]

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!

[darkone]

Ports < 1024 are reserved for administrators.

[PaJa]

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

[richto]

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.

[Mouton]

Do u start ioftpd.exe as an administrator user ?
a normal user can't open ports < 1024, as dark mentionned.

[PaJa]

yeah as user in local admins group. but its ok already, the local policy settings helps. thanks richto

[richto]

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.