user/sven/linux.git/include/net, branch v2.6.25.2

IPSEC: Fix catch-22 with algorithm IDs above 31

2008-05-01T21:44:33Z

[ Upstream commit: c5d18e984a313adf5a1a4ae69e0b1d93cf410229 ] As it stands it's impossible to use any authentication algorithms with an ID above 31 portably. It just happens to work on x86 but fails miserably on ppc64. The reason is that we're using a bit mask to check the algorithm ID but the mask is only 32 bits wide. After looking at how this is used in the field, I have concluded that in the long term we should phase out state matching by IDs because this is made superfluous by the reqid feature. For current applications, the best solution IMHO is to allow all algorithms when the bit masks are all ~0. The following patch does exactly that. This bug was identified by IBM when testing on the ppc64 platform using the NULL authentication algorithm which has an ID of 251. Signed-off-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

TCP: Increase the max_burst threshold from 3 to tp->reordering.

2008-05-01T21:44:32Z

[ Upstream commit: dd9e0dda66ba38a2ddd1405ac279894260dc5c36 ] This change is necessary to allow cwnd to grow during persistent reordering. Cwnd moderation is applied when in the disorder state and an ack that fills the hole comes in. If the hole was greater than 3 packets, but less than tp->reordering, cwnd will shrink when it should not have. Signed-off-by: John Heffner Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

[IPV6]: Use appropriate sock tclass setting for routing lookup.

2008-04-14T06:40:51Z

Signed-off-by: YOSHIFUJI Hideaki Signed-off-by: David S. Miller

[SCTP]: Fix compiler warning about const qualifiers

2008-04-13T01:40:06Z

Fix 3 warnings about discarding const qualifiers: net/sctp/ulpevent.c:862: warning: passing argument 1 of 'sctp_event2skb' discards qualifiers from pointer target type net/sctp/sm_statefuns.c:4393: warning: passing argument 1 of 'SCTP_ASOC' discards qualifiers from pointer target type net/sctp/socket.c:5874: warning: passing argument 1 of 'cmsg_nxthdr' discards qualifiers from pointer target type Signed-off-by: Vlad Yasevich Signed-off-by: David S. Miller

[SCTP]: Fix protocol violation when receiving an error lenght INIT-ACK

2008-04-13T01:39:34Z

When receiving an error length INIT-ACK during COOKIE-WAIT, a 0-vtag ABORT will be responsed. This action violates the protocol apparently. This patch achieves the following things. 1 If the INIT-ACK contains all the fixed parameters, use init-tag recorded from INIT-ACK as vtag. 2 If the INIT-ACK doesn't contain all the fixed parameters, just reflect its vtag. Signed-off-by: Gui Jianfeng Signed-off-by: Vlad Yasevich Signed-off-by: David S. Miller

[TCP]: tcp_simple_retransmit can cause S+L

2008-04-08T05:33:07Z

This fixes Bugzilla #10384 tcp_simple_retransmit does L increment without any checking whatsoever for overflowing S+L when Reno is in use. The simplest scenario I can currently think of is rather complex in practice (there might be some more straightforward cases though). Ie., if mss is reduced during mtu probing, it may end up marking everything lost and if some duplicate ACKs arrived prior to that sacked_out will be non-zero as well, leading to S+L > packets_out, tcp_clean_rtx_queue on the next cumulative ACK or tcp_fastretrans_alert on the next duplicate ACK will fix the S counter. More straightforward (but questionable) solution would be to just call tcp_reset_reno_sack() in tcp_simple_retransmit but it would negatively impact the probe's retransmission, ie., the retransmissions would not occur if some duplicate ACKs had arrived. So I had to add reno sacked_out reseting to CA_Loss state when the first cumulative ACK arrives (this stale sacked_out might actually be the explanation for the reports of left_out overflows in kernel prior to 2.6.23 and S+L overflow reports of 2.6.24). However, this alone won't be enough to fix kernel before 2.6.24 because it is building on top of the commit 1b6d427bb7e ([TCP]: Reduce sacked_out with reno when purging write_queue) to keep the sacked_out from overflowing. Signed-off-by: Ilpo Järvinen Reported-by: Alessandro Suardi Signed-off-by: David S. Miller

[LLC]: skb allocation size for responses

2008-04-01T04:02:47Z

Allocate the skb for llc responses with the received packet size by using the size adjustable llc_frame_alloc. Don't allocate useless extra payload. Cleanup magic numbers. So, this fixes oops. Reported by Jim Westfall: kernel: skb_over_panic: text:c0541fc7 len:1000 put:997 head:c166ac00 data:c166ac2f tail:0xc166b017 end:0xc166ac80 dev:eth0 kernel: ------------[ cut here ]------------ kernel: kernel BUG at net/core/skbuff.c:95! Signed-off-by: Joonwoo Park Acked-by: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller

[LLC]: station source mac address

2008-03-28T23:28:36Z

kill unnecessary llc_station_mac_sa. Signed-off-by: Joonwoo Park Acked-by: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller

[IPSEC]: Fix BEET output

2008-03-26T23:51:09Z

The IPv6 BEET output function is incorrectly including the inner header in the payload to be protected. This causes a crash as the packet doesn't actually have that many bytes for a second header. The IPv4 BEET output on the other hand is broken when it comes to handling an inner IPv6 header since it always assumes an inner IPv4 header. This patch fixes both by making sure that neither BEET output function touches the inner header at all. All access is now done through the protocol-independent cb structure. Two new attributes are added to make this work, the IP header length and the IPv4 option length. They're filled in by the inner mode's output function. Thanks to Joakim Koskela for finding this problem. Signed-off-by: Herbert Xu Signed-off-by: David S. Miller

[IPSEC]: Fix inter address family IPsec tunnel handling.

2008-03-24T21:51:51Z

Signed-off-by: Kazunori MIYAZAWA Signed-off-by: David S. Miller