Using tcpdump input
Peter Van Epp
vanepp at sfu.ca
Mon Mar 31 11:01:15 EST 2003
Sounds like a reasonable explaination. I didn't have the sniffer on
the wire to see what it thought. I'll see if I can arrange a test like that
and get the problem from the tcpdump output and confirm the problem is libpcap
(or tcpdump).
Peter Van Epp / Operations and Technical Support
Simon Fraser University, Burnaby, B.C. Canada
On Mon, Mar 31, 2003 at 08:29:18AM -0500, Carter Bullard wrote:
> 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