Firewall question

We have a cisco asa here and we are having issues ftp'ing from one site.

We can download from other sites without issue, just not one. When we
try from this one, the file downloads until the last few bytes, then
the ftp session times out and the file is 'corrupt'. Doesn't matter
how big or small the file is.

If we download via ftp from this site on a connection not behind our
asa, things download fine.

Any suggestions on what to check?

--
Stevo

Tags:

Parents
  • A colleague of mine ran into a similar symptom recently. (And if you ended up opening a SR with SUSE, it may have well been your case.) But anyway, in the case I heard about, at the end of a FTP file transfer, the last few bytes would be absent and so the file was essentially corrupt.

    In that case, he discovered that some packet fragmentation and reassembly was not occurring correctly. That, in combination with the very primitive way the FTP signals that the file is done, caused the file to be considered "ended" prematurely.

    FTP signals end-of-file by putting a FIN in the packet. (Remember that FTP transfers files on a separate connection from the main FTP control connection, so a FIN on the data connection doesn't end the whole session.) But what if your final packet of file data was in a packet of size 3000 that came from a OS or network that could handle that size, but then went through a router (or NIC doing segmentation offloading) than had to break it into 2 packets of 1500? That entity doing the fragmentation would create 2 packets and would have to be make sure to put the FIN *only* in the second of those packets.

    In my colleague's case, the device doing the fragmentation made the mistake of putting the FIN in the first fragment. By doing so, it caused the receiving side to believe that end-of-file was reached, and anything contained in the second fragment would be lost.

    You can catch this kind of thing by looking at a packet trace from the perspective of the receiving side of the file transfer. Examine the last few packets, their sequence numbers, and which one contains the FIN. If the FIN comes before the final data (by packet sequence number, not necessary by arrival time) then my above description fits. If this is indeed happening, the hard part may be tracking down what device is building the bad fragment (i.e. putting the FIN in a fragment other than the last one.) Sometimes a machine using segmentation offloading is responsible (where the NIC is in charge of segmentation instead of the OS). On linux, segmentation offloading is one of many offloadings that can be controlled with ethtool -K.
Reply
  • A colleague of mine ran into a similar symptom recently. (And if you ended up opening a SR with SUSE, it may have well been your case.) But anyway, in the case I heard about, at the end of a FTP file transfer, the last few bytes would be absent and so the file was essentially corrupt.

    In that case, he discovered that some packet fragmentation and reassembly was not occurring correctly. That, in combination with the very primitive way the FTP signals that the file is done, caused the file to be considered "ended" prematurely.

    FTP signals end-of-file by putting a FIN in the packet. (Remember that FTP transfers files on a separate connection from the main FTP control connection, so a FIN on the data connection doesn't end the whole session.) But what if your final packet of file data was in a packet of size 3000 that came from a OS or network that could handle that size, but then went through a router (or NIC doing segmentation offloading) than had to break it into 2 packets of 1500? That entity doing the fragmentation would create 2 packets and would have to be make sure to put the FIN *only* in the second of those packets.

    In my colleague's case, the device doing the fragmentation made the mistake of putting the FIN in the first fragment. By doing so, it caused the receiving side to believe that end-of-file was reached, and anything contained in the second fragment would be lost.

    You can catch this kind of thing by looking at a packet trace from the perspective of the receiving side of the file transfer. Examine the last few packets, their sequence numbers, and which one contains the FIN. If the FIN comes before the final data (by packet sequence number, not necessary by arrival time) then my above description fits. If this is indeed happening, the hard part may be tracking down what device is building the bad fragment (i.e. putting the FIN in a fragment other than the last one.) Sometimes a machine using segmentation offloading is responsible (where the NIC is in charge of segmentation instead of the OS). On linux, segmentation offloading is one of many offloadings that can be controlled with ethtool -K.
Children
No Data