Re: [PATCH] [IPv4] Reply net unreachable ICMP message

2007-12-06 Thread Mitsuru Chinen 
On Thu, 6 Dec 2007 08:49:47 +0100
Jarek Poplawski [EMAIL PROTECTED] wrote:

 On 06-12-2007 07:31, Mitsuru Chinen wrote:
  IPv4 stack doesn't reply any ICMP destination unreachable message
  with net unreachable code when IP detagrams are being discarded
  because of no route could be found in the forwarding path.
  Incidentally, IPv6 stack replies such ICMPv6 message in the similar
  situation.
  
  Signed-off-by: Mitsuru Chinen [EMAIL PROTECTED]
  ---
   net/ipv4/route.c |2 ++
   1 files changed, 2 insertions(+), 0 deletions(-)
  
  diff --git a/net/ipv4/route.c b/net/ipv4/route.c
  index 6714bbc..ba85ec9 100644
  --- a/net/ipv4/route.c
  +++ b/net/ipv4/route.c
  @@ -1375,6 +1375,7 @@ static int ip_error(struct sk_buff *skb)
  break;
  case ENETUNREACH:
  code = ICMP_NET_UNREACH;
  +   IP_INC_STATS_BH(IPSTATS_MIB_INNOROUTES);
  break;
  case EACCES:
  code = ICMP_PKT_FILTERED;
  @@ -2004,6 +2005,7 @@ no_route:
  RT_CACHE_STAT_INC(in_no_route);
  spec_dst = inet_select_addr(dev, 0, RT_SCOPE_UNIVERSE);
  res.type = RTN_UNREACHABLE;
  +   err = -ENETUNREACH;
  goto local_input;
   
  /*
 
 This patch seems to be wrong. It overrides err codes from
 fib_lookup, where such decisions should be made.

fib_lookup() replies -ESRCH in this situation.
It is necessary to override the variable by the suitable error
number like the code under e_hostunreach label.

Best Regards,

Mitsuru Chinen [EMAIL PROTECTED]
--
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

[PATCH] [IPv4] Add strict check for replying net unreachable message

2007-12-06 Thread Mitsuru Chinen 
The patch `Reply net unreachable ICMP message' had a bug.
A route whose type is blockhole or prohibit type is treated as
unreachable type. The case where err is set to ENETUNREACH should
be that no route is found in the routing table only.

Signed-off-by: Mitsuru Chinen [EMAIL PROTECTED]
---
 net/ipv4/route.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 8a79f74..d2bc614 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1882,7 +1882,8 @@ no_route:
RT_CACHE_STAT_INC(in_no_route);
spec_dst = inet_select_addr(dev, 0, RT_SCOPE_UNIVERSE);
res.type = RTN_UNREACHABLE;
-   err = -ENETUNREACH;
+   if (err == -ESRCH)
+   err = -ENETUNREACH;
goto local_input;
 
/*
-- 
1.5.3.4

--
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: [PATCH] [IPv4] Reply net unreachable ICMP message

2007-12-06 Thread Mitsuru Chinen 
On Thu, 6 Dec 2007 09:47:33 +0100
Jarek Poplawski [EMAIL PROTECTED] wrote:

 On 06-12-2007 09:14, Mitsuru Chinen wrote:
  On Thu, 6 Dec 2007 08:49:47 +0100
  Jarek Poplawski [EMAIL PROTECTED] wrote:
  
  On 06-12-2007 07:31, Mitsuru Chinen wrote:
  IPv4 stack doesn't reply any ICMP destination unreachable message
  with net unreachable code when IP detagrams are being discarded
  because of no route could be found in the forwarding path.
  Incidentally, IPv6 stack replies such ICMPv6 message in the similar
  situation.
 ...
  This patch seems to be wrong. It overrides err codes from
  fib_lookup, where such decisions should be made.
  
  fib_lookup() replies -ESRCH in this situation.
  It is necessary to override the variable by the suitable error
  number like the code under e_hostunreach label.
 
 Probably I miss something, but I can't see how can you be sure it's
 only -ESRCH possible here? Isn't opt-action() in fib_rules_lookup()
 supposed to return this -ENETUNREACH when needed?

Oh, excuse me. I did mistake.
fib_rules_lookup() replies -ESRCH when no route is found. The case
it replies -ENETUNREACH is that user adds unreachable route.
However, if the err value is override with no check, a blackhole
or prohibit route is treated as a unreachable route.

As the patch is already applied, I will send another patch to add
a check for it.
Thank you very much for pointing out the issue!

Best Regards,

Mitsuru Chinen [EMAIL PROTECTED]
--
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

[PATCH] [IPv6] SNMP: Increment OutNoRoutes when connecting to unreachable network

2007-12-05 Thread Mitsuru Chinen 
IPv6 stack doesn't increment OutNoRoutes counter when IP datagrams
is being discarded because no route could be found to transmit them
to their destination. IPv6 stack should increment the counter.
Incidentally, IPv4 stack increments that counter in such situation.

Signed-off-by: Mitsuru Chinen [EMAIL PROTECTED]
---
 net/ipv6/ip6_output.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 89cca7c..388a098 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -960,6 +960,8 @@ static int ip6_dst_lookup_tail(struct sock *sk,
return 0;
 
 out_err_release:
+   if (err == -ENETUNREACH)
+   IP6_INC_STATS_BH(NULL, IPSTATS_MIB_OUTNOROUTES);
dst_release(*dst);
*dst = NULL;
return err;
-- 
1.5.3.4

--
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

[PATCH] [IPv4] Reply net unreachable ICMP message

2007-12-05 Thread Mitsuru Chinen 
IPv4 stack doesn't reply any ICMP destination unreachable message
with net unreachable code when IP detagrams are being discarded
because of no route could be found in the forwarding path.
Incidentally, IPv6 stack replies such ICMPv6 message in the similar
situation.

Signed-off-by: Mitsuru Chinen [EMAIL PROTECTED]
---
 net/ipv4/route.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 6714bbc..ba85ec9 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1375,6 +1375,7 @@ static int ip_error(struct sk_buff *skb)
break;
case ENETUNREACH:
code = ICMP_NET_UNREACH;
+   IP_INC_STATS_BH(IPSTATS_MIB_INNOROUTES);
break;
case EACCES:
code = ICMP_PKT_FILTERED;
@@ -2004,6 +2005,7 @@ no_route:
RT_CACHE_STAT_INC(in_no_route);
spec_dst = inet_select_addr(dev, 0, RT_SCOPE_UNIVERSE);
res.type = RTN_UNREACHABLE;
+   err = -ENETUNREACH;
goto local_input;
 
/*
-- 
1.5.3.4

--
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: [UDP6]: Restore sk_filter optimisation

2007-11-01 Thread Mitsuru Chinen 
On Wed, 31 Oct 2007 22:42:57 +0800
Herbert Xu [EMAIL PROTECTED] wrote:

 On Wed, Oct 31, 2007 at 11:05:45PM +0900, Mitsuru Chinen wrote:
 
 1. udp6InDatagrams is incremented instead of udpInErrors
 2. In userland, recvfrom() replies an error with EAGAIN.
recvfrom() wasn't aware of such a packet before.

Are these changes intentional?
 
  As far as I tested, this doesn't happen with the old code even if
  a filter is attached. However, this happen with the new code
  without a filter and I don't see this rather when a filter is
  attached. So, I'm afraid it's new.
 
 Sorry, I read the patch the wrong way around :)
 
 1) is just an accounting issue.  It shouldn't be too difficult
 to fix it up.  In fact, I think udpInErrors will still be
 incremented once we detect the error.
 
 2) shouldn't be an issue because we've already solved the
 problem by making poll/select do the checksum verification
 before indiciating that the socket is readable.
 
   And, we're not sure how much the optimization's benefit is.
   It is even worse when we are hand
 
 The checksum verification is costly because we have to bring
 the payload into cache.  Since filters are very rare it's
 worthwhile to postpone the checksum verification for the common
 case.
 
 Also as a general rule, we want to avoid divergent behaviour
 between IPv4 and IPv6.  So for changes like this we should
 really modify both stacks in future rather than have each
 stack do its own thing.

I got it. OK. I will submit a patch to postpone the udpInError
counter incrementation, either.

Thanks for your detailed explanation!

Best Regards,

Mitsuru Chinen [EMAIL PROTECTED]
-
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

[PATCH] [IPv6] SNMP: Restore Udp6InErrors incrementation

2007-11-01 Thread Mitsuru Chinen 
As the checksum verification is postponed till user calls recv or poll,
the inrementation of Udp6InErrors counter should be also postponed.
Currently, it is postponed in non-blocking operation case. However it
should be postponed in all case like the IPv4 code.

Signed-off-by: Mitsuru Chinen [EMAIL PROTECTED]
---
 net/ipv6/udp.c |5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index caebad6..8344d8c 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -205,12 +205,11 @@ out:
return err;
 
 csum_copy_err:
+   UDP6_INC_STATS_USER(UDP_MIB_INERRORS, is_udplite);
skb_kill_datagram(sk, skb, flags);
 
-   if (flags  MSG_DONTWAIT) {
-   UDP6_INC_STATS_USER(UDP_MIB_INERRORS, is_udplite);
+   if (flags  MSG_DONTWAIT)
return -EAGAIN;
-   }
goto try_again;
 }
 
-- 
1.5.3.4

-
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: [UDP6]: Restore sk_filter optimisation

2007-10-31 Thread Mitsuru Chinen 
On Mon, 29 Oct 2007 20:53:28 +0800
Herbert Xu [EMAIL PROTECTED] wrote:

 On Mon, Oct 29, 2007 at 03:33:20PM +0900, Mitsuru Chinen wrote:
  Hello Herbert,
  
  Let me ask a question about this patch.
  After this patch was applied, 2 of the protocol stack behaviors were
  changed when it receives a UDP datagram with broken checksum:
  
   1. udp6InDatagrams is incremented instead of udpInErrors
   2. In userland, recvfrom() replies an error with EAGAIN.
  recvfrom() wasn't aware of such a packet before.
  
  Are these changes intentional?
 
 It wasn't my intention if that's what you mean :)
 
 However, this would've happened with the old code anyway if
 someone had a filter attached so this isn't new.

 If it's a problem then we should just get it fixed.

As far as I tested, this doesn't happen with the old code even if
a filter is attached. However, this happen with the new code
without a filter and I don't see this rather when a filter is
attached. So, I'm afraid it's new.

By the way, could you answer the Yoshifuji-san's question?
I think the code where we should fix depends on this. 

On Mon, 29 Oct 2007 15:41:50 +0900 (JST)
YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED] wrote:

 And, we're not sure how much the optimization's benefit is.
 It is even worse when we are handling multicast packets.

Thank you,

Mitsuru Chinen [EMAIL PROTECTED]
-
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: [UDP6]: Restore sk_filter optimisation

2007-10-28 Thread Mitsuru Chinen 
Hello Herbert,

Let me ask a question about this patch.
After this patch was applied, 2 of the protocol stack behaviors were
changed when it receives a UDP datagram with broken checksum:

 1. udp6InDatagrams is incremented instead of udpInErrors
 2. In userland, recvfrom() replies an error with EAGAIN.
recvfrom() wasn't aware of such a packet before.

Are these changes intentional?

Best Regards,

Mitsuru Chinen [EMAIL PROTECTED]


On Tue, 6 Mar 2007 12:20:10 +1100
Herbert Xu [EMAIL PROTECTED] wrote:

 Hi Dave:
 
 [UDP6]: Restore sk_filter optimisation
 
 This reverts the changeset
 
 [IPV6]: UDPv6 checksum.
 
 We always need to check UDPv6 checksum because it is mandatory.
 
 The sk_filter optimisation has nothing to do whether we verify the
 checksum.  It simply postpones it to the point when the user calls
 recv or poll.
 
 Signed-off-by: Herbert Xu [EMAIL PROTECTED]
 
 Cheers,
 -- 
 Visit Openswan at http://www.openswan.org/
 Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
 Home Page: http://gondor.apana.org.au/~herbert/
 PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
 --
 diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
 index 0ad4719..4474480 100644
 --- a/net/ipv6/udp.c
 +++ b/net/ipv6/udp.c
 @@ -279,8 +279,10 @@ int udpv6_queue_rcv_skb(struct sock * sk, struct sk_buff 
 *skb)
   }
   }
 
 - if (udp_lib_checksum_complete(skb))
 - goto drop;
 + if (sk-sk_filter) {
 + if (udp_lib_checksum_complete(skb))
 + goto drop;
 + }
 
   if ((rc = sock_queue_rcv_skb(sk,skb))  0) {
   /* Note that an ENOMEM error is charged twice */
