NetBSD Problem Report #25796
Received: (qmail 6185 invoked by uid 605); 3 Jun 2004 10:45:56 -0000
Message-Id: <20040603104553.DDA6C11152@narn.netbsd.org>
Date: Thu, 3 Jun 2004 10:45:53 +0000 (UTC)
From: arto@selonen.org
Sender: gnats-bugs-owner@NetBSD.org
Reply-To: arto@selonen.org
To: gnats-bugs@gnats.NetBSD.org
Subject: tcpdump does not show all packets on gif(4)
X-Send-Pr-Version: www-1.0
>Number: 25796
>Category: bin
>Synopsis: tcpdump does not show all packets on gif(4)
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: bin-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Jun 03 10:46:01 +0000 2004
>Closed-Date:
>Last-Modified: Sun Apr 26 19:51:36 +0000 2009
>Originator: Arto Selonen
>Release: NetBSD-current w/ sources ca. May 31st 2004
>Organization:
>Environment:
NetBSD blah 2.0F NetBSD 2.0F (BLAH) #40: Tue Jun 1 11:57:37 EEST 2004 blah@blah:/obj/sys/arch/i386/compile/BLAH i386
>Description:
While capturing packet traces for another problem (kern/25087) I noticed
that tcpdump output of a gif interface was not showing the same amount
of packets that I was expecting to see. Specifically, there is a
transport mode IPSEC tunnel between the problem system and another one:
W<->(fxp1)GWD(fxp0)->(gif0)<==IPSEC==>(gif0)<-(ep0)GWS(ex0)<->CL
The problem system is GWD, and the problem traffic is CL making
a HTTP request to W. tcpdump is run on GWD for both fxp0 and gif0.
This is how gif0 is defined on GWD
# cat /etc/ifconfig.gif0
create
tunnel <ip-of-fxp0> <ip-of-ep0>
10.0.0.1 10.0.0.2 netmask 0xfffffffc
This is what /etc/ifconfig.fxp0 looks like on GWD:
<ip-of-fxp0> netmask 255.255.255.240 media auto
link0
# tcpdump -vvvi fxp0 -s 1500
11:25:00.283368 GWS > GWD: AH(spi=0x00000995,sumlen=16,seq=0x14d4e56): ESP(spi=0x00000994,seq=0x14d4e56) (ttl 19, id 30042, len 132)
11:25:00.283820 GWD > GWS: AH(spi=0x00000993,sumlen=16,seq=0x192a):
ESP(spi=0x00000992,seq=0x192a) (ttl 30, id 47924, len 132)
11:25:00.291760 GWS > GWD: AH(spi=0x00000995,sumlen=16,seq=0x14d4e57):
ESP(spi=0x00000994,seq=0x14d4e57) (ttl 19, id 30044, len 116)
11:25:00.333793 GWS > GWD: AH(spi=0x00000995,sumlen=16,seq=0x14d4e58):
ESP(spi=0x00000994,seq=0x14d4e58) (ttl 19, id 30046, len 1364)
11:25:00.526469 GWD > GWS: AH(spi=0x00000993,sumlen=16,seq=0x192b):
ESP(spi=0x00000992,seq=0x192b) (ttl 30, id 47935, len 116)
11:25:00.542197 GWS > GWD: AH(spi=0x00000995,sumlen=16,seq=0x14d4e59):
ESP(spi=0x00000994,seq=0x14d4e59) (ttl 19, id 30053, len 1364)
11:25:00.542409 GWS > GWD: AH(spi=0x00000995,sumlen=16,seq=0x14d4e5a):
ESP(spi=0x00000994,seq=0x14d4e5a) (ttl 19, id 30054, len 532)
11:25:00.542837 GWD > GWS: AH(spi=0x00000993,sumlen=16,seq=0x192c):
ESP(spi=0x00000992,seq=0x192c) (ttl 30, id 47936, len 116)
Due to checksum issues the HTTP transaction is not complete; the above
is as far as it gets before being stuck (that is kern/25087).
The problem with tcpdump is that since all the above packets go through
gif0, and this is the tcpdump output:
# tcpdump -vvvi gif0 -s 1500
11:25:00.283764 W.www > 10.0.0.2.52192: S [tcp sum ok] 1255747952:1255747952(0) ack 306725568 win 61440 <mss 1460,nop,wscale 0> (ttl 59, id 3466, len 48)
11:25:00.526408 W.www > 10.0.0.2.52192: . [tcp sum ok] 1:1(0) ack 1241 win 61440 (ttl 59, id 3558, len 40)
11:25:00.542808 W.www > 10.0.0.2.52192: . [tcp sum ok] 1:1(0) ack 2889 win 61440 (ttl 59, id 3565, len 40)
It only shows responses from W back to CL (which appears as 10.0.0.2,
since it is mapped by NAT in GWS to be from GWS; should not affect
tcpdump on GWD).
Why are there no packets from 10.0.0.2 in the gif0 tcpdump output?
Is tcpdump choosing not to show them for some reason, or is it the kernel hiding them?
>How-To-Repeat:
I have not tested with other systems whether this is simply related
to tcpdump/gif, or if there are other factors present (both systems run
ipfilter, both systems have internal systems behind them, there is
some NAT present on both ends to hide some internal systems, etc).
>Fix:
>Release-Note:
>Audit-Trail:
From: Arto Selonen <arto@selonen.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: re: bin/25796
Date: Tue, 20 Jul 2004 14:12:30 +0300 (EEST)
Hi!
'netstat -i' only reports output packets for the gif(4) interface (at both
ends of the connection). Furthermore, this seems to be related to just
the gif interface used for the IPSEC transport mode tunnel setup,
ie. other IPv4 gif-based tunnels seem to work OK.
Maybe this is a kernel bug? Traffic seems to flow both ways just fine,
but it is only accounted one way (output).
Artsi
--
#######======------ http://www.selonen.org/arto/ --------========########
Everstinkuja 5 B 35 Don't mind doing it.
FIN-02600 Espoo arto@selonen.org Don't mind not doing it.
Finland tel +358 50 560 4826 Don't know anything about it.
From: Arto Selonen <arto@selonen.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: re: bin/25796
Date: Tue, 20 Jul 2004 14:06:06 +0300 (EEST)
Hi!
Box upgraded to 2.0G with anoncvs-fi mirror sources from ~20040719.
No change; tcpdump only shows one direction of the gif(4) traffic.
Artsi
--
#######======------ http://www.selonen.org/arto/ --------========########
Everstinkuja 5 B 35 Don't mind doing it.
FIN-02600 Espoo arto@selonen.org Don't mind not doing it.
Finland tel +358 50 560 4826 Don't know anything about it.
From: Arto Selonen <arto@selonen.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: tech-net@netbsd.org
Subject: Re: kern/25796 (IPSEC traffic is not for the receiver to see)
Date: Wed, 18 Aug 2004 12:31:36 +0300 (EEST)
Hi!
I've been trying to look at the source code to see why kern/25796
occurs, and even with my *very limited* understanding of the inner
workings of the IP stack, I think tcpdump (and friends) is not allowed
to see any traffic that used to be IPSEC encapsulated.
The part of code that I've been looking at is src/sys/netinet/ip_input.c,
specifically this part:
#ifdef PFIL_HOOKS
/*
* Run through list of hooks for input packets. If there are any
* filters which require that additional packets in the flow are
* not fast-forwarded, they must clear the M_CANFASTFWD flag.
* Note that filters must _never_ set this flag, as another filter
* in the list may have previously cleared it.
*/
/*
* let ipfilter look at packet on the wire,
* not the decapsulated packet.
*/
#ifdef IPSEC
if (!ipsec_getnhist(m))
#elif defined(FAST_IPSEC)
if (!ipsec_indone(m))
#else
if (1)
#endif
which was introduced on revision 1.127 on January 24th, 2001, so it is
not new. It may be related to threads 'ipsec after nat', 'ipsec/tunnel for
private spaces' on tech-net on January 2001. Message by itojun on
tech-net announced it in 'ipsec/ipf interaction change'. I also
understand, that the change was done to fix some real problem, so I'm not
too keen to try to locally reverse that, either. What could I expect to
break if I tried it the old way?
I then read the following web page, that confirmed my interpretation
at least partially:
http://www.netbsd.org/Documentation/network/ipsec/#ipf-interaction
So, since the traffic was at some point IPSEC-protected, it may not
be shown to tcpdump, and friends? Sounds weird, but it explains
this PR, so I guess this is not a bug, and this PR could be changed
to a feature request. I think one should be able to see the traffic
one receives. :)
Personally, I can't figure out why ipf should not be allowed to mess
with decapsulated data, provided that it shows up on another interface,
like gif. That would allow one to write rules to filter the traffic
properly, yet it would also guarantee that the packet was not spoofed,
since to make it to gif, it would have had to be properly processed
by the IPSEC stage (provided that the gif tunnel was properly configured).
Or am I just missing something obvious?
Of course, it would be much better if ipfilter (and friends) were
ipsec-aware, so they could be allowed access to the packets just as
they were prior to January 24th, 2001. Or, something like
http://mail-index.netbsd.org/tech-net/2001/01/13/0008.html might
take place?
A totally separate issue is the gif interface incoming statistics.
I can't understand why they don't get updated. Should that be filed
as a separate PR, or is it related to the same design that caused
kern/25796 ?
Artsi
--
#######======------ http://www.selonen.org/arto/ --------========########
Everstinkuja 5 B 35 Don't mind doing it.
FIN-02600 Espoo arto@selonen.org Don't mind not doing it.
Finland tel +358 50 560 4826 Don't know anything about it.
From: Arto Selonen <arto@selonen.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/25796 (no change after upgrade)
Date: Thu, 30 Sep 2004 13:19:59 +0300 (EEST)
Hi!
Box upgraded on 20040929 from whatever sources anoncvs-fi mirror gave
at the time. Quick testing with the new tcpdump version still shows
only outgoing traffic on the IPSEC-used gif-interface.
In other words: still does not work.
Artsi
--
#######======------ http://www.selonen.org/arto/ --------========########
Everstinkuja 5 B 35 Don't mind doing it.
FIN-02600 Espoo arto@selonen.org Don't mind not doing it.
Finland tel +358 50 560 4826 Don't know anything about it.
From: Arto Selonen <arto@selonen.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/25796 (still there)
Date: Thu, 25 Nov 2004 10:03:58 +0200 (EET)
Hi!
Box upgraded on 20041123 with whatever sources anoncvs-fi mirror gave.
tcpdump still shows only outgoing traffic on the gif interface.
'netstat -I gif0' only shows non-zero counters for outgoing traffic.
Artsi
--
#######======------ http://www.selonen.org/arto/ --------========########
Everstinkuja 5 B 35 Don't mind doing it.
FIN-02600 Espoo arto@selonen.org Don't mind not doing it.
Finland tel +358 50 560 4826 Don't know anything about it.
From: Arto Selonen <arto@selonen.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/25796 (problem remains)
Date: Wed, 2 Feb 2005 09:33:29 +0200 (EET)
Hi!
All NetBSD-current systems related to producing the problem in this PR
have been upgraded to 2.99.1x, yet the problem remains. No incoming
traffic is seen with tcpdump, no incoming traffic counters are incremented
for the gif interface.
Artsi
--
#######======------ http://www.selonen.org/arto/ --------========########
Everstinkuja 5 B 35 Don't mind doing it.
FIN-02600 Espoo arto@selonen.org Don't mind not doing it.
Finland tel +358 50 560 4826 Don't know anything about it.
From: Arto Selonen <arto@selonen.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/25796 (still there)
Date: Tue, 26 Apr 2005 13:02:37 +0300 (EEST)
Hi!
Box upgraded with whatever sources anoncvs-us2 mirror gave on 20050421.
Tcpdump still shows only outgoing traffic on the gif interface.
'netstat -I gif0' only shows non-zero counters for outgoing traffic.
So, no change here.
Artsi
PS. It would be nice to have a user-feedback-request, so that eventually
there was also some feedback from the other end as well, and not just
from the reporting user. It's been ~10 months now, and nobody has
acknowledge this in any way.
--
#######======------ http://www.selonen.org/arto/ --------========########
Everstinkuja 5 B 35 Don't mind doing it.
FIN-02600 Espoo arto@selonen.org Don't mind not doing it.
Finland tel +358 50 560 4826 Don't know anything about it.
From: Arto Selonen <arto@selonen.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/25796 (still there)
Date: Tue, 25 Apr 2006 09:44:08 +0300 (EEST)
Hi!
Box upgraded with whatever sources anoncvs.netbsd.org gave on
20060420. Tcpdump still shows only outgoing traffic on the gif interface.
'netstat -I gif0' only shows non-zero counters for outgoing traffic.
So, no change here.
Artsi
--
#######======------ http://www.selonen.org/arto/ --------========########
Everstinkuja 5 B 35 Don't mind doing it.
FI-02600 Espoo arto@selonen.org Don't mind not doing it.
Finland tel +358 50 560 4826 Don't know anything about it.
Responsible-Changed-From-To: bin-bug-people->pavel
Responsible-Changed-By: pavel@netbsd.org
Responsible-Changed-When: Sun, 02 Jul 2006 11:01:06 +0000
Responsible-Changed-Why:
I would like to look at it one day.
Responsible-Changed-From-To: pavel->bin-bug-people
Responsible-Changed-By: spz@NetBSD.org
Responsible-Changed-When: Sun, 26 Apr 2009 19:51:36 +0000
Responsible-Changed-Why:
pavel resigned, reassign back to default
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.