Definition of filter fin and finack
Nick Diel
nick at engineerity.com
Wed Aug 27 17:54:59 EDT 2008
Carter,
As always, thanks for the info. I have a couple more questions.
First, most of my fin packets (from the source who initiated the teardown)
also have the ack bit set. So I was a little confused when you said that
the fin means a packet with onlythe fin bit set. I don't know what the RFC
says, I just know the vast majority of my packets are this way (and I have
billions of them).
I did just a couple of tests where I tested a flow that is complete
(syn-synack-data-fin-finack). Then tested one with just a fin packet and
finally one with just the first fin and the ack for it. Based on the
results it appears as if fin means the fin bit was set, while finack seems
to mean a fin was acknowledged. I can't put src or dst in front of finack
to completey test this theory as I get a syntax error.
The results are below, hopefully you can shed some light onto what I am
missing.
Thanks,
Nick
First I test a complete flow in argus:
tcpdump -r singleCompleteFlow.pcap
reading from file singleCompleteFlow.pcap, link-type EN10MB (Ethernet)
09:36:54.772992 IP 1.1.1.1.14713 > 2.2.2.2.pop3: S 2565614892:2565614892(0)
win 64512 <mss 1460,nop,nop,sackOK>
09:36:54.789305 IP 2.2.2.2.pop3 > 1.1.1.1.14713: S 2137176771:2137176771(0)
ack 2565614893 win 49640 <mss 1460,nop,nop,sackOK>
09:36:54.789395 IP 1.1.1.1.14713 > 2.2.2.2.pop3: . ack 1 win 64512
09:36:55.917052 IP 2.2.2.2.pop3 > 1.1.1.1.14713: P 1:56(55) ack 1 win 49640
....
09:36:56.442469 IP 2.2.2.2.pop3 > 1.1.1.1.14713: P 216:230(14) ack 55 win
49640
09:36:56.443141 IP 2.2.2.2.pop3 > 1.1.1.1.14713: F 230:230(0) ack 55 win
49640
09:36:56.443227 IP 1.1.1.1.14713 > 2.2.2.2.pop3: . ack 231 win 64283
09:36:56.479347 IP 1.1.1.1.14713 > 2.2.2.2.pop3: F 55:55(0) ack 231 win
64283
09:36:56.493103 IP 2.2.2.2.pop3 > 1.1.1.1.14713: . ack 56 win 49640
ra -r singleCompleteFlow.argus - fin
09:36:54.772992 e tcp 1.1.1.1.14713 ->
2.2.2.2.pop3 23 1571 FIN
ra -r singleCompleteFlow.argus - src fin
09:36:54.772992 e tcp 1.1.1.1.14713 ->
2.2.2.2.pop3 23 1571 FIN
ra -r singleCompleteFlow.argus - dst fin
09:36:54.772992 e tcp 1.1.1.1.14713 ->
2.2.2.2.pop3 23 1571 FIN
ra -r singleCompleteFlow.argus - finack
09:36:54.772992 e tcp 1.1.1.1.14713 ->
2.2.2.2.pop3 23 1571 FIN
Here I test the same flow, but with only the first fin packet.
tcpdump -r singleF.pcap
reading from file singleCompleteFlow.pcap, link-type EN10MB (Ethernet)
09:36:54.772992 IP 1.1.1.1.14713 > 2.2.2.2.pop3: S 2565614892:2565614892(0)
win 64512 <mss 1460,nop,nop,sackOK>
09:36:54.789305 IP 2.2.2.2.pop3 > 1.1.1.1.14713: S 2137176771:2137176771(0)
ack 2565614893 win 49640 <mss 1460,nop,nop,sackOK>
09:36:54.789395 IP 1.1.1.1.14713 > 2.2.2.2.pop3: . ack 1 win 64512
09:36:55.917052 IP 2.2.2.2.pop3 > 1.1.1.1.14713: P 1:56(55) ack 1 win 49640
....
09:36:56.442469 IP 2.2.2.2.pop3 > 1.1.1.1.14713: P 216:230(14) ack 55 win
49640
09:36:56.443141 IP 2.2.2.2.pop3 > 1.1.1.1.14713: F 230:230(0) ack 55 win
49640
ra -r singleF.argus - fin
09:36:54.772992 e tcp 1.1.1.1.14713 ->
2.2.2.2.pop3 20 1403 FIN
ra -r singleF.argus - src fin
(no results as expected)
ra -r singleF.argus - dst fin
09:36:54.772992 e tcp 1.1.1.1.14713 ->
2.2.2.2.pop3 20 1403 FIN
ra -r singleF.argus - finack
(no results as expected)
Next I test a flow that only has the first half of the tcp teardown (initial
fin and ack of the fin).
tcpdump -r singleFA.pcap
reading from file singleCompleteFlow.pcap, link-type EN10MB (Ethernet)
09:36:54.772992 IP 1.1.1.1.14713 > 2.2.2.2.pop3: S 2565614892:2565614892(0)
win 64512 <mss 1460,nop,nop,sackOK>
09:36:54.789305 IP 2.2.2.2.pop3 > 1.1.1.1.14713: S 2137176771:2137176771(0)
ack 2565614893 win 49640 <mss 1460,nop,nop,sackOK>
09:36:54.789395 IP 1.1.1.1.14713 > 2.2.2.2.pop3: . ack 1 win 64512
09:36:55.917052 IP 2.2.2.2.pop3 > 1.1.1.1.14713: P 1:56(55) ack 1 win 49640
....
09:36:56.442469 IP 2.2.2.2.pop3 > 1.1.1.1.14713: P 216:230(14) ack 55 win
49640
09:36:56.443141 IP 2.2.2.2.pop3 > 1.1.1.1.14713: F 230:230(0) ack 55 win
49640
09:36:56.443227 IP 1.1.1.1.14713 > 2.2.2.2.pop3: . ack 231 win 64283
ra -r singleFA.argus - fin
09:36:54.772992 e tcp 1.1.1.1.14713 ->
2.2.2.2.pop3 21 1457 FIN
ra -r singleFA.argus - src fin
(no results as expected)
ra -r singleFA.argus - dst fin
09:36:54.772992 e tcp 1.1.1.1.14713 ->
2.2.2.2.pop3 21 1457 FIN
ra -r singleFA.argus - finack
09:36:54.772992 e tcp 1.1.1.1.14713 ->
2.2.2.2.pop3 21 1457 FIN
Nick
On Wed, Aug 27, 2008 at 12:46 PM, Carter Bullard <carter at qosient.com> wrote:
> Hey Nick,
> Fin means that we saw a TCP packet with only the fin bit set. It doesn't
> excude
> that other states were seen, it just means that we did see a proper FIN
> packet.
>
> Finack means that we saw a TCP packet with only the fin and the ack bit
> set,
> so we know that there appears to be a proper response to a FIN packet.
>
> If you put "src" or "dst" in front of a TCP flag keyword, you aren't asking
> about
> TCP states, you're just asking for the occurrence of the bit being set in
> any packet
> observed by the flow record. For example this filter:
>
> "src \( fin and ack\)"
>
> is not the same as
>
> "finack"
>
> In the first filter, the fin and the ack bits are not related, in that,
> they could
> have occurred in different packets. The "finack" filter requires that a
> packet
> with the fin and ack were seen or'd in the same packet. This is much
> different
> that what you see with Netflow, or any other flow data.
>
> Carter
>
>
> On Aug 27, 2008, at 12:45 PM, Nick Diel wrote:
>
> A quick question as I work on a paper. For the filters "fin" and
>> "finack", do each one represent one half of the 3-way tear down. For
>> example, does "fin" mean that argus saw the first fin and saw the ACK for
>> this fin? And on the other side, does "finack" mean that argus saw the
>> second fin and saw the ACK for this fin? Or does a complete teardown in
>> terms of fin and finack filters look like this: (src fin and dst finack) and
>> (dst fin and src finack)?
>>
>> I want to make sure I get my defitions right for a paper.
>>
>> Thanks,
>> Nick
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20080827/1f5256e4/attachment.html>
More information about the argus
mailing list