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 showing 5 of 9 show 4 more comments |
One Answer:
turns out it is sourcefire mangling the packets. had to tweak the policy to get it to work thank you everyone for your input answered 30 Sep '16, 08:12 tmkunte I could say I told you so, but I won't. (30 Sep '16, 10:18) Jaap ♦ |
The sourcefire device fails?
no it does not
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?
https://www.cloudshark.org/captures/00661524237a
source IP is 10.100.26.16
destination ftp server is 216.75.205.235
@tmkunte
Your "answer" has been converted to a comment as that's how this site works. Please read the FAQ for more information.
At which point, 1 or 2, in the chain
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.
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.
The
ethernet FCS badseems to me to be a Wireshark "issue" rather than a sourcefire one - in particular, a consequence of the fact that thetcpdissector stops dealing with the payload at the point of finding the brokentcp.ackvalue and reports back the processed tvb size only spanning the header up to that value. So theipdissector does the same, and theetherdissector, 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.@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.