You can make a difference in the Apple Support Community!

When you sign up with your Apple Account, you can provide valuable feedback to other community members by upvoting helpful replies and User Tips.

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

StigBull Author

Level 1

20 points

My network connection completely died - "failed: 49 - Can't assign requested address"

The entire networking stack on my 2012 Retina MBP died just a few minutes ago, and I was only able to get it up and running by rebooting.

First no sites in Safari worked and then I noticed when using telnet that:

[stig@Hyperion:~]$ telnet www.allthingsd.com 80

Trying 192.0.65.213...

telnet: connect to address 192.0.65.213: Can't assign requested address

Trying 192.0.65.216...

telnet: connect to address 192.0.65.216: Can't assign requested address

telnet: Unable to connect to remote host

Strangely enough traceroute and ping worked.

In the system log there is no warning untill the network is down:

Nov 12 10:28:31 Hyperion.local mDNSResponder[62]: AppendDNSNameString: Illegal empty label in name ".weblamb.com"

Nov 12 10:28:31 Hyperion com.apple.launchd.peruser.501[164] (com.onible.iTunificationStartup[65065]): Exited with code: 1

Nov 12 10:28:31 Hyperion com.apple.launchd.peruser.501[164] (com.onible.iTunificationStartup): Throttling respawn: Will start in 10 seconds

Nov 12 10:28:33 Hyperion.local PluginProcess[65047]: CoreText performance note: Client called CTFontCreateWithName() using name "Arial" and got font with PostScript name "ArialMT". For best performance, only use PostScript names when calling this API.

Nov 12 10:28:33 Hyperion.local PluginProcess[65047]: CoreText performance note: Set a breakpoint on CTFontLogSuboptimalRequest to debug.

Nov 12 10:28:33 Hyperion.local PluginProcess[65047]: CoreText performance note: Client called CTFontCreateWithName() using name "Times Roman" and got font with PostScript name "Times-Roman". For best performance, only use PostScript names when calling this API.

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_destination_prepare_complete 111635 connectx to 88.221.96.163#443 failed: 49 - Can't assign requested address

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_handle_destination_prepare_complete 111635 failed to connect

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_destination_prepare_complete 111634 connectx to 88.221.96.163#443 failed: 49 - Can't assign requested address

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_handle_destination_prepare_complete 111634 failed to connect

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_destination_prepare_complete 111637 connectx to 88.221.96.163#443 failed: 49 - Can't assign requested address

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_handle_destination_prepare_complete 111637 failed to connect

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_destination_prepare_complete 111636 connectx to 88.221.96.163#443 failed: 49 - Can't assign requested address

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_handle_destination_prepare_complete 111636 failed to connect

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_destination_prepare_complete 111639 connectx to 173.194.32.62#443 failed: 49 - Can't assign requested address

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_handle_destination_prepare_complete 111639 failed to connect

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_destination_prepare_complete 111638 connectx to 173.194.32.62#443 failed: 49 - Can't assign requested address

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_handle_destination_prepare_complete 111638 failed to connect

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_destination_prepare_complete 111642 connectx to 173.194.32.62#443 failed: 49 - Can't assign requested address

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_handle_destination_prepare_complete 111642 failed to connect

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_destination_prepare_complete 111640 connectx to 23.23.14.248#80 failed: 49 - Can't assign requested address

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_destination_prepare_complete 111644 connectx to 192.237.224.183#80 failed: 49 - Can't assign requested address

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_handle_destination_prepare_complete 111644 failed to connect

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_destination_prepare_complete 111646 connectx to 173.194.32.62#443 failed: 49 - Can't assign requested address

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_handle_destination_prepare_complete 111646 failed to connect

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_destination_prepare_complete 111645 connectx to 173.194.32.62#443 failed: 49 - Can't assign requested address

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_handle_destination_prepare_complete 111645 failed to connect

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_destination_prepare_complete 111647 connectx to 173.194.32.62#443 failed: 49 - Can't assign requested address

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_handle_destination_prepare_complete 111647 failed to connect

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_destination_prepare_complete 111648 connectx to 173.194.32.62#443 failed: 49 - Can't assign requested address

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_handle_destination_prepare_complete 111648 failed to connect

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_destination_prepare_complete 111640 connectx to 107.22.72.129#80 failed: 49 - Can't assign requested address

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_destination_prepare_complete 111649 connectx to 173.194.32.62#443 failed: 49 - Can't assign requested address

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_handle_destination_prepare_complete 111649 failed to connect

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_destination_prepare_complete 111650 connectx to 184.86.224.214#80 failed: 49 - Can't assign requested address

