argus-clients-3.0.0.rc.20

Peter Van Epp vanepp at sfu.ca
Tue Aug 1 11:21:32 EDT 2006


On Tue, Aug 01, 2006 at 02:35:22AM -0400, Carter Bullard wrote:
> Hey Peter,
> The parser->ArgusConvBuffer is used to build a TLV structure, and  
> ArgusGenerateRecordStruct
> parses the TLV and generates the argus record.  The ArgusConvBuffer  
> can have any amount of
> garbage in it, and not cause a problem, as long as the TLV is being  
> generated properly.
> By zeroing out the appropriate values in the  
> ArgusGenerateRecordStruct routine buffer,
> all the values should be initialized to zero, each time.
> 
> So this is the output that my ra() generates for the two files you  
> attached on a big endian machine.
> 
> ../bin/ra -r ~/Desktop/badtcp.argus -s +sipid +dipid -n
>         StartTime            Flgs   Proto      SrcAddr         
> Sport   Dir      DstAddr        Dport  SrcPkts  DstPkts      
> SrcBytes     DstBytes State   sIpId   dIpId
> 06/06/27 14:20:28.835259  v          tcp       
> 142.58.64.150.4074      ?>     216.239.57.104.80           24         
> 0         5227            0   FIN  0xa4ef
> 06/06/27 14:21:15.514446  v          tcp      
> 216.239.57.104.80        ?>      142.58.64.150.4074         13         
> 0         6178            0   FIN  0x7972
> 
> 
> ../bin/ra -r ~/Desktop/badtcp2.argus -s +sipid +dipid -n
>         StartTime            Flgs   Proto      SrcAddr         
> Sport   Dir      DstAddr        Dport  SrcPkts  DstPkts      
> SrcBytes     DstBytes State   sIpId   dIpId
> 06/06/27 14:20:28.834986  v          udp      142.58.250.27.2049      
> <->     142.58.249.237.800       20760    19989      4521068       
> 3178714   CON          0x0000
> 06/06/27 14:20:28.835259  v          tcp       
> 142.58.64.150.4074      ?>     216.239.57.104.80           24         
> 0         5227            0   FIN  0xa4ef
> 06/06/27 14:20:30.103319  v          udp     142.58.249.237.800       
> <->      142.58.250.27.2049      19976    20746      3176652       
> 4518840   CON          0xb9c4
> 06/06/27 14:21:15.514446  v          tcp      
> 216.239.57.104.80        ?>      142.58.64.150.4074         13         
> 0         6178            0   FIN  0x7972
> 
> 
> And here are the to files on a little endian machine:
> ../bin/ra -r /tmp/badtcp.argus -s +sipid +dipid -n
>         StartTime            Flgs   Proto      SrcAddr         
> Sport   Dir      DstAddr        Dport  SrcPkts  DstPkts      
> SrcBytes     DstBytes State   sIpId   dIpId
> 06/06/27 14:20:28.835259  v          tcp       
> 142.58.64.150.4074      ?>     216.239.57.104.80           24         
> 0         5227            0   FIN  0xa4ef
> 06/06/27 14:21:15.514446  v          tcp      
> 216.239.57.104.80        ?>      142.58.64.150.4074         13         
> 0         6178            0   FIN  0x7972
> 
> ../bin/ra -r /tmp/badtcp2.argus -s +sipid +dipid -n
>         StartTime            Flgs   Proto      SrcAddr         
> Sport   Dir      DstAddr        Dport  SrcPkts  DstPkts      
> SrcBytes     DstBytes State   sIpId   dIpId
> 06/06/27 14:20:28.834986  v          udp      142.58.250.27.2049      
> <->     142.58.249.237.800       20760    19989      4521068       
> 3178714   CON          0x0000
> 06/06/27 14:20:28.835259  v          tcp       
> 142.58.64.150.4074      ?>     216.239.57.104.80           24         
> 0         5227            0   FIN  0xa4ef
> 06/06/27 14:20:30.103319  v          udp     142.58.249.237.800       
> <->      142.58.250.27.2049      19976    20746      3176652       
> 4518840   CON          0xb9c4
> 06/06/27 14:21:15.514446  v          tcp      
> 216.239.57.104.80        ?>      142.58.64.150.4074         13         
> 0         6178            0   FIN  0x7972
> 
> 
> one thing puzzles me.  why are your flows unidirectional?  shouldn't  
> these be tallied
> as bidirectional flows?
> 
> Do you see a problem with the new ra output above (at least for ipid?).
> 
> Carter
>

	My bad for not providing enough details. While I'll try rc.21 in a 
while, I think this may not fix this problem. What is happening is the 
conversion buffer doesn't get cleared, and if there aren't any dst packets
(as in this case) but were dest packets in the last record, the count in the
dsr doesn't get cleared and the dst ttl, tos and ipid values get printed
when they shouldn't be (because there are no dst packets in this case):
	In this case ra3 is without the bzero of the buffer and ra3.new is 
with the bzero:

	here the first record correctly omits the dst tos, ttl and ipid fields
because there are not dest packets (this flow is single arm routed back on 
to the same network which is why the flow doesn't combine I expect, the MACs 
are different): 

%cd /var/log/argus
%ra3 -Fra3.conf.full -r badtcp.argus
StartTime,LastTime,Trans,Dur,AvgDur,SrcAddr,DstAddr,Proto,Sport,Dport,sTos,dTos,sTtl,dTtl,SrcBytes,DstBytes,SAppBytes,DAppBytes,SrcPkts,DstPkts,Src_bps,Dst_bps,Src_pps,Dst_pps,SrcLoss,DstLoss,SrcId,Flgs,SrcMac,DstMac,Dir,SrcJitter,DstJitter,State,srcUdata,dstUdata,SrcWin,DstWin,Seq,sMpls,dMpls,sVlan,dVlan,sIpId,dIpId
1151432428.835259,1151432550.587752,1,121.752493,121.752495,142.58.64.150,216.239.57.104,tcp,4074,80,0,,128,,5227,0,3835,0,24,0,343.451,0.000,0.197,0.000,0,0,229.97.122.203, v       ,0:13:ce:6:e2:bf,0:11:88:5:5d:1d,?>,,16163523.00,FIN,s[16]="GET /pagead/imga",,17520,0,8695,,,0x0286,,0xa4ef,
1151432475.514446,1151432550.585041,1,75.070595,75.070595,216.239.57.104,142.58.64.150,tcp,80,4074,0,,255,,6178,0,5424,0,13,0,658.367,0.000,0.173,0.000,0,0,229.97.122.203, v       ,0:11:88:5:5d:1d,0:13:ce:6:e2:bf,?>,,3601074.00,FIN,s[16]="HTTP/1.1 200 OK.",,8190,0,23380,,,0x0286,,0x7972,

	In this case there is a packet with both source and dest packets 
preceding the packet above. Because the conversion buffer wasn't cleared it
still has src and dst counts in the dsr and thus prints dst ttl tos and ipid
even though there aren't any dest packets. It gets the counts correctly from 
somewhere else in the record though so it does know there aren't any dst 
packets and the perl script flags the change in dst fields as wrong. 

