[LARTC] tc filter u32 nexthdr, chained filters?

[LARTC] tc filter u32 nexthdr, chained filters?

[Henrik Nordstrom]

Hi.

Is there anyone who has understood of how u32 nexthdr addressing is supposed 
to work? (including the "tcp/icmp/.." matches who implicitly uses nexthdr)

From reading the kernel code it apparently is using the location set by 
"offset at", but this seems to only be evaluated on hash parents, and only 
for it's children..

I.e. the logic for u32 filter rule processing seems to be something like

  if all matches true
    if terminal filter rule
      execute action
    else if link rule
      if offset plus/at
        calculate nexthdr offset
      if offset eat
        skip any data up to the nexthdr pointer
      follow filter link
    endif
  endif


Think it would be more logical if the nexthdr offset was calculated before 
the matches. This way one could create a simple filter rule for matching TCP 
data. But I am sure there is some reason to why it is the way it is?

Also, the filter processing seems to be capable of linking filter rules 
without using a hash table, but I cannot figure out how to create such a tc 
filter rule.

Obviously I am a bit confused.. I have not yet fully got the grips on how to 
set up hashed or linked filters. The HOWTO is a bit confusing in this chapter 
I think. Would be nice with a explanation why that many filter rules are 
created (or if they are not actually many filters, why that many commands are 
required). Intuitively it should be sufficient with one tc filter command to 
create the hash table rule, and then the tc filter commands to create the 
hash chains as required... And the fact that some qdisc has built in filters 
does not make the filter concepts easier to understand either (prio)..

Regards
Henrik Nordström

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/