linux-toradex.git/net, branch v2.6.13.4

[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 IPv6 per-socket multicast filtering in exact-match case

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

per-socket multicast filters were not being applied to all sockets
in the case of an exact-match bound address, due to an over-exuberant
"return" in the look-up code. Fix below. IPv4 does not have this problem.

Thanks to Hoerdt Mickael for reporting the bug.

Signed-off-by: David L Stevens 
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] 32bit sendmsg() flaw (CAN-2005-2490)

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

When we copy 32bit ->msg_control contents to kernel, we walk the same
userland data twice without sanity checks on the second pass.

Second version of this patch: the original broke with 64-bit arches
running 32-bit-compat-mode executables doing sendmsg() syscalls with
unaligned CMSG data areas

Another thing is that we use kmalloc() to allocate and sock_kfree_s()
to free afterwards; less serious, but also needs fixing.

Patch by Al Viro, David Miller, David Woodhouse
(sparc64 clean compile fix from David Miller)

Signed-off-by: Al Viro 
Signed-off-by: David Woodhouse 
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

[PATCH] 2.6.13 breaks libpcap (and tcpdump)

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

[NET]: 2.6.13 breaks libpcap (and tcpdump)

Patrick McHardy says:

  Never mind, I got it, we never fall through to the second switch
  statement anymore. I think we could simply break when load_pointer
  returns NULL. The switch statement will fall through to the default
  case and return 0 for all cases but 0 > k >= SKF_AD_OFF.

Here's a patch to do just that.

I left BPF_MSH alone because it's really a hack to calculate the IP
header length, which makes no sense when applied to the special data.

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman