linux-toradex.git/net/ipv6, branch v2.6.28

ipv6: silence log messages for locally generated multicast

2008-12-09T23:48:32+00:00

This patch fixes minor annoyance during transmission of unsolicited
neighbor advertisements from userspace to multicast addresses (as
far as I can see in RFC, this is allowed and the similar functionality
for IPv4 has been in arping for a long time).

Outgoing multicast packets get reinserted into local processing as if they
are received from the network. The machine thus sees its own NA and fills
the logs with error messages. This patch removes the message if NA has been
generated locally.

Signed-off-by: Jan Sembera 
Signed-off-by: David S. Miller

net: fix tiny output corruption of /proc/net/snmp6

2008-11-20T12:20:10+00:00

Because "name" is static, it can be occasionally be filled with
somewhat garbage if two processes read /proc/net/snmp6.

Also, remove useless casts and "-1" -- snprintf() correctly terminates it's
output.

Signed-off-by: Alexey Dobriyan 
Signed-off-by: David S. Miller

ipv6: use seq_release_private for ip6mr.c /proc entries

2008-11-20T12:16:12+00:00

In ip6mr.c, /proc entries /proc/net/ip6_mr_cache and /proc/net/ip6_mr_vif
are opened with seq_open_private(), thus seq_release_private() should be 
used to release them.
Should fix a small memory leak.

Signed-off-by: Benjamin Thery 
Signed-off-by: David S. Miller

ipv6: routing header fixes

2008-11-13T06:59:21+00:00

This patch fixes two bugs:

1. setsockopt() of anything but a Type 2 routing header should return
EINVAL instead of EPERM.  Noticed by Shan Wei
(shanwei@cn.fujitsu.com).

2. setsockopt()/sendmsg() of a Type 2 routing header with invalid
length or segments should return EINVAL.  These values are statically
fixed in RFC 3775, unlike the variable Type 0 was.

Signed-off-by: Brian Haley 
Signed-off-by: David S. Miller

ipv6: fix ip6_mr_init error path

2008-11-11T00:34:11+00:00

The order of cleanup operations in the error/exit section of ip6_mr_init()
is completely inversed. It should be the other way around.
Also a del_timer() is missing in the error path.

Signed-off-by: Benjamin Thery 
Signed-off-by: David S. Miller

ipv6: fix run pending DAD when interface becomes ready

2008-11-05T09:43:57+00:00

With some net devices types, an IPv6 address configured while the
interface was down can stay 'tentative' forever, even after the interface
is set up. In some case, pending IPv6 DADs are not executed when the
device becomes ready.

I observed this while doing some tests with kvm. If I assign an IPv6 
address to my interface eth0 (kvm driver rtl8139) when it is still down
then the address is flagged tentative (IFA_F_TENTATIVE). Then, I set
eth0 up, and to my surprise, the address stays 'tentative', no DAD is
executed and the address can't be pinged.

I also observed the same behaviour, without kvm, with virtual interfaces
types macvlan and veth.

Some easy steps to reproduce the issue with macvlan:

1. ip link add link eth0 type macvlan
2. ip -6 addr add 2003::ab32/64 dev macvlan0
3. ip addr show dev macvlan0
   ... 
   inet6 2003::ab32/64 scope global tentative
   ...
4. ip link set macvlan0 up
5. ip addr show dev macvlan0
   ...
   inet6 2003::ab32/64 scope global tentative
   ...
   Address is still tentative

I think there's a bug in net/ipv6/addrconf.c, addrconf_notify():
addrconf_dad_run() is not always run when the interface is flagged IF_READY.
Currently it is only run when receiving NETDEV_CHANGE event. Looks like
some (virtual) devices doesn't send this event when becoming up.

For both NETDEV_UP and NETDEV_CHANGE events, when the interface becomes
ready, run_pending should be set to 1. Patch below.

'run_pending = 1' could be moved below the if/else block but it makes 
the code less readable.

Signed-off-by: Benjamin Thery 
Signed-off-by: David S. Miller

xfrm: Have af-specific init_tempsel() initialize family field of temporary selector

2008-11-04T22:49:19+00:00

While adding MIGRATE support to strongSwan, Andreas Steffen noticed that
the selectors provided in XFRM_MSG_ACQUIRE have their family field
uninitialized (those in MIGRATE do have their family set).

Looking at the code, this is because the af-specific init_tempsel()
(called via afinfo->init_tempsel() in xfrm_init_tempsel()) do not set
the value.

Reported-by: Andreas Steffen 
Acked-by: Herbert Xu 
Signed-off-by: Arnaud Ebalard

udp: Fix the SNMP counter of UDP_MIB_INERRORS

2008-11-03T07:52:46+00:00

UDP packets received in udpv6_recvmsg() are not only IPv6 UDP packets, but
also have IPv4 UDP packets, so when do the counter of UDP_MIB_INERRORS in
udpv6_recvmsg(), we should check whether the packet is a IPv6 UDP packet
or a IPv4 UDP packet.

Signed-off-by: Wei Yongjun 
Signed-off-by: David S. Miller

udp: Fix the SNMP counter of UDP_MIB_INDATAGRAMS

2008-11-03T07:52:45+00:00

If UDP echo is sent to xinetd/echo-dgram, the UDP reply will be received
at the sender. But the SNMP counter of UDP_MIB_INDATAGRAMS will be not
increased, UDP6_MIB_INDATAGRAMS will be increased instead.

  Endpoint A                      Endpoint B
  UDP Echo request ----------->
  (IPv4, Dst port=7)
                   <----------    UDP Echo Reply
                                  (IPv4, Src port=7)

This bug is come from this patch cb75994ec311b2cd50e5205efdcc0696abd6675d.

It do counter UDP[6]_MIB_INDATAGRAMS until udp[v6]_recvmsg. Because
xinetd used IPv6 socket to receive UDP messages, thus, when received
UDP packet, the UDP6_MIB_INDATAGRAMS will be increased in function
udpv6_recvmsg() even if the packet is a IPv4 UDP packet.

This patch fixed the problem.

Signed-off-by: Wei Yongjun 
Signed-off-by: David S. Miller

udp: multicast packets need to check namespace

2008-11-02T04:22:23+00:00

Current UDP multicast delivery is not namespace aware.

Signed-off-by: Eric Dumazet 
Acked-by: Pavel Emelyanov 
Signed-off-by: David S. Miller