Differentiating between arp requests and arp replies inargus records

[Carter Bullard]

Hey Kevin,
Argus does have a bi-directional flow model for arp, and it works great for me.  If you have a packet file that has arps in it that don't seem to work, then send them on, and I'll take a look.

Argus's flow model for arp has all the information that you are looking for, I believe.  If you get an arp reply without a request, you should see "is-at" instead of "who".  Of course, this is assuming that it works.

Capture a file of arp packets from your machine an we'll see if it is really broken!!!

Carter


Carter Bullard
QoSient LLC
150 E. 57th Street Suite 12D
New York, New York 10022
+1 212 588-9133 Phone
+1 212 588-9134 Fax

-----Original Message-----
From: Kevin & Leah Branch <klkbranch at hotmail.com>

Date: Thu, 10 Jan 2008 20:54:56 
To:<argus-info at lists.andrew.cmu.edu>
Subject: [ARGUS] Differentiating between arp requests and arp replies in
 argus records


I'm running the January 2008 argus-3.0.0 and ra-clients-3.0.0.rc.67

I'm not sure how argus intends to handle arp packets, since they aren't exactly IP traffic.  In my environments at least, argus does not pair up an arp request and its reply into a single argus record, but actually I think I like that since it preserves more details of the arp traffic.  Given this fact, it does seem funny to me that at times when there are clusters of repeated identical arp-requests, that argus will create a single record for them.  In that case argus sets the record as having many source packets, which makes sense.  However, I have never seen an argus arp record with more than zero destination bytes.  I guess arp conversations aren't being treated as stateful but blabbering of identical arp requests does get aggregated into single r

My main question about argus and arps, though, is how am I to tell the requests from the replies?

Here is an example ra output of an arp request and its reply

ra -r arps.arg -s +dpkts -L0
         StartTime    Flgs  Proto            SrcAddr  Sport   Dir            DstAddr  Dport  TotPkts   TotBytes State  DstPkts
   15:15:38.515522  e         arp         172.18.0.1          who        172.18.4.90               1         60   INT        0
   15:15:38.515841  e         arp         172.18.0.1          who        172.18.4.90               1         60   INT        0

They look the same to me.  In fact, the only way I can tell which is which is by looking at the mac addresses
         StartTime    Flgs  Proto            SrcAddr  Sport   Dir            DstAddr  Dport  TotPkts   TotBytes State  DstPkts             SrcMac             DstMac
   15:15:38.515522  e         arp         172.18.0.1          who        172.18.4.90               1         60   INT        0   0:10:db:1b:1d:80          Broadcast
   15:15:38.515841  e         arp         172.18.0.1          who        172.18.4.90               1         60   INT        0   0:11:43:19:6d:13   0:10:db:1b:1d:80

The record with the broadcast dest mac is the request and the one with the unicast dest mac is the reply.  That's fairly predictable, unless you think someone is arp poisoning you.  If you're researching arp shenanigans, this isn't so clear. 

I was just wondering if there might be some way to disambiguate arp requests from arp replies.  Maybe instead of giving all arp packtets, be they requests or replies, the direction attribute of "who", that attribute could be "who" for request and "is-at" for replies or something like that?  Or perhaps there is some other record attribute I'm just missing that would clears this all up for me.

Many thanks for any input you all can give,
Kevin


----------------
Watch “Cause Effect,” a show about real people making a real difference. Learn more