Problem with Paypal connection - Error (28) connect() timed out!

mc12345678:

Amen... In part makes me want to go work for one to improve their capability and performance, while at the same time not to because of the lack of expected competence.

I had in my mind more of a "one (web) pager" that I thought you had developed somewhere in the forums but was discussed in this thread, but the first referenced post probably would be the most "educational". My guess is that they continued to test like I did (as I didn't have the necessary tools to implement a TCP traceroute on port 443), and "assumed" that it was all a-okay. :/ at least they did provide a response within the time frame they stated they would, albeit was just a yeah we know people are having difficulty, working on it, and will get back to you type response. rolling eyes

As part of their policy if they are late in responding then they can be contacted to provide reimbursement for services. I've suggested to those that pay to follow up with that because of the minimum three occasions spanning two months (end of July and beginning of August) when they haven't even come close to responding within the time frame they identified. Realize we're not talking about pizza delivery, but three+ days is not even close to 4-6 hours.

May I Asked who your host is? It seems like it's not just affecting Network Solutions customers. All of us seems to have the problems resolved all of a sudden. RNRN has his resolved and told me about it. And I found out mine is resolved. RNRN and I happens to have the same host.

twi:

I believe One thing is still amiss. The confirmation emails send to customer on account creation and order updates returns as undeliverable. any insight into this one?
Not related to PayPal Express.

If your emails are coming back as undeliverable, then either you're sending to invalid addresses, or your hosting company's email gateway is mangling the outgoing emails.

That's really something for you and your host to sort out.

twi:

May I Asked who your host is? It seems like it's not just affecting Network Solutions customers. All of us seems to have the problems resolved all of a sudden. RNRN has his resolved and told me about it. And I found out mine is resolved. RNRN and I happens to have the same host.

Fatcow is our host. I have half-heartidly tried to determine what if any relationship the two have. All I have seen though is that fatcow discusses something about adjusting or changing some settings associated with network solutions in a help file.

As I have seen messages of success, I have attempted to test without success, so problem is still present on my service.

I've provided a link to this thread, and previouusly a number of test methods (not directly available to me and that should be possible by them). I plan on giving them some more time to self-identify the issue and then point towards what has been reported here as a firewall upgrade/changeout performed about two weeks ago.

DrByte:

Not related to PayPal Express.

If your emails are coming back as undeliverable, then either you're sending to invalid addresses, or your hosting company's email gateway is mangling the outgoing emails.

That's really something for you and your host to sort out.

Thank you. I will look into that in that direction and notify the host of the same.

Thank you all in here that was involved and being very supportive of each other in solving the problems. I call that human nature at its best. :clap:

mc12345678:

Fatcow is our host. I have half-heartidly tried to determine what if any relationship the two have. All I have seen though is that fatcow discusses something about adjusting or changing some settings associated with network solutions in a help file.

As I have seen messages of success, I have attempted to test without success, so problem is still present on my service.

I've provided a link to this thread, and previouusly a number of test methods (not directly available to me and that should be possible by them). I plan on giving them some more time to self-identify the issue and then point towards what has been reported here as a firewall upgrade/changeout performed about two weeks ago.

best of luck to you. patience will pay off even though very frustrating in the process since everything is at stake. Interesting that you mention fatcow hosting discussed about network solutions. Maybe that are related, or one and same company that we are not aware of.

So far all of my sites worked, and I have jump the gun to point all my urls to my new upgraded zc1.5.1 Multisites. I hope it will actually work using Paypal Express. Initial testing does take me the to the Paypal payment page. As Dr Byte mentioned, if zc is able to go to the Paypal payment page, than that means that zc is communicating correctly with paypal and it should work.

The problem ticket I submitted concerning outdated DNS, to my host was not answered yet. RNRN 's sites are working after he called the host (Netsol, which is mine as well). Mine as well now. It appears that he was the one that solved my problems as well.

Again thank you all that is involved.

twi:

best of luck to you. patience will pay off even though very frustrating in the process since everything is at stake. Interesting that you mention fatcow hosting discussed about network solutions. Maybe that are related, or one and same company that we are not aware of.

Not sure of the relationship between the two, the link I tried to describe actually was from a google search of "fatcow and network solutions" to try to see if there was a connection. There's not much that comes up with those two other than this site (http://www.fatcow.com/knowledgebase/read_article.bml?kbid=5782) on fatcow talking about updating DNS settings at Network Solutions.

By the way, for those that have had this issue resolved and had made either or both curltester.php and ipncheck.php available to the internet world, remember to remove it from the accessible area(s) and ensure that still have a copy where it originally was. Just in case of the unfortunate event that it/they are needed again.

Still waiting on my end, but congratulations on yours being successfully restored.

So, aint this a kick in the pants: finally after commenting to support person, commenting in our service ticket, and commenting in a survey, our host provided some information about the status of our issue 2 weeks after initiating the first of two trouble tickets.

Ready for this? Problem exists at or beyond AT&T, with whom started with the first go round and who told me that they didn't see any issues and when asked to perform the telling test(s) took an easy way out and did a test that provided no value. Imagine that. (For those just reading, it's been two weeks of trial after trial to attempt to identify where the problem is, being provided information that has nothing to do with the request although I didn't initially realize that I was being provided non-useful information, etc. So let's just say it has been frustrating to get such a run around.)
So back to reaching out to AT&T to see if I can correctly describe the problem, and methods to test for the issue and see if I can get a different response.

