Argus 3.0.2 unable to remember the direction of a connection
Cees
celzinga at gmail.com
Wed Feb 9 09:43:27 EST 2011
Hello list,
I encountered a strange bug in Argus where Argus is unable to remember the
direction of a connection.
At first the direction is correct, but half-way through the session Argus
'forgets' the direction.
I managed to create a test case, see the attachments.
correct.pcap contains a TCP session of 52 packets between 172.16.12.165 port
1051 and 192.168.234.166 port 8080
test-case.pcap contains the same session, but with two additional packets on
port 1058. In the original PCAP the packets were part of a complete session,
but these two packets are enough to confuse Argus.
Packet 21:
15:55:10.283193 IP 192.168.234.166.8080 > 172.16.12.165.1058: Flags [P.],
seq 1142777472:1142777806, ack 3607727599, win 65535, length 334
Packet 22:
15:55:40.595459 IP 172.16.12.165.1058 > 192.168.234.166.8080: Flags [.], ack
17423, win 63163, length 0
With Argus 3.0.2:
./argus/argus-3.0.2/bin/argus -r correct.pcap -w - |
./argus/argus-clients-3.0.2/bin/ra -nnr -
27 Jan 11 15:55:05 e 6 172.16.12.165.1051 ->
192.168.234.166.8080 20 1080 CON
27 Jan 11 15:56:03 e 6 172.16.12.165.1051 ->
192.168.234.166.8080 4 216 CON
27 Jan 11 15:56:34 e 6 172.16.12.165.1051 ->
192.168.234.166.8080 4 216 CON
27 Jan 11 15:57:05 e 6 172.16.12.165.1051 ->
192.168.234.166.8080 4 216 CON
27 Jan 11 15:57:37 e 6 172.16.12.165.1051 ->
192.168.234.166.8080 4 216 CON
27 Jan 11 15:58:08 e 6 172.16.12.165.1051 ->
192.168.234.166.8080 4 216 CON
27 Jan 11 15:58:39 e 6 172.16.12.165.1051 ->
192.168.234.166.8080 4 216 CON
27 Jan 11 15:59:10 e 6 172.16.12.165.1051 ->
192.168.234.166.8080 4 216 CON
27 Jan 11 15:59:41 e 6 172.16.12.165.1051 ->
192.168.234.166.8080 4 216 CON
./argus/argus-3.0.2/bin/argus -r test-case.pcap -w - |
./argus/argus-clients-3.0.2/bin/ra -nnr -
27 Jan 11 15:55:05 e 6 172.16.12.165.1051 ->
192.168.234.166.8080 20 1080 CON
27 Jan 11 15:55:10 e 6 192.168.234.166.8080 ?>
172.16.12.165.1058 1 54 CON
27 Jan 11 15:55:40 e 6 192.168.234.166.8080 <?
172.16.12.165.1058 1 54 CON
27 Jan 11 15:56:03 e 6 172.16.12.165.1051 <?>
192.168.234.166.8080 4 216 CON
27 Jan 11 15:56:34 e 6 172.16.12.165.1051 <?>
192.168.234.166.8080 4 216 CON
27 Jan 11 15:57:05 e 6 172.16.12.165.1051 <?>
192.168.234.166.8080 4 216 CON
27 Jan 11 15:57:37 e 6 172.16.12.165.1051 <?>
192.168.234.166.8080 4 216 CON
27 Jan 11 15:58:08 e 6 172.16.12.165.1051 <?>
192.168.234.166.8080 4 216 CON
27 Jan 11 15:58:39 e 6 172.16.12.165.1051 <?>
192.168.234.166.8080 4 216 CON
27 Jan 11 15:59:10 e 6 172.16.12.165.1051 <?>
192.168.234.166.8080 4 216 CON
27 Jan 11 15:59:41 e 6 172.16.12.165.1051 <?>
192.168.234.166.8080 4 216 CON
As you can see the connection direction is lost.
Attached are the PCAPs. (I'm not a liberty to provide the complete data, so
they are stripped at 54 bytes p/packet and the MAC addresses are obfuscated,
but they will still trigger the bug.)
Any ideas what's going on here?
Thanks in advance,
Cees
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20110209/48b0cf92/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-case.pcap
Type: application/force-download
Size: 3804 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20110209/48b0cf92/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: correct.pcap
Type: application/force-download
Size: 3664 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20110209/48b0cf92/attachment-0001.bin>
More information about the argus
mailing list