ipt_string maximum packet size

Gianni Tedesco gianni@ecsc.co.uk
31 Oct 2001 08:41:22 +0000

On Tue, 2001-10-30 at 19:10, William Stearns wrote:
> Good day, all,
> 	I'm starting to use the ipt_string module for string matches.
> Nice work!
> 	As a side note, I _am_ aware of the issues in attempting string
> matches on raw packets (fragmentation, encoding, case sensitivity, string
> split across packets...).
> 	I'm coming across one of the search limits in that module:
> Oct 30 13:40:03 sparrow kernel: ipt_string: Packet too big to attempt sublinear string search (1376 bytes)
> Oct 30 13:42:46 sparrow kernel: ipt_string: Packet too big to attempt sublinear string search (1432 bytes)
> Oct 30 13:43:32 sparrow last message repeated 14 times
> Oct 30 13:43:34 sparrow last message repeated 4 times
> 	The limit in question appears to be:
> #define BM_MAX_HLEN 1024
> 	which is the maximum size of some arrays and the max hlen:


Basically the fast searching algorithm uses some fixed size tables to
speed things up. If a packet comes in thats too big, a slower
(non-size-limited) algorithm kicks in instead. Those messages don't mean
that the packet wasn't matched, its just a warning that the slow
algorithm was used on a big packet.

Increasing BM_MAX_HLEN will not break anything, in your case it will
just increase memory usage a bit, and also increase performance when
matching large packets.

I picked a quite conservative size for the tables purely as a trade off
between memory usage and string match speed as I doubt most users care
about string matching speed in netfilter, especially if the module is
loaded and they aren't even using it ;)

> I do realize that string matches are processor intensive and I'm
making the problem worse, but are you aware of any fundamental
limitations in that code?

I am aware of no limitations other than BM_MAX_HLEN which is the maximum
haystack size, and BM_MAX_NLEN which is maximum needle size. BM_MAX_HLEN
isn't even a real limitation because if a packet comes in that exceeds
it, it is matched using the linear (slow) search algorithm anyway.

Like I say increasing these actually increases performance rather than
decrease it. The sublinear search algorithm gets faster, the bigger the

Thanks for your interest.

// Gianni Tedesco <gianni@ecsc.co.uk>
"Every great advance in natural knowledge has involved
the absolute rejection of authority." -- Thomas H. Huxley