Thanks Rick.
For test purposes, this is a very simple, barebones, generic Client/Server setup.
Client: while (1)
{
socket()
connect()
close()
5 sec delay
}
Server: socket()
bind()
listen()
while (1)
{
accept()
close()
}
There is something about 1 min and 10 mins here. Don't know what.
Also, Redhat is not too conducive to giving out much info unless
you open your wallet, at least as far as I can tell.
ShutEye Thinkin
-----Original Message-----
From: Rick Warner [SMTP:[EMAIL PROTECTED]]
Sent: Friday, January 05, 2001 9:31 AM
To: Redhat-list (E-mail)
Cc: Redhat-devel-list (E-mail)
Subject: Re: TCP Server stops accepting after 10mins
Question: does the TCP client make then break the TCP connection or just
make the TCP connection? A popular Denial of Service attack a few years
back was to automate clients making but not breaking TCP connections in
rapid fashion, with the goal to fill up the connection queue with
incomplete connections so that the server would not accept any new
connections. Most OS's since have had tunable parameters to try to
determine if such an attack is in progress and deny connections to the
perpetrator. If the clients are not terminating the connections (FIN,
FIN-ACK, ACK) properly the UUT may be seeing this as a DoS and denying
connects. Any info from the manufacturer on the kernel config for the
device?
- rick warner
On Fri, 5 Jan 2001, Steven Vacca wrote:
> Here's my problem,
>
> The Unit Under Test (UUT) has Redhat's embedded Linux kernel (based on Linux/PPC
> kernel 2.2.13), from the Redhat EDK 1.0, running on an embedded PowerPC
> processor with 8M of RAM, and is connected to a LAN.
>
> For my test, I have a TCP Client (Microsoft) on a PC, also connected to the LAN,
>connect
> to a TCP Server (linux) on the UUT at the following intervals (1/5s = "once every 5
>secs"):
> 1/5s, 1/20s, 1/30s, and 1/60s.
>
> For 1/5s, 1/20s, and 1/30s, approx. 10 minutes is the constant time when the TCP
> Client fails to connect to the Server.
>
> But, whenever the connect frequency = 1/60s, or longer, then the problem goes away
>and
> the TCP Client can connect forever at this rate.
>
> Test Results:
>
> 1/5s: stopped connecting on next try @ 10:05
>
> 1/20s: stopped connecting on nex try @ 9:40
>
> 1/30s: stopped connecting on next try @ 10:30
>
> 1/60s: connects forever (several hours in test)
>
> The fact that regardless of whether the connects occur at a very high frequency
>(100/s) or
> low frequency (1/30s), the TCP Client fails to connect after 10 mins. I think 10
>min is the key).
> So it appears that something happens once a minute, and if that goes on for 10
>times, then
> connects are denied. As long as at least 1 min is allowed to go by without
>accepting a connect
> from a client, then there is no problem.
>
> This is very repeatable. Note that if I pause the Client from connecting just
>before the 10 minute
> time period connect() failure is to occur, and wait at least 1 minute (can't be
>less), and then allow
> the Client to continue connecting, then the Client is able to connect for another 10
>minutes before
> the connect() failure occurs.
>
> So, it appears that something must be scheduled to run once per minute, and it
>somehow does
> something to the TCP Server. There aren't any background activities running tha I
>know of in this
> small-sized embedded environment.
>
> Thanks a million for anybody's help or suggestions,
>
> ShutEye Thinkin
> Roanoke, Virginia USA
>
>
>
> _______________________________________________
> Redhat-list mailing list
> [EMAIL PROTECTED]
> https://listman.redhat.com/mailman/listinfo/redhat-list
>
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
