Re: PATCH: IPSEC xfrm events

[jamal <hadi@cyberus.ca>]

Herbert,

On Fri, 2005-04-01 at 20:28, Herbert Xu wrote:
> Hi Jamal:
> 
> On Fri, Apr 01, 2005 at 08:04:05PM -0500, jamal wrote:
> >
> > The issue is that pfkey echoes back a few things from the original
> > message - important ones being version, pid, seq, and msgtype (as a
> > sample take a look at pfkey_add()). So these need to be remembered...
> 
> You're right.  The pid and seq should be stored in km_event by
> af_key and xfrm_user before they call km_notify.  In fact bring
> back that the km_type field too and put it in km_event. 

Do we need km_type? Given we have: the event, seq, pid (regardless of
where it was generated) we have sufficient info to create eitehr a
netlink or pfkey message.

>  That'll
> become useful when we figure out a way to include it in the netlink
> message so that the originator can be uniquely identified.
> 

The pid seems pretty accurate to describe what process generated the
initial message.

hold on: Ah, I think i may get what you are trying to get to: You want
iproute to display something along the lines of "this was created by a
pfkey app pid 1534". Did i read you correctly?
 
> The version should always be set by the kernel though.  This is because
> the packet we're broadcasting has been regenerated by the kernel.  If
> we ever get PFKEY v3 then in order that all existing applications
> understand these messages you'll have to reformat them as PFKEY v2
> anyway.
> 

So always go v2?

> msgtype should be derived from the event as you did in xfrm_user.
> 

indeed.

cheers,
jamal