This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

FTP Session Drops

0

Hi all,

Im new with Wireshark and trying to solve a problem that is failing all the time.

My setup is a Windows Vista machine that is used to communicate with 2 other nodes/computers at the same time.

Im my application im starting a FTP session toward Node1. After a while i need to communicate with Node2 also (TCP).

What i can see in Wireshark output, Node1 starts sending [TCP WINDOW UPDATE] requests after a while and after that the FTP session drops and all communication goes toward Node2.

Output when FTP drops: SOURCE: DEST:

192.168.1.140 LocalComputer TCP 66 [TCP Window Update] 20→50775 [ACK] Seq=1 Ack=18737701 Win=16048 Len=0 TSval=17 TSecr=124476481 20 50775 
192.168.1.140 LocalComputer TCP 66 [TCP Window Update] 20→50775 [ACK] Seq=1 Ack=18737701 Win=20144 Len=0 TSval=17 TSecr=124476481 20 50775
192.168.1.140 LocalComputer TCP 66 [TCP Window Update] 20→50775 [ACK] Seq=1 Ack=18737701 Win=24240 Len=0 TSval=17 TSecr=124476481 20 50775
192.168.1.140 LocalComputer TCP 66 [TCP Window Update] 20→50775 [ACK] Seq=1 Ack=18737701 Win=28336 Len=0 TSval=17 TSecr=124476481 20 50775
192.168.1.140 LocalComputer TCP 66 [TCP Window Update] 20→50775 [ACK] Seq=1 Ack=18737701 Win=32432 Len=0 TSval=17 TSecr=124476481 20 50775
-------------------- FTP Session drops here ----------------
192.168.1.144 LocalComputer TCP 260 [TCP segment of a reassembled PDU] 80 50789
192.168.1.144 LocalComputer TCP 1514 [TCP segment of a reassembled PDU] 80 50789
192.168.1.144 LocalComputer TCP 1514 [TCP segment of a reassembled PDU] 80 50789
LocalComputer 192.168.1.144 TCP 54 50789→80 [ACK] Seq=171 Ack=1667 Win=64240 Len=0 50789 80

Other things i can see in output are STP from 3COM Switch:

3comEuro40:54:9e Spanning-tree-(for-bridges)00 STP 64 RST. Root = 32768/0/40:01:c6:40:54:9a Cost = 0 Port = 0x8003 [ETHERNET FRAME CHECK SEQUENCE INCORRECT]

Red marked fields:

LocalComputer 192.168.1.144 TCP 54 50789→80 [RST, ACK] Seq=172 Ack=9288 Win=0 Len=0 50789 80
192.168.1.144 LocalComputer TCP 60 80→50789 [ACK] Seq=9288 Ack=172 Win=33580 Len=0 80 50789
LocalComputer 192.168.1.144 TCP 54 50789→80 [RST] Seq=172 Win=0 Len=0 50789 80

I have tried changing some settings on local NIC but with no success. Also have set adaptive tcp window to off (Hoping it will use full tcp window) using netsh.

Any help would be much appreciated!

BR Jimmie

asked 09 Feb '15, 23:49

Seven47's gravatar image

Seven47
6113
accept rate: 0%

edited 09 Feb '15, 23:56

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245

Some update..

Just tried to set "netsh int tcp set global autotuninglevel=normal"

This resulted in FTP session lasted approx. 80% of the file transfer until it dropped. Before, when it was set to disabled, it lasted about 15% before it dropped..

Coinsidence?