Nov 12 10:28:34 Hyperion.local com.apple.WebKit.Networking[2157]: tcp_connection_handle_destination_prepare_complete 111650 failed to connect

I tried flushing the routes and using ifconfig to down/up the interfaces but nothing worked.

Has anybody seen anything like this?

MacBook Pro with Retina display, OS X Mavericks (10.9)

Posted on Nov 12, 2013 2:15 AM

158 replies

Feb 19, 2014 8:55 PM in response to Skandragon

Just fell over again. Uptime of 33 days, 17.5 hours approximately.

Tried the ifconfig en0 down trick, including verifying that I could no longer ping domains after taking it down and was definitely using the right en port.

Tried dnsflush.

Even tried purge while en0 was down.

netstat -n -p tcp was FULL of LAST_ACK's.

There were 5200 connections, 5000 of them were LAST_ACK, with a smattering of CLOSE_WAIT and FIN_WAIT_1's thrown in. I believe of the 5000 LAST_ACK's, something like 4000 of them were to imap servers, so perhaps this has to do with leaving Mail running and how badly the mail servers it is talking to are behaving.

At any rate, finally gave up and rebooted and everything is running well again. I note that immediateliy after reboot with the same software netstat -n -p tcp now shows 52 connections, all but one of which are in ESTABLISHED state.

I hope like **** Apple releases a patch for this soon!

Feb 21, 2014 10:01 AM in response to heavyboots

Just a 'me2'. I have this issue every 22 days (approx). I have enabled the PF packet filter and set it to aggressive. Till today I had around 100 sessions that were counted via pfctl -si, that didn't increase, I saw however that the amount of sessions hanging is 15k, which are not shown in the packet filter.

Seems that the OS X Mavericks is not cleaning up the tcp sockets nicely, leaving the system broken after soo many sessions.

