Hi Jamal:
On Wed, Mar 30, 2005 at 07:09:32AM -0500, jamal wrote:
>
> In the case you flush you dont wanna send multiple DELETEs. Just one
> FLUSH at the end when flushing is done. At least this is behavior
> of PFKEY (at least on the RFC). I think its a good thing.
You're right.
> > > +/* callback structure passed from either netlink or pfkey */
> > > +struct xfrm_sa_cb
> > > +{
> > > + u32 type; /* the type of caller netlink/pfkey/other */
> > > + u32 data; /* callee to caller */
> > > + void *hdr;
> > > + struct sk_buff *skb;
> >
> > I don't think we need to carry the original hdr and skb around.
> > I see below that you're using it to fill in the pid/seq when
> > sending netlink messages. Since these are multicast messages
> > resent by the kernel they should not inherit those values from
> > the original skb.
> >
>
> Thinking ... thinking .. Good point.
>
> I defineteley need at least:
> a) case original message sent via netlink: pid of the original process
> so when i multicast in netlink i dont echo back to it.
I don't think you need to do that. RFC 2367 says that the kernel should
send that message to all listening processes. It doesn't put an exception
on the sending process.
This makes sense also because the echoed message is really a new packet
sent by the kernel. It's not necessarily equal to the original packet.
In fact checking the socket pid is not enough to avoid sending the
message back to the originator. For instance, if the originator
used a different socket for receiving multicast messages then this
wouldn't work anyway.
For netlink it is important to use a different socket for receiving
multicast messages since otherwise you run the risk of losing unicast
messages when it overruns.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
|