Using tcpdump input
Carter Bullard
carter at qosient.com
Mon Mar 31 08:29:18 EST 2003
Hey Peter,
From the file you sent, Argus is reporting
the correct length as calculated from the header
values. For IP traffic, it's the length declared
in the header, plus any encapsulation.
In the two packets that you mention, tcpdump
is reporting 5 additional bytes in each that aren't
accounted for from the ethernet header length and
the IP header length together. I've confirmed this
with all the tools available to me, ethereal, argus
and tcpdump. My experience is that this is pretty
common with tcpdump. Two machines capturing from the
same hub reporting different length values for the
same packet. In all cases that I have investigated,
it was tcpdump reporting packets that are shorter than
the snaplen with a few extra bytes here or there. All
the additional bytes have had zero as the values. So
when confronted with this scenario, I tried to eliminate
the variability, since I think it's a libpcap problem.
So, argus is reporting bytes as determined from
the packet headers. Seems like the only real truth
to report?
Carter
Carter Bullard
QoSient, LLC
300 E. 56th Street
Suite 18K
New York, New York 10022
+1 212 588-9133 Phone
+1 212 588-9134 Fax
> -----Original Message-----
> From: owner-argus-info at lists.andrew.cmu.edu
> [mailto:owner-argus-info at lists.andrew.cmu.edu] On Behalf Of
> Peter Van Epp
> Sent: Monday, March 31, 2003 12:14 AM
> To: argus-info at lists.andrew.cmu.edu
> Subject: Re: Using tcpdump input
>
>
> Andrew's post motivated me to check the counts sooner
> rather than
> later, and he appears to be correct there is a bug or bugs.
> Some packets
> aren't being counted correctly and the summary looks high to
> me. A slightly
> rearranged comparison between tcpdump and ra (using argus-2.0.6.beta.8
> on FreeBSD):
>
> tcpdump (tcpdump -r test.tcpd -n -e rearranged so all flows
> are together and
> numbered 1) to 9) ):
>
>
> 1)
>
> 15:14:20.477823 0:1:f4:6:98:40 0:e0:63:38:73:50 0800 74:
> 142.58.108.10.3593 > 142.58.109.129.9100: S
> 1037685688:1037685688(0) win 6144 <mss 1460,nop,wscale
> 0,nop,nop,timestamp 2235296 0> (DF)
> 15:14:20.477853 0:e0:63:38:73:50 0:1:e6:5b:4:bd 0800 74:
> 142.58.108.10.3593 > 142.58.109.129.9100: S
> 1037685688:1037685688(0) win 6144 <mss 1460,nop,wscale
> 0,nop,nop,timestamp 2235296 0> (DF)
>
> 2)
>
> 15:14:21.478628 0:1:f4:6:98:40 0:e0:63:38:73:50 0800 74:
> 142.58.108.10.3595 > 142.58.109.128.9100: S
> 891433938:891433938(0) win 6144 <mss 1460,nop,wscale
> 0,nop,nop,timestamp 2235298 0> (DF)
> 15:14:21.478660 0:e0:63:38:73:50 8:0:9:9b:28:27 0800 74:
> 142.58.108.10.3595 > 142.58.109.128.9100: S
> 891433938:891433938(0) win 6144 <mss 1460,nop,wscale
> 0,nop,nop,timestamp 2235298 0> (DF)
> 15:14:33.497140 0:1:f4:6:98:40 0:e0:63:38:73:50 0800 74:
> 142.58.108.10.3595 > 142.58.109.128.9100: S
> 891433938:891433938(0) win 6144 <mss 1460,nop,wscale
> 0,nop,nop,timestamp 2235322 0> (DF)
> 15:14:33.497171 0:e0:63:38:73:50 8:0:9:9b:28:27 0800 74:
> 142.58.108.10.3595 > 142.58.109.128.9100: S
> 891433938:891433938(0) win 6144 <mss 1460,nop,wscale
> 0,nop,nop,timestamp 2235322 0> (DF)
>
>
> 3)
> 15:14:21.761152 0:2:55:8c:17:e9 1:0:5e:37:96:d0 0800 163:
> 142.58.109.66.1346 > 229.55.150.208.1345: udp 121
>
> 4)
> 15:14:22.023100 0:1:f4:6:98:40 0:e0:63:38:73:50 0800 62:
> 142.58.200.67 > 142.58.109.10: icmp: echo request (DF)
> 15:14:22.023231 0:1:f4:6:98:40 0:5:2:31:4c:2d 0800 62:
> 142.58.109.10 > 142.58.200.67: icmp: echo reply (DF)
>
> 5)
> 15:14:24.716709 0:2:55:8c:1a:41 1:0:5e:37:96:d0 0800 163:
> 142.58.109.71.1346 > 229.55.150.208.1345: udp 121
>
> 6)
> 15:14:25.988962 0:1:e6:5b:4:bd 0:e0:63:38:73:50 0800 62:
> 142.58.109.129.9100 > 142.58.108.10.3587: S
> 32301501:32301501(0) ack 393763605 win 11680 <mss 1460,nop,wscale 0>
>
> 7)
> 15:14:25.988972 0:e0:63:38:73:50 0:1:e6:5b:4:bd 0800 70:
> 142.58.109.254 > 142.58.109.129: icmp: net 142.58.108.10 unreachable
>
> 8)
> 15:14:32.324825 0:3:47:de:ec:c0 0:e0:18:69:72:82 0800 60:
> 142.58.109.18.139 > 142.58.109.110.3282: .
> 521147083:521147084(1) ack 3813546656 win 62987
> >>> NBT Packet
> flags=0x2
> NBT - Unknown packet type
> Type=0x2000000
> 15:14:32.324836 0:e0:18:69:72:82 0:3:47:de:ec:c0 0800 60:
> 142.58.109.110.3282 > 142.58.109.18.139: . ack 1 win 16948 (DF)
>
> 9)
> 15:14:32.324845 0:e0:18:69:72:82 ff:ff:ff:ff:ff:ff 0806 60:
> arp who-has 142.58.109.18 tell 142.58.109.110
> 15:14:32.324896 0:3:47:de:ec:c0 0:e0:18:69:72:82 0806 60: arp
> reply 142.58.109.18 is-at 0:3:47:de:ec:c0
>
> ra -r test -c -n (where test was created by argus_bpf -r
> test.tcpd -w test
> and numbered to match the tcpdump numbers from 1) to 9). Note
> the counts
> for 8) are incorrect from ra as is the summary byte number (I get only
> 1246 bytes with the corrected count not 1266 unless I have
> mis calculated):
>
>
> 30 Mar 03 19:43:38 man version=2.0 probeid=3848370891
> STA
>
> 2)
> 08 Mar 03 15:14:21 tcp 142.58.108.10.3595 ->
> 142.58.109.128.9100 4 0 296 0 REQ
>
> 5)
> 08 Mar 03 15:14:24 udp 142.58.109.71.1346 ->
> 229.55.150.208.1345 1 0 163 0 INT
>
>
> 4)
> 08 Mar 03 15:14:22 icmp 142.58.200.67 <->
> 142.58.109.10 1 1 62 62 ECO
>
> 8) **** Counts wrong! *** should be 60 and 60
> 08 Mar 03 15:14:32 tcp 142.58.109.18.139 ?>
> 142.58.109.110.3282 1 1 55 54 EST
>
> 9)
> 08 Mar 03 15:14:32 arp 142.58.109.110 who-has
> 142.58.109.18 1 1 60 60 ACC
>
> 3)
> 08 Mar 03 15:14:21 udp 142.58.109.66.1346 ->
> 229.55.150.208.1345 1 0 163 0 INT
>
> 1)
> 08 Mar 03 15:14:20 tcp 142.58.108.10.3593 ->
> 142.58.109.129.9100 2 0 148 0 REQ
>
> 6)
> 08 Mar 03 15:14:25 tcp 142.58.108.10.3587 <-
> 142.58.109.129.9100 0 1 0 62 ACC
>
> 7)
> 08 Mar 03 15:14:25 icmp 142.58.109.254 ->
> 142.58.109.129 1 0 70 0 URN
>
>
> 30 Mar 03 19:43:38 man pkts 16 bytes 1266
> drops 0 flows 0 closed 9 SHT
>
> and finally the test file (uuencoded)
>
> Peter Van Epp / Operations and Technical Support
> Simon Fraser University, Burnaby, B.C. Canada
>
>
More information about the argus
mailing list