syncache_timer: errors; What do they mean?

[Matthew Seaman]

David Southwell wrote:
> Here are some example entries in /var/log/messages (server ip address removed 
> and replaced by [xxx.xxx.xxx.xxx] :
> 
> Can anyone please tell me what thses messages mean and what action (if any) I 
> should be taking.
> Thanks in advance for any replies
> Jan 11 10:41:57 dns1 kernel: TCP: [113.53.173.247]:63584 to 
> [xxx.xxx.xxx.xxx]:25; syncache_timer: Response timeout, retransmitting (1) 
> SYN|ACK
> Jan 11 10:42:01 dns1 kernel: TCP: [113.53.173.247]:63429 to 
> [xxx.xxx.xxx.xxx]:25; syncache_timer: Response timeout, retransmitting (2) 
> SYN|ACK
> Jan 11 10:42:03 dns1 kernel: TCP: [113.53.173.247]:63584 to 
> [xxx.xxx.xxx.xxx]:25; syncache_timer: Response timeout, retransmitting (2) 
> SYN|ACK
> Jan 11 10:42:13 dns1 kernel: TCP: [113.53.173.247]:63429 to 
> [xxx.xxx.xxx.xxx]:25; syncache_timer: Response timeout, retransmitting (3) 
> SYN|ACK
> Jan 11 10:42:16 dns1 kernel: TCP: [113.53.173.247]:63584 to 
> [xxx.xxx.xxx.xxx]:25; syncache_timer: Response timeout, retransmitting (3) 
> SYN|ACK
> 

What is happening is this: host 113.53.173.247 (which appears to be
somewhere in Thailand) is trying to connect to port 25 on your machine.
[I guess it's probably trying to spam you.]

Now, the very first packet sent to establish a TCP connection is known
as the 'SYN' packet -- that's because it has the Syn bit set in the 
options bitmap.  That comes from the remote system (as  it is trying to
connect to you.) Your machine is receiving that OK.

The next step is for your machine to respond, sending a SYNACK packet
back to the remote machine (Yes: you guessed it: this has both the Syn
and the Ack bits set in the packet options).  Your machine is sending
these packets off OK, but here is where it is all going horribly wrong.

Your machine never receives the 3rd packet back from the originating
machine -- which is just an ACK packet -- to say it received the response.
So it logs the message you've seen and tries again.  After a certain
number of retries, it will give up on the attempted connection, clear
out any allocated memory and go back to a quiescent state just listening
for new incoming connections.

Unless all three of these packets make it to and fro, the TCP connection
has not been properly set up.  This process is described as the "Three
way handshake" -- unless that succeeds do data can flow across the connection,
so if this is an attempt to spam you, it's going to be singularly ineffective.

Chances are, you've run into a badly configured firewall, or a broken
spam-bot, which is causing packets to disappear from the wire. It /might/ 
possibly be an attempt to DoS you by filling up various kernel memory
structures allocated to managing TCP connection state, but judging by the
time chops on the log extract you've shown, the other side would need to
be sending orders of magnitude more traffic in order to beeffective.

Given this is too low intensity to have much effect on your machine, you
can simply do nothing and ignore the log messages: it will clear itself up
given enough time.  Otherwise, a firewall rule to drop traffic from the 
offending source will help reduce the noise level.

On the vanishingly remote chance that this really is a valid SMTP peer of
yours, you'ld need to contact them out of band and try and work out where
the traffic is being blocked and what to do about it.

	Cheers,

	Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
                                                  Kent, CT11 9PW

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20100111/438269e4/signature.pgp