Hello, I am hoping that this forum, that I visit quite a lot, can help me answer a question that I cannot get Google to produce.

Is there a way to view the TCP transmission control block for a particular session?

Background:

I need to find out what sequence number is being used by the remote end (FTP server) of a hung session. I need this information to craft a TCP reset packet and close a connection that is stuck in CLOSE_WAIT on the client machine.

I could run a loop to increment the sequence number by the receive window but I do not want to run the chance of doing something that may trigger a bigger issue.

The client that has this stuck connection is a Linux box that is very limited, no root privileges, and the process behind this CLOSE_WAIT is taking the CPU to 100%. In this scenario I also do not have any access to the server, so restarting the process there to try and force a TCP reset is a no go.

In the end, this is a problem with the vendors FTP client program and I am sure it will be fixed in an upcoming firmware release.... doesn't help me now though.

Thanks!

You don't give many details to work with. What kind of machine is initiating the FTP send, and what kind of machine is it connecting to? Depending on the resources you have at either end, that will make the answer different. You could run wireshark and capture those packets to examine them, or you could put a script on the server to check the FTP process and if it hits 100% usage, restart it (which would kill the errant connection).
[/QUOTE]In the end, this is a problem with the vendors FTP client program and I am sure it will be fixed in an upcoming firmware release.... doesn't help me now though.[/QUOTE]
If your vendor is as responsive as most I've dealt with, you may be waiting a good while.

Hey thanks for the response. I think the FTP server is Debian or RedHat based, I am not sure because I do not have access to it. The client, the host that has the orphaned connection, is I believe a Debian based embedded distribution. I am not to sure. I can navigate the filesystem and run some very basic BusyBox commands but that is it.

I have used tcpdump on an intermediate router but there is nothing coming from either side for this session.

I know there is some info in the /proc/net/tcp file but that does not have the SEQ/ACK numbers in use and I am hoping that there is another file in the procfs that could be of help.

Thanks!

Well, if you don't have access to the server, and only a very limited command-set on the client, you don't have many options. Given that you have only busybox on the embedded device, you may not be able to load ANYTHING on it at all, especially if you need root level access to write to devices or perform other tasks. Is the server a device you/your company owns? If so, there has to be an administrator for it, who could work with you to figure something out. Otherwise, you're at the mercy of the client/embedded vendor...because anything you load on that box may void the warranty (guessing, read your EULA).

Also, how confident are you that the problem lies in the client/embedded device? You could try a simple test by bringing up an FTP server on a machine on the same subnet, and try a connection to it, and see if the problem follows the client or not, and at least have root access to a linux box you can run tests/programs on to diagnose things further.
Not sure about that, but honestly, I've never looked.

Thanks for your time on this one! I am just going to reset the device/s and not put any more effort into this... besides pushing the vendor to get this issue resolved. Thanks again.

matak you are HF? contact me twitter.com/spellnax