Project

General

Profile

Actions

Bug #37

closed

stream pool error messages

Added by Victor Julien almost 15 years ago. Updated over 14 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

[29054] 1/1/2010 -- 23:07:30 - (stream-tcp-reassemble.c:1608) <Error> (StreamTcpGetSegment) -- [ERRCODE: SC_ERR_POOL_EMPTY(41)] - segment_pool7->empty_list_size 512, alloc 512
[29054] 1/1/2010 -- 23:07:30 - (stream-tcp-reassemble.c:1086) <Error> (StreamTcpReassembleHandleSegmentHandleData) -- [ERRCODE: SC_ERR_POOL_EMPTY(41)] - segment_pool7 is empty
[29054] 1/1/2010 -- 23:07:30 - (stream-tcp-reassemble.c:1485) <Error> (StreamTcpReassembleHandleSegment) -- [ERRCODE: SC_ERR_REASSEMBLY_FAILED(42)] - StreamTcpReassembleHandleSegmentHandleData error

Actions #1

Updated by Victor Julien almost 15 years ago

Seeing a lot of those after a while on my firewall box running nfq inline.

Actions #2

Updated by Victor Julien almost 15 years ago

  • Assignee set to OISF Dev
Actions #3

Updated by Will Metcalf almost 15 years ago

I'm requesting that we make segment pools a user configurable option. Perhaps we also need some payload sizes between 1448 and 65535. Might also be nice to just have an option to set a generic memcap for reassembly.

/* We define serveral pools with prealloced segments with fixed size * payloads. We do this to prevent having to do an malloc call for every * data segment we receive, which would be a large performance penalty. * The cost is in memory of course. */
#define segment_pool_num 8
static uint16_t segment_pool_pktsizes[segment_pool_num] = {4, 16, 112, 248, 512,
768, 1448, 0xffff};
static uint16_t segment_pool_poolsizes[segment_pool_num] = {2048, 3072, 3072,
3072, 3072, 8192,
8192, 512};

Actions #4

Updated by Victor Julien over 14 years ago

  • Status changed from New to Closed

This was fixed a few masters ago with the stream memcap and pool changes.

Actions

Also available in: Atom PDF