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

alt text

see attached screenshot

my ftp downloads are failing randomly. the download starts fine and goes upto 99.9% after which it stalls for a few seconds and asks me to start the download again. I have an inline sourcefire device which is allowing traffic thru

any ideas ?

asked 29 Sep '16, 07:20

tmkunte's gravatar image

tmkunte
11223
accept rate: 0%

The sourcefire device fails?

(30 Sep '16, 04:30) Jaap ♦

no it does not

(30 Sep '16, 05:51) tmkunte

Well, I can't think of anything else based on the data provided.

Can you share a capture in a publicly accessible spot, e.g. CloudShark? Problem solving from a screenshot is a pain since all (possible relevant) details are missing.

What are the IP addresses of the nodes involved?

(30 Sep '16, 06:13) Jaap ♦

https://www.cloudshark.org/captures/00661524237a

source IP is 10.100.26.16

destination ftp server is 216.75.205.235

(30 Sep '16, 06:24) tmkunte

@tmkunte

Your "answer" has been converted to a comment as that's how this site works. Please read the FAQ for more information.

(30 Sep '16, 06:26) grahamb ♦

At which point, 1 or 2, in the chain

client --1-- sourcefire --2-- server

has the capture been taken?

You should capture at both places simultaneously to find out whether the last data segment (429 bytes total frame size) has been corrupt already by the sender or by the sourcefire box.

(30 Sep '16, 07:25) sindy

Looking at that capture reviles a lot. These last frames are totally borked, since looking at the raw bytes shows that there's FTP data, but the packet headers say there's nothing, followed by an incorrect Ethernet checksum.

Would be interesting to see if sindy's #2 capture point shows that too.

(30 Sep '16, 08:10) Jaap ♦

The ethernet FCS bad seems to me to be a Wireshark "issue" rather than a sourcefire one - in particular, a consequence of the fact that the tcp dissector stops dealing with the payload at the point of finding the broken tcp.ack value and reports back the processed tvb size only spanning the header up to that value. So the ip dissector does the same, and the ether dissector, as no payload size field exists in the Ethernet frame header, thus handles the rest of the packet as just a stuffing until the minimum frame size, and as there are still more bytes available than the minimum size, it treats them as the FCS.

(30 Sep '16, 08:29) sindy

@sindy: I don't think so, since the IP Total Length field is already reduced to only the size of the IP and TCP header (20+20 octets). The remaining Total Length - Header Length (40 - 20) worth of data is passed on the the TCP dissector. As far as the TCP dissector is concerned there is no more data.

(30 Sep '16, 10:37) Jaap ♦
showing 5 of 9 show 4 more comments

turns out it is sourcefire mangling the packets. had to tweak the policy to get it to work

thank you everyone for your input

permanent link

answered 30 Sep '16, 08:12

tmkunte's gravatar image

tmkunte
11223
accept rate: 0%

I could say I told you so, but I won't.

(30 Sep '16, 10:18) Jaap ♦
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×56

question asked: 29 Sep '16, 07:20

question was seen: 924 times

last updated: 30 Sep '16, 10:37

p​o​w​e​r​e​d by O​S​Q​A