Re: [RFC][PATCH 0/3][XFRM]: Support packet processing error statistics.
Wednesday 24 October 2007 21:18, jamal wrote: > On Wed, 2007-24-10 at 12:30 +0900, Masahide NAKAMURA wrote: > > > At IPsec point of view, actually "SPI mismatch" caused by user configuration > > cannot be identified easily since identify of SAD is consist of SPI, > > address and > > protocol(ESP/AH...) and linux SAD uses hash database. It is database > > identify > > mismatch. Then, SPI mismatch goes "NoStates" at my patch. > > OTOH Key mismatch goes "ProtoError" since esp[46]_input returns error. > > Would be useful to just document what you said above so that user doesnt > have to intepret it. OK, I write it to commit-log then. If anybody have another place where such information should be written, tell me. [snip] > > > In any case, it seems to me to be more accurate to not call them MIB > > > stats if they are not. This doesnt qualify using the macros, utilities > > > etc used for MIBs. > > > > BTW, I meant "doesnt disqualify them" above;-> OK ;-) Jamal, thanks for many comments. -- Masahide NAKAMURA - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/3][XFRM]: Support packet processing error statistics.
On Wed, 2007-24-10 at 12:59 +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote: > In article <[EMAIL PROTECTED]> (at Tue, 23 Oct 2007 16:08:34 +0900), Masahide > NAKAMURA <[EMAIL PROTECTED]> says: > > > Now we have the following candidates: > > > > (1) my patchXFRM_MIB_INHDRERROR > > (2) some extender XFRM_XXX_INHDRERROR (XXX is requested) > > (3) not-mib extenderXFRM_NOTMIB_INHDRERROR > > (4) no extender XFRM_INHDRERROR > > (5) merge linux-mib LINUX_MIB_XFRMINHDRERROR > > > > Comments? > > I would support (5) or (1). #5 it is then. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/3][XFRM]: Support packet processing error statistics.
On Wed, 2007-24-10 at 12:30 +0900, Masahide NAKAMURA wrote: > At IPsec point of view, actually "SPI mismatch" caused by user configuration > cannot be identified easily since identify of SAD is consist of SPI, address > and > protocol(ESP/AH...) and linux SAD uses hash database. It is database identify > mismatch. Then, SPI mismatch goes "NoStates" at my patch. > OTOH Key mismatch goes "ProtoError" since esp[46]_input returns error. Would be useful to just document what you said above so that user doesnt have to intepret it. > Thanks for pointing the RFC. I've read it, however, I cannot find them at the > RFC. My bad. > > In any case, it seems to me to be more accurate to not call them MIB > > stats if they are not. This doesnt qualify using the macros, utilities > > etc used for MIBs. > BTW, I meant "doesnt disqualify them" above;-> > How about assuming it as "private MIB" of linux? Ok, makes sense to me now - that would be a good choice (i dont see any confusion with enteprise mib). > Shouldn't we have something after XFRM_ to distinguish from other XFRM > macros? > It is not needed - I am sorry that i missed the "Linux MIB" part in your emails so far. That would be good enough. > > > > 2) Why /proc? Are you going to make these available also via netlink? > > > > > > Because /proc is easy to see it without any modified application. > > > If you want the netlink interface, I can do it as the next step. Do you > > > want it? > > > > Absolutely - it would be much appreciated. And if you dont have time, I > > will write and test the user space part extension. > > Thanks. After my first step is completed, could you write the netlink part? Thanks. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/3][XFRM]: Support packet processing error statistics.
In article <[EMAIL PROTECTED]> (at Tue, 23 Oct 2007 16:08:34 +0900), Masahide NAKAMURA <[EMAIL PROTECTED]> says: > Monday 22 October 2007 21:28, jamal wrote: > > On Mon, 2007-22-10 at 15:11 +0900, Masahide NAKAMURA wrote: : > This point is one of what I want to hear comment. > My patch uses "XFRM_MIB_XXX" because I found "LINUX_MIB_XXX" definition at > include/linux/snmp.h for TCP extended statistics at /proc/net/netstat and > it does not seem to be defined by any RFC specification. Then I feel it is > not so bad to > use _MIB_ for them. Maybe we have another idea to merge them into LINUX_MIB. > > Now we have the following candidates: > > (1) my patch XFRM_MIB_INHDRERROR > (2) some extender XFRM_XXX_INHDRERROR (XXX is requested) > (3) not-mib extender XFRM_NOTMIB_INHDRERROR > (4) no extender XFRM_INHDRERROR > (5) merge linux-mib LINUX_MIB_XFRMINHDRERROR > > Comments? I would support (5) or (1). --yoshfuji - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/3][XFRM]: Support packet processing error statistics.
Wednesday 24 October 2007 04:47, jamal wrote: > On Tue, 2007-23-10 at 16:08 +0900, Masahide NAKAMURA wrote: > > > Thanks. I would like you to find too much item at my patch > > for the statistics, too. > > I am not anywhere close to a machine where i can give you precise > details to this; the one thing that sticks out in my brain cells is the > SPI mismatch. This (in static setups) seemed to be the most common > mistake i saw (other than a mismatched key). Your stats as you have them > now and as is will catch both in one spot - which is a good start. At IPsec point of view, actually "SPI mismatch" caused by user configuration cannot be identified easily since identify of SAD is consist of SPI, address and protocol(ESP/AH...) and linux SAD uses hash database. It is database identify mismatch. Then, SPI mismatch goes "NoStates" at my patch. OTOH Key mismatch goes "ProtoError" since esp[46]_input returns error. > > This point is one of what I want to hear comment. > > My patch uses "XFRM_MIB_XXX" because I found "LINUX_MIB_XXX" definition at > > include/linux/snmp.h for TCP extended statistics at /proc/net/netstat and > > it does not seem to be defined by any RFC specification. > > I thought those were part of some MIB somewhere. Doesnt RFC 4898 cover > them? Thanks for pointing the RFC. I've read it, however, I cannot find them at the RFC. > In any case, it seems to me to be more accurate to not call them MIB > stats if they are not. This doesnt qualify using the macros, utilities > etc used for MIBs. How about assuming it as "private MIB" of linux? > > Then I feel it is not so bad to > > use _MIB_ for them. Maybe we have another idea to merge them into LINUX_MIB. > > > > Now we have the following candidates: > > > > (1) my patchXFRM_MIB_INHDRERROR > > (2) some extender XFRM_XXX_INHDRERROR (XXX is requested) > > (3) not-mib extenderXFRM_NOTMIB_INHDRERROR > > (4) no extender XFRM_INHDRERROR > > (5) merge linux-mib LINUX_MIB_XFRMINHDRERROR > > > > Comments? > > I am very tempted to say #4. And when you push this to be a real MIB > stat then Shouldn't we have something after XFRM_ to distinguish from other XFRM macros? > > > 2) Why /proc? Are you going to make these available also via netlink? > > > > Because /proc is easy to see it without any modified application. > > If you want the netlink interface, I can do it as the next step. Do you > > want it? > > Absolutely - it would be much appreciated. And if you dont have time, I > will write and test the user space part extension. Thanks. After my first step is completed, could you write the netlink part? -- Masahide NAKAMURA - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/3][XFRM]: Support packet processing error statistics.
On Tue, 2007-23-10 at 16:08 +0900, Masahide NAKAMURA wrote: > Thanks. I would like you to find too much item at my patch > for the statistics, too. I am not anywhere close to a machine where i can give you precise details to this; the one thing that sticks out in my brain cells is the SPI mismatch. This (in static setups) seemed to be the most common mistake i saw (other than a mismatched key). Your stats as you have them now and as is will catch both in one spot - which is a good start. > This point is one of what I want to hear comment. > My patch uses "XFRM_MIB_XXX" because I found "LINUX_MIB_XXX" definition at > include/linux/snmp.h for TCP extended statistics at /proc/net/netstat and > it does not seem to be defined by any RFC specification. I thought those were part of some MIB somewhere. Doesnt RFC 4898 cover them? In any case, it seems to me to be more accurate to not call them MIB stats if they are not. This doesnt qualify using the macros, utilities etc used for MIBs. > Then I feel it is not so bad to > use _MIB_ for them. Maybe we have another idea to merge them into LINUX_MIB. > > Now we have the following candidates: > > (1) my patch XFRM_MIB_INHDRERROR > (2) some extender XFRM_XXX_INHDRERROR (XXX is requested) > (3) not-mib extender XFRM_NOTMIB_INHDRERROR > (4) no extender XFRM_INHDRERROR > (5) merge linux-mib LINUX_MIB_XFRMINHDRERROR > > Comments? I am very tempted to say #4. And when you push this to be a real MIB stat then > > > 2) Why /proc? Are you going to make these available also via netlink? > > Because /proc is easy to see it without any modified application. > If you want the netlink interface, I can do it as the next step. Do you want > it? Absolutely - it would be much appreciated. And if you dont have time, I will write and test the user space part extension. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/3][XFRM]: Support packet processing error statistics.
Monday 22 October 2007 21:28, jamal wrote: > On Mon, 2007-22-10 at 15:11 +0900, Masahide NAKAMURA wrote: > > This patch introduces statistics about transformation error (or almost > > error) > > factor at packet processing for developer. > > It is not a SNMP/MIB specification from IPsec/MIPv6 but a counter > > designed from current transformation source code. > > > > Comment please. > > very nice - these stats make IPSEC a lot more usable (I will go look and > see if theres anything that i have used for debug before that you dont > have and send you mail). Two comments: Thanks. I would like you to find too much item at my patch for the statistics, too. > 1) Since these are not MIB stats, it sounds like a good idea not to use > _MIB_ extender in the naming. Maybe something like _NOTMIB_ ;-> or > totaly leave it out. One other approach is to push these to be a MIB at > IETF since they are sensible to have. This point is one of what I want to hear comment. My patch uses "XFRM_MIB_XXX" because I found "LINUX_MIB_XXX" definition at include/linux/snmp.h for TCP extended statistics at /proc/net/netstat and it does not seem to be defined by any RFC specification. Then I feel it is not so bad to use _MIB_ for them. Maybe we have another idea to merge them into LINUX_MIB. Now we have the following candidates: (1) my patchXFRM_MIB_INHDRERROR (2) some extender XFRM_XXX_INHDRERROR (XXX is requested) (3) not-mib extenderXFRM_NOTMIB_INHDRERROR (4) no extender XFRM_INHDRERROR (5) merge linux-mib LINUX_MIB_XFRMINHDRERROR Comments? > 2) Why /proc? Are you going to make these available also via netlink? Because /proc is easy to see it without any modified application. If you want the netlink interface, I can do it as the next step. Do you want it? -- Masahide NAKAMURA - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/3][XFRM]: Support packet processing error statistics.
On Mon, 2007-22-10 at 15:11 +0900, Masahide NAKAMURA wrote: > This patch introduces statistics about transformation error (or almost error) > factor at packet processing for developer. > It is not a SNMP/MIB specification from IPsec/MIPv6 but a counter > designed from current transformation source code. > > Comment please. very nice - these stats make IPSEC a lot more usable (I will go look and see if theres anything that i have used for debug before that you dont have and send you mail). Two comments: 1) Since these are not MIB stats, it sounds like a good idea not to use _MIB_ extender in the naming. Maybe something like _NOTMIB_ ;-> or totaly leave it out. One other approach is to push these to be a MIB at IETF since they are sensible to have. 2) Why /proc? Are you going to make these available also via netlink? cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/3][XFRM]: Support packet processing error statistics.
Monday 22 October 2007 17:50, Herbert Xu wrote: > On Mon, Oct 22, 2007 at 03:11:06PM +0900, Masahide NAKAMURA wrote: > > This patch introduces statistics about transformation error (or almost > > error) > > factor at packet processing for developer. > > It is not a SNMP/MIB specification from IPsec/MIPv6 but a counter > > designed from current transformation source code. > > > > Comment please. > > Looks fine to me. But could you hold onto this for a few days? > I'm in the process of merging the input paths of IPv4 and IPv6. > Once that's done you'll only need to count things once rather > than once for IPv4 and again for IPv6. No problem, I'll fix my patches upon your work and resend them. Regards, -- Masahide NAKAMURA - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/3][XFRM]: Support packet processing error statistics.
On Mon, Oct 22, 2007 at 03:11:06PM +0900, Masahide NAKAMURA wrote:
> This patch introduces statistics about transformation error (or almost error)
> factor at packet processing for developer.
> It is not a SNMP/MIB specification from IPsec/MIPv6 but a counter
> designed from current transformation source code.
>
> Comment please.
Looks fine to me. But could you hold onto this for a few days?
I'm in the process of merging the input paths of IPv4 and IPv6.
Once that's done you'll only need to count things once rather
than once for IPv4 and again for IPv6.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 0/3][XFRM]: Support packet processing error statistics.
This patch introduces statistics about transformation error (or almost error) factor at packet processing for developer. It is not a SNMP/MIB specification from IPsec/MIPv6 but a counter designed from current transformation source code. Comment please. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
