[Bug 1707] iptables-extensions man page misleading for --to

[bugzilla-daemon at netfilter.org]

https://bugzilla.netfilter.org/show_bug.cgi?id=1707

--- Comment #5 from Phil Sutter <phil at nwl.cc> ---
(In reply to Pablo Neira Ayuso from comment #4)
> (In reply to Phil Sutter from comment #3)
> > (In reply to Pablo Neira Ayuso from comment #2)
> > > (In reply to Phil Sutter from comment #1)
> > > > Pablo, am I on the right track? Could you please review?
> > > 
> > > According to the code:
> > > 
> > [...]
> > >         ret = textsearch_find(config, &state);                              
> > >         return (ret <= to - from ? ret : UINT_MAX);                         
> > [...]
> > > commit f72b948dcbb8558d639214536c2ace1b0760f41d
> > > Author: Phil Oester <kernel at linuxace.com>
> > > Date:   Mon Jun 26 00:00:57 2006 -0700
> > > 
> > >     [NET]: skb_find_text ignores to argument
> > 
> > Ah, thanks for digging this up! IIUC, it merely asserts the start of the
> > matching string lies within the given boundaries, it may still extend to past
> > the end.
> > 
> > Is my interpretation about skb_seq_read() right though and specifying a too
> > narrow range could lead to a false negative? In other words, does 'from - to'
> > have to include the pattern's length?
> 
> By false negative you mean, pattern goes over the 'to' boundary?

I meant not finding the string in the packet even though it's present. IIUC,
skb_seq_read() deals with fragments. Assume I search for 'www.netfilter.org' at
offset 40 to 45 (obviously too small). Fragment 1 contains data until offset
50, fragment 2 data from 50 on. The pattern is there, so the end of fragment 1
has "www.netfil" and fragment 2 starts with "ter.org". My small range should
cause skb_seq_read() to return just the first fragment data, not the second one
and thus the match should fail although the string is present. An appropriately
large --to value (17 in this case) would cause skb_seq_read() to return the
next fragment's data in a consecutive call and thus the string is found.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20230926/c7adc79e/attachment.html>