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

IPv6: fix IPV6_RECVERR handling of locally-generated errors

2010-05-06T04:32:40+00:00

I noticed when I added support for IPV6_DONTFRAG that if you set
IPV6_RECVERR and tried to send a UDP packet larger than 64K to an
IPv6 destination, you'd correctly get an EMSGSIZE, but reading from
MSG_ERRQUEUE returned the incorrect address in the cmsg:

struct msghdr:
	 msg_name         0x7fff8f3c96d0
	 msg_namelen      28
struct sockaddr_in6:
	 sin6_family      10
	 sin6_port        7639
	 sin6_flowinfo    0
	 sin6_addr        ::ffff:38.32.0.0
	 sin6_scope_id    0  ((null))

It should have returned this in my case:

struct msghdr:
	 msg_name         0x7fffd866b510
	 msg_namelen      28
struct sockaddr_in6:
	 sin6_family      10
	 sin6_port        7639
	 sin6_flowinfo    0
	 sin6_addr        2620:0:a09:e000:21f:29ff:fe57:f88b
	 sin6_scope_id    0  ((null))

The problem is that ipv6_recv_error() assumes that if the error
wasn't generated by ICMPv6, it's an IPv4 address sitting there,
and proceeds to create a v4-mapped address from it.

Change ipv6_icmp_error() and ipv6_local_error() to set skb->protocol
to htons(ETH_P_IPV6) so that ipv6_recv_error() knows the address
sitting right after the extended error is IPv6, else it will
incorrectly map the first octet into an IPv4-mapped IPv6 address
in the cmsg structure returned in a recvmsg() call to obtain
the error.

Signed-off-by: Brian Haley 

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Signed-off-by: David S. Miller

ipv6: Fix default multicast hops setting.

2010-05-04T06:42:27+00:00

As per RFC 3493 the default multicast hops setting
for a socket should be "1" just like ipv4.

Ironically we have a IPV6_DEFAULT_MCASTHOPS macro
it just wasn't being used.

Reported-by: Elliot Hughes 
Signed-off-by: David S. Miller

Revert "tcp: bind() fix when many ports are bound"

2010-04-28T18:25:59+00:00

This reverts two commits:

fda48a0d7a8412cedacda46a9c0bf8ef9cd13559
tcp: bind() fix when many ports are bound

and a follow-on fix for it:

6443bb1fc2050ca2b6585a3fa77f7833b55329ed
ipv6: Fix inet6_csk_bind_conflict()

It causes problems with binding listening sockets when time-wait
sockets from a previous instance still are alive.

It's too late to keep fiddling with this so late in the -rc
series, and we'll deal with it in net-next-2.6 instead.

Signed-off-by: David S. Miller

ipv6: Fix inet6_csk_bind_conflict()

2010-04-25T22:09:42+00:00

Commit fda48a0d7a84 (tcp: bind() fix when many ports are bound)
introduced a bug on IPV6 part.
We should not call ipv6_addr_any(inet6_rcv_saddr(sk2)) but
ipv6_addr_any(inet6_rcv_saddr(sk)) because sk2 can be IPV4, while sk is
IPV6.

Reported-by: Michael S. Tsirkin 
Signed-off-by: Eric Dumazet 
Tested-by: Michael S. Tsirkin 
Signed-off-by: David S. Miller

tcp: bind() fix when many ports are bound

2010-04-23T02:06:06+00:00

Port autoselection done by kernel only works when number of bound
sockets is under a threshold (typically 30000).

When this threshold is over, we must check if there is a conflict before
exiting first loop in inet_csk_get_port()

Change inet_csk_bind_conflict() to forbid two reuse-enabled sockets to
bind on same (address,port) tuple (with a non ANY address)

Same change for inet6_csk_bind_conflict()

Reported-by: Gaspar Chilingarov 
Signed-off-by: Eric Dumazet 
Acked-by: Evgeniy Polyakov 
Signed-off-by: David S. Miller

net: ipv6 bind to device issue

2010-04-22T05:59:24+00:00

The issue raises when having 2 NICs both assigned the same
IPv6 global address.

