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

[mc12345678]

So computer doesn't offer the ability to force TCP and/or port, so implementing PHP on local server to perform traceroute and provide results. Update to follow, again if of any value from functioning local computer. Still no feedback from host, nothing from PayPal, and it appears that AT&T has had their final word, even though it appears to have nothing to do with the request nor the issue...

Yeah...

Uncle!!!

I've found a php program that establishes socket connections and other socket actions, but I can't get it to work with udp to provide back actual ip addresses, let alone convert over to tcp port 443, the traceroute program I have is windows based and does not have any switches to enable tcp or communicate via a port, other traceroute programs I have looked for and found also don't have port or tcp functionality. At this point I can't seem to get or be given any information and appear utterly at the mercy of everyone else without some cooperation.

I was advised by my host that I will hear back from them in 5-29 hours from now. In the mean time without further assistance we'll be looking for a new host I guess.

[RodG]

In the case(s) of "our ip address" that is the ip address of the website that is having the problem. Traceroute provided is from at&t to us.

I've no idea what you/they are trying to show. None of this seems relevant to your problem, and confusion abounds.

For example:

From at&t:
Please visit http://www.ehow.com/how_8619185_chec...-443-open.html for instructions to check if Port 443 is open.

What a (mostly) pointless thing to suggest. We are discussing the PayPal API servers here are we not? I think it is pretty safe to assume that port 443 on these servers will be open, just as we can pretty much assume that port 80 on their public web servers will be open. There is simply no need to test the bleeding obvious. :)

A trace to [our ip address] through port 80 is reachable without avail:

A trace from AT&T to port 80 at wherever your store is hosted isn't going to tell us a thing about about port 443 connectivity between your store and the PayPal API servers. Again, I've no idea what this is supposed to be showing us.

Also, unless I've missed something in this thread, I'm not seeing how AT&T are fitting into the picture with your problem. Are you hosted with AT&T (or one of their clients)?

Cheers
Rod

[RodG]

So computer doesn't offer the ability to force TCP and/or port,

In that case...........
telnet api-3t.paypal.com 443
.....is suitable for a go/nogo test, but to be useful it needs to be run from your stores' server. It's pretty safe to assume that unless your localhost (home computer) has its own networking issues that the tests will be positive.

Cheers
Rod

[mc12345678]

I've no idea what you/they are trying to show. None of this seems relevant to your problem, and confusion abounds.

For example:



What a (mostly) pointless thing to suggest. We are discussing the PayPal API servers here are we not? I think it is pretty safe to assume that port 443 on these servers will be open, just as we can pretty much assume that port 80 on their public web servers will be open. There is simply no need to test the bleeding obvious. :)



A trace from AT&T to port 80 at wherever your store is hosted isn't going to tell us a thing about about port 443 connectivity between your store and the PayPal API servers. Again, I've no idea what this is supposed to be showing us.

Also, unless I've missed something in this thread, I'm not seeing how AT&T are fitting into the picture with your problem. Are you hosted with AT&T (or one of their clients)?

Cheers
Rod

So, unable to also tell if AT&T truly fits in with my issue, it has been reported multiple times before that they are most likely. Because I can't get a traceroute to the paypal servers, I went with most likely.

The datat provided last? Well, basically to show the lack of support. I asked for them to try to tracerute from them to the paypal servers, and they gave me data on the path back to my server. Earlier, I had provided my traceroute to the paypal server, but that was without port 443 and tcp, which I didn't realize at the time would give me a different result.

I guess in part, trying to keep the community apprized of actions taken and results. Unfortunately some of the data/results are utter rubbish.

As for us having a SSL, we do (shared as it may be), but there have been no web browsing issues when using it. I mean I can securely login to my admin panel, I can securely get to web pages on our site, so I certainly didn't see the point in the "suggestion" to review that ehow article for our situation.

[mc12345678]

In that case...........
telnet api-3t.paypal.com 443
.....is suitable for a go/nogo test, but to be useful it needs to be run from your stores' server. It's pretty safe to assume that unless your localhost (home computer) has its own networking issues that the tests will be positive.

Cheers
Rod

I will search through my available options and see if I can issue a telnet command from my hosts server.
Curious what the results would imply, if the telnet fails, doesn't it mean the same thing as the timeout that we've been getting? Bt I could see if it works, maybe something is taking too long in the process?

[twi]

I've tried to run both curltester.php and ipnchecker.php and each time I get a 404 error page. I have checked and have both php files in my extras folder. The url I am using is the correct one, yet neither test will work. Suggestions?

I've already sent an email to AT&T and want to also contact Network Solutions but would like to be able to provide them with the test results.

I too have Network solutions for host. So it is not just me that is having this problem on paypal.
DO you have problems with your UPS module too if you use one? Mine intermittently provides rate and most of the time do not. Which makes checkout impossible even using paypal standard. Transactions go through given if UPS is able to provide shipping rates.

[mc12345678]

I too have Network solutions for host. So it is not just me that is having this problem on paypal.
DO you have problems with your UPS module too if you use one? Mine intermittently provides rate and most of the time do not. Which makes checkout impossible even using paypal standard. Transactions go through given if UPS is able to provide shipping rates.

Unfortunately someone else with the paypal problems may have to answer that question. Most of our current products are non-shipped. I can though say that I haven't had any errors associated with ups or usps.

[RodG]

As for us having a SSL, we do (shared as it may be), but there have been no web browsing issues when using it

The SSL on your server has no bearing on the SSL connections to the PayPal servers.

Cheers
Rod

[RodG]

Curious what the results would imply, if the telnet fails, doesn't it mean the same thing as the timeout that we've been getting?

Yes. That's why its only useful as a go/nogo test. You'll still need the traceroute output to find where things are being blocked.

Bt I could see if it works, maybe something is taking too long in the process?

Maybe.

Cheers
Rod

[RodG]

So, unable to also tell if AT&T truly fits in with my issue, it has been reported multiple times before that they are most likely.

I have to agree that most reports of this nature (especially in the last 6-12months) have turned out to be AT&T related, but that doesn't mean we should assume that this is always the case.

Because I can't get a traceroute to the paypal servers, I went with most likely.

But if your reacerouts were done without the required options then your test, and the conclusions you drew from it are invalid.

The datat provided last? Well, basically to show the lack of support. I asked for them to try to tracerute from them to the paypal servers, and they gave me data on the path back to my server. Earlier, I had provided my traceroute to the paypal server, but that was without port 443 and tcp, which I didn't realize at the time would give me a different result.

You have my sympathy, but it doesn't help with the issue.

Cheers
Rod