summaryrefslogtreecommitdiff
path: root/net/netrom/af_netrom.c
diff options
context:
space:
mode:
authorWei Dong <weid@nanjing-fnst.com>2006-08-02 20:41:21 (GMT)
committerDavid S. Miller <davem@davemloft.net>2006-08-02 20:41:21 (GMT)
commitdafee490858f79e144c5e6cdd84ceb9efa20a3f1 (patch)
treeb14c78f41845026fd2ab161a7348d898a2fa6d3e /net/netrom/af_netrom.c
parent32c524d1c48b62be49fa1b1dd93fed10792debc0 (diff)
downloadlinux-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