Re: strange Mac OSX RST behavior

2016-07-22 Thread Jason Baron
Hi, After looking at this further we found that there is actually a rate limit on 'rst' packets sent by OSX on a closed socket. Its set to 250 per second and controlled via: net.inet.icmp.icmplim. Increasing that limit resolves the issue, but the default is apparently 250. Thanks, -Jason On

Re: strange Mac OSX RST behavior

2016-07-01 Thread Jason Baron
On 07/01/2016 02:16 PM, One Thousand Gnomes wrote: >> yes, we do in fact see a POLLRDHUP from the FIN in this case and >> read of zero, but we still have more data to write to the socket, and >> b/c the RST is dropped here, the socket stays in TIME_WAIT until >> things eventually time out... >

Re: strange Mac OSX RST behavior

2016-07-01 Thread One Thousand Gnomes
> yes, we do in fact see a POLLRDHUP from the FIN in this case and > read of zero, but we still have more data to write to the socket, and > b/c the RST is dropped here, the socket stays in TIME_WAIT until > things eventually time out... After the FIN when you send/retransmit your next segment do

Re: strange Mac OSX RST behavior

2016-07-01 Thread Jason Baron
On 07/01/2016 01:08 PM, Rick Jones wrote: > On 07/01/2016 08:10 AM, Jason Baron wrote: >> I'm wondering if anybody else has run into this... >> >> On Mac OSX 10.11.5 (latest version), we have found that when tcp >> connections are abruptly terminated (via ^C), a FIN is sent followed >> by an RST

Re: strange Mac OSX RST behavior

2016-07-01 Thread Rick Jones
On 07/01/2016 08:10 AM, Jason Baron wrote: I'm wondering if anybody else has run into this... On Mac OSX 10.11.5 (latest version), we have found that when tcp connections are abruptly terminated (via ^C), a FIN is sent followed by an RST packet. That just seems, well, silly. If the client

Re: strange Mac OSX RST behavior

2016-07-01 Thread One Thousand Gnomes
> On Mac OSX 10.11.5 (latest version), we have found that when tcp > connections are abruptly terminated (via ^C), a FIN is sent followed > by an RST packet. The RST is sent with the same sequence number as the > FIN, and thus dropped since the stack only accepts RST packets matching > rcv_nxt

strange Mac OSX RST behavior

2016-07-01 Thread Jason Baron
I'm wondering if anybody else has run into this... On Mac OSX 10.11.5 (latest version), we have found that when tcp connections are abruptly terminated (via ^C), a FIN is sent followed by an RST packet. The RST is sent with the same sequence number as the FIN, and thus dropped since the stack