From
[email protected] 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 <
[email protected]>
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: <
[email protected]>
References: <
[email protected]> <1is34ik.9tnp3phjhpm1N%
[email protected]>
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:
[email protected]
X-ID: VPsY8OZZoeOuL-ZnPL7eAtwJeVVJsTHr3tpSlyCfIqRrpNgQ2ogfgc
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
In-Reply-To: <1is34ik.9tnp3phjhpm1N%
[email protected]>
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 <
[email protected]> 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.
>
