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

wademax

Level 1

9 points

May 12, 2014 3:56 PM in response to Wil Shipley

I haven't suffered it since upgrading to 10.9.2 either.

I was suffering this on 2 Mac Mini Servers running 10.9.1 as well. Very low traffic as they were running at my office for bedding in before transferring to data centre. Since I first found the issue they have stayed on the desk until a fix was released. It occurred at least 3 times, each around 18-24 days uptime, before I upgraded one machine to 10.9.2.

Sleep is disabled since these are DB servers. All services offered by OS X Server are disabled, and only MySQL, monit (reporting to m/monit) and nrpe (reporting to nagios) are running. After reboot machine is left at login screen. MySQL is acting as a slave, receiving replication data from the main servers in the remote data centre. When the issue hits, monit is unable to make the outgoing connection to my local m/monit server, so I get a notification from m/monit server that the monit heartbeat has failed. When it does fail I can still SSH into the machine, and MySQL is still responsive to incoming connections. Strangely, replication also still runs, so data continues to update.

I upgraded one mini to 10.9.2 so I could run it against 10.9.1 as a control. Rebooted both machines to start the testing. After around 22 days the 10.9.1 control failed. I didn't run the netstat commands outlined in this thread, as I didn't know about it. After about 12 hours the machine came right and made outgoing connections to m/monit (I received heatbeat succeeded notification). It then ran fine for 2 days before failing again. After 7 days of failure I finally rebooted it. It failed again after 19 days. After 5 days it didn't come right by itself so I rebooted.

During the same period the 10.9.2 machine had no issues (uptime 57 days so far), while 10.9.1 had suffered the issue twice.

Not a definitive "issue is fixed" but for me 10.9.2 seems not to suffer it. I've since upgrade the second mini and moved both machines to data centre for duty. I'll keep an eye on them and try the netstat commands.

-- Wade

nt005

Level 1

0 points

May 13, 2014 6:04 AM in response to wademax

wademax wrote:

I haven't suffered it since upgrading to 10.9.2 either.

....

Not a definitive "issue is fixed" but for me 10.9.2 seems not to suffer it. I've since upgrade the second mini and moved both machines to data centre for duty. I'll keep an eye on them and try the netstat commands.

-- Wade

I do appear to be suffering with this problem on 10.9.2

Neil

May 13, 2014 8:08 AM in response to nt005

I have some customers running Mavericks Server 10.9.2 and we get called about once a week with this error and we always find the error message in the logs.

Reboot - Server up and running for about a week😕

Is this the future of Apples quality we have to expect?

Maybe I sound a little bit angry - I am trapped by three bugs in Mavericks - I can not do my work any more.

Bye

Eric Root

Level 10

684,531 points

May 13, 2014 12:42 PM in response to Christoph Ewering1

Send Apple feedback. They won't answer, but at least will know there is a problem. If enough people send feedback, it may get the problem solved sooner.

Feedback

nt005

Level 1

0 points

May 13, 2014 3:38 PM in response to Christoph Ewering1

Yep, mine does it every 3 to 4 days. Radar 16897275.

May 16, 2014 8:33 AM in response to StigBull

Anyone know if 10.9.3 solves this?

May 16, 2014 8:44 AM in response to James Weisbin2

Regardless of whether people are still having this issue, I noticed Tuesday night that Apple has marked the bug as closed in their database. The one I submitted was marked as a duplicate of some other bug and that bug is marked closed.

Just an FYI! If people are still seeing this, they probably need to submit another bug report.

May 16, 2014 9:15 PM in response to heavyboots

In my case, I found 11000 sockets in LAST_ACK state, with ~1000 of those connected to mdnsresponder. Killing mdnsresponder did not help and it appears that OSX is missing tools like those found on Linux/FreeBSD to allow you to reclaim sockets stuck in closing states. This does appear to be a kernel bug in the TCP stack, otherwise killing mdnsresponder should have freed up ~1000 sockets - but it didn't ..

Another interesting thing is that nettop is the only tool that I have found on OSX that is able to correlate the sockets in LAST_ACK state to a PID - even a PID that has been killed...

I tried to turn off Back to My Mac feature of the iCloud service, (since all the mdnsresponder sockets in the LAST_ACK state were connected to apple service related to BTMM service), but that made no difference either.

Still haven't found a workaround besides a reboot...

刘昕

Level 1

0 points

May 24, 2014 7:19 AM in response to StigBull

I can just confirm this is still happening on 10.9.3 on really busy server. I mean a web server with Nginx + Python + MySQL serving over 400K dynamic requests per day.

:-(

May 24, 2014 8:18 AM in response to 刘昕

Can you please confirm, are you running Server.app version 3.1.2?

May 24, 2014 8:24 AM in response to blueviking

I can confirm that blocking these outgoing ports solved the problem for me, under 10.9.3 and Server 3.1.1. Now that I'm running Server 3.1.2, not sure if the problem is gone because I'm still blocking those outgoing ports. BTW I'm blocking them with an access rule on a Sonicwall firewall.

TCP port 5223 (used by devices to communicate to the APNs servers)

TCP port 2195 (used to send notifications to the APNs)

TCP port 2196 (used by the APNs feedback service)

刘昕

Level 1

0 points

May 24, 2014 5:39 PM in response to James Weisbin2

No I'm not running Server.app, just my own Nginx + Python (Tornado) + MySQL stack.

May 24, 2014 8:34 PM in response to 刘昕

So it's not an issue with Server.app, it's the OS. Good to know, thanks.

meople

Level 1

0 points

Jun 15, 2014 4:51 PM in response to StigBull

Still not fixed, 10.9.3, the same uptime as usual for me.

Jun 16, 2014 1:03 PM in response to James Weisbin2

Hi,

At the time I was running 3.1.1.

Since updating to 3.1.2 3 days ago and to OSX 10.9.3 it seems like the LAST_ACK issue is gone. Netstat shows no sockets in this state after 3 days of running (intermittenly I will have a few but they do timeout like they should). I see a few in *WAIT* state, but they also seem to timeout correctly. The majority of these are to port 4444 ..

tcp6 0 0 ::1.57544 ::1.4444 CLOSE_WAIT

The system has been up for 9 days since last reboot. I do not see any sockets stuck in LAST_ACK yet. I have 56 sockets stuck in CLOSE_WAIT, and 44 of those are to port 4444 ... FWIW

Lars

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