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

Device can retrieve file over active FTP from one server but not another

1

I am trying to get my device to retrieve a firmware upgrade over FTP from two servers. I know that the device uses active FTP but I do not have access to the source running on it so I can't get any more details about it's configuration.

I cannot understand what's going on with Server A below. I've linked to an anonymized trace of the packets for each server. While the two servers are running different versions of Windows and IIS, the setup on Server B was configured to be as close as possible to that of Server A.

Both servers are running in the same physical environment so there are no external firewalls getting in the way. Each server was assigned the identical static IP address during the test, although this is not clear in the traces since the data has been anonymized.

Server A

Windows Server 2012 R2

IIS V8.5

FTP V8.5.9600.17086

Windows firewall turned off

Packets

Server B

Windows 10

IIS V10

FTP V10.0.10586.0

Windows firewall turned off

asked 01 Nov '16, 02:16

AlasdairStark's gravatar image

AlasdairStark
21115
accept rate: 100%

edited 01 Nov '16, 04:41

As you have reduced the capture size to a minimum of 66 bytes, the contents of the ftp control session is missing i your capture file => no way to find out what happened. Please capture complete frames, at least in the failed case (better in the correct one as well while transferring a file which you don't mind to be seen by the public).

(01 Nov '16, 02:23) sindy
(01 Nov '16, 04:00) AlasdairStark

For me it seems that the Win FW is still active, as the trace is at client side and the SYN for FTPDATA didn't get a RST or SYN,ACK.

(01 Nov '16, 05:35) Christian_R

2 Answers:

0

The problem was that ECN is enabled by default on Windows Server 2012 and not Windows 10.

The device was not able to negotiate a data port with ECN enabled and therefore the transfer failed.

I turned ECN off with the following command:

netsh interface tcp set global ecncapability=disabled

See this serverfault question for more info.

answered 01 Nov '16, 10:14

AlasdairStark's gravatar image

AlasdairStark
21115
accept rate: 100%

edited 02 Nov '16, 02:01

Good to know that the ftp client does hold the data port only less than 15 seconds open.

(01 Nov '16, 10:18) Christian_R

0

In the control session, 217.196.35.149 is the TCP client, and the control session is established properly.

In the data session, the FTP server at 192.168.107.229 acts as a TCP client, but the SYN packets it sends to the FTP client are never responded.

But when you look into the parameters of the PORT command (frame 15), you'll see that the FTP client asks the FTP server to connect to a public IP address 93.186.33.66, while the FTP server sends the TCP SYN to what it can see as the remote party of the FTP control session, i.e. to 217.196.35.149.

As you say you have anonymized the original traces, you may have anonymized this one as well.

If not:

  • the FTP server may ignore the IP address from the PORT command and attempt to establish the data TCP session to the remote party of the control session because it is configured to do so, or

  • the FTP client may have two interfaces with different addresses and send the other one by mistake or due to configuration.

answered 01 Nov '16, 03:30

sindy's gravatar image

sindy
6.0k4851
accept rate: 24%

Hey Sindy, 93.186.33.66 was the actual IP, I've updated the link on the original question to try and make that less confusing. Sorry, this is the first time I've used TraceWrangler and it's difficult to achieve the correct level of obfuscation.

(01 Nov '16, 04:15) AlasdairStark

In that case, check the logs and settings of the firewall of the FTP client, as it probably doesn't permit incoming TCP connections on "high" ports. As you have removed the original captures, I cannot check whether the other FTP server uses a different local port as client one for the data TCP connection, which could explain why the FTP client's firewall treats the two cases differently.

As for TraceWrangler, I'm afraid it is not realistic to have all L4 and above protocols parsed for occurrence of L3 addresses and replace them in accord with those in L3 fields. FTP is "especially special" here as its PORT command transports the IP address as four ASCII-encoded decimal numbers.

(01 Nov '16, 05:34) sindy

TraceWrangler can't parse protocols on top of TCP right now, which includes FTP, HTTP and others. So right now it will either cut everything away, or keep it intact.

Any IP address will not be modified in those protocols on top of TCP, especially (as @sindy already mentions) not ASCII representations like FTP uses, because that will mess up sequence numbers.

(01 Nov '16, 10:51) Jasper ♦♦