Julian,
On Mon, 6 Jan 2003, Julian Anastasov wrote:
>
> Hello,
>
> On Mon, 6 Jan 2003, jamal wrote:
>
> > > May be sort of: ... alter andmask 0xFF00 xormask 0x0023 at -4 ...
> > > i.e. syntax similar to ipchains TOS and u32 match.
> >
> > I wanted to use u32 as the basis; which means u32 type matching is needed.
> > then use vi/sed type substitution s/OL/V where:
> > O = offset (from skb->data, could be -ve),
>
> IMO, using skb->nh.raw as basis is preferred. By this way
> the filters can be used from different places in the net stack.
Makes sense, let me think about it more and maybe experiment.
"different places in the stack"? I was thinking only ingress or egress.
>
> > L = length (cant go beyond head or end),
> > V is a static value configured (its size cant exceed L). V can also
> > be computed off something example the data at offset O. I am trying to
> > keep away from situations where L is larger or smaller than sizeof V
> > so theres no mucking with any of the skb pointers ore reallocing etc. In
>
> Yes, changing skb len is problematic mostly for TCP. As
> for L and V: I assume they are HEX digits or there will be a way
> to encode alphanumeric chars?
>
We leave that to user space. User space can translate from strings for
example into hex. But yes, hex should be the default as is now.
> > the next iteration things could change. Note i havent written this but
> > will in the near future (so anyone is welcome to hack on it)
> > I didnt understand your andmask and xormask idea...
>
> The above example:
>
> - goto word at offset -4
> - AND the 2 bytes with FF00
> - XOR the 2 bytes with 0023
>
> AND+XOR allow any operations for bits:
>
> 1) preserving (AND 1 XOR 0)
> 2) inverting (AND 1 XOR 1)
> 3) setting (AND 0 XOR 1)
> 4) clearing (AND 0 XOR 0)
>
Ok, makes sense and oughta be used.
> > u32 needs to be taught about ARP so it can understand different
> > ARP header bits like sip (shouldnt be that difficult)
>
> Yes, we can teach u32 to know about ARP offsets,
> ethhdr offsets...
ethheaders are i think generic enough to be done first.
>
> > I plan to move ingress to below IP just before the bridging and tap
> > code; experiments shows this works just fine.
> > So all the filters + edits going there should work fine. Thoughts?
>
> I assume just after skb->nh.raw = skb->data;
> Also, before or after deliver to ptype_all?
yes before ptype_all i.e the first thing. But it could be a
programmability thing where you at least allow ptype_all to see things.
>
> I see one problem: egress is called after all csum calcs,
> bad for IP (if tc is going to damage the payload), good for ethhdr, ARP.
>
well unless you pass options to recalculate csums or make csum an
action by itself. I am thinking of "auxillary" actions which could
be done by all actions - this could be one of them; logging is another;
"change classid" is another.
Lets take this discussion offline, i think we have exceeded the topic
that started it all and people are hitting "D"s.
cheers,
jamal
|