If a sender binds to a particular NIC (SO_BINDTODEVICE),
the outgoing traffic is being sent via the first found.
The bonded device is thus not taken into an account during the
routing.

From the ip6_route_output function:

If the binding address is multicast, linklocal or loopback,
the RT6_LOOKUP_F_IFACE bit is set, but not for global address.

So binding global address will neglect SO_BINDTODEVICE-binded device,
because the fib6_rule_lookup function path won't check for the
flowi::oif field and take first route that fits.

Signed-off-by: Jiri Olsa 
Signed-off-by: Scott Otto 
Signed-off-by: David S. Miller

ipv6: allow to send packet after receiving ICMPv6 Too Big message with MTU field less than IPV6_MIN_MTU

2010-04-22T05:48:26+00:00

According to RFC2460, PMTU is set to the IPv6 Minimum Link
MTU (1280) and a fragment header should always be included
after a node receiving Too Big message reporting PMTU is
less than the IPv6 Minimum Link MTU.

After receiving a ICMPv6 Too Big message reporting PMTU is
less than the IPv6 Minimum Link MTU, sctp *can't* send any
data/control chunk that total length including IPv6 head
and IPv6 extend head is less than IPV6_MIN_MTU(1280 bytes).

The failure occured in p6_fragment(), about reason
see following(take SHUTDOWN chunk for example):
sctp_packet_transmit (SHUTDOWN chunk, len=16 byte)
|------sctp_v6_xmit (local_df=0)
   |------ip6_xmit
       |------ip6_output (dst_allfrag is ture)
           |------ip6_fragment

In ip6_fragment(), for local_df=0, drops the the packet
and returns EMSGSIZE.

The patch fixes it with adding check length of skb->len.
In this case, Ipv6 not to fragment upper protocol data,
just only add a fragment header before it.

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

xfrm6: ensure to use the same dev when building a bundle

2010-04-21T23:25:30+00:00

When building a bundle, we set dst.dev and rt6.rt6i_idev.
We must ensure to set the same device for both fields.

Signed-off-by: Nicolas Dichtel 
Signed-off-by: David S. Miller

ipv6: Fix tcp_v6_send_response transport header setting.

2010-04-21T07:47:15+00:00

My recent patch to remove the open-coded checksum sequence in
tcp_v6_send_response broke it as we did not set the transport
header pointer on the new packet.

Actually, there is code there trying to set the transport
header properly, but it sets it for the wrong skb ('skb'
instead of 'buff').

This bug was introduced by commit
a8fdf2b331b38d61fb5f11f3aec4a4f9fb2dedcb ("ipv6: Fix
tcp_v6_send_response(): it didn't set skb transport header")

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller

ip: Fix ip_dev_loopback_xmit()

2010-04-15T21:25:22+00:00

Eric Paris got following trace with a linux-next kernel

[   14.203970] BUG: using smp_processor_id() in preemptible [00000000]
code: avahi-daemon/2093
[   14.204025] caller is netif_rx+0xfa/0x110
[   14.204035] Call Trace:
[   14.204064]  [] debug_smp_processor_id+0x105/0x110
[   14.204070]  [] netif_rx+0xfa/0x110
[   14.204090]  [] ip_dev_loopback_xmit+0x71/0xa0
[   14.204095]  [] ip_mc_output+0x192/0x2c0
[   14.204099]  [] ip_local_out+0x20/0x30
[   14.204105]  [] ip_push_pending_frames+0x28d/0x3d0
[   14.204119]  [] udp_push_pending_frames+0x14c/0x400
[   14.204125]  [] udp_sendmsg+0x39c/0x790
[   14.204137]  [] inet_sendmsg+0x45/0x80
[   14.204149]  [] sock_sendmsg+0xf1/0x110
[   14.204189]  [] sys_sendmsg+0x20c/0x380
[   14.204233]  [] system_call_fastpath+0x16/0x1b

While current linux-2.6 kernel doesnt emit this warning, bug is latent
and might cause unexpected failures.

ip_dev_loopback_xmit() runs in process context, preemption enabled, so
must call netif_rx_ni() instead of netif_rx(), to make sure that we
process pending software interrupt.

Same change for ip6_dev_loopback_xmit()

Reported-by: Eric Paris 
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller