Re: Some more test on ingress, ifb, fwmark

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On Fri, 2012-05-11 at 22:08 +0100, Andy Furniss wrote:
> <snip>>
> > I've to read carefully out link, but for now really i don't understood
> > this ''warning'':
> >
> >   ip sport<VALUE>  <MASK>
> >    Matches the 16 bit source port in a TCP or UDP IPv4 packet.
> >    This only works if the ip header contains no options.  Use the
> >    "link" and "match tcp src" or "match udp src" options if you
> >    can not be sure of that.
> >
> > Somenone can explain me?
> It's possible, but AFAIK rare, that the ip header length may be greater 
> than 20, which will mess up normal matching - but I think most people 
> just use normal and don't bother doing it this way.
Hi, Marco.  The u32 match is so powerful because it can match on
anything at any offset.  The drawback is that the offset must be exact.
In the very rare occasion where IP option are used, the extend the IP
header by four bytes.  That means that everything in the TCP or UDP
headers is shifted by four bytes so all the u32 offsets will be wrong.

Using hash tables and linking to them gives one the ability to specify
the offset from the previous header.  Thus, one can specify a TCP or UDP
offset relative to the end of the IP header wherever the IP header ends.

We use hash tables and linking for an additional reason.  It allows one
to create a bit of a hierarchy similar to iptables user defined chains.
However, I'm not sure if this reasoning is valid so I would appreciate
it if someone with more experience would correct me if what I'm about to
say is incorrect.

Let's say I want to filter TCP packets on port 80, port 25, port 3389,
and also on port 22 but only with ToS set to 0x10, and all TCP packets
with the ACK bit set.  I also want to filter UDP packets less than 288
bytes between ports 10000 and 20000, UDP packets on port 53, and others
on port 67.  Rather than having to evaluate all those matches for every
packet until I find a match, I can create a hierarchy, i.e., I create a
filter for TCP traffic where I link to another hash table where I check
the port and, if it is 22, link to another has table where I check the
ToS.  Likewise, I have another for UDP traffic which links to a separate
hash table where I check for port and, if it is between 10000 and 20000
link to another hash table where I check for size.

This would seem to create an "indexed" and more efficient processing of
ports.  Is that a proper way of approaching hash tables and filters plus
we gain the benefit of correct filtering if IP options just happen to be
used? Thanks - John

To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Bugtraq]     [Fedora Legacy]     [GCC Help]     [Yosemite News]     [Yosemite Photos]     [IP Tables]     [Netfilter Devel]     [Fedora Users]

Powered by Linux