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

[mc12345678]

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.

[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.

[RodG]

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

[mc12345678]

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.)

[mc12345678]

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.p...03#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.

[raycruzer]

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.