diff options
author | Wei Dong <weid@nanjing-fnst.com> | 2006-08-02 20:41:21 (GMT) |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2006-08-02 20:41:21 (GMT) |
commit | dafee490858f79e144c5e6cdd84ceb9efa20a3f1 (patch) | |
tree | b14c78f41845026fd2ab161a7348d898a2fa6d3e /net/netrom/af_netrom.c | |
parent | 32c524d1c48b62be49fa1b1dd93fed10792debc0 (diff) | |
download | linux-fsl-qoriq-dafee490858f79e144c5e6cdd84ceb9efa20a3f1.tar.xz |
[IPV6]: SNMPv2 "ipv6IfStatsOutFragCreates" counter error
When I tested linux kernel 2.6.71.7 about statistics
"ipv6IfStatsOutFragCreates", and found that it couldn't increase
correctly. The criteria is RFC 2465:
ipv6IfStatsOutFragCreates OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of output datagram fragments that have
been generated as a result of fragmentation at
this output interface."
::= { ipv6IfStatsEntry 15 }
I think there are two issues in Linux kernel.
1st:
RFC2465 specifies the counter is "The number of output datagram
fragments...". I think increasing this counter after output a fragment
successfully is better. And it should not be increased even though a
fragment is created but failed to output.
2nd:
If we send a big ICMP/ICMPv6 echo request to a host, and receive
ICMP/ICMPv6 echo reply consisted of some fragments. As we know that in
Linux kernel first fragmentation occurs in ICMP layer(maybe saying
transport layer is better), but this is not the "real"
fragmentation,just do some "pre-fragment" -- allocate space for date,
and form a frag_list, etc. The "real" fragmentation happens in IP layer
-- set offset and MF flag and so on. So I think in "fast path" for
ip_fragment/ip6_fragment, if we send a fragment which "pre-fragment" by
upper layer we should also increase "ipv6IfStatsOutFragCreates".
Signed-off-by: Wei Dong <weid@nanjing-fnst.com>
Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/netrom/af_netrom.c')
0 files changed, 0 insertions, 0 deletions