>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 UTC 2004
>Closed-Date:
>Last-Modified:
>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:
>Unformatted: