Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*RFC\:\s+IPSEC\s+patch\s+0\s+for\s+netlink\s+events\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*RFC\:\s+IPSEC\s+patch\s+0\s+for\s+netlink\s+events\s*$/: 48 ]

Total 48 documents matching your query.

1. all protos partially use sk_prot (score: 1): Author: nn <marcel@xxxxxxxxxxxx>; Date: 26 Mar 2005 14:22:51 -0500; first patch that changes internal api slightly to allow for next patch which will add other events. It includes the other acquire patch i posted earlier - please ignore that - Or if you like this pa; /archives/netdev/2005-03/msg01493.html (8,904 bytes)
2. PATCH: IPSEC acquire in presence of multiple managers (score: 1): Author: ir_sarbazi <amir.sarbazi@xxxxxxxxx>; Date: Sun, 27 Mar 2005 05:40:06 +1000; Is the intention that you'll be sending policy expire messages to POLEXPIRE only? If so please add a new group for SA expire messages only so that XFRMGRP_EXPIRE continues to get all expire messages; /archives/netdev/2005-03/msg01495.html (9,738 bytes)
3. PATCH: IPSEC acquire in presence of multiple managers (score: 1): Author: xxxxxxxxx>; Date: Sun, 27 Mar 2005 05:47:07 +1000; Since we're adding new multicast groups, what about adding one for the passive event monitor? That way we can return ESRCH in km_query if there are no registered ACQUIRE listeners but still send mess; /archives/netdev/2005-03/msg01499.html (10,166 bytes)
4. le managers (score: 1): Author: t Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Date: 26 Mar 2005 15:05:05 -0500; Right. Unless you think this will break existing apps? Ok, i should have read ahead ;-> Maybe i should leave EXPIRE alone? cheers, jamal; /archives/netdev/2005-03/msg01500.html (10,011 bytes)
5. PATCH: IPSEC acquire in presence of multiple managers (score: 1): Author: erbert@xxxxxxxxxxxxxxxxxxx>; Date: 26 Mar 2005 15:11:15 -0500; Not sure how to do it for both PF_KEY and netlink. It does sound like a reasonable thing to do. Thoughts? cheers, jamal; /archives/netdev/2005-03/msg01502.html (9,918 bytes)
6. iscuss] Summary of 2005 Kernel Summit Proposed Topics (score: 1): Author: rea@xxxxxxx>; Date: Sun, 27 Mar 2005 18:18:48 +1000; For non-standard extensions like this I wouldn't worry about PF_KEY. After all, if you're going to make sense of all the messages from the kernel you'll have to use netlink anyway. Cheers, -- Visit O; /archives/netdev/2005-03/msg01518.html (10,760 bytes)
7. PATCH: IPSEC acquire in presence of multiple managers (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Sun, 27 Mar 2005 18:24:22 +1000; Yes openswan listens on XFRMGRP_EXPIRE for poilcy expire messages to detect unused pass policies that were automatically generated. I think so. Thanks, -- Visit Openswan at http://www.openswan.org/ E; /archives/netdev/2005-03/msg01520.html (10,160 bytes)
8. PATCH: IPSEC acquire in presence of multiple managers (score: 1): Author: eli <andrea@xxxxxxx>; Date: 27 Mar 2005 14:07:29 -0500; Just for consistency (since both call the same xfrm_state core code) I made some minor changes to pf_key internal-to-kernel API (not exposed to user space). Sample patch, still under construction, at; /archives/netdev/2005-03/msg01534.html (11,055 bytes)
9. hnologies (score: 1): Author: af <tgraf@xxxxxxx>; Date: Mon, 28 Mar 2005 23:23:19 +0200; jamal wrote: @@ -478,6 +491,9 @@ if (x1->km.state == XFRM_STATE_ACQ) { __xfrm_state_insert(x); + /* XXXX: We already have xfrm_state_lock + * do we need to grab x->lock as well? */ + xfrm_sa_notify(x; /archives/netdev/2005-03/msg01619.html (10,761 bytes)
10. (score: 1): Author: OIE" <util@xxxxxxxxxxxxxxx>; Date: Tue, 29 Mar 2005 09:43:35 +1000; That's true for now but it's something that I'd like to change for 2.6.13. We should use the refcnt as much as possible and modify the locking so that the state lock is only used to guard the state o; /archives/netdev/2005-03/msg01639.html (11,268 bytes)
11. iscuss] Summary of 2005 Kernel Summit Proposed Topics (score: 1): Author: xxxx>; Date: Wed, 30 Mar 2005 10:49:03 +1000; Hi Jamal: This looks good over all. Just a few minor things. What's the difference between DELETED and FLUSHED and why do we need that distinction? I don't think we need to carry the original hdr and; /archives/netdev/2005-03/msg01737.html (13,969 bytes)
12. cls_u32 compile failure in current 2.6.12-rc1+BK tree (score: 1): Author: tin Schwidefsky <schwidefsky@xxxxxxxxxx>; Date: 30 Mar 2005 07:09:32 -0500; 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. Thinki; /archives/netdev/2005-03/msg01758.html (15,037 bytes)
13. rc1+BK tree (score: 1): Author: fsky@xxxxxxxxxx>; Date: Wed, 30 Mar 2005 22:23:21 +1000; Hi Jamal: You're right. 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; /archives/netdev/2005-03/msg01759.html (13,139 bytes)
14. link events (score: 1): Author: ichal Vanco <vanco@xxxxxxxx>; Date: Wed, 30 Mar 2005 22:32:55 +1000; This would work for PFKEY too since if we did this, we can simply remove the BROADCAST_ONE messages from the pfkey_* functions. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>H; /archives/netdev/2005-03/msg01760.html (11,619 bytes)
15. link events (score: 1): Author: herbert@xxxxxxxxxxxxxxxxxxx>; Date: 30 Mar 2005 07:53:30 -0500; I may be influenced by some of the behaviors of rtnetlink users then. Typically (I may need to go back and double check), they dont echo back. The final response of success is unicast though if a AC; /archives/netdev/2005-03/msg01761.html (13,216 bytes)
16. link events (score: 1): Author: xxx>; Date: Wed, 30 Mar 2005 22:55:18 +1000; Hi Jamal: Actually, this shouldn't be here at all. Calls to xfrm_sa_notify (better to call it km_state_notify for consistency) should be made from the places where we currently call pfkey_broadcast a; /archives/netdev/2005-03/msg01762.html (10,499 bytes)
17. link events (score: 1): Author: Engel <joern@xxxxxxxxxxxxxxxxxxxx; Date: Wed, 30 Mar 2005 23:14:22 +1000; Hi Jamal: That's right. However, this isn't really an echo. It's a notification from the kernel to a particular multicast group. For example, in the case of a delete request, the multicast message wi; /archives/netdev/2005-03/msg01763.html (12,692 bytes)
18. link events (score: 1): Author: Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Date: 30 Mar 2005 08:18:25 -0500; we let the km make the call; pfkey already had these calls and i believe they are the ones that should go in order to be generic. Actually more like split into two. But thats defered for later (if it; /archives/netdev/2005-03/msg01764.html (10,697 bytes)
19. link events (score: 1): Author: xxxxxxxx>; Date: 30 Mar 2005 08:24:42 -0500; Since you feel strongly about this - I will make the change and we can always blame the RFC;-> I need to do some testing later tonight to make sure nothing goes berserk. cheers, jamal; /archives/netdev/2005-03/msg01765.html (13,076 bytes)
20. link events (score: 1): Author: xxxxxxxx>; Date: Wed, 30 Mar 2005 23:27:17 +1000; Yes you're right. I thought you were putting it into xfrm_state_insert but that's not the case. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxx; /archives/netdev/2005-03/msg01766.html (10,320 bytes)

Current List: 1 - 20
Page: [1] [2] [3]