linux/net, branch v2.6.17.2

[PATCH] IPV6 ADDRCONF: Fix default source address selection without CONFIG_IPV6_PRIVACY

2006-06-30T00:17:16Z

We need to update hiscore.rule even if we don't enable CONFIG_IPV6_PRIVACY, because we have more less significant rule; longest match. Signed-off-by: YOSHIFUJI Hideaki Signed-off-by: David S. Miller Signed-off-by: Chris Wright

[PATCH] IPV6: Fix source address selection.

2006-06-30T00:17:16Z

Two additional labels (RFC 3484, sec. 10.3) for IPv6 addreses are defined to make a distinction between global unicast addresses and Unique Local Addresses (fc00::/7, RFC 4193) and Teredo (2001::/32, RFC 4380). It is necessary to avoid attempts of connection that would either fail (eg. fec0:: to 2001:feed::) or be sub-optimal (2001:0:: to 2001:feed::). Signed-off-by: Łukasz Stelmach Signed-off-by: YOSHIFUJI Hideaki Signed-off-by: David S. Miller Signed-off-by: Chris Wright

[PATCH] ETHTOOL: Fix UFO typo

2006-06-30T00:17:15Z

The function ethtool_get_ufo was referring to ETHTOOL_GTSO instead of ETHTOOL_GUFO. Signed-off-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Chris Wright

[PATCH] SCTP: Fix persistent slowdown in sctp when a gap ack consumes rx buffer.

2006-06-30T00:17:15Z

In the event that our entire receive buffer is full with a series of chunks that represent a single gap-ack, and then we accept a chunk (or chunks) that fill in the gap between the ctsn and the first gap, we renege chunks from the end of the buffer, which effectively does nothing but move our gap to the end of our received tsn stream. This does little but move our missing tsns down stream a little, and, if the sender is sending sufficiently large retransmit frames, the result is a perpetual slowdown which can never be recovered from, since the only chunk that can be accepted to allow progress in the tsn stream necessitates that a new gap be created to make room for it. This leads to a constant need for retransmits, and subsequent receiver stalls. The fix I've come up with is to deliver the frame without reneging if we have a full receive buffer and the receiving sockets sk_receive_queue is empty(indicating that the receive buffer is being blocked by a missing tsn). Signed-off-by: Neil Horman Signed-off-by: Sridhar Samudrala Signed-off-by: David S. Miller Signed-off-by: Chris Wright

[PATCH] SCTP: Send only 1 window update SACK per message.

2006-06-30T00:17:15Z

Right now, every time we increase our rwnd by more then MTU bytes, we trigger a SACK. When processing large messages, this will generate a SACK for almost every other SCTP fragment. However since we are freeing the entire message at the same time, we might as well collapse the SACK generation to 1. Signed-off-by: Tsutomu Fujii Signed-off-by: Vlad Yasevich Signed-off-by: Sridhar Samudrala Signed-off-by: David S. Miller Signed-off-by: Chris Wright

[PATCH] SCTP: Reset rtt_in_progress for the chunk when processing its sack.

2006-06-30T00:17:15Z

Signed-off-by: Vlad Yasevich Signed-off-by: Sridhar Samudrala Signed-off-by: David S. Miller Signed-off-by: Chris Wright

[PATCH] SCTP: Reject sctp packets with broadcast addresses.

2006-06-30T00:17:15Z

Make SCTP handle broadcast properly Signed-off-by: Vlad Yasevich Signed-off-by: Sridhar Samudrala Signed-off-by: David S. Miller Signed-off-by: Chris Wright

[PATCH] SCTP: Limit association max_retrans setting in setsockopt.

2006-06-30T00:17:15Z

When using ASSOCINFO socket option, we need to limit the number of maximum association retransmissions to be no greater than the sum of all the path retransmissions. This is specified in Section 7.1.2 of the SCTP socket API draft. However, we only do this if the association has multiple paths. If there is only one path, the protocol stack will use the assoc_max_retrans setting when trying to retransmit packets. Signed-off-by: Vlad Yasevich Signed-off-by: Sridhar Samudrala Signed-off-by: David S. Miller Signed-off-by: Chris Wright

[PATCH] IPV6: Sum real space for RTAs.

2006-06-30T00:17:14Z

This patch fixes RTNLGRP_IPV6_IFINFO netlink notifications. Issue pointed out by Patrick McHardy . Signed-off-by: YOSHIFUJI Hideaki Acked-by: Patrick McHardy Signed-off-by: David S. Miller Signed-off-by: Chris Wright

[PATCH] xt_sctp: fix endless loop caused by 0 chunk length (CVE-2006-3085)

2006-06-20T09:31:42Z

Fix endless loop in the SCTP match similar to those already fixed in the SCTP conntrack helper (was CVE-2006-1527). Signed-off-by: Patrick McHardy Signed-off-by: Chris Wright