%ra3 -Fra3.conf.full -r badtcp2.argus
StartTime,LastTime,Trans,Dur,AvgDur,SrcAddr,DstAddr,Proto,Sport,Dport,sTos,dTos,sTtl,dTtl,SrcBytes,DstBytes,SAppBytes,DAppBytes,SrcPkts,DstPkts,Src_bps,Dst_bps,Src_pps,Dst_pps,SrcLoss,DstLoss,SrcId,Flgs,SrcMac,DstMac,Dir,SrcJitter,DstJitter,State,srcUdata,dstUdata,SrcWin,DstWin,Seq,sMpls,dMpls,sVlan,dVlan,sIpId,dIpId
1151432428.834986,1151433529.662031,1,1100.827045,1100.827026,142.58.250.27,142.58.249.237,udp,2049,800,0,0,64,64,4521068,3178714,2499724,2259220,20760,19989,32855.793,23100.553,18.859,18.158,0,0,229.97.122.203, v       ,0:2:b3:d8:98:6e,0:11:88:5:5d:1d,<->,,,CON,s[16]="fx..............",d[16]="gx..............",,,14,,,0x8200,0x8200,0x0000,0x0000
1151432428.835259,1151432550.587752,1,121.752493,121.752495,142.58.64.150,216.239.57.104,tcp,4074,80,0,0,128,64,5227,0,3835,0,24,0,343.451,0.000,0.197,0.000,0,0,229.97.122.203, v       ,0:13:ce:6:e2:bf,0:11:88:5:5d:1d,?>,,16163523.00,FIN,s[16]="GET /pagead/imga",,17520,0,8695,,,0x0286,,0xa4ef,0x0000
1151432430.103319,1151433529.662021,1,1099.558702,1099.558716,142.58.249.237,142.58.250.27,udp,800,2049,0,0,63,63,3176652,4518840,2257756,2498140,19976,20746,23112.195,32877.480,18.167,18.868,0,0,229.97.122.203, v       ,0:11:88:5:5d:1d,0:2:b3:d8:98:6e,<->,,,CON,s[16]="px..............",d[16]="px..............",,,1,,,0x8200,0x8200,0xb9c4,0xb9c4
1151432475.514446,1151432550.585041,1,75.070595,75.070595,216.239.57.104,142.58.64.150,tcp,80,4074,0,0,255,63,6178,0,5424,0,13,0,658.367,0.000,0.173,0.000,0,0,229.97.122.203, v       ,0:11:88:5:5d:1d,0:13:ce:6:e2:bf,?>,,3601074.00,FIN,s[16]="HTTP/1.1 200 OK.",,8190,0,23380,,,0x0286,,0x7972,0xb9c4

	With the buffer cleared (which may well be overkill, only parts of it
need to be done) both cases work correctly. I chose to clear the whole buffer
to make sure there weren't any less obvious cases that were going to bite us. 

%ra3.new -Fra3.conf.full -r badtcp2.argus
StartTime,LastTime,Trans,Dur,AvgDur,SrcAddr,DstAddr,Proto,Sport,Dport,sTos,dTos,sTtl,dTtl,SrcBytes,DstBytes,SAppBytes,DAppBytes,SrcPkts,DstPkts,Src_bps,Dst_bps,Src_pps,Dst_pps,SrcLoss,DstLoss,SrcId,Flgs,SrcMac,DstMac,Dir,SrcJitter,DstJitter,State,srcUdata,dstUdata,SrcWin,DstWin,Seq,sMpls,dMpls,sVlan,dVlan,sIpId,dIpId
1151432428.834986,1151433529.662031,1,1100.827045,1100.827026,142.58.250.27,142.58.249.237,udp,2049,800,0,0,64,64,4521068,3178714,2499724,2259220,20760,19989,32855.793,23100.553,18.859,18.158,0,0,229.97.122.203, v       ,0:2:b3:d8:98:6e,0:11:88:5:5d:1d,<->,,,CON,s[16]="fx..............",d[16]="gx..............",,,14,,,0x8200,0x8200,0x0000,0x0000
1151432428.835259,1151432550.587752,1,121.752493,121.752495,142.58.64.150,216.239.57.104,tcp,4074,80,0,,128,,5227,0,3835,0,24,0,343.451,0.000,0.197,0.000,0,0,229.97.122.203, v       ,0:13:ce:6:e2:bf,0:11:88:5:5d:1d,?>,,16163523.00,FIN,s[16]="GET /pagead/imga",,17520,0,8695,,,0x0286,,0xa4ef,
1151432430.103319,1151433529.662021,1,1099.558702,1099.558716,142.58.249.237,142.58.250.27,udp,800,2049,0,0,63,63,3176652,4518840,2257756,2498140,19976,20746,23112.195,32877.480,18.167,18.868,0,0,229.97.122.203, v       ,0:11:88:5:5d:1d,0:2:b3:d8:98:6e,<->,,,CON,s[16]="px..............",d[16]="px..............",,,1,,,0x8200,0x8200,0xb9c4,0xb9c4
1151432475.514446,1151432550.585041,1,75.070595,75.070595,216.239.57.104,142.58.64.150,tcp,80,4074,0,,255,,6178,0,5424,0,13,0,658.367,0.000,0.173,0.000,0,0,229.97.122.203, v       ,0:11:88:5:5d:1d,0:13:ce:6:e2:bf,?>,,3601074.00,FIN,s[16]="HTTP/1.1 200 OK.",,8190,0,23380,,,0x0286,,0x7972,

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada



More information about the argus mailing list