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 lin
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
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 IPse
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
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
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 mismatc
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 on
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
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 id
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) som
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/
11 matches
Mail list logo
