RunUO Community

This is a sample guest message. Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!

Connection doesn't dispose immediately to incorrect password users

ntony

Sorceror
Connection doesn't dispose immediately to incorrect password users

When user connect to my shard with incorrect username/password, they freeze on "Verify Account". But not the invalid credential page.

The connection is not disposed immediately with state:

Code:
tcp        0      0 208.219.161.175:2593      61.10.98.34:50099      FIN_WAIT2

However in the console, I can found:

Code:
Login: 61.10.98.34: Invalid password for 'ntony'
Client: 61.10.98.34: Disconnected. [0 Online]

I have read through these:

\Scripts\Accounting\AccountHandlers.cs
Code:
			else if ( !acct.CheckPassword( pw ) )
			{
				Console.WriteLine( "Login: {0}: Invalid password for '{1}'", e.State, un );
				e.RejectReason = ALRReason.BadPass;
			}

\Server\Network\PackerHandlers.cs
Code:
		public static void AccountLogin_ReplyRej( NetState state, ALRReason reason )
		{
			state.Send( new AccountLoginRej( reason ) );
			state.Dispose();
		}

\Server\Network\Packets.cs
Code:
	public enum ALRReason : byte
	{
		Invalid = 0x00,
		InUse = 0x01,
		Blocked = 0x02,
		BadPass = 0x03,
		Idle = 0xFE,
		BadComm = 0xFF
	}

	public sealed class AccountLoginRej : Packet
	{
		public AccountLoginRej( ALRReason reason ) : base( 0x82, 2 )
		{
			m_Stream.Write( (byte)reason );
		}
	}


Any idea?
 

Mark

Knight
FIN_WAIT_2 is normal: RFC 793 (rfc793) - Transmission Control Protocol

Essentially your server is waiting for the client to acknowledge that the connection is closed. There are a few reasons the socket might be stuck in this state (the most common being a bug in the client or a network issue). Either way, it's not a huge problem.

You can check and adjust how long the socket will remain in that state without a response by adjusting the tcp_fin_timeout parameter.

Code:
$ cat /proc/sys/net/ipv4/tcp_fin_timeout
60

See: http://www.cs.uwaterloo.ca/~brecht/servers/ip-sysctl.txt

Code:
tcp_fin_timeout - INTEGER
	Time to hold socket in state FIN-WAIT-2, if it was closed
	by our side. Peer can be broken and never close its side,
	or even died unexpectedly. Default value is 60sec.
	Usual value used in 2.2 was 180 seconds, you may restore
	it, but remember that if your machine is even underloaded WEB server,
	you risk to overflow memory with kilotons of dead sockets,
	FIN-WAIT-2 sockets are less dangerous than FIN-WAIT-1,
	because they eat maximum 1.5K of memory, but they tend
	to live longer.	Cf. tcp_max_orphans.
 
Top