The network connection was lost kCFStreamErrorDomainKey and kCFStreamErrorCodeKey

Question

genjokoan OP

Created Oct ’22

Replies 3

Boosts 1

Views 5.2k

Participants 2

Hi All,

we are experiencing the following network error:

NSLocalizedDescription = "Connection error making token request to 'https://foobar.com': The network connection was lost..";
    NSUnderlyingError = "Error Domain=NSURLErrorDomain Code=-1005 \"The network connection was lost.\" UserInfo={_kCFStreamErrorCodeKey=53, NSUnderlyingError=0x281b571b0 {Error Domain=kCFErrorDomainCFNetwork Code=-1005 \"(null)\" UserInfo={_kCFStreamErrorCodeKey=53, _kCFStreamErrorDomainKey=1}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <48900801-EEF7-493A-AE53-48E443D03461>.<3>, _NSURLErrorRelatedURLSessionTaskErrorKey=(\n    \"LocalDataTask <48900801-EEF7-493A-AE53-48E443D03461>.<3>\"\n), NSLocalizedDescription=The network connection was lost., NSErrorFailingURLStringKey=https://foobar.com, NSErrorFailingURLKey=https://foobar.com, _kCFStreamErrorDomainKey=1}";
})

I have studied a similar post What is kCFStreamErrorCodeKey=-4 (kCFStreamErrorDomainKey=4).

Do the above error constants - for example _kCFStreamErrorCodeKey and _kCFStreamErrorDomainKey - add anything meaningful beyond “network connection was lost”?

Moreover “network connection” refers to this url https connection specifically, or the network connection of the customer device?

Thanks & Best Wishes.

Boost

Answer 1

DTS Engineer OP

Apple

Oct ’22

Do the above error constants … add anything meaningful beyond “network connection was lost”?

They can. But in this case the 53 translates to ECONNABORTED, from <sys/errno.h>, which isn’t particularly enlightening.

Moreover “network connection” refers to this url https connection specifically, or the network connection of the customer device?

The error is specific to the connection being used to transport your HTTPS request but it’s not impossible for that to be triggered by the device losing connectivity.

Are you able to reproduce this?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

1

Answer 2

genjokoan OP

Oct ’22

At present, the error affects about one in seven customers in Australia. The host is based in Europe.

Thus far, have been unable to reproduce. Have tried the Network Link Conditioner, Charles Proxy throttling and breakpoints, disabling wifi, disconnecting ethernet, and combinations thereof. All whilst connected to ExpressVPN Sydney using Xcode and simulator.

This induced:

-1004 "Could not connect to the server."
-1009 "The Internet connection appears to be offline."

but as yet no -1005.

How does “could not connect” and “internet connection appears to be offline” differ from "network connection was lost”? After all, we are pulling the plug - literally - while the url is awaiting response.

Please, any clues about how to induce a -1005, or the specific conditions in the private CFNetwork code that trigger a -1005, would be much appreciated.

We have one of the team based in Sydney and can ask for his help if need be.

0

Answer 3

DTS Engineer OP

Apple

Oct ’22

In general:

NSURLErrorCannotConnectToHost (-1004) means that the outgoing connection failed, typically because of an ECONNREFUSED from the underlyng TCP protocol. In that case it means that the SYN made it to the server and the server responded with an RST.
NSURLErrorNotConnectedToInternet (-1009) means that system was unable to find a viable path to the destination. You’ll get this if, for example, both Wi-Fi and WWAN are turned off. It’s best to avoid this entirely by setting waitsForConnectivity.
NSURLErrorNetworkConnectionLost (-1005) means that the TCP connection started but then failed midway through the HTTP transaction.

Having said that, all of these are very general descriptions and these errors can show up in all sorts of odd circumstances.

In most cases the error you get back from NSURLSession will have an underlying error that explains more. And that error might have its own underlying error. It’s good to include all of that in your diagnostics.

But if you can reproduce this problem easily then the way forward is clear:

Install the CFNetwork and Network Diagnostics profiles from our Bug Reporting > Profiles and Logs page.
Reproduce the problem, noting down a rough timestamp.
Immediately after that, trigger a sysdiagnose log.
Rummage around in the captured system log for hints about what’s actually going wrong.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

1