[lkml]   [1996]   [Apr]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: PPP is slow (and so is TCP!) [with fixes]

Bernd Wiebelt <> writes:
>I had some problems with pre-87-kernels, they used to
>hang on specific http/www-sessions, and even better,
>these hangs were reproducible (always at the same place).
>With 1.3.87 this works somehow, in a quite funny way:
>There are servers working under http, while they do not
>work under ftp.
>For me, is such a location.
>Works under http, but when I do a "dir", the ftp-session hangs.
>You may also want to try out ""
>which does not work at all (I get 167 bytes until connection dies).

The removal of the tcp_send_ack in bad_tcp_sequence turns
out to have been a bad idea (TM). I stupidly forgot that
more than one ACK packet can be lost at a time. (doh)
To avoid retransmission storms with Solaris we probably still
want to make this a delayed ack, but we should probably at
least put an ack in there.

Try changing the code to bad_tcp_sequence() in tcp_input.c
to the following:

static void bad_tcp_sequence(struct sock *sk, struct tcphdr *th, u32 end_seq,
struct device *dev)
if (th->rst)

* Send a reset if we get something not ours and we are
* unsynchronized. Note: We don't do anything to our end. We
* are just killing the bogus remote connection then we will
* connect again and it will work (with luck).

if (sk->state==TCP_SYN_SENT || sk->state==TCP_SYN_RECV)
tcp_send_reset(sk->saddr,sk->daddr,th,sk->prot,NULL,dev, sk->ip_

tcp_send_delayed_ack(sk, HZ/2);

I've got to go and do some real work right now, so I haven't tested
this yet. If you try it let me know how it works...

-- eric

Eric Schenk www:
Department of Computer Science email:
University of Toronto

 \ /
  Last update: 2005-03-22 13:37    [W:0.038 / U:1.988 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site