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 Server B Windows 10 IIS V10 FTP V10.0.10586.0 Windows firewall turned off asked 01 Nov '16, 02:16  AlasdairStark edited 01 Nov '16, 04:41 |
2 Answers:
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: answered 01 Nov '16, 10:14 AlasdairStark 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 |
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:
answered 01 Nov '16, 03:30  sindy 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 ♦♦ |
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).
https://www.cloudshark.org/captures/b0dc6c1a0a69
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.