OK, …, so ,…., the direction indicator is the result of a pretty simple algorithm that tries
to discern who started (initiated) the flow. This is important, as the destination port,
from the perspective of the initiator, is almost always the service port, and understanding
the client / service can be pretty important .
For connectionless traffic, like UDP traffic, we can't " know " who really initiated a
request / response volley, but you can attempt to use the protocol and the port numbers
to surmise who is the requestor, and who is the responder. Argus doesn't do any of
this guessing, it tries to be as simple as possible, providing the hints in its output, so
that the client programs can make the decision. This may seem more complicated
that it should need to be, but with so many forged packets trying to beat stateful firewalls,
its important to try to determine these relationships.
What argus will do, is guarantee that the flow state, as perceived on the wire, is well
represented. So argus will always report flows where the source and destination
identifiers (IP addrs for example) are derived from the first packet observed. Argus
will also provide as many hints as it can, to help client programs change that
assignment, if needed, to report the state of a flow.
This is important, when trying to deal with flows with long idle times, asymmetric routing
situations, failure conditions, spurious packets and forged packets used for scanning.
The simple status information that netflow like flow models provide is not sufficient for
understanding the initiator of most TCP connections (masking the TCP flags together,
loses critical information), so argus tries to provide more information, to solve this
problem, and the direction indicator is the result of processing this additional information.
So, the algorithm is pretty simple. If we're working with TCP, and argus saw the SYN
or SYN_ACK flag combinations, then we've got a good idea of who initiated
the connection, and the direction indicator uses a " - " as the central character. In this
case, the arrow will point from initiator to responder / target. Other algorithms may
flip the addresses, but the error should always point from initiator (source) to target (dest).
If we haven't met these conditions, you get a " ? ", and the arrow will indicate the direction
of data. So ?> and <? are uni-directional flows, without connection setup. <?> are
bidirectional flows without connection setup.
You can do this test yourself with this filter:
tcp and (syn or synack)
For connectionless traffic, UDP for example. There will not ever be a " ? ", and the arrow
is there simply to indicate direction of traffic. " -> " and " <- " are unidirectional flows, and
" <-> " are bi-directional flows.
You can do this with filters as well:
not tcp and src pkts gt 0 and dst pkts 0
not tcp and dst pkts gt 0 and src pkts 0
not tcp and dst pkts gt 0 and src pkts gt 0
Just as examples of course.
Hope this is useful !!!!!! Don't hesitate to ask, comment, criticize whatever,
On May 25, 2012, at 6:31 PM, Matt Brown wrote:
Here is a pastebin of some of the records I am talking about:
I'm guessing, from your reply, that <? and ?> mean "I tried, some things tell me that it goes in this direction, but I'm not 52-100% sure?" Or is that 52 a 99?
This is skype traffic for sure.
Thanks for your assistance, Mark.
On Thu, May 24, 2012 at 10:33 PM, Matt Brown <matthewbrown <at> gmail.com>
I'll grab some stuff out of the DB I populated and reply to this thread.
I'm really focusing on creating a variety of macro views and trying to figure out how to consider 'dir' in those derived views.
I'm currently focused on the easy stuff as pivot points, source and destination: bytes, packet count, address and port. But I am interested in leverage other parts of the DSR as well, if they are useful. (am I using DSR right?)
I'll spend more time reviewing other threads as well as the NSMwiki, but any further examples of how people create macro views of the data, versus considering solely 'dir,' would be appreciated.
On Thu, May 24, 2012 at 9:39 PM, Mark Poepping <poepping <at> cmu.edu>
Taking a stab (trying to relieve Carter of some of the burden)…
For directionality specifically, if it’s a well-defined protocol and argus saw most (if not all) of the packets from the beginning, it will know the direction,
but there are many examples of ordinary and hybrid protocols where you won’t necessarily know the direction in all cases: peer-to-peer, ICMP, UDP can all make it hard to understand direction – or direction might not have meaning. Packet loss (esp. packet
sampling) often causes this output, and multi-path routing will ‘look like’ packet loss too, depending on where you’re watching and how your paths are advertised or have evolved over time.
On a simple, lightly loaded network (my house), long-running argus probes generally get the directionality right.
At my work, it’s not so simple so it helps to interact with questions that we have for the data and considerations of probe location and efficiency given the
Hope that helps some, it takes a little getting used to. If you have specific questions or confusions, it does help to snap a packet capture that displays
your confusion – that way others may be work with them directly and try to help you (with no explicit promises, of course).
I see the man page for ra, but it seems lacking for some DSR value output. For instance, there are somethings that aren't implicit, but appear like they should/were intended to be.
Specifically, I see this with 'dir's possible values.
The cases if confusion are <? And ?>. How can argus "not" know the direction of the transaction "sort of?"