(10 Feb '15, 00:10) Seven47

One Answer:

0

From this data alone it cannot be determined why you have session drops, you need at least the timestamps so that a guess can be made about timeouts. Also, did the transfer go well before the Window Updates? Was there any packet between 192.168.1.140 and LocalComputer after the point where you say "-------------------- FTP Session drops here ----------------"

If you can supply a capture file (on Cloudshark for instance), that would be great. You can anonimize the file with TraceWrangler if you need to remove the ip addresses and/or the TCP payload of the packets.

answered 10 Feb '15, 00:02

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

Wow.. Fast answer there SYN-bit! Thanks!

I will supply a capture file in a moment.

(10 Feb '15, 00:12) Seven47

Hi again,

It seems Cloudshark can only take 2MB of file, Mine is 45MB..

And it seems it was only coinsidence that i reach 80%.. I just tried it again and it failed at 15% with the new tcpwindow setting..

Also, did the transfer go well before the Window Updates? No, it has always dropped FTP session even before i messed with tcpwindow size.

Was there any packet between 192.168.1.140 and LocalComputer after the point where you say "-------------------- FTP Session drops here ----------------"

No, after that the FTP session is lost completely. No more traffic between 192.168.1.140 and LocalComputer.

BR Jimmie

(10 Feb '15, 00:28) Seven47

alt text

alt text

alt text

(10 Feb '15, 00:39) Seven47

(please use comments instead of new answers, that works better on this QA site :-))

Can you at least post the command session (traffic on port 21)? And maybe the past 100 or so packets of the data session?

How long does the transfer take? Do you see traffic in the command session at the time the data transfer stops? I have seen situations where a firewall would kill the command due to a timeout while the transfer in the data session is happily sending packets.

(10 Feb '15, 00:39) SYN-bit ♦♦

Sorry, will use comment instead :)

(10 Feb '15, 00:55) Seven47

I have a window progress bar that are showing the transfer and i can see that it "freezes" right about when IP .140 sends [TCP WINDOW UPDATE].. It takes about 2 minutes after FTP session has started when it drops. I also see some [TCP Window Full] FTP Data: 1200 bytes that localhost sends to .140

(10 Feb '15, 00:58) Seven47

In the control channel in frame 32084, you can see that the remote server issues a "421 service not available" error. This forces the client to close the (control) session with a "QUIT". However, the data transfer seems to continue. It looks like it finishes in 54304, as this is a non-full-sized frame. Can you check if the file that you were sending is 18737701 bytes in size? If it is, the file is indeed fully sent to the server, but as the control channel was closed, it will nog be (properly) processed.

The question is, why does the server issue a 421 error after accepting the upload. Is there a file size limit perhaps (how many bytes were sent in the data channel right before this 421 error was sent?) or maybe a timelimit for sending files?

(10 Feb '15, 01:22) SYN-bit ♦♦

This application runs in 2 threads but if i manually only run the thread where FTP is used towards .140 then there is no FTP session drops. So the server, (140) should then not have any file size restrictions. The file is 18737700 on server and client so it seems it has transferred it completely. Maybe there is a timelimit for files to be transferred and when Localhost is "talking" to both Nodes, the limit for a big file to be transferred is reached?

(10 Feb '15, 02:38) Seven47

please upload the pcap file somewhere (google drive, dropbox, cloudshark.org). It's really hard to troubleshoot a complex issue with screenshots that don't match. The port used in the Window update screenshot does not match the port used in the last FTP PORT command that generated the error 421!

It seems Cloudshark can only take 2MB of file, Mine is 45MB..

then please use google drive, dropbox, mega.co.nz or any other file hosting service and post the link here.

(10 Feb '15, 02:59) Kurt Knochner ♦

Why are we fixing Windows Vista problems? How is this a Wireshark use issue?

(10 Feb '15, 05:11) Jaap ♦
1

Why are we fixing Windows Vista problems? How is this a Wireshark use issue?

Good question.

I guess these questions are beeing asked because the general perception of the Q&A site is

  • Wireshark "issues"
  • Wireshark usage questions
  • general questions about protocols (TCP behaviour)
  • general questions about network troubleshooting with or without using Wireshark

As far as I can see, the community so far has tried to answer all of these question categories and denied help only if the question was totally off-topic.

The FAQ states:

What kinds of questions can I ask here?
Questions should be relevant to Wireshark features, protocol analysis, or Wireshark development.

protocol analysis is a wide field and can include almost anything, maybe even FTP problems.

Regards
Kurt

(10 Feb '15, 05:28) Kurt Knochner ♦

In your trace, the client (.14) closes other FTP data transfers with a FIN on the last DATA packet. But in the failing transfer, there is no FIN in the last DATA packet (frame 54191). So it looks like the FTP client (or library) needs some polishing...

(10 Feb '15, 05:38) SYN-bit ♦♦

Umm.. I didnt say this was a Wireshark issue. I just said that i was new to Wireshark and was using it to find out why my FTP session was dropped. Since asking for that was "Illegal" im very sorry and i appologise. I will of course uninstall wireshark immediately and find another software to use instead.

Anyways, thank you SYN-bit for being kind and actually trying to help out.

(10 Feb '15, 07:02) Seven47

Kurt and I don't think it was so illegal, so feel free to stay and continue this issue. Jaap is trying to protect the QA site which is good, but I think he was a little too strict this time :-)

(10 Feb '15, 07:11) SYN-bit ♦♦

@Seven47: please relax. You are getting help, aren't you?

(10 Feb '15, 07:51) Kurt Knochner ♦
showing 5 of 16 show 11 more comments