linux-stable.git/net/ipv4, branch linux-2.6.13.y

[PATCH] BIC coding bug in Linux 2.6.13

2005-10-10T18:50:54+00:00

Please consider this change for 2.6.13-stable   Since BIC is
the default congestion control algorithm, this fix is quite
important.

Missing parenthesis in causes BIC to be slow in increasing congestion
window.

Spotted by Injong Rhee.

Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

[PATCH] Don't over-clamp window in tcp_clamp_window()

2005-10-03T23:27:19+00:00

Handle better the case where the sender sends full sized
frames initially, then moves to a mode where it trickles
out small amounts of data at a time.

This known problem is even mentioned in the comments
above tcp_grow_window() in tcp_input.c, specifically:

...
 * The scheme does not work when sender sends good segments opening
 * window and then starts to feed us spagetti. But it should work
 * in common situations. Otherwise, we have to rely on queue collapsing.
...

When the sender gives full sized frames, the "struct sk_buff" overhead
from each packet is small.  So we'll advertize a larger window.
If the sender moves to a mode where small segments are sent, this
ratio becomes tilted to the other extreme and we start overrunning
the socket buffer space.

tcp_clamp_window() tries to address this, but it's clamping of
tp->window_clamp is a wee bit too aggressive for this particular case.

Fix confirmed by Ion Badulescu.

Signed-off-by: "David S. Miller" 
Signed-off-by: Chris Wright

[PATCH] tcp: set default congestion control correctly for incoming connections

2005-10-03T23:27:18+00:00

Patch from Joel Sing to fix the default congestion control algorithm for incoming connections. If a new congestion control handler is added (via module),
it should become the default for new connections. Instead, the incoming
connections use reno. The cause is incorrect
initialisation causes the tcp_init_congestion_control() function to return
after the initial if test fails.

Signed-off-by: Stephen Hemminger 
Acked-by: "David S. Miller" 
Signed-off-by: Chris Wright

[PATCH] ipvs: ip_vs_ftp breaks connections using persistence

2005-10-03T23:27:18+00:00

	ip_vs_ftp when loaded can create NAT connections with unknown
client port for passive FTP. For such expectations we lookup with
cport=0 on incoming packet but it matches the format of the persistence
templates causing packets to other persistent virtual servers to be
forwarded to real server without creating connection. Later the
reply packets are treated as foreign and not SNAT-ed.

	If the IPVS box serves both FTP and other services (eg. HTTP)
for the time we wait for first packet for the FTP data connections with
unknown client port (there can be many), other HTTP connections
that have nothing common to the FTP conn break, i.e. HTTP client
sends SYN to the virtual IP but the SYN+ACK is not NAT-ed properly
in IPVS box and the client box returns RST to real server IP. I.e.
the result can be 10% broken HTTP traffic if 10% of the time
there are passive FTP connections in connecting state. It hurts
only IPVS connections.

	This patch changes the connection lookup for packets from
clients:

* introduce IP_VS_CONN_F_TEMPLATE connection flag to mark the
connection as template
* create new connection lookup function just for templates - ip_vs_ct_in_get
* make sure ip_vs_conn_in_get hits only connections with
IP_VS_CONN_F_NO_CPORT flag set when s_port is 0. By this way
we avoid returning template when looking for cport=0 (ftp)

Signed-off-by: Julian Anastasov 
Signed-off-by: Chris Wright

[PATCH] Fix DHCP + MASQUERADE problem

2005-09-17T01:01:57+00:00

In 2.6.13-rcX the MASQUERADE target was changed not to exclude local
packets for better source address consistency. This breaks DHCP clients
using UDP sockets when the DHCP requests are caught by a MASQUERADE rule
because the MASQUERADE target drops packets when no address is configured
on the outgoing interface. This patch makes it ignore packets with a
source address of 0.

Thanks to Rusty for this suggestion.

Signed-off-by: Patrick McHardy 
Signed-off-by: Chris Wright

[PATCH] raw_sendmsg DoS (CAN-2005-2492)

2005-09-10T02:42:53+00:00

Fix unchecked __get_user that could be tricked into generating a
memory read on an arbitrary address.  The result of the read is not
returned directly but you may be able to divine some information about
it, or use the read to cause a crash on some architectures by reading
hardware state.  CAN-2005-2492.

Fix from Al Viro, ack from Dave Miller.

Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

[PATCH] Reassembly trim not clearing CHECKSUM_HW

2005-09-10T02:42:52+00:00

[IPV4]: Reassembly trim not clearing CHECKSUM_HW

This was found by inspection while looking for checksum problems
with the skge driver that sets CHECKSUM_HW. It did not fix the
problem, but it looks like it is needed.

If IP reassembly is trimming an overlapping fragment, it
should reset (or adjust) the hardware checksum flag on the skb.

Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

[FIB_TRIE]: Don't ignore negative results from fib_semantic_match

2005-08-24T05:06:09+00:00

When a semantic match occurs either success, not found or an error
(for matching unreachable routes/blackholes) is returned. fib_trie
ignores the errors and looks for a different matching route. Treat
results other than "no match" as success and end lookup.

Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller

[TCP]: Document non-trivial locking path in tcp_v{4,6}_get_port().

2005-08-23T17:49:54+00:00

This trips up a lot of folks reading this code.
Put an unlikely() around the port-exhaustion test
for good measure.

Signed-off-by: David S. Miller

[TCP]: Unconditionally clear TCP_NAGLE_PUSH in skb_entail().

2005-08-23T17:13:06+00:00

Intention of this bit is to force pushing of the existing
send queue when TCP_CORK or TCP_NODELAY state changes via
setsockopt().

But it's easy to create a situation where the bit never
clears.  For example, if the send queue starts empty:

1) set TCP_NODELAY
2) clear TCP_NODELAY
3) set TCP_CORK
4) do small write()

The current code will leave TCP_NAGLE_PUSH set after that
sequence.  Unconditionally clearing the bit when new data
is added via skb_entail() solves the problem.

Signed-off-by: David S. Miller