Error #6

With release 1.0, we changed the default network protocol to SSL, which sends data over port 443. The first thing to try is to disable this option, by going to the RescueTime preferences, select the Privacy tab, and unselect "Send updates using SSL".

After that option is turned off, go to the Basic tab and try to "Verify" your connection.

Let me know if that works for you!

The error #6 indicates that RescueTime is unable to resolve the hostname of the web service.

The next thing to try is to see if you can reach the RescueTime web service from a regular browser.

- Check to make sure your machine is able to communicate with the RescueTime servers outside of the data collector. To do this, open a web browser and paste in the following URL:
http://api.rescuetime.com/api/handsha...@test.com&password=test123
The result that should be returned back is: "login failure!"

- Next, do the same test but this time replace the test123 next to the email and password fields with the email address and password of your RescueTime account.
For example: http://api.rescuetime.com/api/handsha...@email.com&password=mypassword
The result that should be returned back is "login success!"

Let me know if that works from your web browser, in the meantime I'll continue looking at other things that could be causing this issue.

Thanks!

Well, that's interesting. I'm still digging into what could be causing it to work from a web browser, but it not working from the command line.

I know it's a pain, but one thing that would help would be if you could re-try RescueTime after rebooting your computer. There have been a couple of instances where unexplained issues were cleared up by this. I'm not real hopeful, but this is feeling like it could be one of those types of issues.

I'll post back when I've figured out what the next troubleshooting step is after that.

Thanks!

Matto, did a restart do anything for you after the software installed? I have been unable to hunt down the cause of this issue.

Thanks!

Thanks for the update Matto, that helps narrow down where the error might be.

ATrerra, could you send an email to team@rescuetime.com with the email address you are using in RescueTime? I'd like to coordinate with you sometime tomorrow to watch your connections attempts in our incoming logs.

Also, if you are comfortable at the Unix/Terminal level of OS X, I'd like to have you try a couple of manual send commands to see if we can get more details on what is failing with the network connectivity.

Thanks!

If there is anyone who is having this problem and comfortable with running a command or two at the Terminal level, I'd love to get some information from you.

Essentially, I'm trying to determine if there is more to the error than what we are capturing in RescueTime.

If you are comfortable with using Terminal and can consistently reproduce the Error #6 it would help if I could get some to do the following:

From the Terminal prompt paste in (all on one line):

/usr/bin/curl -k -d 'email=test@test.com&password=testpassword' https://api.rescuetime.com/api/handshake -m 10 -s

You should see something like the following:

System02:~ jhruska$ /usr/bin/curl -k -d 'email=test@test.com&password=testpassword' https://api.rescuetime.com/api/handshake -m 10 -s
login failure!System02:~ jhruska$

Where the important information is the "login failure!".

Paste back your results here or to me in an email at team@rescuetime.com

We'll try to beat this error into submission,

Thanks!

Ok, here is an update for everyone on this issue.

First, I want to thank Susheel who has been great in volunteering many hours of assistance in tracking this issue down.

The short answer is that some DNS servers are not properly resolving the host api.rescuetime.com. The short term work around to this issue is to get your DNS requests from a provider like OpenDNS. See the steps at the end of this post.

The longer term fix is that we are trying to track down why some DNS servers are not correctly responding to cURL's request for domain resolution. This includes us directly contacting DNS support at ISP's where this is occurring. You can assist us by letting us know the following information:

1. Which ISP do you use - and the URL to their web site
2. Which DNS servers you currently have in your Network settings. This can be found on OS X by going to the Apple Menu -> System Preferences... -> Network and pasting in what is in the "DNS Server" line

In Susheel's case, we were able to resolve the issue by having him set his DNS servers to use OpenDNS - a public, popular and free set of DNS servers.

You can set your computer to use the OpenDNS servers by doing the following:

- Open the System Preferences (Apple Menu -> System Preferences...)
- Click on the Network settings and select your current network configuration (Built-in Ethernet or AirPort)
- Click the Advanced... button
- Click on the DNS tab
- Make note of the DNS entry that is currently there in case you need to revert back to your initial DNS entry
- Click the + on the DNS Servers list and add both 208.67.222.222 and 208.67.220.220 to the list
- Click OK and then Apply to make the DNS changes active

NOTE: Changing your DNS servers, especially if you are on a corporate network, might cause other issues with internal customizations. This work around is meant for individuals who are comfortable in making these changes and have the ability to revert the changes back to their previous settings.

Thank you

Earlier this week I requested reverse DNS entries for our api URLs, so that might have done the trick.

I've got a couple more people I want to have validate it's working before I call it resolved though.

Thanks for the updates guys!