linux/net/ipv6, branch v2.6.22.15

IPV6: Restore IPv6 when MTU is big enough

2007-12-14T18:31:59Z

[IPV6]: Restore IPv6 when MTU is big enough [ Upstream commit: d31c7b8fa303eb81311f27b80595b8d2cbeef950 ] Avaid provided test application, so bug got fixed. IPv6 addrconf removes ipv6 inner device from netdev each time cmu changes and new value is less than IPV6_MIN_MTU (1280 bytes). When mtu is changed and new value is greater than IPV6_MIN_MTU, it does not add ipv6 addresses and inner device bac. This patch fixes that. Tested with Avaid's application, which works ok now. Signed-off-by: Evgeniy Polyakov Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

Fix crypto_alloc_comp() error checking.

2007-11-21T17:25:54Z

[IPSEC]: Fix crypto_alloc_comp error checking [ Upstream commit: 4999f3621f4da622e77931b3d33ada6c7083c705 ] The function crypto_alloc_comp returns an errno instead of NULL to indicate error. So it needs to be tested with IS_ERR. This is based on a patch by Vicenç Beltran Querol. Signed-off-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

Fix TCP MD5 on big-endian.

2007-11-02T15:44:11Z

changeset f8ab18d2d987a59ccbf0495032b2aef05b730037 in mainline. Based upon a report and initial patch by Peter Lieven. tcp4_md5sig_key and tcp6_md5sig_key need to start with the exact same members as tcp_md5sig_key. Because they are both cast to that type by tcp_v{4,6}_md5_do_lookup(). Unfortunately tcp{4,6}_md5sig_key use a u16 for the key length instead of a u8, which is what tcp_md5sig_key uses. This just so happens to work by accident on little-endian, but on big-endian it doesn't. Instead of casting, just place tcp_md5sig_key as the first member of the address-family specific structures, adjust the access sites, and kill off the ugly casts. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

Fix ipv6 redirect processing, leads to TAHI failures.

2007-11-02T15:44:10Z

changeset bf0b48dfc368c07c42b5a3a5658c8ee81b4283ac from mainline. When the ICMPv6 Target address is multicast, Linux processes the redirect instead of dropping it. The problem is in this code in ndisc_redirect_rcv(): if (ipv6_addr_equal(dest, target)) { on_link = 1; } else if (!(ipv6_addr_type(target) & IPV6_ADDR_LINKLOCAL)) { ND_PRINTK2(KERN_WARNING "ICMPv6 Redirect: target address is not link-local.\n"); return; } This second check will succeed if the Target address is, for example, FF02::1 because it has link-local scope. Instead, it should be checking if it's a unicast link-local address, as stated in RFC 2461/4861 Section 8.1: - The ICMP Target Address is either a link-local address (when redirected to a router) or the same as the ICMP Destination Address (when redirected to the on-link destination). I know this doesn't explicitly say unicast link-local address, but it's implied. This bug is preventing Linux kernels from achieving IPv6 Logo Phase II certification because of a recent error that was found in the TAHI test suite - Neighbor Disovery suite test 206 (v6LC.2.3.6_G) had the multicast address in the Destination field instead of Target field, so we were passing the test. This won't be the case anymore. The patch below fixes this problem, and also fixes ndisc_send_redirect() to not send an invalid redirect with a multicast address in the Target field. I re-ran the TAHI Neighbor Discovery section to make sure Linux passes all 245 tests now. Signed-off-by: Brian Haley Acked-by: David L Stevens Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

Fix some cases of missed IPV6 DAD

2007-11-02T15:44:09Z

changeset 0fcace22d38ce9216f5ba52f929a99d284aa7e49 from mainline 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 Signed-off-by: YOSHIFUJI Hideaki Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

Fix ipv6 source address handling.

2007-09-26T17:54:43Z

commit 6ae5f983cf8de769214d2d9e8a783c881eccd4cd in mainline The commit 95c385 broke proper source address selection for cases in which there is a address which is makred 'deprecated'. The commit mistakenly changed ifa->flags to ifa_result->flags (probably copy/paste error from a few lines above) in the 'Rule 3' address selection code. The patch restores the previous RFC-compliant behavior. Signed-off-by: Jiri Kosina Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

Fix IPV6 DAD handling

2007-09-26T17:54:42Z

commit 9e3be4b34364a670bd6e57d2e8c3caabdd8d89f8 in mainline addrconf_dad_failure calls addrconf_dad_stop which takes referenced address and drops the count. So, in6_ifa_put perrformed at out: is extra. This results in message: "Freeing alive inet6 address" and not released dst entries. Signed-off-by: Denis V. Lunev Signed-off-by: Alexey Dobriyan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

Fix ipv6 double-sock-release with MSG_CONFIRM

2007-09-26T17:54:42Z

commit 3ef9d943d26dea764f4fecf3767001c90b778b0c in mainline Signed-off-by: YOSHIFUJI Hideaki Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

Fix IPV6 append OOPS.

2007-09-26T17:54:42Z

commit e1f52208bb968291f7d9142eff60b62984b4a511 in mainline. [IPv6]: Fix NULL pointer dereference in ip6_flush_pending_frames Some of skbs in sk->write_queue do not have skb->dst because we do not fill skb->dst when we allocate new skb in append_data(). BTW, I think we may not need to (or we should not) increment some stats when using corking; if 100 sendmsg() (with MSG_MORE) result in 2 packets, how many should we increment? If 100, we should set skb->dst for every queued skbs. If 1 (or 2 (*)), we increment the stats for the first queued skb and we should just skip incrementing OutDiscards for the rest of queued skbs, adn we should also impelement this semantics in other places; e.g., we should increment other stats just once, not 100 times. *: depends on the place we are discarding the datagram. I guess should just increment by 1 (or 2). Signed-off-by: YOSHIFUJI Hideaki Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

TCP: Do not autobind ports for TCP sockets

2007-08-31T06:01:51Z

[TCP]: Invoke tcp_sendmsg() directly, do not use inet_sendmsg(). As discovered by Evegniy Polyakov, if we try to sendmsg after a connection reset, we can do incredibly stupid things. The core issue is that inet_sendmsg() tries to autobind the socket, but we should never do that for TCP. Instead we should just go straight into TCP's sendmsg() code which will do all of the necessary state and pending socket error checks. TCP's sendpage already directly vectors to tcp_sendpage(), so this merely brings sendmsg() in line with that. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman