From mint-bounce@lists.fishpool.fi  Sat Jul  9 01:07:33 2005
X-Original-To: fnaumann@mail.boerde.de
Delivered-To: fnaumann@mail.boerde.de
Message-ID: <20050708190246.9tvxvm26eudcw80w@coolrunningconcepts.com>
Date: Fri, 08 Jul 2005 19:02:46 -0400
From: evan@coolrunningconcepts.com
To: mint@fishpool.com
Subject: Re: [MiNT] e-mail problems with Mint
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.0)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - esc14.midphase.com
X-AntiAbuse: Original Domain - fishpool.com
X-AntiAbuse: Originator/Caller UID/GID - [32001 502] / [47 12]
X-AntiAbuse: Sender Address Domain - coolrunningconcepts.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-ecartis-version: Ecartis v1.0.0
Sender: mint-bounce@lists.fishpool.fi
Errors-To: mint-bounce@lists.fishpool.fi
X-original-sender: evan@coolrunningconcepts.com
Precedence: bulk
List-help: <mailto:ecartis@lists.fishpool.fi?Subject=help>
List-unsubscribe: <mailto:mint-request@lists.fishpool.fi?Subject=unsubscribe>
List-Id: <mint.lists.fishpool.fi>
X-List-ID: <mint.lists.fishpool.fi>
X-Virus-Scanned: by amavisd-new at relay.boerde.de
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de
X-Spam-Status: No, hits=-0.4 tagged_above=-50.5 required=7.0 tests=AWL,
 BAYES_00, NO_REAL_NAME
X-Spam-Level: 

Quoting Peter Slegg <p.slegg@scubadivers.co.uk>:

> I have added Evan's e-mail below. I didn't summarise it because
> that was bound to confuse things.

My Summary:  packets don't seem to be leaving the machine sometime
after it hits
the DATA portion of sending mail, or its not recieving them.  And there is an
odd issue during retransmits.

I don't know if its related to the tcp_sndseg() failures that people are
reporting, but it could be a possibility.   We could have two unrelated issues
as well.

> It does look like there is a bug in MiNTs re-transmission - the
> packets shouldn't be getting 1 byte bigger each retransmit, at least I don't
> think so, but the other end should still be sending an ACK if it got
> the packet and it doesn't.

As it turns out, after briefly looking at the source, this is being done on
purpose.  Its sort of unusual, but seems to be done on purpose.  This is the
result of
#ifdef USE_DROPPED_SEGMENT_DETECTION

-- Evan