[Snort-devel] More Stream3 Fun

william.c.gercken at ...350... william.c.gercken at ...350...
Wed May 16 17:25:02 EDT 2001


Marty, Todd,

I modified Todd's debug code to output the session state for each of the
sessions and imported the data into a database to make it easier to work
with. The data was generated by sending a USR2 once a minute for 42
minutes. The timeout for the sessions was set to 10 seconds. Attached are
three reports. The first (report2.lst) is a select on all sessions that
still exist by the time we get to the last minute. Note that I excluded
established sessions (s_status = 4 and c_status=4). In the reports,
dump_index is just a sequential count of the number of times a USR2 was
sent.The sql was:

select dump_index "DI", to_char( dump_time, 'HH24:MI:ss' ) "D_Time",
session_id "Session",
to_char( session_time, 'HH24:MI:ss' ) "S_Time",
s_status "ServerStatus", c_status "ClientStatus"
from stream3_leak
where
( c_status != 4 and s_status != 4 )
AND session_id in (
select session_id from
stream3_leak where dump_index='42'
)
order by dump_index

You will be able to see in the report that threre are many sessions that
should have expired and have been pruned based on their status. Session
88029 for example.

The second report (report3.lst) is a drill down on session 73941 to see
what was up there. It appears that the server and client status remain the
same. It could be that during the one minute interval I am missing other
states for this session. I will check into this. The sql:

select dump_index "DI", to_char( dump_time, 'HH24:MI:ss' ) "D_Time",
session_id "Session",
to_char( session_time, 'HH24:MI:ss' ) "S_Time",
s_status "ServerStatus", c_status "ClientStatus"
from stream3_leak
where session_id = '73491'
AND session_id in (
select session_id from
stream3_leak where dump_index='42'
)
order by dump_index
/

The third report (report4.lst)  is a drill down on session 88029, which is
in a TIME_WAIT/LAST_ACK state and then CLOSED. The sql:

select dump_index "DI", to_char( dump_time, 'HH24:MI:ss' ) "D_Time",
session_id "Session",
to_char( session_time, 'HH24:MI:ss' ) "S_Time",
s_status "ServerStatus", c_status "ClientStatus"
from stream3_leak
where session_id = '88029'
AND session_id in (
select session_id from
stream3_leak where dump_index='42'
)
order by dump_index

The bottom line is that it appears some nodes are not getting pruned
properly from the list. Our firewall indicated that we had around 14K
connections established at the time I ran this. The avl count was up to
about 28K or so.

I have become obsessed trying to figure this out, so I will probably keep
providing more input. Let me know if you want me to stop....

Regards,
-bill


(See attached file: report2.lst)(See attached file: report3.lst)(See
attached file: report4.lst)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: report2.lst
Type: application/octet-stream
Size: 54791 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20010516/a96f27fa/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: report3.lst
Type: application/octet-stream
Size: 2728 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20010516/a96f27fa/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: report4.lst
Type: application/octet-stream
Size: 1445 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20010516/a96f27fa/attachment-0002.obj>


More information about the Snort-devel mailing list