All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roberto Nibali <ratz@tac.ch>
To: Netfilter Developers <netfilter-devel@lists.netfilter.org>
Cc: chris@tac.ch
Subject: Re: strange INVALID SYN in ip_conntrack (tcp window tracking enabled) in 2.4.27 kernel
Date: Fri, 17 Dec 2004 13:01:13 +0100	[thread overview]
Message-ID: <41C2CA89.2040007@tac.ch> (raw)
In-Reply-To: <Pine.LNX.4.58.0412171215330.26459@blackhole.kfki.hu>

Hello,

>>I just wanted to know if this is a known feature of the conntrack code. When I
>>issue a local redirect ssh command, I get an ACCEPT followed by an INVALID on
>>the SYN packet but the connection still works (kernel 2.4.27).
>>
>># /foobar/bin/sshc www@172.23.139.11 -o BatchMode=yes -2 -q -f -N -p 2345 -R
>>1513:127.0.0.1:1514
>>
>># tail -f /var/log/kernlog
>>Dec 17 11:18:41 s_int@foobar tfx3: fw-tcp2fw [110] a:ACCEPT s:NEW
>>f:INPUT IN=eth0 OUT= SRC=172.23.139.20 DST=172.23.139.11 DF PROTO=TCP SPT=1059
>>DPT=2345 SYN
>>Dec 17 11:18:41 s_int@foobar ip_conntrack_tcp: INVALID: invalid SYN
>>(ignored) SRC=172.23.139.20 DST=172.23.139.11 DF PROTO=TCP SPT=1059 DPT=2345
>>SYN OPT (020405B40402080A0085041F0000000001030300)
> Please dump the traffic and send the corresponding log lines. (It seems to
> be a retransmitted SYN, which is harmless.)

foobar:~# grep DPT=2345 /var/log/kernlog | tail -2
Dec 17 12:40:49 s_int@foobar tfx3: fw-tcp2fw [110] a:ACCEPT s:NEW
f:INPUT IN=eth0 OUT= SRC=172.23.139.20 DST=172.23.139.11 DF PROTO=TCP SPT=1040
DPT=2345 SYN
Dec 17 12:40:49 s_int@foobar ip_conntrack_tcp: INVALID: invalid SYN
(ignored) SRC=172.23.139.20 DST=172.23.139.11 DF PROTO=TCP SPT=1040 DPT=2345
SYN OPT (020405B40402080A00007E750000000001030300)

foobar:~# tcpdump -nvi eth0 port 2345 and tcp #edited for ledgibility
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 68 bytes

12:40:49.907439 IP (tos 0x0, ttl  64, id 59607, offset 0, flags [DF], length:
60) 172.23.139.20.1040 > 172.23.139.11.2345: S 1063163554:1063163554(0) win
5840 <mss 1460,sackOK,timestamp 32373[|tcp]>

#SYN 172.23.139.20.1040 > 172.23.139.11.2345

12:40:49.907583 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], length: 60)
172.23.139.11.2345 > 172.23.139.20.1040: S 1491192392:1491192392(0) ack
1063163555 win 5792 <mss 1460,sackOK,timestamp 9210436[|tcp]>

#SYN/ACK 172.23.139.11.2345 > 172.23.139.20.1040

12:40:49.907443 IP (tos 0x0, ttl  64, id 59607, offset 0, flags [DF], length:
60) 172.23.139.20.1040 > 172.23.139.11.2345: S 1063163554:1063163554(0) win
5840 <mss 1460,sackOK,timestamp 32373[|tcp]>

#SYN 172.23.139.20.1040 > 172.23.139.11.2345

12:40:49.907748 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], length: 60)
172.23.139.11.2345 > 172.23.139.20.1040: S 1491192392:1491192392(0) ack
1063163555 win 5792 <mss 1460,sackOK,timestamp 9210436[|tcp]>

#SYN/ACK 172.23.139.11.2345 > 172.23.139.20.1040

12:40:49.908559 IP (tos 0x0, ttl  64, id 59608, offset 0, flags [DF], length:
52) 172.23.139.20.1040 > 172.23.139.11.2345: . [tcp sum ok] ack 1 win 5840
<nop,nop,timestamp 32373 9210436>

#ACK 172.23.139.20.1040 > 172.23.139.11.2345

12:40:49.908562 IP (tos 0x0, ttl  64, id 59608, offset 0, flags [DF], length:
52) 172.23.139.20.1040 > 172.23.139.11.2345: . [tcp sum ok] ack 1 win 5840
<nop,nop,timestamp 32373 9210436>

#ACK 172.23.139.20.1040 > 172.23.139.11.2345

[repeat ad nauseum]

foobar:~# ping 172.23.139.11
PING 172.23.139.11 (172.23.139.11): 56 data bytes
64 bytes from 172.23.139.11: icmp_seq=0 ttl=64 time=0.963 ms
64 bytes from 172.23.139.11: icmp_seq=0 ttl=64 time=1.343 ms (DUP!)
64 bytes from 172.23.139.11: icmp_seq=0 ttl=64 time=1.609 ms (DUP!)
64 bytes from 172.23.139.11: icmp_seq=0 ttl=64 time=1.704 ms (DUP!)
--- 172.23.139.11 ping statistics ---
1 packets transmitted, 1 packets received, +3 duplicates, 0% packet loss
round-trip min/avg/max = 0.963/1.404/1.704 ms
taclog-central:~#

D'oh, I feel kind of stupid now. I should have looked closer at the tcpdump 
output. Thanks for helping me engaging my brain. We set up a cluster on VMWare 
GSX and configure multiple secondary IP addresses on the same virtual bridge.

> That path covers multiple cases and the comment refers to ignored SYN/ACK
> packets :-) .

True.

> You can't be in sNO state: if the assumption is valid (i.e. that's a
> resent SYN) then the connection is in sSR or above.

Of course it's in sSR, I was just being mentally slow. Unfortunately I've got to 
debug on so many things right now that my brain stack flushes every 10 minutes.

Best regards,
Roberto Nibali, ratz
-- 
-------------------------------------------------------------
addr://Rathausgasse 31, CH-5001 Aarau  tel://++41 62 823 9355
http://www.terreactive.com             fax://++41 62 823 9356
-------------------------------------------------------------
terreActive AG                       Wir sichern Ihren Erfolg
-------------------------------------------------------------

      reply	other threads:[~2004-12-17 12:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-17 11:07 strange INVALID SYN in ip_conntrack (tcp window tracking enabled) in 2.4.27 kernel Roberto Nibali
2004-12-17 11:32 ` Jozsef Kadlecsik
2004-12-17 12:01   ` Roberto Nibali [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41C2CA89.2040007@tac.ch \
    --to=ratz@tac.ch \
    --cc=chris@tac.ch \
    --cc=netfilter-devel@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.