From sprenger@moving-bytes.de Thu Dec 18 08:34:09 2008
Path: egsner!news.cirr.com!goblin1!goblin.stu.neva.ru!newsfeed.datemas.de!feeder1.news.weretis.net!newsfeeder.dynfx.net!weretis.net!newsfeed01.sul.t-online.de!newsmm00.sul.t-online.de!t-online.de!news.t-online.com!not-for-mail
From: Peter Sprenger <sprenger@moving-bytes.de>
Newsgroups: comp.sys.mac.system
Subject: Re: Mac OSX tcp/ip problem
Date: Wed, 17 Dec 2008 10:08:57 +0100
Organization: T-Online
Lines: 57
Message-ID: <giafjc$v5o$03$1@news.t-online.com>
References: <gi8dgi$i1q$1@newsreader2.netcologne.de> <1is34ik.9tnp3phjhpm1N%dempson@actrix.gen.nz>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.t-online.com 1229504940 03 n31928 cA3flylJbngqp4G 081217 09:09:00
X-Complaints-To: usenet-abuse@t-online.de
X-ID: VPsY8OZZoeOuL-ZnPL7eAtwJeVVJsTHr3tpSlyCfIqRrpNgQ2ogfgc
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
In-Reply-To: <1is34ik.9tnp3phjhpm1N%dempson@actrix.gen.nz>
Xref: egsner!news.cirr.com comp.sys.mac.system:764840
X-IMAPbase: 1230221467 1
Status: O
X-Status: 
X-Keywords:                       
X-UID: 1

> Peter Sprenger <sprenger@moving-bytes.de> wrote:
> 
>> perhaps can somebody give me some info about a problem with the Mac 
>> TCP/IP stack I encounter at the moment. The issue is that at the end of
>> a TCP/IP connection the Mac is not ACKing the last FIN of the opposite
>> connection. Example:
>>
>> Mac:  FIN/ACK
>> IPdevice: FIN/ACK
>> <here should come an ACK from Mac>
>> .
>> <timeout>
>> IPdevice: FIN/ACK
>> Mac:  ACK
>>
>> Any idea?
> 
> Which version of Mac OS X?
> 
> I tried a couple of connections with tcpdump running and have observed
> the same behaviour. I'm running 10.5.5.

Juergen Meier in de.comp.sys.mac.internet (german newsgroup) reproduced 
it for 10.5.6 (the MacBook I tested also had 10.5.6).
I can confirm, that it only happens when the Mac closes the connection 
first.

It causes a problem with our ethernet based power switches, that only 
have limited RAM. We have only space for about 20 sockets, so when a 
socket is occupied until the timeout for the retransmission, our socket 
space is running dry.

> 
> The problem only appears if the Mac closes the connection first. I saw
> exactly the same pattern as you described, with a one second gap between
> the first and second received FIN/ACK.
> 
> If the other device closes the connection first (probably expected by
> the Mac, so it may have been a near simultaneous close), I got a clean
> close:
> 
> IPdev: FIN/ACK
> Mac: ACK
> Mac: FIN/ACK
> IPdev: ACK
> 
> Speculation: probably a bug in the TCP/IP stack. It would be useful to
> establish a wider range of systems exhibiting the problem, and producing
> a simple and repeatable test which can be filed in a bug report to
> Apple.
> 
> It might cause problems with some NAT routers or packet filtering
> firewalls which forget the connection after having seen the first FIN in
> both directions - the other station is likely to be in a half-closed
> state until it gives up sending FIN retries, which will use up one
> potential connection.
>