Argus handling of bad checksums?

[Peter Van Epp]

	I suspect the right (but possibly difficult) answer is to fix the 
anonymization program to write correct checksums in the anonimized data.
Vern Paxton has a policy driven anonymization tool although I can't find a
reference in a quick search (and I don't know if it corrects the checksums
but I expect it will).
	If (as it appears) you have unanonymized and anonymized pcap files
feed both of them to wireshark and compare the outputs. I'd expect wireshark
to have similar problems to argus with bad header lengths and the hex dumps
of the packet streams should tell you where the errors are. That may point to
a problem with the anonymization program. 
	In the general case of checksum errors, I expect the only place it 
can be done is on the ethernet card. Argus doesn't get the complete packet 
and thus can only check the header checksums not the data check sum. I don't
think bpf passes crc error information with the pcap data (although I could
be wrong).

Peter Van Epp

On Wed, Aug 12, 2009 at 10:38:37PM -0400, Carter Bullard wrote:
> Hey Steven,
> I suspect that the packet header lengths are incorrect, and that is  
> causing argus
> some problems.  Send me a copy of the anonymized file, and I'll try to  
> figure
> out what is going on.  Upload to ftp://qosient.com/incoming.
>
> Carter
>
> On Aug 12, 2009, at 6:46 PM, Steven DiBenedetto wrote:
>
>> We know for sure that we have large number of packets with bad  
>> checksums caused by an anonymizating tool we use to capture traffic.  
>> In this case, we have a trace in the libpcap format which we are  
>> feeding through Argus for processing.
>>
>> Recently, we have discovered Argus produces different results when  
>> given a normal pcap trace and its anonymized counterpart. Some packets 
>> seem to be missing in the argus file generated by anonymized trace 
>> generated by racount. We are currently running argus-3.0.1.beta.3 and 
>> argus-clients-3.0.2.beta.10.
>>
>> Here's an example comparison with Argus:
>>
>> $ argus -S 1000 -r checksum_test.pcap -w checksum_test.argus
>>
>> $ argus -S 1000 -r anon_checksum_test.pcap -w anon_checksum_test.argus
>>
>> argus[13711]: 12 Aug 09 16:32:54.547458 ArgusNewFlow() flow key is not 
>> correct len equals zero
>> argus[13711]: 12 Aug 09 16:32:54.584273 ArgusNewFlow() flow key is not 
>> correct len equals zero
>> argus[13711]: 12 Aug 09 16:32:54.584438 ArgusNewFlow() flow key is not 
>> correct len equals zero
>>
>>
>> $ racount -r checksum_test.argus
>>
>> racount   records     total_pkts     src_pkts       dst_pkts  
>> total_bytes       		src_bytes          dst_bytes
>> sum	24386       200000         137572         62428		177236752          
>> 170786494          6450258
>>
>> $ racount -r anon_checksum_test.argus
>>
>> racount   records     total_pkts     src_pkts       dst_pkts  
>> total_bytes        src_bytes          dst_bytes
>> sum   	24382       199994         137568         62426 177236392        
>>   170786254          6450138
>>
>>
>> Also, the actual number of packets in the example trace is exactly  
>> 100,000 despite it showing up as twice that in total packets count.
>>
>> -Steve
>>
>> On Aug 12, 2009, at 3:33 PM, Carter Bullard wrote:
>>
>>> Hey Steven,
>>> Currently we don't check for bad checksum's.  It is such a rare  
>>> event and expensive
>>> to check. Do you think you're getting bad checksums?
>>>
>>> Carter
>>>
>>> On Aug 12, 2009, at 4:40 PM, Steven DiBenedetto wrote:
>>>
>>>> Hi Carter,
>>>>
>>>> How does Argus handle packets with a bad IP checksum?
>>>>
>>>> -Steve
>>>>
>>>
>>
>>
>