[133] in linux-net channel archive
Re: Possible Bug in tcp.c
daemon@ATHENA.MIT.EDU (Rob Janssen reading Linux mailingl)
Wed Mar 15 22:49:59 1995
To: mccabe@nscgld.com (Mike McCabe)
Date: Wed, 15 Mar 1995 23:30:25 +0100 (MET)
Cc: linux-net@vger.rutgers.edu
In-Reply-To: <199503151658.LAA02984@diamond.nscgld.com> from "Mike McCabe" at Mar 15, 95 11:58:48 am
Reply-To: pe1chl@wab-tis.rabobank.nl
From: linux@sys3.pe1chl.ampr.org (Rob Janssen reading Linux mailinglist)
According to Mike McCabe:
> I think we have found a possible bug in the code for tcp. In the file
> /usr/src/linux/net/inet/tcp.c in the routine tcp_data there is a line
> that reads.
>
> if ( skb->len == 0 && !th->fin && !th->urg && !th->psh )
>
> and then inside this if statement is a check to see if the message was
> an ack. If it was then it does not send it because tcp_ack() already did.
>
> The problem we have run into is with a machine that uses MSDOS and a netbios
> to tcp/ip driver from Wollogong. This system has a very small buffer for
> packets (on the order of 190 bytes). It also pushes every ack it sends.
> But since it pushes the ack both tcp_ack and tcp_data send an ack and the
> two systems get into an ack war. By removing the !th->psh from this if
> statement our problem was solved.
>
> A question is however, is this fix messing with the tcp standard or is this
> a bug in the Linux tcp driver? The problem only occurred when the MSDOS
> machine shrunk its window to zero.
The MSDOS machine is in error when setting the PUSH bit for a segment that
has no data. However, it is not according to the "be conservative in what
you send and liberal in what you expect" principle of TCP to fail because
of errors at the other end.
Linux should not be acking segments that occupy no sequence space.
PUSH alone does not occupy sequence space.
Rob
--
+------------------------------------+--------------------------------------+
| Rob Janssen rob@knoware.nl | AMPRnet: rob@pe1chl.ampr.org |
| e-mail: pe1chl@wab-tis.rabobank.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
+------------------------------------+--------------------------------------+