Hello all, I now have this error 28 problem which started Thursday 15th Aug. I have yet to contact my host (host papa) I have read all 13 pages of this thread and it gets complex in parts.

Before I go further could someone please look at my ipn check below and tell me if ok or not.
Thank you, Carl.

IPNCHECK.PHP - Version 1.3.9

CURL ERROR: Attempted connection on: https://www.paypal.com/cgi-bin/webscr
(6) Couldn't resolve host 'www.paypal.com'
Trying direct HTTP on port 80 instead ...
CURL RESPONSE RECEIVED - Communications OKAY
IPN TESTING - Response Received via CURL -- COMMUNICATIONS OKAY
IPN TESTING - Confirmation/Validation response with fsockopen(): FSOCKOPEN() RESPONSE RECEIVED - Communications OKAY

Default method likely to be used for communications is: CURL, with the fallback method being FSOCKOPEN if possible.

Script finished.

Carl:

Hello all, I now have this error 28 problem which started Thursday 15th Aug. I have yet to contact my host (host papa) I have read all 13 pages of this thread and it gets complex in parts.

Before I go further could someone please look at my ipn check below and tell me if ok or not.
Thank you, Carl.

IPNCHECK.PHP - Version 1.3.9

CURL ERROR: Attempted connection on: https://www.paypal.com/cgi-bin/webscr
(6) Couldn't resolve host 'www.paypal.com'
Trying direct HTTP on port 80 instead ...
CURL RESPONSE RECEIVED - Communications OKAY
IPN TESTING - Response Received via CURL -- COMMUNICATIONS OKAY
IPN TESTING - Confirmation/Validation response with fsockopen(): FSOCKOPEN() RESPONSE RECEIVED - Communications OKAY

Default method likely to be used for communications is: CURL, with the fallback method being FSOCKOPEN if possible.

Script finished.

So to me it looks like you can safely use the standard method of accepting payment via paypal; however, the test does not reflect on paypal express. Have you tried curltester.php yet? (Realize you said you're getting a 28 error, but didn't see that stated what process was giving it.)

Carl:

Hello all, I now have this error 28 problem which started Thursday 15th Aug. I have yet to contact my host (host papa) I have read all 13 pages of this thread and it gets complex in parts.

Before I go further could someone please look at my ipn check below and tell me if ok or not.

How does 'mostly OK' sit with you?