@Apple: please let me know how I can help resolve this, this is an frustrating issue :-(

Phorkus

Level 1

4 points

Feb 22, 2014 3:44 PM in response to StigBull

So, this appears to be some kinf of condition in which the TCP timer is becoming prematurely detached from the socket construct. This is something that happens at the kernel level and shouldn't *ever* happen. Something in the kernel's state machine is causing this to happen, however. (I've been doing kernel level work with Linux since 1991, waaaayyyy back in collge, so I suppose I might have a "qualified" opinion, if there is such a thing :-) ).

I've had this issue a couple of times since the 10.9.1 update and it's directly tied to a change made in the Darwin kernel from what I can tell. Essentially the TCP state machine has a few states that allow it to determine if it's in negotiation to open, connected, disconnecting, and fully disconnected. The state machine is getting stuck somewhere in the disconnecting phase in TIMED_WAIT1 or LAST_ACK. This indicates that some form of a "timer drop off" has likely happened. Meaning the clock stopped on the expiration of the TCP socket, and the kernel eventually runs out of "buckets" to put these sockets locked in a disconenecting state in.

The thing I find odd is that the socket count at the time the protocol stack becomes unresponsive is NOT a match for the maximum number of system wide file handles (or even a mathematical function of the maximum minus the open filesystem handles). So something is causing resource exaustion on the kernels socket file handles, but not the file system handles (technically they are different inside most kernels, but not by a lot).

This leads me to ask Apple, will you release the source for the darwin 10.9.1 update please, so we can have at it? I'd love to submit a bug fix for this, and since it impacts me directly, I will spend the needed time and effort. If legal hasn't released it yet, please let them know that an eager group of developers would like to fix some problems that are affecting a large number of folks. :-)

Ben.R

Level 1

0 points

Feb 24, 2014 9:53 PM in response to StigBull

Ditto here. 23 day uptime. Not the first time this has happened, but the first time I bothered to try to figure out the cause. Mid 2011 mini running 10.9.1 (13b42). Interestingly, I wasn't seeing *huge* numbers of stale connections: ~1300 total open with ~500 stalled on LAST_ACK. Neither flushing routes nor repairing permissions changed a thing (unsurprisingly); had to reboot.

trisweb

Level 1

0 points

Feb 25, 2014 10:52 AM in response to Ben.R

10.9.2 just released. I guess we'll find out in 2-3 weeks if it resolves anything...

Feb 27, 2014 5:25 PM in response to Phorkus

Wow seriously nice analysis Phorkus. I've been doing system level work with Unix(TM) since 1987, but not at the kernel level, waaaaayyy back in colllege too. Great to see an "old timer" 😉

P.S. by the way, yes me too. Just hit it at 24 days.

Feb 27, 2014 10:12 PM in response to StigBull

Upgrade to 10.9.2! For serious!

-Wil

Feb 28, 2014 10:50 AM in response to Wil Shipley

Sorry it's been a while since I was in this discussion. "It" happened to me again the very afternoon the 10.9.2 release became available. I had just done a quick check of things with netstat -p tcp and found the usual assortment of CLOSE_WAITs and LAST+ACK's. 10.9.2 is running now, we'll see what happens in 3 weeks or so :-)

Doug

Feb 28, 2014 10:55 AM in response to StigBull

This just happened to me on 2011 Mac Mini uptime 25 days. Then I see the update to 10.9.2. I hope this fixes it. Will let you know in 25 days.

StigBull Author

Level 1

20 points

Feb 28, 2014 11:37 AM in response to StigBull

I am the OP, and I have to say this has happened so far twice on my rMBP at work.

It is always on so I can SSH/VNC into it from home.

However, I have two Mac Mini's at home, which are set to sleep after 10 minutes of inactivity.

So far, it has never happened on the Mini's.

Feb 28, 2014 12:59 PM in response to StigBull

Maybe sleeping "resets" the TCP stack upon waking up. My Mini is like your rMBP, always on. I have a MBP that sleeps and I have never had the prolem on it.

Feb 28, 2014 5:18 PM in response to jfialkowski

It has happened on my wife's iMac after 54 days, but mostly it sleeps. It's not that the TCP stack "resets" when waking; it doesn't, the machine carries on from where it left off. However, while it's sleeping, it isn't doing whatever it does to eventually use up all of the TCP sockets. The problem still happens on a machine that sleeps, it just takes longer to get to the fail point. My wife has changed her habit and shuts down at end of day, so this will avoid the problem even if 10.9.2 doesn't fix it. I also typically shut down my MBP at end of day, so avoid the problem.

Hopefully, 10.9.2 will fix it. Those who run all the time will find out first, I think. Good luck.

Mar 5, 2014 7:52 AM in response to StigBull

i have the same issue but i could solve this.

after about 8 hours the tcp connections stuck on my mac mini. so i changed the router and now the mac mini runs without problems for about 3 days. i think this is a quick fix to solve the problem.

Mar 5, 2014 9:00 AM in response to ElBarteros

The main problem referred to in this thread prevents the machine from establishing TCP/IP connecitons to itself.

Making the problem a kernel one and not an external router one. Though it will be possible for other circumstances to generate the same error message.

Mar 10, 2014 2:46 PM in response to StigBull

Here's something interesting to add into the mix. I am experiencing the issue as I type this on a relatively new Macbook Pro with 10.9.1. I can ping just fine. I can't connect to any sites in Safari, or use Telnet, or get any other TCP based connections...unless I do what I am doing right now: Using a VM in Parallels. Even though I am unable to get any connection from within the native 10.9 environment, using a bridged virtual adapter on a Windows or OS/X 10.8 virtual machine works just fine.

My network connection completely died - "failed: 49 - Can't assign requested address"