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

No ACK after SYN

0

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?

alt text

asked 23 Apr '15, 12:00

DavidFournier's gravatar image

DavidFournier
6124
accept rate: 100%

edited 23 Apr '15, 14:29

Are the checksums IP and TCP correct?

(23 Apr '15, 13:35) mrEEde

Yes TCP chcksum are correct.

-> Here is the pcapng file <-

(24 Apr '15, 08:29) DavidFournier

3 Answers:

0

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's gravatar image

DavidFournier
6124
accept rate: 100%

0

One of the following things:

  • the PC is offline
  • the local firewall of the PC blocks the request
  • a security device (e.g. firewall) between client and server blocks the request
  • an IP filter in the FTP server software blocks the request
  • the packets are lost somewhere on the way
  • One of the routers between client and server does not know a route to 192.168.100.x and drops the packet without sending any ICMP messages (or you did not capture those ICMP messages)
  • The client is using the wrong MAC address for the server (for whatever reason), if the subnet is 192.168.0.0/16

Regards
Kurt

answered 23 Apr '15, 12:33

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

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

Since WireShark sees the SYN requests, it means they have reached the PC

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

0

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.
In fact the first session in the trace is already flagged this way, maybe a problem with the port reuse detection algorithm when the initial sequence number is 0.

alt text alt text

answered 24 Apr '15, 08:43

mrEEde's gravatar image

mrEEde
3.9k152270
accept rate: 20%

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

http://www.barco.com/en/mybarco/mysupport/productsupport/documentation?productid=a42a61cc-33bd-4ed9-938a-3ee309098229

(25 Apr '15, 08:53) mrEEde