Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Jan 2010 12:35:43 +0000
From:      Matthew Seaman <m.seaman@infracaninophile.co.uk>
To:        David Southwell <david@vizion2000.net>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: syncache_timer: errors; What do they mean?
Message-ID:  <4B4B1B1F.1010701@infracaninophile.co.uk>
In-Reply-To: <201001111051.56331.david@vizion2000.net>
References:  <201001111051.56331.david@vizion2000.net>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig166516BBCF5EB59BDA0AE750
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

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

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=20
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=
=2E
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 connec=
tion,
so if this is an attempt to spam you, it's going to be singularly ineffec=
tive.

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/=
=20
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 u=
p
given enough time.  Otherwise, a firewall rule to drop traffic from the=20
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

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


--------------enig166516BBCF5EB59BDA0AE750
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEUEAREIAAYFAktLGyYACgkQ8Mjk52CukIwi2QCWNmrbXltO1GmDtpZsJN1vczaI
EgCeKiwgMUZzWPj3+jqjFdfZMM9aml8=
=cQtw
-----END PGP SIGNATURE-----

--------------enig166516BBCF5EB59BDA0AE750--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B4B1B1F.1010701>