-
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

[PATCH] [IPv4] SNMP: Refer correct memory location to display ICMP out-going statistics

2007-10-25 Thread Mitsuru Chinen 
While displaying ICMP out-going statistics as Outname counters in
/proc/net/snmp, the memory location for ICMP in-coming statistics
was referred by mistake.

Acked-by: David L Stevens [EMAIL PROTECTED] 
Signed-off-by: Mitsuru Chinen [EMAIL PROTECTED]
---
 net/ipv4/proc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index fd16cb8..b7f7f8a 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -312,7 +312,7 @@ static void icmp_put(struct seq_file *seq)
for (i=0; icmpmibmap[i].name != NULL; i++)
seq_printf(seq,  %lu,
snmp_fold_field((void **) icmpmsg_statistics,
-   icmpmibmap[i].index));
+   icmpmibmap[i].index | 0x100));
 }
 
 /*
-- 
1.5.3.4

-
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

[PATCH] [IPV6] Defer IPv6 device initialization until a valid qdisc is specified

2007-10-09 Thread Mitsuru Chinen 
To judge the timing for DAD, netif_carrier_ok() is used. However,
there is a possibility that dev-qdisc stays noop_qdisc even if
netif_carrier_ok() returns true. In that case, DAD NS is not sent out.
We need to defer the IPv6 device initialization until a valid qdisc
is specified.

Signed-off-by: Mitsuru Chinen [EMAIL PROTECTED]
Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
---
 net/ipv6/addrconf.c |   13 ++---
 1 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 6d5c3c2..da8c79c 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -74,6 +74,7 @@
 #include net/tcp.h
 #include net/ip.h
 #include net/netlink.h
+#include net/pkt_sched.h
 #include linux/if_tunnel.h
 #include linux/rtnetlink.h
 
@@ -213,6 +214,12 @@ static struct ipv6_devconf ipv6_devconf_dflt __read_mostly 
= {
 const struct in6_addr in6addr_any = IN6ADDR_ANY_INIT;
 const struct in6_addr in6addr_loopback = IN6ADDR_LOOPBACK_INIT;
 
+/* Check if a valid qdisc is available */
+static inline int addrconf_qdisc_ok(struct net_device *dev)
+{
+   return (dev-qdisc != noop_qdisc);
+}
+
 static void addrconf_del_timer(struct inet6_ifaddr *ifp)
 {
if (del_timer(ifp-timer))
@@ -384,7 +391,7 @@ static struct inet6_dev * ipv6_add_dev(struct net_device 
*dev)
}
 #endif
 
