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

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*PATCH\:\s+IPSEC\s+xfrm\s+events\s*$/: 38 ]

Total 38 documents matching your query.

1. Re: PATCH: IPSEC xfrm events (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: 01 Apr 2005 06:03:18 -0500; note: used by both SP/SA sure. agreed. You need to be able to generate events at every km not just the one that generated the request. You also (most of the time) need to do it before affected object; /archives/netdev/2005-04/msg00005.html (19,814 bytes)
2. Re: PATCH: IPSEC xfrm events (score: 1): Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Date: Fri, 1 Apr 2005 21:42:58 +1000; I understand. However, that's not determined by where you put the km_notify call itself. Even when you call km_notify from af_key or xfrm_user it will notify every km in the system. It's the fact tha; /archives/netdev/2005-04/msg00007.html (14,362 bytes)
3. Re: PATCH: IPSEC xfrm events (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: 01 Apr 2005 07:24:38 -0500; I think either scheme is fine really;-> I will definetely go back and consider the approach you are suggesting and see if it results into more maintanable code - then fair. Otherwise you realize its; /archives/netdev/2005-04/msg00009.html (15,286 bytes)
4. Re: PATCH: IPSEC xfrm events (score: 1): Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Date: Fri, 1 Apr 2005 22:35:54 +1000; Well I'm happy to code that part if you want :) Agreed. That's what we'll get if we make __xfrm_state_delete return success/failure. You're right that the RFC isn't very clear. Let's forget about the; /archives/netdev/2005-04/msg00010.html (11,723 bytes)
5. Re: PATCH: IPSEC xfrm events (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: 01 Apr 2005 07:59:39 -0500; Let me review first. If it is valuable (we may have to leave expire alone). If i can get it done within next day or two fine - else if i get busyed out elsewhere i will hand it to you. Actually if yo; /archives/netdev/2005-04/msg00011.html (11,634 bytes)
6. Re: PATCH: IPSEC xfrm events (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: 01 Apr 2005 08:18:37 -0500; Ok, from a first review I would agree with you the result of doing it in km user will be more maintainable. It will result in a larger patch but in the long run more maintainable. Let me code away at; /archives/netdev/2005-04/msg00012.html (10,327 bytes)
7. Re: PATCH: IPSEC xfrm events (score: 1): Author: Masahide NAKAMURA <nakam@xxxxxxxxxxxxxx>; Date: Fri, 01 Apr 2005 23:19:45 +0900; Hello Jamal and Herbert, I think FLUSH should be sent in such case. Because flushing empty SADB/SPD is not an error (at current code), it is reasonable to broadcast it. Regards, -- Masahide NAKAMURA; /archives/netdev/2005-04/msg00013.html (11,080 bytes)
8. Re: PATCH: IPSEC xfrm events (score: 1): Author: Masahide NAKAMURA <nakam@xxxxxxxxxxxxxx>; Date: Sat, 02 Apr 2005 02:28:07 +0900; Jamal and Herbert, Short report: I've tested on this patched kernel and it works. - add/del/flush for SA/SP and allocspi/acquire/upd for SA through netlink socket - racoon runs fine (pfkey works for; /archives/netdev/2005-04/msg00021.html (11,104 bytes)
9. Re: PATCH: IPSEC xfrm events (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: 01 Apr 2005 20:04:05 -0500; Staring at the code, obversation: as a result of some app using netlink such as ip x - the reverse is actually easier to deal with. This problem doesnt exist with current approach i am taking. The i; /archives/netdev/2005-04/msg00048.html (11,109 bytes)
10. Re: PATCH: IPSEC xfrm events (score: 1): Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Date: Sat, 2 Apr 2005 11:28:13 +1000; Hi Jamal: 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. That'll; /archives/netdev/2005-04/msg00051.html (11,455 bytes)
11. Re: PATCH: IPSEC xfrm events (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: 01 Apr 2005 20:42:45 -0500; 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. The pid seems pretty accurate to de; /archives/netdev/2005-04/msg00053.html (12,267 bytes)
12. Re: PATCH: IPSEC xfrm events (score: 1): Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Date: Sat, 2 Apr 2005 11:45:43 +1000; That's right. Someone with a pathological mind might do pfkey and netlink from the same pid :) -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>; /archives/netdev/2005-04/msg00054.html (11,312 bytes)
13. Re: PATCH: IPSEC xfrm events (score: 1): Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Date: Sat, 2 Apr 2005 11:46:19 +1000; Yes since that's the only version that the kernel knows how to generate. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: ht; /archives/netdev/2005-04/msg00055.html (11,197 bytes)
14. PATCH: IPSEC xfrm events (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: 05 Apr 2005 08:03:24 -0400; Heres the final patch. What this patch provides - netlink xfrm events - ability to have events generated by netlink propagated to pfkey and vice versa. - fixes the acquire lets-be-happy-with-one-suc; /archives/netdev/2005-04/msg00223.html (9,991 bytes)
15. Re: PATCH: IPSEC xfrm events (score: 1): Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Date: Tue, 5 Apr 2005 22:07:24 +1000; Jamal you forgot to sign off your own patch :) Anyway this looks good to me. Signed-off-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{; /archives/netdev/2005-04/msg00224.html (10,695 bytes)
16. Re: PATCH: IPSEC xfrm events (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: 05 Apr 2005 08:19:06 -0400; Gah, Ok - I guess i too can be famous Signed-off-by: Jamal Hadi Salim <hadi@xxxxxxxxxx> cheers, jamal; /archives/netdev/2005-04/msg00227.html (10,513 bytes)
17. Re: PATCH: IPSEC xfrm events (score: 1): Author: Arnaldo Carvalho de Melo <arnaldo.melo@xxxxxxxxx>; Date: Tue, 5 Apr 2005 09:24:30 -0300; Or funny! /me runs - Arnaldo; /archives/netdev/2005-04/msg00228.html (10,968 bytes)
18. -Device (score: 1): Author: xxxxx>; Date: 31 Mar 2005 20:37:21 -0500; Herbert et al, Ok, heres the final patch with all the changes discussed. include/linux/xfrm.h | 2 include/net/xfrm.h | 29 ++++++- net/key/af_key.c | 24 +++++- net/xfrm/xfrm_policy.c | 25 ++++-- net/x; /archives/netdev/2005-03/msg01902.html (8,098 bytes)
19. (score: 1): Author: xxxxxxx>; Date: Fri, 1 Apr 2005 14:21:06 +1000; Thanks Jamal. The patch looks good overall. However, the delete/flush code is new so I've got something to say again :) This name is a bit non-specific. Might as well put the event into it if we're g; /archives/netdev/2005-03/msg01908.html (15,843 bytes)
20. Re: PATCH: IPSEC xfrm events (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: 01 Apr 2005 06:03:18 -0500; note: used by both SP/SA sure. agreed. You need to be able to generate events at every km not just the one that generated the request. You also (most of the time) need to do it before affected object; /archives/netdev/2005-04/msg01141.html (19,990 bytes)

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