Reset of FTP data transfer

asked 2021-04-07 09:13:34 +0000

ihamzic
1 ●1

updated 2021-04-07 14:59:24 +0000

Hi all,

I'm troubleshooting random resets happening occasionally during FTP data transfer when users are transferring mostly large video files to our FTP server which is behind a firewall.

I have made captures on user machines as well on the firewall and I think that some device on the path is resetting the data transfer based on the TTL I'm seeing in the captures.

Here is the text from reset packets since I can't seem to upload images. I removed the public IP of the server for security.

User side - packets before reset

From the FTP server

Frame 153780: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) on interface \Device\NPF_{2E0B0549-D9FE-4565-87F6-BB3B8FB3CFF7}, id 0
Ethernet II, Src: HuaweiTe_b5:d8:12 (24:31:54:b5:d8:12), Dst: 6e:57:4b:ff:b2:bd (6e:57:4b:ff:b2:bd)
Internet Protocol Version 4, Src: x.x.x.x, Dst: 192.168.8.100
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 40
    Identification: 0x69ca (27082)
    Flags: 0x40, Don't fragment
    Fragment Offset: 0
    Time to Live: 122
    Protocol: TCP (6)
    Header Checksum: 0x300f [validation disabled]
    [Header checksum status: Unverified]
    Source Address: x.x.x.x
    Destination Address: 192.168.8.100
Transmission Control Protocol, Src Port: 57013, Dst Port: 50580, Seq: 1, Ack: 136511960, Len: 0

From the client PC

Frame 153781: 1434 bytes on wire (11472 bits), 1434 bytes captured (11472 bits) on interface \Device\NPF_{2E0B0549-D9FE-4565-87F6-BB3B8FB3CFF7}, id 0
Ethernet II, Src: 6e:57:4b:ff:b2:bd (6e:57:4b:ff:b2:bd), Dst: HuaweiTe_b5:d8:12 (24:31:54:b5:d8:12)
Internet Protocol Version 4, Src: 192.168.8.100, Dst: x.x.x.x
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 1420
    Identification: 0xe80f (59407)
    Flags: 0x40, Don't fragment
    Fragment Offset: 0
    Time to Live: 128
    Protocol: TCP (6)
    Header Checksum: 0xa665 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 192.168.8.100
    Destination Address: x.x.x.x
Transmission Control Protocol, Src Port: 50580, Dst Port: 57013, Seq: 136521620, Ack: 1, Len: 1380
FTP Data (1380 bytes data)
[Setup frame: 24]
[Setup method: PASV]
[Command: STOR SLM_6519.MOV]
Command frame: 28
[Current working directory: /p]

User side - reset packet 1

Frame 153785: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) on interface \Device\NPF_{2E0B0549-D9FE-4565-87F6-BB3B8FB3CFF7}, id 0
Ethernet II, Src: HuaweiTe_b5:d8:12 (24:31:54:b5:d8:12), Dst: 6e:57:4b:ff:b2:bd (6e:57:4b:ff:b2:bd)
Internet Protocol Version 4, Src: x.x.x.x, Dst: 192.168.8.100
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 40
    Identification: 0x5f9a (24474)
    Flags: 0x40, Don't fragment
    Fragment Offset: 0
    Time to Live: 252
    Protocol: TCP (6)
    Header Checksum: 0xb83e [validation disabled]
    [Header ...

(more)

edit retag flag offensive close merge delete

add a comment

Comments

Hi. On the firewall the TCP timeout is set by default to 1 hour. The timeouts sometime happen within a minute of starting the transfer(the most extreme case I've seen only once). Usually if they happen it's around 10-15 minutes after starting the transfer.

As the users are sending the files using mobile internet using SIM cards the pattern I saw was that the slower the transfer speed the greater the chance is that it will be interrupted.

Also on my firewall when doing the troubleshooting I didn't see that the firewall or the IPS was resetting the connection(I followed the connections in the debug mode).

The one thing that stands out is the TTL when the user gets RST supposedly from the server. Usual TTL when receiving data from the server is 122(indicating that TTL is initaly set to 128) and server is ...(more)

ihamzic ( 2021-04-12 08:35:58 +0000 )edit

Can the user to a traceroute? It looks like the system sending the resets is in the provider network. Is is 3 hops away already within your network?

SYN-bit ( 2021-04-12 15:07:27 +0000 )edit

Three hops away is about halfway between the user and the FTP server so as you said somewhere in the provider network.

We will do another traceroute when we get a chance to test again to see when the drops happen if they are in the same place.

But thank you for confirming that something along the path is probably resetting the connection.

We will also try to use another provider to see if we can avoid this reset of the connection.

I will update as I get new info on the matter.

ihamzic ( 2021-04-13 08:09:00 +0000 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Reset of FTP data transfer

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Reset of FTP data transfer edit

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Reset of FTP data transfer