-   if (netif_running(dev)  netif_carrier_ok(dev))
+   if (netif_running(dev)  addrconf_qdisc_ok(dev))
ndev-if_flags |= IF_READY;
 
ipv6_mc_init_dev(ndev);
@@ -2283,7 +2290,7 @@ static int addrconf_notify(struct notifier_block *this, 
unsigned long event,
break;
 
if (event == NETDEV_UP) {
-   if (!netif_carrier_ok(dev)) {
+   if (!addrconf_qdisc_ok(dev)) {
/* device is not ready yet. */
printk(KERN_INFO
ADDRCONF(NETDEV_UP): %s: 
@@ -2295,7 +2302,7 @@ static int addrconf_notify(struct notifier_block *this, 
unsigned long event,
if (idev)
idev-if_flags |= IF_READY;
} else {
-   if (!netif_carrier_ok(dev)) {
+   if (!addrconf_qdisc_ok(dev)) {
/* device is still not ready. */
break;
}
-- 
1.5.2.2

-
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: [PATCH 6/6] [IPV4] SNMP: Display new statistics at /proc/net/snmp

2007-05-11 Thread Mitsuru Chinen 
On Mon, 7 May 2007 20:29:05 +0900
Mitsuru Chinen [EMAIL PROTECTED] wrote:

 On Thu, 03 May 2007 03:15:46 -0700 (PDT)
 David Miller [EMAIL PROTECTED] wrote:
 
  From: Mitsuru Chinen [EMAIL PROTECTED]
  Date: Wed, 2 May 2007 10:05:13 +0900
  
   [IPV4] SNMP: Display new statistics at /proc/net/netstat
   
   This displays the statistics specified in the updated IP-MIB RFC
   (RFC4293) in /proc/net/netstat. The reason why these are not added
   to /proc/net/snmp is that some existing utilities are developed under
   the assumption that ipstat items in /proc/net/snmp is unchanged.
   
   Signed-off-by: Mitsuru Chinen [EMAIL PROTECTED]
  
  Magic constant 17 is not the best, somebody will break this
  next time this table it touched.
  
  Why not use another sentinel, or something like that, to mark
  the entry groups?
 
 Excuse me, but I can't catch why this magic constant is not good.
 When we don't increase the number of entries in /proc/net/snmp,
 I think the start number of new entries which is displayed in
 /proc/net/netstat would be fixed value.

Thanks to Yoshifuji-san and USAGI guys, I'm able to remove
magic constant totally. How about this?


[IPV4] SNMP: Display new statistics at /proc/net/netstat

This displays the statistics specified in the updated IP-MIB RFC
(RFC4293) in /proc/net/netstat. The reason why these are not displayed
in /proc/net/snmp is that some existing utilities are developed under
the assumption which ipstat items in /proc/net/snmp is unchanged.

Signed-off-by: Mitsuru Chinen [EMAIL PROTECTED]


---

 net/ipv4/proc.c |   21 +
 1 files changed, 21 insertions(+), 0 deletions(-)

fc11ca885424125a2add36ab6ff29aa8e4302d4b
diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index 37ab580..cdbc6c1 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -109,6 +109,17 @@ static const struct snmp_mib snmp4_ipsta
SNMP_MIB_SENTINEL
 };
 
+/* Following RFC4293 items are displayed in /proc/net/netstat */
+static const struct snmp_mib snmp4_ipextstats_list[] = {
+   SNMP_MIB_ITEM(InNoRoutes, IPSTATS_MIB_INNOROUTES),
+   SNMP_MIB_ITEM(InTruncatedPkts, IPSTATS_MIB_INTRUNCATEDPKTS),
+   SNMP_MIB_ITEM(InMcastPkts, IPSTATS_MIB_INMCASTPKTS),
+   SNMP_MIB_ITEM(OutMcastPkts, IPSTATS_MIB_OUTMCASTPKTS),
+   SNMP_MIB_ITEM(InBcastPkts, IPSTATS_MIB_INBCASTPKTS),
+   SNMP_MIB_ITEM(OutBcastPkts, IPSTATS_MIB_OUTBCASTPKTS),
+   SNMP_MIB_SENTINEL
+};
+
 static const struct snmp_mib snmp4_icmp_list[] = {
SNMP_MIB_ITEM(InMsgs, ICMP_MIB_INMSGS),
SNMP_MIB_ITEM(InErrors, ICMP_MIB_INERRORS),
@@ -338,6 +349,16 @@ static int netstat_seq_show(struct seq_f
   snmp_fold_field((void **)net_statistics,
   snmp4_net_list[i].entry));
 
+   seq_puts(seq, \nIpExt:);
+   for (i = 0; snmp4_ipextstats_list[i].name != NULL; i++)
+   seq_printf(seq,  %s, snmp4_ipextstats_list[i].name);
+
+   seq_puts(seq, \nIpExt:);
+   for (i = 0; snmp4_ipextstats_list[i].name != NULL; i++)
+   seq_printf(seq,  %lu,
+  snmp_fold_field((void **)ip_statistics,
+  snmp4_ipextstats_list[i].entry));
+
seq_putc(seq, '\n');
return 0;
 }
-- 
1.3.3


-
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: [PATCH 6/6] [IPV4] SNMP: Display new statistics at /proc/net/snmp

2007-05-01 Thread Mitsuru Chinen 
On Mon, 30 Apr 2007 00:50:14 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:

 From: Mitsuru Chinen [EMAIL PROTECTED]
 Date: Fri, 27 Apr 2007 16:46:30 +0900
 
  On Tue, 17 Apr 2007 20:14:36 +0900
  Mitsuru Chinen [EMAIL PROTECTED] wrote:
  
   This displays the statistics specified in the updated IP-MIB RFC
   (RFC4293) at /proc/net/snmp. As new statistics are placed as the
   last elements, this change wouldn't affect netstat, net-snmp, etc.
  
  I'm sorry. I found adding new entries to /proc/net/snmp affects
  net-snmp. I'm ashamed of my inadequate investigation.
  
  However the other patches to support new statistics will be useful.
  Could you pick up 1st to 5th patches?
 
 You could display them on a new line of /proc/net/netstat, which
 we currently use to display extensions to the TCP snmp variables.
 
 It is just one idea.

Thanks for your proposal! I created a patch based on your idea.
How about this?


[IPV4] SNMP: Display new statistics at /proc/net/netstat

This displays the statistics specified in the updated IP-MIB RFC
(RFC4293) in /proc/net/netstat. The reason why these are not added
to /proc/net/snmp is that some existing utilities are developed under
the assumption that ipstat items in /proc/net/snmp is unchanged.

Signed-off-by: Mitsuru Chinen [EMAIL PROTECTED]


---

 net/ipv4/proc.c |   22 --
 1 files changed, 20 insertions(+), 2 deletions(-)

7d86d2fc56dee38e18b4c8b3d2dc15d7d27f8a09
diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index 37ab580..38f24f9 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -88,6 +88,7 @@ static const struct file_operations sock
 };
 
 /* snmp items */
+#define IPSTATS_RFC4293_START 17
 static const struct snmp_mib snmp4_ipstats_list[] = {
SNMP_MIB_ITEM(InReceives, IPSTATS_MIB_INRECEIVES),
SNMP_MIB_ITEM(InHdrErrors, IPSTATS_MIB_INHDRERRORS),
@@ -106,6 +107,13 @@ static const struct snmp_mib snmp4_ipsta
SNMP_MIB_ITEM(FragOKs, IPSTATS_MIB_FRAGOKS),
SNMP_MIB_ITEM(FragFails, IPSTATS_MIB_FRAGFAILS),
SNMP_MIB_ITEM(FragCreates, IPSTATS_MIB_FRAGCREATES),
+   /* Following RFC4293 items are displayed in /proc/net/netstat */
+   SNMP_MIB_ITEM(InNoRoutes, IPSTATS_MIB_INNOROUTES),
+   SNMP_MIB_ITEM(InTruncatedPkts, IPSTATS_MIB_INTRUNCATEDPKTS),
+   SNMP_MIB_ITEM(InMcastPkts, IPSTATS_MIB_INMCASTPKTS),
+   SNMP_MIB_ITEM(OutMcastPkts, IPSTATS_MIB_OUTMCASTPKTS),
+   SNMP_MIB_ITEM(InBcastPkts, IPSTATS_MIB_INBCASTPKTS),
+   SNMP_MIB_ITEM(OutBcastPkts, IPSTATS_MIB_OUTBCASTPKTS),
SNMP_MIB_SENTINEL
 };
 
@@ -245,13 +253,13 @@ static int snmp_seq_show(struct seq_file
 
seq_puts(seq, Ip: Forwarding DefaultTTL);
 
-   for (i = 0; snmp4_ipstats_list[i].name != NULL; i++)
+   for (i = 0; i  IPSTATS_RFC4293_START; i++)
seq_printf(seq,  %s, snmp4_ipstats_list[i].name);
 
seq_printf(seq, \nIp: %d %d,
ipv4_devconf.forwarding ? 1 : 2, sysctl_ip_default_ttl);
 
-   for (i = 0; snmp4_ipstats_list[i].name != NULL; i++)
+   for (i = 0; i  IPSTATS_RFC4293_START; i++)
seq_printf(seq,  %lu,
   snmp_fold_field((void **)ip_statistics,
   snmp4_ipstats_list[i].entry));
@@ -338,6 +346,16 @@ static int netstat_seq_show(struct seq_f
   snmp_fold_field((void **)net_statistics,
   snmp4_net_list[i].entry));
 
+   seq_puts(seq, \nIpExt:);
+   for (i = IPSTATS_RFC4293_START; snmp4_ipstats_list[i].name != NULL; i++)
+   seq_printf(seq,  %s, snmp4_ipstats_list[i].name);
+
+   seq_puts(seq, \nIpExt:);
+   for (i = IPSTATS_RFC4293_START; snmp4_ipstats_list[i].name != NULL; i++)
+   seq_printf(seq,  %lu,
+  snmp_fold_field((void **)ip_statistics,
+  snmp4_ipstats_list[i].entry));
+
seq_putc(seq, '\n');
return 0;
 }
-- 
1.3.3

-
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: [PATCH 6/6] [IPV4] SNMP: Display new statistics at /proc/net/snmp

2007-04-27 Thread Mitsuru Chinen 
On Tue, 17 Apr 2007 20:14:36 +0900
Mitsuru Chinen [EMAIL PROTECTED] wrote:

 This displays the statistics specified in the updated IP-MIB RFC
 (RFC4293) at /proc/net/snmp. As new statistics are placed as the
 last elements, this change wouldn't affect netstat, net-snmp, etc.

I'm sorry. I found adding new entries to /proc/net/snmp affects
net-snmp. I'm ashamed of my inadequate investigation.

However the other patches to support new statistics will be useful.
Could you pick up 1st to 5th patches?

Thank you,

Mitsuru Chinen [EMAIL PROTECTED]

-
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

[PATCH 0/6] SNMP: new statistics specified in RFC4293

2007-04-17 Thread Mitsuru Chinen 
Hi all,

Let me post a patch set to net-2.6.22 tree for new IPv4 statistics
specified in the updated RFC (RFC4293). All of them (except broadcast
statistics) are already supported in IPv6 stack. However they are not
supported in IPv4 stack yet.

The patch set consists of following 6 patches:

  [PATCH 1/6] SNMP: Add definitions for {In,Out}BcastPkts
  [PATCH 2/6] [IPV4] SNMP: Support InNoRoutes
  [PATCH 3/6] [IPV4] SNMP: Support InTruncatedPkts
  [PATCH 4/6] [IPV4] SNMP: Support InMcastPkts and InBcastPkts
  [PATCH 5/6] [IPV4] SNMP: Support OutMcastPkts and OutBcastPkts
  [PATCH 6/6] [IPV4] SNMP: Display new statistics at /proc/net/snmp

Best Regards,

Mitsuru Chinen [EMAIL PROTECTED]
-
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

[PATCH 1/6] SNMP: Add definitions for {In,Out}BcastPkts

2007-04-17 Thread Mitsuru Chinen 
The updated IP-MIB RFC (RFC4293) specifys new objects, InBcastPkts
and OutBcastPkts. This adds definitions for them.

Signed-off-by: Mitsuru Chinen [EMAIL PROTECTED]
---
 include/linux/snmp.h |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/include/linux/snmp.h b/include/linux/snmp.h
index 854aa6b..802b3a3 100644
--- a/include/linux/snmp.h
+++ b/include/linux/snmp.h
@@ -40,6 +40,8 @@ enum
IPSTATS_MIB_FRAGCREATES,/* FragCreates */
IPSTATS_MIB_INMCASTPKTS,/* InMcastPkts */
IPSTATS_MIB_OUTMCASTPKTS,   /* OutMcastPkts */
+   IPSTATS_MIB_INBCASTPKTS,/* InBcastPkts */
+   IPSTATS_MIB_OUTBCASTPKTS,   /* OutBcastPkts */
__IPSTATS_MIB_MAX
 };
 
-- 
1.4.3.4

-
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

[PATCH 2/6] [IPV4] SNMP: Support InNoRoutes

2007-04-17 Thread Mitsuru Chinen 
An IP datagram which is being discarded because of no routes in the
forwarding path should be counted as InNoRoutes.

Signed-off-by: Mitsuru Chinen [EMAIL PROTECTED]
---
 net/ipv4/ip_input.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 324e7e0..63ab523 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -340,6 +340,8 @@ static inline int ip_rcv_finish(struct s
if (unlikely(err)) {
if (err == -EHOSTUNREACH)
IP_INC_STATS_BH(IPSTATS_MIB_INADDRERRORS);
+   else if (err == -ENETUNREACH)
+   IP_INC_STATS_BH(IPSTATS_MIB_INNOROUTES);
goto drop;
}
}
-- 
1.4.3.4

-
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

[PATCH 3/6] [IPV4] SNMP: Support InTruncatedPkts

2007-04-17 Thread Mitsuru Chinen 
An IP datagram which is being discarded because the datagram frame
didn't carry enough data should be counted as InTruncatedPkts.

Signed-off-by: Mitsuru Chinen [EMAIL PROTECTED]
---
 net/ipv4/ip_input.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 63ab523..c8c455d 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -416,7 +416,10 @@ int ip_rcv(struct sk_buff *skb, struct n
goto inhdr_error;
 
len = ntohs(iph-tot_len);
-   if (skb-len  len || len  (iph-ihl*4))
+   if (skb-len  len) {
+   IP_INC_STATS_BH(IPSTATS_MIB_INTRUNCATEDPKTS);
+   goto drop;
+   } else if (len  (iph-ihl*4))
goto inhdr_error;
 
/* Our transport medium may have padded the buffer out. Now we know it
-- 
1.4.3.4

-
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

[PATCH 4/6] [IPV4] SNMP: Support InMcastPkts and InBcastPkts

2007-04-17 Thread Mitsuru Chinen 
A received IP multicast datagram should be counted as InMcastPkts.
By the same token, a received IP broadcast datagram should be
counted as InBcastPkts.

Signed-off-by: Mitsuru Chinen [EMAIL PROTECTED]
---
 net/ipv4/ip_input.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index c8c455d..9706939 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -329,6 +329,7 @@ drop:
 static inline int ip_rcv_finish(struct sk_buff *skb)
 {
const struct iphdr *iph = ip_hdr(skb);
+   struct rtable *rt;
 
/*
 *  Initialise the virtual path cache for the packet. It describes
@@ -360,6 +361,12 @@ static inline int ip_rcv_finish(struct s
if (iph-ihl  5  ip_rcv_options(skb))
goto drop;
 
+   rt = (struct rtable*)skb-dst;
+   if (rt-rt_type == RTN_MULTICAST)
+   IP_INC_STATS_BH(IPSTATS_MIB_INMCASTPKTS);
+   else if (rt-rt_type == RTN_BROADCAST)
+   IP_INC_STATS_BH(IPSTATS_MIB_INBCASTPKTS);
+
return dst_input(skb);
 
 drop:
-- 
1.4.3.4

-
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

[PATCH 5/6] [IPV4] SNMP: Support OutMcastPkts and OutBcastPkts

2007-04-17 Thread Mitsuru Chinen 
A transmitted IP multicast datagram should be counted as OutMcastPkts.
By the same token, a transmitted IP broadcast datagram should be
counted as OutBcastPkts.

Signed-off-by: Mitsuru Chinen [EMAIL PROTECTED]
---
 net/ipv4/ip_output.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 704bc44..4442185 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -160,9 +160,15 @@ EXPORT_SYMBOL_GPL(ip_build_and_send_pkt)
 static inline int ip_finish_output2(struct sk_buff *skb)
 {
struct dst_entry *dst = skb-dst;
+   struct rtable *rt = (struct rtable *)dst;
struct net_device *dev = dst-dev;
int hh_len = LL_RESERVED_SPACE(dev);
 
+   if (rt-rt_type == RTN_MULTICAST)
+   IP_INC_STATS(IPSTATS_MIB_OUTMCASTPKTS);
+   else if (rt-rt_type == RTN_BROADCAST)
+   IP_INC_STATS(IPSTATS_MIB_OUTBCASTPKTS);
+
/* Be paranoid, rather than too clever. */
if (unlikely(skb_headroom(skb)  hh_len  dev-hard_header)) {
struct sk_buff *skb2;
-- 
1.4.3.4

-
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

[PATCH 6/6] [IPV4] SNMP: Display new statistics at /proc/net/snmp

2007-04-17 Thread Mitsuru Chinen 
This displays the statistics specified in the updated IP-MIB RFC
(RFC4293) at /proc/net/snmp. As new statistics are placed as the
last elements, this change wouldn't affect netstat, net-snmp, etc.

Signed-off-by: Mitsuru Chinen [EMAIL PROTECTED]
---
 net/ipv4/proc.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index ae68a69..cc4c80a 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -119,6 +119,12 @@ static const struct snmp_mib snmp4_ipsta
SNMP_MIB_ITEM(FragOKs, IPSTATS_MIB_FRAGOKS),
SNMP_MIB_ITEM(FragFails, IPSTATS_MIB_FRAGFAILS),
SNMP_MIB_ITEM(FragCreates, IPSTATS_MIB_FRAGCREATES),
+   SNMP_MIB_ITEM(InNoRoutes, IPSTATS_MIB_INNOROUTES),
+   SNMP_MIB_ITEM(InTruncatedPkts, IPSTATS_MIB_INTRUNCATEDPKTS),
+   SNMP_MIB_ITEM(InMcastPkts, IPSTATS_MIB_INMCASTPKTS),
+   SNMP_MIB_ITEM(OutMcastPkts, IPSTATS_MIB_OUTMCASTPKTS),
+   SNMP_MIB_ITEM(InBcastPkts, IPSTATS_MIB_INBCASTPKTS),
+   SNMP_MIB_ITEM(OutBcastPkts, IPSTATS_MIB_OUTBCASTPKTS),
SNMP_MIB_SENTINEL
 };
 
-- 
1.4.3.4

-
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

[PATCH] [IPv6] Exclude truncated packets from InHdrErrors statistics

2007-04-03 Thread Mitsuru Chinen 
Incoming trancated packets are counted as not only InTruncatedPkts but
also InHdrErrors. They should be counted as InTruncatedPkts only.

Signed-off-by: Mitsuru Chinen [EMAIL PROTECTED]
---
 net/ipv6/ip6_input.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c
index f225fa1..be0ee8a 100644
--- a/net/ipv6/ip6_input.c
+++ b/net/ipv6/ip6_input.c
@@ -108,8 +108,10 @@ int ipv6_rcv(struct sk_buff *skb, struct
 
/* pkt_len may be zero if Jumbo payload option is present */
if (pkt_len || hdr-nexthdr != NEXTHDR_HOP) {
-   if (pkt_len + sizeof(struct ipv6hdr)  skb-len)
-   goto truncated;
+   if (pkt_len + sizeof(struct ipv6hdr)  skb-len) {
+   IP6_INC_STATS_BH(idev, IPSTATS_MIB_INTRUNCATEDPKTS);
+   goto drop;
+   }
if (pskb_trim_rcsum(skb, pkt_len + sizeof(struct ipv6hdr))) {
IP6_INC_STATS_BH(idev, IPSTATS_MIB_INHDRERRORS);
goto drop;
@@ -128,8 +130,6 @@ int ipv6_rcv(struct sk_buff *skb, struct
rcu_read_unlock();
 
return NF_HOOK(PF_INET6,NF_IP6_PRE_ROUTING, skb, dev, NULL, 
ip6_rcv_finish);
-truncated:
-   IP6_INC_STATS_BH(idev, IPSTATS_MIB_INTRUNCATEDPKTS);
 err:
IP6_INC_STATS_BH(idev, IPSTATS_MIB_INHDRERRORS);
 drop:
-- 
1.4.3.4

-
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: [PATCH] Ensure IF_READY is unset when link is not ready

2007-03-07 Thread Mitsuru Chinen 
On Wed, 07 Mar 2007 15:54:38 -0800 (PST)
David Miller [EMAIL PROTECTED] wrote:

 From: Herbert Xu [EMAIL PROTECTED]
 Date: Thu, 08 Mar 2007 10:47:56 +1100
 
  Mitsuru Chinen [EMAIL PROTECTED] wrote:
   
   On linux-2.6.21-rc2 or later, IPv6 link-local address is not assigned to
   some kind of interfaces during system start-up. (I found this issue
   occures with e100, e1000 and tg3.)
  
  Here is an alternative fix.
  
  [IPV6]: Do not set IF_READY if device is down
  
  Now that we add the IPv6 device at registration time we don't need
  to set IF_READY in ipv6_add_dev anymore because we will always get
  a NETDEV_UP event later on should the device ever become ready.
  
  Signed-off-by: Herbert Xu [EMAIL PROTECTED]
 
 Indeed, this looks like it will do the right thing.
 
 And if you look into the history of the code in this area
 I think you'll find that this snippet being removed existed
 exactly because inet6_dev creation happened long after the
 device was registered.

I understand. Thanks.
And I thank Herbert to provide suitable fix.

Best Regards,

Mitsuru Chinen [EMAIL PROTECTED]

-
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

[PATCH] Ensure IF_READY is unset when link is not ready

2007-03-05 Thread Mitsuru Chinen 
Hi there,

On linux-2.6.21-rc2 or later, IPv6 link-local address is not assigned to
some kind of interfaces during system start-up. (I found this issue
occures with e100, e1000 and tg3.)

This issue comes from the change that inet6_dev is allocated when
NETDEV_REGISTER event occurs. The allocation code is at ipv6_add_dev()
in net/ipv6/addrinfo.c. At the code, IF_READY bit would be set when the
link is ready. The link readyness is verified by netif_caeeir_ok().
However as the drivers don't call netif_carrier_off() prior to calling
register_netdev(), netif_caeeir_ok() returns true in spite of the
actual link state.

Here's a work around patch. This make IF_READY unset when NETDEV_UP
event occurs and the link is not ready. This patch may not be an
fundamental fix. But I don't have any other idea now.

Signed-off-by: Mitsuru Chinen [EMAIL PROTECTED]
---
 net/ipv6/addrconf.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index e16f1bb..1593cd1 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2196,6 +2196,7 @@ static int addrconf_notify(struct notifi
ADDRCONF(NETDEV_UP): %s: 
link is not ready\n,
dev-name);
+   idev-if_flags = ~IF_READY;
break;
}
 
-- 
1.4.3.4

-
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: (usagi-core 31424) Re: [PATCH 7/13] [RFC] [IPV6] Move source address selection into route lookup.

2006-10-19 Thread Mitsuru Chinen 

Hello Ville,

Ville Nuorvala wrote:

Mitsuru-san,

could you apply patch #12 and rerun the test? I think this particular
problem is caused by the routing cache entry not having a valid source
address in the first place. As ip6_dst_lookup() doesn't do the source
address lookup anymore, it is critical that we only store cache entries
with complete address data for both destination and source.

These two patches apparently shouldn't have been split in the first
place. Sorry!


I'm afraid patch #12 doesn't work for this issue.

Although I applied patch #12, I still got fails.
The test log is the same as the last one.
When I applied all patches, I got fails, either.

Best Regards,
--
Mitsuru Chinen [EMAIL PROTECTED]

-
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: [PATCH 7/13] [RFC] [IPV6] Move source address selection into route lookup.

2006-10-17 Thread Mitsuru Chinen 

YOSHIFUJI Hideaki / 吉藤英明 wrote:

In article [EMAIL PROTECTED] (at Tue, 17 Oct 2006 10:01:24 +0200), Jean-Mickael 
Guerin [EMAIL PROTECTED] says:


Although this conversion is very clean and the next patch
is very logic, I'm going to hold on all patches from 7 onward
so there is some time for some discussion of the RFC'ness
of them :-)

With regard to RFC'ness, passing self tests TAHI Ready Logo 2 with 
SUBTREE

turned on could be a valuable feedback.


Have you done it?

We've been trying to pass that, but we failed to compile;
we probably used wrong tree...


Excuse me. I overlooked an error message from patch command.
When I appiled the patch manually, we could compile them.

We will double-check these patches with TAHI, either.
And then, we will report the results.

Best Regards,
--
Mitsuru Chinen [EMAIL PROTECTED]

-
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