Establishing a connection reliably?

[brett-doffing]

Any insight into why I would get [] nw_protocol_read_connect Received SOCKS connect status 5, failing only sometimes, and unreliably, when making a call with session.dataTask() to a hidden service?

If I am not mistaken (which I very well could be), status 5 means "Connection refused", so it would be curious to find that it works sometimes?

[tladesignz]

Not really.

The SOCKS service is the phone side of Tor. So something there is unreliable. Maybe an issue with not holding on to a reference long enough?

[brett-doffing]

Well, I can say that successive session.dataTask() calls within a block seem to work reliably, and the unreliability I am working through occurs outside this block (as one example), so it seems there may be a reference held, but I'm not exactly sure what that reference is. For all cases, the session remains the same, but from errors that occur, a "Connection" counter increments: [] nw_protocol_read_connect Received SOCKS connect status 5, failing Connection 3: received failure notification Connection 3: failed to connect 1:50, reason -1 Connection 3: encountered error(1:50) ...

I wonder if this "Connection" is the reference you speak of? If so, and if you know what it is, what exactly is it so that I may hold on to it, or if not, is there a reference I can hold on to? Maybe I shouldn't try to hold on to a reference?

[tladesignz]

I wonder if this "Connection" is the reference you speak of?

Well, I just remembered in the back of my head from another project, that I had connection issues, when I didn't hold on to (I think) a URLSession object with a class property.

The connections were closed immediately after the function was left and ARC removed the reference to URLSession. The closure never got called.

Anyhow, that seems not to be the case with your issue when you say:

Well, I can say that successive session.dataTask() calls within a block seem to work reliably

You positively do wait for Tor to have started up properly, do you? Something like this: https://github.com/OnionBrowser/OnionBrowser/blob/2.X/OnionBrowser/OnionManager.swift#L213-L389

[brett-doffing]

You positively do wait for Tor to have started up properly, do you?

AFAICT, yes. I haven't dug too deep into the configuration and setup of this framework in the code I am working with yet, but I can say that the unreliable calls most certainly can and do happen after successful calls have occurred, implying that Tor is setup. Our TorClient is a singleton with a URLSession property that is only used to make dataTask() calls. As it stands, our current solution is to retry the call an arbitrary number of times, which seems to work ok, but I guess I am looking for a better fix.

Also, AFAICT, the error looks to always be of the finished with error [-1009] Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." variety, if that helps. Maybe it really is due to a bad connection from the device, but wrt to frequency of errors, successful calls after the fact, and assumed reliable connection, I'm inclined to think otherwise. Should really test ;)

[tladesignz]

Also, AFAICT, the error looks to always be of the finished with error [-1009] Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." variety, if that helps. Maybe it really is due to a bad connection from the device, but wrt to frequency of errors, successful calls after the fact, and assumed reliable connection, I'm inclined to think otherwise. Should really test ;)

This error typically shows, when DNS resolution didn't work. That could mean, your network connection dropped, Tor lost connection or you're trying to resolve a .onion address over the unencrypted network.

If you don't, yet, do use Tor.framework's logging facility:

https://github.com/iCepa/Tor.framework/blob/master/Tor/TORLogging.h https://github.com/iCepa/Tor.framework/blob/master/Tor/TORLogging.m

Used like this:

https://github.com/OnionBrowser/OnionBrowser/blob/2.X/OnionBrowser/OnionManager.swift#L305-L309

[brett-doffing]

I'm not sure how much I can make of the logs, but I may be able to point out what looks to be a differentiation from a failed attempt:

[app] connection_ap_process_end_not_open: Edge got end (misc error) before we're connected. Marking for close.

and a successful one:

[app] connection_edge_process_relay_cell_not_open: 'connected' received for circid ######### streamid ###### after 1 seconds.

Would this tell me anything significant?

[tladesignz]

Looks like you have serious connection issues to the Tor network. In which country are you/where is your entry into the open internet?

There are some countries which actively try to interfere with the Tor nodes, esp. China and Iran. Esp. blocking/resetting requests to known Tor nodes and proxies.

You might have more luck with not-widely-known OBFS4 bridges: http://bridges.torproject.org

Check out Onion Browser on how to add OBFS4/Meek support to your app.

[Fonta1n3]

The server is hosted in USA, its a V3 HS. It is weird that there are so many unsuccessful attempts.. I am wondering if there are any general torrc settings you would recommend trying server side to improve the reachability of the HS? TIA.

[tladesignz]

Sorry, I was under the impression we're talking about a phone here. Is this all server side? I can't help you with that.

[Fonta1n3]

No, it is an iOS app using Tor.framework connecting to a V3 hidden service which is the server.

[tladesignz]

Ok. Still, can't help you with the server. Cross check with other apps from different locations if you have trouble there.

On the app side you still need to consider where the device is entering the net: If that's in a difficult country, you will experience issues with authorities or ISPs trying to meddle with your connection.

[tladesignz]

So, I'll close this, as there was no activity since over a month. I just released a new version containing the latest Tor. You might want to upgrade!