Modify skb from match module?

Modify skb from match module?

[Juha Heljoranta]

I would like to associate some information to struct sk_buff *skb so 
that it would be available later while processing packet. But it turns 
out that the skb is const

    static int match(const struct sk_buff *skb, ...

Is there any way to modify skb from match module? Or is there another 
way to store/cache information so that it can be later associated to skb.

The information that I'd like to store consist inode and device number 
and some other stuff about the process owning sending/receiving socket. 
Storing this information makes sense because it can be used later (e.g. 
for logging) and fetching it takes time/cpu.

Regards,
Juha Heljoranta

Re: Modify skb from match module?

[Tobias DiPasquale]

On Wed, 16 Feb 2005 23:03:21 +0200, Juha Heljoranta
<juha.heljoranta@evtek.fi> wrote:
> I would like to associate some information to struct sk_buff *skb so
> that it would be available later while processing packet. But it turns
> out that the skb is const
> 
>     static int match(const struct sk_buff *skb, ...
> 
> Is there any way to modify skb from match module? 

No. As you correctly point out, the sk_buff is constant and thus
unmodifiable. Packets can only be modified by rules in the mangle
table using a target, not a match.

> Or is there another way to store/cache information so that it can be later
> associated to skb.

Potentially, depending on the protocol you need to manipulate, you
could create a conntrack helper that has its own data structure for
storing the information you require. This would allow you to store
data on a per-connection basis. This data would not persist past the
life of the connection, however.

Alternatively, you could create a module that serves only to store the
data that you need and call out to it in your match module in order to
save data about packets you match on. This would allow you to store
data beyond the life of a connection or single packet and also to
aggregate data in more complicated manners. You would then have to
come up with some way to clean this data, however.

-- 
[ Tobias DiPasquale ]
0x636f6465736c696e67657240676d61696c2e636f6d