CURL ERROR: Attempted connection on: https://www.paypal.com/cgi-bin/webscr
(6) Couldn't resolve host 'www.paypal.com'

This is telling me that there was a DNS problem (name lookup failed).

However,

Trying direct HTTP on port 80 instead ...
CURL RESPONSE RECEIVED - Communications OKAY

This is suggesting that the DNS failure was only temporary, because when it tried again using a different port to the same server/host the lookup was actually successful.

The question needs to be asked, is the problem you are having 'consistent', or does it seem to come and go with no apparent pattern?

If it seems to come and go you'll be looking for a DNS related cause.
If it is consistent you are probably another victim of the AT&T routing/firewall problem.

Cheers
Rod

Thanks MC and Rod. Curltester.php ok. The problem had been constant since 4 days ago.
I reported to paypal and my host. The host reported that they did have issues with servers slow response times.
I don't know if this was connected. I am not sure who did what or anything at all but later today all was well.
I hope i am lucky here. I will report any further probs here. Thanks again for help,, priceless.. Carl..

For anyone still having issues, try out this new tool to test whether you're blocked by AT&T or not: See the link to sadbox.net in my post at: http://www.zen-cart.com/showthread.php?65680-PayPal-Communications-Response-Testing-Tools&p=1215303#post1215303

DrByte:

For anyone still having issues, try out this new tool to test whether you're blocked by AT&T or not: See the link to sadbox.net in my post at: http://www.zen-cart.com/showthread.php?65680-PayPal-Communications-Response-Testing-Tools&p=1215303#post1215303

Unfortunately problem was resolved before the above was posted for testing; however, was notified by host last night that was resolved, but I didn't want to post anything too early and doom it again. They did say they were going to report the cause in what is about 2 hours from now in the ticket that has now been closed. If they do update it then I will report what they identified. If they don't I plan on initiating a ticket to obtain the information (and report it).

AT&T throughout this 3 week outage reported that they were not blocking our ip address so I am curious to know where the problem was.

This is an old post, but in case anyone is still looking for solutions, I have recently upgraded my ZC to v1.5.5f and have been struggling with the same timeout errors as above. Today, I found a way to increase the timeout settings for PayPal connections with cURL. Good news. In a file called paypal_curl.php I modified the critical timeout settings thusly:
/**

• Options for cURL. Defaults to preferred (constant) options.
• xRay changed CURLOPT_CONNECTTIMEOUT => 10 to 20 7/25/2018
• xRay changed CURLOPT_TIMEOUT=> 45 to 60 7/25/2018
  */
  var $_curlOptions = array(CURLOPT_HEADER => 0,
  CURLOPT_RETURNTRANSFER => TRUE,
  CURLOPT_TIMEOUT => 60,
  CURLOPT_CONNECTTIMEOUT => 20,
  CURLOPT_FOLLOWLOCATION => FALSE,
  //CURLOPT_SSL_VERIFYPEER => FALSE, // Leave this line commented out! This should never be set to FALSE on a live site!
  //CURLOPT_CAINFO => '/local/path/to/cacert.pem', // for offline testing, this file can be obtained from http://curl.haxx.se/docs/caextract.html ... should never be used in production!
  CURLOPT_FORBID_REUSE => TRUE,
  CURLOPT_FRESH_CONNECT => TRUE,
  CURLOPT_POST => TRUE,
  );

My first attempt failed when I increased CURLOPT_CONNECTTIMEOUT to 15. After I increased it to 20 and also increased CURLOPT_TIMEOUT from 45 to 60, I was able to successfully connect with PayPal and complete a test transaction for $0.99. Finally, after about a month of darkness, I can now see the light!

Those of us with slow shared rented servers should consider this option. In my humble opinion, I believe there should be a couple of settings in the configuration form for PayPal Express to manipulate the critical CURLOPT settings as needed. I also should credit the PayPal tech support helper, Nate, for suggesting the CURLOPT_TIMEOUT increase from 45 to 60.