argus 3 - direction determination algorithm - bug!!!! Fixed!!!!

[Carter Bullard]

Hey John,
The new clients I uploaded Tues had a very bad bug, where for some
TCP flows the timestamps would be removed.  I've fixed this and uploaded
a new argus-clients-3.0.3.6.tar.gz to the server.  Please get that for any
testing that you will be doing.

   http://qosient.com/argus/dev/argus-clients-3.0.3.6.tar.gz

Sorry for any inconvenience!!!

Carter

On Apr 6, 2010, at 8:23 PM, Carter Bullard wrote:

> Hey John,
> I've uploaded a new argus-clients-3.0.3.6.tar.gz to the developers site
> that fixes your direction problem.  The clients make all the "override"
> decisions on direction, and I added some more tests for the TCP syn/synAck
> decisions.  I also added better weights for the destination port number when
> there is no Syn or SynAck, and at least one of the ports is IPPORT_RESERVED,
> < 1024.
> 
> Give this a run, and if you're having problems, holler!!!!
> 
> Carter
> 
> On Apr 6, 2010, at 4:40 PM, Carter Bullard wrote:
> 
>> Hey John,
>> The reset is probably negating some other logic, so let me take a look, and
>> check it out.
>> 
>> All the logic is already in the client library, so you don't have to do anything,
>> at least that is the design ;o)
>> 
>> Carter
>> 
>> On Apr 6, 2010, at 4:11 PM, John Gerth wrote:
>> 
>>> On 4/6/2010 12:58 PM, Carter Bullard wrote:
>>>> Hey John,
>>>> In argus-3.0, we removed most of the direction logic out of argus, and moved
>>>> it into the clients, just for this very situation.  argus-2.x would declare that the
>>>> originator of a SYN_ACK packet was the destination, regardless of what was
>>>> going on, and we put a lot of complex logic in the clients to try to deal with
>>>> that when it was a A.SYN_ACK / B.RESET volley.
>>>> 
>>>> You should be getting that A is the source, now, and that B is the destination.
>>>> If that is not correct, then, could you send some flow records that demonstrate
>>>> the problem, so I can debug?  Better yet, if you had a packet capture, then
>>>> I can debug the whole flow thread.  I'll look around for a packet trace, maybe
>>>> on 
>>>> 
>>> Attached is an extract done with:
>>>    ra -r ar-2010-04-06.12 -w ~/win/synack.argus - host 69.16.172.40 and port 6667
>>> It shows that most of the S/A are src'ed remotely but whenever there's an R, ra
>>> shows it the other way.  It's conceivable that this is our fault if somehow the
>>> span ports are dumping things down incorrectly (I don't have bi-directional timing
>>> turned on), but this seems oddly consistent.
>>> 
>>> I do not have a pcap as I found this out afterwards and we normally just record flows.
>>> 
>>> If clients are supposed to do the direction determination, I guess I should plan
>>> on fixing mine up and will want to know what rules you normally use in your clients.
>>> 
>>> -- 
>>> John Gerth      gerth at cs.stanford.edu  Gates 378   (650) 725-3273  fax 723-0033
>>> <synack.argus.gz>
>> 
>> 
>> 
> 
> 
> 

Carter Bullard
CEO/President
QoSient, LLC
150 E 57th Street Suite 12D
New York, New York  10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3815 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20100408/a5bde873/attachment.bin>