Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I'm observing an issue with Linux(2.3), where is not responding to a SYN after a normal close. I checked the netstat and the connection doesn't exist. That means the connection is not in FIN_WAIT or TIME_WAIT state. The client app uses the same port and ip for the connection. On of my observation is that srever accepts the connection after 2-3 minutes not before that.
What i have observed is the SYN packet is not reaching the application. Do you think of any reason? How to debug this issue.
1. Client close the connection and reopen immediately. Working fine.
2. Client close the connection and reopen it, error SYN accepted after few retransmission
"Yes, TCP/IP works on Linux 2.3" (and all current versions of Linux too, for that matter)
You've left out a lot of important information about the server, the platform, your application, and the topology.
But, in general:
1. The first SYN will be from a client trying to connect to a "well known port" (e.g. 6061)
2. The server will respond with an ACK and a SYN; the client will respond with another ACK, and the connection will be established (TCP/IP's "three-way handshake").
3. The connection will be on a *different* port (an "ephemeral port"): 6061 is just needed to *establish* the connection; it isn't monopolized for the entire duration of the connection.
4. When the connection is closed, the *ephemeral port* will be in a TIME_WAIT state for 2-3 minutes (and cannot be reused during that time).
5. But the server should generally be free to accept new connections on the "well known port" (e.g. 6061) all the while.
TCP/IP itself is almost certainly OK. There's probably something wrong with the application (the "server" accepting connections on port 6061). Look there, first. Then look at the client (the guy who's initiating the connection). Next, look at any potential firewalls (hardware or software firewalls) between the two.
Thanks for the reply. The 6061 is the client port and server port is 5061(sip-tls). The server is not using the ephemeral port. It uses the same port 5061 but with a new soscket descriptor.
I don't see a new incoming TCP connection is coming to the application. It is basically getting TCP syn on the third time. How do we find out the kernel is dropping the packet?
The system is very much idle, which doesn't have much TCP connections also.
Your client application is misbehaving. According to RFC 1323 -
B.2 Closing and Reopening a Connection
When a TCP connection is closed, a delay of 2*MSL in TIME-WAIT
state ties up the socket pair for 4 minutes (see Section 3.5 of
[Postel81]. Applications built upon TCP that close one connection
and open a new one (e.g., an FTP data transfer connection using
Stream mode) must choose a new socket pair each time.