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 11, 2014 7:20 AM in response to StigBull

My MacPro just had this problem again.

OS10.9 -- I know there's a .1 now but nothing in the information seemed related to this problem.

Uptime: 21 days

Tried the "sudo ifconfig en0 down && sudo route flush && sudo ifconfig en0 up" command suggested earlier but it didn't help - still couldn't connect to perforce, can't assign requested address.

Only solution was to reboot, which is a pretty terrible solution in this day and age.

Sonic84

Level 2

159 points

Feb 12, 2014 8:29 AM in response to EveryUsernameIsAlreadyTaken

I've been investigating why several Mac Mini servers went down all of a sudden and came across this thread. All but one of the servers are back up affter a reboot... this is frusterating.

georgn

Level 1

5 points

Feb 12, 2014 2:00 PM in response to Sonic84

So I've been chasing network flakiness for months. Much of it was with my cable modem (direct ethernet connection, no wifi). After I got that resolved, I was seeing some ISP packet loss (which I was noticing because websites were randomly getting stuck while loading). But even when my ISP recovers and resumes providing good service, my Mac does not seem to recover... And netstat shows hundreds of connections in FIN_WAIT_1 state.

Google led me here.

So my current hypothesis is that the bug is a ISP packet loss interfering with the TCP teardown protocol that fills the networking stack with a bunch of stale connections.

How am I observing packet loss? In a terminal windo, I simply run:

ping -c1000 google.com # or whatever site you want that actually pings back

After 1000 pings, note the packet loss number. Should be close to zero...

Anybody got a better hypothesis?

When this problem hits again (I rebooted today) I will try the solutions offered here and report back.

justinwr

Level 1

0 points

Feb 12, 2014 2:39 PM in response to georgn

@georgn: If it's happening to you more regularly than myself, would it be possible to setup Wireshark, capture all incoming packets and try to correlate with your Mac's syslogs to determine if a series of packets are truly causing this? If so, that's a DDoS exploit which is something a lot of people would like to know about especially Apple.

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

Happened on early iMac 20 inch mid 2007 OS X 10.9.1 (13B42)

uptime

18:28 up 54 days, 22:21, 2 users, load averages: 1.08 1.13 1.14

netstat -n -p tcp |wc -l

359

netstat -n -p tcp -a |wc -l

369

Not a lot of tcp sessions (almost all in either FIN_WAIT_1 or LAST_ACK)

Number of days much greater than ~20, but mostly it sleeps

No servers, no dropbox, ethernet connected, wifi off, bluetooth off, has Cisco Anyconnect installed but not in use. Mostly used for Outlook (started and stopped when used), Safari (just browsing around and started and stopped when used).

Feb 14, 2014 11:09 AM in response to StigBull

FYI for all we were having a similiar issue with what appeared to be orphaned socket connections in the FIN_WAIT_1 state. The only connections that were not clearing for us were to 17.X network range, which I believe is APN services. Resolved this issue by repairing permissions on the drive. Good luck.

georgn

Level 1

5 points

Feb 14, 2014 12:26 PM in response to justinwr

@justinwr: I'll try to but it's not happening with particular frequency. Last reboot came after 14 days uptime.

As for my hypothesis (packet loss leading to stale connections), I think I can rule it out. I've had two occasions of intermittent packet loss and in both cases the number of stale connections got no higher than three and went back to zero when my ISP started behaving again.

Feb 15, 2014 6:19 PM in response to StigBull

I found this thread after getting; ssh: connect to host xxx port 22: Can't assign requested address. This is a mac mini in my office at work. I connect to it remotely via ssh or vnc.

In sharing;

remote logins: enabled

remote management: enabled

Able to ssh and vnc to the host. chrome/safari is works with IPv6 while browsing.

http://inetcore.com/project/46checker/index.html.en

only returns an IPv6 address.

Apple mail configured for a single exchange account is not functional, and ssh is not functional over IPv4 but will work to localhost via IPv6.

uptime: 32 days when Ii noticed the problem. 4 day earlier I had open 4 ssh connections with 2 different hosts.

It has an encrypted drive, so it is only rebooted when I’m in the office with it.

33 FIN_WAIT_1 exist for TrendMicro server

1 FIN_WAIT_1 exist for microsoft exchange server vip

Model Name: Mac mini

Model Identifier: Macmini6,2

Processor Name: Intel Core i7

Processor Speed: 2.6 GHz

Energy Saver

Computer Sleeps: never

Display Sleeps: 6 minutes

Put hard disks to sleep when possible: yes

Wake for network access:yes

Startup automatically a power failure:yes

Enable Power Nap: No

things that didn’t work.

dscacheutil -flushcache

ifconfig en0 down

route flush

ifconfig en0 up

If anyone has any ideas it will be 36 hours before i reboot it.

Feb 18, 2014 10:07 AM in response to StigBull

This is defintely a defect in the network stack, and it seems to have started with Mavericks. I have "little snitch" installed. Is there anyone who had this problem that does not have this installed?

tixetsal

Level 1

9 points

Feb 18, 2014 10:14 AM in response to Skandragon

It does seem to be a problem in the network stack.

Little snitch is not the source of the issue.

lsolberg

Level 1

0 points

Feb 18, 2014 10:38 AM in response to StigBull

I've started creating a shared spreadsheed to collect this thread..

If someone else is doing this, please share and I will use that one instead 🙂

The doc is located at https://docs.google.com/spreadsheet/ccc?key=0As3NA5bVAGcydFlGaW81UjRMenRkNkNaQ2d KcDRGWGc&usp=sharing

I don't know what people have tried, or what you think the issue might be. So please just add a column of what you want other people to try..

georgn

Level 1

5 points

Feb 18, 2014 10:45 AM in response to Skandragon

I do not have little snitch installed and have the problem. Pretty sure it's safe to rule it out.

Feb 18, 2014 3:27 PM in response to lsolberg

The symptoms as I see it:

Lots of connected listed as CLOSED in the IPv4 protocol (I did not check IPv6, although I have it here at home) -- local and remote addresses are all listed as *.*. This seems... strange.

tcp4 0 0 *.* *.* CLOSED

Also, many connections in FIN_WAIT_1, or LAST_ACK state, and they are not progressing. It really does sound like a bug in once introduced into NetBSD's kernel while I was debugging some clever code, many years ago, where I broke the stack. Ooops. But I don't think I can hack the code in OSX.

Feb 19, 2014 7:39 AM in response to dpistolenma

In my case, it was not any specific network that had problems. I am also not at all sure how filesystem permissions could affect the network stack on a stable, running machine when a reboot causes teh network stack to work again.

Feb 19, 2014 7:40 AM in response to StigBull

I have filed a bug through the developer portal. If others have done this as well, reference ticket 16109222.

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