* Possible conntrack/kernel bug - not catching certain ICMP packets
@ 2011-07-15 11:45 Ed W
2011-07-18 11:36 ` Ed W
0 siblings, 1 reply; 3+ messages in thread
From: Ed W @ 2011-07-15 11:45 UTC (permalink / raw)
To: Netfilter; +Cc: Jan Engelhardt, Andrew Beverley
Hi, This is related to a previous thread, but more complete problem
statement below:
I notice that I can get an ICMP packet to bypass parts of conntrack
under the following conditions
- Send a UDP packet that triggers some kind of UDP reply
- Close the listening UDP socket before that reply arrives
- Kernel generates an ICMP unreachable response which does not appear to
be tracked (as expected) by conntrack
Tested with kernel 2.6.38.4 + iptables 1.4.11.1
Reproduce this easily like so:
nslookup www.yahoo.co.uk 8.8.8.8 & sleep 0.001 && killall nslookup
(where the sleep obviously needs to be smaller than your DNS RTT
lookup time. Obviously substitute nslookup/dig as appropriate...)
My results
# conntrack -E
[NEW] udp 17 30 src=10.141.86.7 dst=8.8.8.8 sport=60721
dport=53 [UNREPLIED] src=8.8.8.8 dst=10.141.86.7 sport=53 dport=60721
[UPDATE] udp 17 29 src=10.141.86.7 dst=8.8.8.8 sport=60721
dport=53 src=8.8.8.8 dst=10.141.86.7 sport=53 dport=60721
[DESTROY] udp 17 src=10.141.86.7 dst=8.8.8.8 sport=60721 dport=53
packets=1 bytes=66 src=8.8.8.8 dst=10.141.86.7 sport=53 dport=60721
packets=1 bytes=110
# tcpdump
11:26:35.072564 IP 10.141.86.7.60721 > 8.8.8.8.domain: 2+ PTR?
8.8.8.8.in-addr.arpa. (38)
11:26:35.351804 IP 8.8.8.8.domain > 10.141.86.7.60721: 2 1/0/0 PTR
google-public-dns-a.google.com. (82)
11:26:35.352110 IP 10.141.86.7 > 8.8.8.8: ICMP 10.141.86.7 udp port
60721 unreachable, length 118
# iptables -A OUTPUT -j LOGMARK
# iptables -A OUTPUT -j LOG
Jul 15 11:26:35 localhost kern.warn kernel: [ 6676.964396] iif=0
hook=OUTPUT nfmark=0x0 secmark=0x0 classify=0x0 ctdir=ORIGINAL
ct=0xcf3d5060 ctmark=0x0 ctstate=NEW ctstatus= lifetime=6346s
Jul 15 11:26:35 localhost kern.warn kernel: [ 6676.964396] IN= OUT=ppp1
SRC=10.141.86.7 DST=8.8.8.8 LEN=66 TOS=0x00 PREC=0x00 TTL=64 ID=19971 DF
PROTO=UDP SPT=60721 DPT=53 LEN=46
Jul 15 11:26:35 localhost kern.warn kernel: [ 6677.249312] iif=0
hook=OUTPUT nfmark=0x0 secmark=0x0 classify=0x0 ctdir=ORIGINAL
ct=0xcf3d5060 ctmark=0x0 ctstate=RELATED ctstatus=SEEN_REPLY,CONFIRMED
lifetime=4294937s
Jul 15 11:26:35 localhost kern.warn kernel: [ 6677.249426] IN= OUT=ppp1
SRC=10.141.86.7 DST=8.8.8.8 LEN=138 TOS=0x00 PREC=0xC0 TTL=64 ID=18412
PROTO=ICMP TYPE=3 CODE=3 [SRC=8.8.8.8 DST=10.141.86.7 LEN=110 TOS=0x00
PREC=0x00 TTL=46 ID=3897 PROTO=UDP SPT=53 DPT=60721 LEN=90
Notice that logmark seems to show that the ctstatus on the ICMP packet
is SEEN_REPLY, but conntrack -E shows only packets=1? tcpdump shows
that the ICMP packet did indeed go out
Could someone with more knowledge of conntrack please investigate further?
Thanks
Ed W
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Possible conntrack/kernel bug - not catching certain ICMP packets
2011-07-15 11:45 Possible conntrack/kernel bug - not catching certain ICMP packets Ed W
@ 2011-07-18 11:36 ` Ed W
2011-07-18 12:16 ` Jan Engelhardt
0 siblings, 1 reply; 3+ messages in thread
From: Ed W @ 2011-07-18 11:36 UTC (permalink / raw)
To: Netfilter
Hi, any chance I could get some of the netfilter gurus to have a look at
this?
Essentially we have a reproducible situation where conntrack is
(apparently) relating a packet to a connection, but not incrementing the
connection counters?
Thanks for any help figuring out a fix?
Ed W
On 15/07/2011 12:45, Ed W wrote:
> Hi, This is related to a previous thread, but more complete problem
> statement below:
>
> I notice that I can get an ICMP packet to bypass parts of conntrack
> under the following conditions
>
> - Send a UDP packet that triggers some kind of UDP reply
> - Close the listening UDP socket before that reply arrives
> - Kernel generates an ICMP unreachable response which does not appear to
> be tracked (as expected) by conntrack
>
> Tested with kernel 2.6.38.4 + iptables 1.4.11.1
>
> Reproduce this easily like so:
>
> nslookup www.yahoo.co.uk 8.8.8.8 & sleep 0.001 && killall nslookup
>
> (where the sleep obviously needs to be smaller than your DNS RTT
> lookup time. Obviously substitute nslookup/dig as appropriate...)
>
> My results
>
> # conntrack -E
>
> [NEW] udp 17 30 src=10.141.86.7 dst=8.8.8.8 sport=60721
> dport=53 [UNREPLIED] src=8.8.8.8 dst=10.141.86.7 sport=53 dport=60721
> [UPDATE] udp 17 29 src=10.141.86.7 dst=8.8.8.8 sport=60721
> dport=53 src=8.8.8.8 dst=10.141.86.7 sport=53 dport=60721
> [DESTROY] udp 17 src=10.141.86.7 dst=8.8.8.8 sport=60721 dport=53
> packets=1 bytes=66 src=8.8.8.8 dst=10.141.86.7 sport=53 dport=60721
> packets=1 bytes=110
>
> # tcpdump
>
> 11:26:35.072564 IP 10.141.86.7.60721 > 8.8.8.8.domain: 2+ PTR?
> 8.8.8.8.in-addr.arpa. (38)
> 11:26:35.351804 IP 8.8.8.8.domain > 10.141.86.7.60721: 2 1/0/0 PTR
> google-public-dns-a.google.com. (82)
> 11:26:35.352110 IP 10.141.86.7 > 8.8.8.8: ICMP 10.141.86.7 udp port
> 60721 unreachable, length 118
>
>
> # iptables -A OUTPUT -j LOGMARK
> # iptables -A OUTPUT -j LOG
>
> Jul 15 11:26:35 localhost kern.warn kernel: [ 6676.964396] iif=0
> hook=OUTPUT nfmark=0x0 secmark=0x0 classify=0x0 ctdir=ORIGINAL
> ct=0xcf3d5060 ctmark=0x0 ctstate=NEW ctstatus= lifetime=6346s
> Jul 15 11:26:35 localhost kern.warn kernel: [ 6676.964396] IN= OUT=ppp1
> SRC=10.141.86.7 DST=8.8.8.8 LEN=66 TOS=0x00 PREC=0x00 TTL=64 ID=19971 DF
> PROTO=UDP SPT=60721 DPT=53 LEN=46
> Jul 15 11:26:35 localhost kern.warn kernel: [ 6677.249312] iif=0
> hook=OUTPUT nfmark=0x0 secmark=0x0 classify=0x0 ctdir=ORIGINAL
> ct=0xcf3d5060 ctmark=0x0 ctstate=RELATED ctstatus=SEEN_REPLY,CONFIRMED
> lifetime=4294937s
> Jul 15 11:26:35 localhost kern.warn kernel: [ 6677.249426] IN= OUT=ppp1
> SRC=10.141.86.7 DST=8.8.8.8 LEN=138 TOS=0x00 PREC=0xC0 TTL=64 ID=18412
> PROTO=ICMP TYPE=3 CODE=3 [SRC=8.8.8.8 DST=10.141.86.7 LEN=110 TOS=0x00
> PREC=0x00 TTL=46 ID=3897 PROTO=UDP SPT=53 DPT=60721 LEN=90
>
>
> Notice that logmark seems to show that the ctstatus on the ICMP packet
> is SEEN_REPLY, but conntrack -E shows only packets=1? tcpdump shows
> that the ICMP packet did indeed go out
>
> Could someone with more knowledge of conntrack please investigate further?
>
> Thanks
>
> Ed W
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Possible conntrack/kernel bug - not catching certain ICMP packets
2011-07-18 11:36 ` Ed W
@ 2011-07-18 12:16 ` Jan Engelhardt
0 siblings, 0 replies; 3+ messages in thread
From: Jan Engelhardt @ 2011-07-18 12:16 UTC (permalink / raw)
To: Ed W; +Cc: Netfilter, Netfilter Developer Mailing List
On Monday 2011-07-18 13:36, Ed W wrote:
>Hi, any chance I could get some of the netfilter gurus to have a look at
>this?
Sent it to nf-dev...
>Essentially we have a reproducible situation where conntrack is
>(apparently) relating a packet to a connection, but not incrementing the
>connection counters?
>
>Thanks for any help figuring out a fix?
>
>Ed W
>
>
>On 15/07/2011 12:45, Ed W wrote:
>> Hi, This is related to a previous thread, but more complete problem
>> statement below:
>>
>> I notice that I can get an ICMP packet to bypass parts of conntrack
>> under the following conditions
>>
>> - Send a UDP packet that triggers some kind of UDP reply
>> - Close the listening UDP socket before that reply arrives
>> - Kernel generates an ICMP unreachable response which does not appear to
>> be tracked (as expected) by conntrack
>>
>> Tested with kernel 2.6.38.4 + iptables 1.4.11.1
>>
>> Reproduce this easily like so:
>>
>> nslookup www.yahoo.co.uk 8.8.8.8 & sleep 0.001 && killall nslookup
>>
>> (where the sleep obviously needs to be smaller than your DNS RTT
>> lookup time. Obviously substitute nslookup/dig as appropriate...)
>>
>> My results
>>
>> # conntrack -E
>>
>> [NEW] udp 17 30 src=10.141.86.7 dst=8.8.8.8 sport=60721
>> dport=53 [UNREPLIED] src=8.8.8.8 dst=10.141.86.7 sport=53 dport=60721
>> [UPDATE] udp 17 29 src=10.141.86.7 dst=8.8.8.8 sport=60721
>> dport=53 src=8.8.8.8 dst=10.141.86.7 sport=53 dport=60721
>> [DESTROY] udp 17 src=10.141.86.7 dst=8.8.8.8 sport=60721 dport=53
>> packets=1 bytes=66 src=8.8.8.8 dst=10.141.86.7 sport=53 dport=60721
>> packets=1 bytes=110
>>
>> # tcpdump
>>
>> 11:26:35.072564 IP 10.141.86.7.60721 > 8.8.8.8.domain: 2+ PTR?
>> 8.8.8.8.in-addr.arpa. (38)
>> 11:26:35.351804 IP 8.8.8.8.domain > 10.141.86.7.60721: 2 1/0/0 PTR
>> google-public-dns-a.google.com. (82)
>> 11:26:35.352110 IP 10.141.86.7 > 8.8.8.8: ICMP 10.141.86.7 udp port
>> 60721 unreachable, length 118
>>
>>
>> # iptables -A OUTPUT -j LOGMARK
>> # iptables -A OUTPUT -j LOG
>>
>> Jul 15 11:26:35 localhost kern.warn kernel: [ 6676.964396] iif=0
>> hook=OUTPUT nfmark=0x0 secmark=0x0 classify=0x0 ctdir=ORIGINAL
>> ct=0xcf3d5060 ctmark=0x0 ctstate=NEW ctstatus= lifetime=6346s
>> Jul 15 11:26:35 localhost kern.warn kernel: [ 6676.964396] IN= OUT=ppp1
>> SRC=10.141.86.7 DST=8.8.8.8 LEN=66 TOS=0x00 PREC=0x00 TTL=64 ID=19971 DF
>> PROTO=UDP SPT=60721 DPT=53 LEN=46
>> Jul 15 11:26:35 localhost kern.warn kernel: [ 6677.249312] iif=0
>> hook=OUTPUT nfmark=0x0 secmark=0x0 classify=0x0 ctdir=ORIGINAL
>> ct=0xcf3d5060 ctmark=0x0 ctstate=RELATED ctstatus=SEEN_REPLY,CONFIRMED
>> lifetime=4294937s
>> Jul 15 11:26:35 localhost kern.warn kernel: [ 6677.249426] IN= OUT=ppp1
>> SRC=10.141.86.7 DST=8.8.8.8 LEN=138 TOS=0x00 PREC=0xC0 TTL=64 ID=18412
>> PROTO=ICMP TYPE=3 CODE=3 [SRC=8.8.8.8 DST=10.141.86.7 LEN=110 TOS=0x00
>> PREC=0x00 TTL=46 ID=3897 PROTO=UDP SPT=53 DPT=60721 LEN=90
>>
>>
>> Notice that logmark seems to show that the ctstatus on the ICMP packet
>> is SEEN_REPLY, but conntrack -E shows only packets=1? tcpdump shows
>> that the ICMP packet did indeed go out
>>
>> Could someone with more knowledge of conntrack please investigate further?
>>
>> Thanks
>>
>> Ed W
>> --
>> To unsubscribe from this list: send the line "unsubscribe netfilter" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>--
>To unsubscribe from this list: send the line "unsubscribe netfilter" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-07-18 12:16 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-07-15 11:45 Possible conntrack/kernel bug - not catching certain ICMP packets Ed W
2011-07-18 11:36 ` Ed W
2011-07-18 12:16 ` Jan Engelhardt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox