I have a hardware unit (192.168.98.1) and a PC (192.168.100.100). The unit contains a FTP client, trying to connect an FTP server on the PC. The unit sends a SYN command, but this command is never answered by the PC. The PC is running Windows XP. Any idea why? Is there any log in the PC to determine if the SYN is received and decoded?
asked 23 Apr '15, 12:00  DavidFournier edited 23 Apr '15, 14:29 |
3 Answers:
Problem solved: the issue was on the client side. The 2 padding bytes of the SYN packet's TCP header were corrupted and contained 0x64 0x64 instead of 0x00 0x00 or 0xFF 0xFF. answered 28 Apr '15, 11:26 DavidFournier |
One of the following things:
Regards answered 23 Apr '15, 12:33  Kurt Knochner ♦ edited 23 Apr '15, 12:34 Hi Kurt, thanks for your help. The unit and the PC are connected through a router, locally, but none of them are connected to a large 'network' (internet, intranet, etc..). Since WireShark sees the SYN requests, it means they have reached the PC, right? So the packets are not dropped, or lost. (23 Apr '15, 12:43) DavidFournier
That's only the case if you cpatured on the PC! If that's true, then it's either the local firewall or any other IP filter including endpoint security software or a filter in the FTP server software itself. BTW: Is the PC multi-homed, meaning: Does it have multiple interfaces? (23 Apr '15, 12:45) Kurt Knochner ♦ Indeed the capture is done on the PC. Also, the PC is multi-homed, but 2 out of the 3 interfaces are disabled to avoid interface confusion. Only the concerned one is enabled. Are there any known implicit system IP filters? The local firewall is disabled, just so you know. Thanks again. (23 Apr '15, 13:06) DavidFournier The connection establishment process is handled by the kernel. The FTP server process does not know that a SYN packet has been received. When connection establishment is complete, the FTP listener is notified by the kernel that a connection has been established. So if the FTP server was blocking the IP address we would see: SYN SYN/ACK ACK RESET If the FTP daemon/process is not running, the SYN packet should be responded to with a RESET. (23 Apr '15, 14:46) Jim Aragon |
The SYNs are probably discarded because the 'real' initial sequence number is zero. Also : The urgent pointer field is nonzero while the URG flag is not set What a strange TCP stack .. The "tcp port numbers reused" flag is a bug in wireshark. The client port numbers are incrementing, 5001 then 5002.
answered 24 Apr '15, 08:43  mrEEde edited 25 Apr '15, 08:28 Hi mrEEde. Is there a way to force the PC (Windows? Firewall?) to accept these packets, even if the sequence number is zero, and urgent pointer is nonzero? (24 Apr '15, 08:50) DavidFournier I doubt that there is a way to accept those. There has been good reasons to use random initial sequence numbers. CERT Advisory CA-2001-09 Statistical Weaknesses in TCP/IP Initial Sequence Numbers http://www.cert.org/advisories/CA-2001-09.html So letting these connections in would impose a security risk ... What kind of hardware unit is this ? If this is a Barco iCon H600 the problem might be fixed in INFOT V1.25 ... • ftp client hanging is solved (25 Apr '15, 08:53) mrEEde |
Are the checksums IP and TCP correct?
Yes TCP chcksum are correct.
-> Here is the pcapng file <-