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. <snip> 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 http://vger.kernel.org/majordomo-info.html
