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

mc12345678:

So, don't want to jinx it, but it looks like our issue got resolved (for the time being). Not sure which of the basic three actions I took resolved it, or if it was the combination of them. But, had notified our host, then after several days, spoke with computer security staff of AT&T who did try to investigate, but would only officially report what they directly controlled, and at the same time submitted a trouble ticket to PayPal identifying total inability to process PayPal payments in PayPal Express (adaptive payments section?). So far none of the three have reported that they were the ones that resolved the issue, but a paypal curltester.php run gave back a 200 code and all types of data.

Btw, I will try to get up here the conversation with AT&T for those that might take interest. Good luck to others with this problem, hope it wasn't just us that got resolved.

Yup... Jinxed it... Again not working. Below is a summary of the correspondence that I've had with AT&T. I have made attempts not to modify the way that they responded, but did not want to include all information for various reasons:

Me: Identified who I was in regards to our network operation, identified the error code received, and what action prompted it. I then indicated that it appeared that it may be their company preventing access to PayPal’s site: https://api-3t.paypal.com/nvp. Provided them the location where the error originated from and also our IP address.
Me: I then provided them a path and instruction to perform the curltester.php actions to attempt communication with paypal (http://www.pugsugottasave.org/shop/curltester.php?paypal=1). Further identified other testing that had been performed such as removing the ?paypal=1 statement or setting =0. Asked if the restriction could be removed and, if not, a reason provided as to why not.
Them: AT&T IP Security is not blocking (your IP), and asked for a traceroute to PayPal.
Me: Unfortunately our host does not offer traceroute related options. (attempted multiple implementations via PHP to no avail.)
Them: AT&T identified not blocking api-3t.paypal.com.
More from AT&T: A deep analysis of a traceroute indicates traffic leaves the AT&T network, but never returns. This indicates a routing issue beyond the AT&T network.
Me: When asked what organization(s) to contact next based on the deep analysis:
Them: Due to legal and privacy concerns, we can't disclose who our customers are.

However, from a public route server, you can determine the AS path.
show route api-3t.paypal.com active-path

Me: That result identified one additional organization between AT&T and PayPal.
Me and them: When asked if they were then “internally” investigating forward seeing that operation is not as expected nor desired, was advised that: The network path to api-3t.paypal.com passes through AT&T's network to another company, a customer, as designed. Any return traffic from that company is controlled by that company.
Them: The latest provided information is that traceroutes end at EBAY.

Me: Based on a whois search, [email protected] was the contact address that appears; however, there has been no response nor bounceback of a message sent to that address.
Me: We had momentary success this morning; however, it was actually short lived… 
Me: I still would go with the instruction and suggestions offered by Dr.Byte in approaching from at least both directions. It is unfortunate that perhaps AT&T will be deluged with notification; however, someone has to know about the issue, contact the right person(s) and continue to press for correction to get the job done, seeing that we have been effected for at least 5 days, though I thought I saw an issue the week before when reviewing previous PayPal payments and that the information did not appear. I thought it was just me and something I may have modified; however, appears it was the start of something bigger.

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.

RNRN:

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.

In summary, follow the instructions posted at http://www.zen-cart.com/showthread.php?65680-PayPal-Communications-Response-Testing-Tools

Instead of downloading the files, copy them over to the location identified in that post to run curltester.php and ipncheck.php.

So, interesting thing, ran a traceroute from local computer, results end at gi1-1-ash1-br01.net.ebay.com [66.211.161.237]; however, paypal processing works from local computer. This is a similar result identified by AT&T. Is problem then still probably/likely in AT&T, even though my traceroute didn't go through AT&T and that they can't see that they are having a problem because something isn't making it to/through their service?

mc12345678:

So, interesting thing, ran a traceroute from local computer, results end at gi1-1-ash1-br01.net.ebay.com [66.211.161.237]; however, paypal processing works from local computer. This is a similar result identified by AT&T. Is problem then still probably/likely in AT&T, even though my traceroute didn't go through AT&T and that they can't see that they are having a problem because something isn't making it to/through their service?

Before discussing this further, what was the exact traceroute command that you are using for testing?

Unless you enable TCP and specify port 443 it is unlikely your results are telling you much at all.

Example#1 (seemingly blocked / no route)
rod@sue:#** traceroute api-3t.paypal.com**
traceroute to api-3t.paypal.com (173.0.88.69), 30 hops max, 60 byte packets
1 gw (192.168.0.254) 0.871 ms 1.163 ms 1.662 ms
2 lns20.adl2.on.ii.net (203.16.215.197) 40.294 ms 41.506 ms 42.412 ms
3 te3-3.cor3.adl2.on.ii.net (150.101.134.29) 44.132 ms 45.606 ms 47.304 ms
4 xe-0-0-0.cr1.adl6.on.ii.net (150.101.225.77) 48.920 ms 50.429 ms 52.932 ms
5 ae4.br1.syd7.on.ii.net (150.101.33.34) 73.005 ms 73.829 ms 75.752 ms
6 te0-2-1-2.br1.sjc2.on.ii.net (150.101.33.147) 232.961 ms 233.349 ms 233.677 ms
7 144.232.191.193 (144.232.191.193) 266.432 ms 244.702 ms 244.354 ms
8 sl-payp2-413771-0.sprintlink.net (144.232.191.210) 215.993 ms 217.464 ms 218.960 ms
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
rod@sue:#

Example#2 (Using TCP port 443 shows all ok)
rod@sue:#** traceroute-T -p 443 api-3t.paypal.com**
traceroute to api-3t.paypal.com (173.0.88.101), 30 hops max, 60 byte packets
1 gw (192.168.0.254) 0.847 ms 1.196 ms 1.528 ms
2 lns20.adl2.on.ii.net (203.16.215.197) 60.540 ms 60.752 ms 60.994 ms
3 te3-3.cor3.adl2.on.ii.net (150.101.134.29) 71.761 ms 71.901 ms 71.958 ms
4 xe-0-0-0.cr1.adl6.on.ii.net (150.101.225.77) 61.367 ms 61.633 ms 61.635 ms
5 * * *
6 te0-2-1-2.br1.sjc2.on.ii.net (150.101.33.147) 233.445 ms 232.920 ms 234.687 ms
7 144.232.191.193 (144.232.191.193) 292.718 ms 216.278 ms 225.398 ms
8 sl-payp2-413771-0.sprintlink.net (144.232.191.210) 217.304 ms 218.512 ms 219.541 ms
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
**15 api-3t.paypal.com (173.0.88.101) 243.720 ms 245.597 ms 246.570 ms
**rod@sue:#

Cheers
Rod

RodG:

Before discussing this further, what was the exact traceroute command that you are using for testing?

Unless you enable TCP and specify port 443 it is unlikely your results are telling you much at all.

---

Example#1 (seemingly blocked / no route)
rod@sue:#** traceroute api-3t.paypal.com**
traceroute to api-3t.paypal.com (173.0.88.69), 30 hops max, 60 byte packets
1 gw (192.168.0.254) 0.871 ms 1.163 ms 1.662 ms
2 lns20.adl2.on.ii.net (203.16.215.197) 40.294 ms 41.506 ms 42.412 ms
3 te3-3.cor3.adl2.on.ii.net (150.101.134.29) 44.132 ms 45.606 ms 47.304 ms
4 xe-0-0-0.cr1.adl6.on.ii.net (150.101.225.77) 48.920 ms 50.429 ms 52.932 ms
5 ae4.br1.syd7.on.ii.net (150.101.33.34) 73.005 ms 73.829 ms 75.752 ms
6 te0-2-1-2.br1.sjc2.on.ii.net (150.101.33.147) 232.961 ms 233.349 ms 233.677 ms
7 144.232.191.193 (144.232.191.193) 266.432 ms 244.702 ms 244.354 ms
8 sl-payp2-413771-0.sprintlink.net (144.232.191.210) 215.993 ms 217.464 ms 218.960 ms
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
rod@sue:#

Example#2 (Using TCP port 443 shows all ok)
rod@sue:#** traceroute-T -p 443 api-3t.paypal.com**
traceroute to api-3t.paypal.com (173.0.88.101), 30 hops max, 60 byte packets
1 gw (192.168.0.254) 0.847 ms 1.196 ms 1.528 ms
2 lns20.adl2.on.ii.net (203.16.215.197) 60.540 ms 60.752 ms 60.994 ms
3 te3-3.cor3.adl2.on.ii.net (150.101.134.29) 71.761 ms 71.901 ms 71.958 ms
4 xe-0-0-0.cr1.adl6.on.ii.net (150.101.225.77) 61.367 ms 61.633 ms 61.635 ms
5 * * *
6 te0-2-1-2.br1.sjc2.on.ii.net (150.101.33.147) 233.445 ms 232.920 ms 234.687 ms
7 144.232.191.193 (144.232.191.193) 292.718 ms 216.278 ms 225.398 ms
8 sl-payp2-413771-0.sprintlink.net (144.232.191.210) 217.304 ms 218.512 ms 219.541 ms
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
**15 api-3t.paypal.com (173.0.88.101) 243.720 ms 245.597 ms 246.570 ms
**rod@sue:#

Cheers
Rod

Example #1 was the latest attempt. Thought I had looked through the command options for determination of a secure route, but guess I missed. The obvious.

When I performed a traceroute from a New Zealand service they identified the same general end service location as option #2.

Previous discussion in this or a similar thread has provided the same end result as #2, but a follow on comment was that it was still AT&T even though the end result was sprintlink. Advice?

Also, today wrote back to AT&T asking if they showed traffic through their servers from or IP address, and was provided a traceroute from them to us. (Thinking also in format of option #1.)

mc12345678:

Previous discussion in this or a similar thread has provided the same end result as #2,

This is the result needed. If this traceroute works, the processing will also work.

mc12345678:

but a follow on comment was that it was still AT&T

The traceroute example I provided shows that there is no problem between my localhost and the paypal server. It doesn't tell us anything about the connectivity between your store and PayPal.

mc12345678:

even though the end result was sprintlink. Advice?

Unless proven otherwise I will be assuming that all traceroutes performed so far (even those performed by AT&T) were done without the required options.

mc12345678:

Also, today wrote back to AT&T asking if they showed traffic through their servers from or IP address, and was provided a traceroute from them to us. (Thinking also in format of option #1.)

Unless you know the traceroute command being used the results are worthless.

Show me the output of a ** traceroute-T -p 443 api-3t.paypal.com** from your store, because I'm seeing conflicting information here.

Cheers
Rod

RodG:

This is the result needed. If this traceroute works, the processing will also work.

The traceroute example I provided shows that there is no problem between my localhost and the paypal server. It doesn't tell us anything about the connectivity between your store and PayPal.

Unless proven otherwise I will be assuming that all traceroutes performed so far (even those performed by AT&T) were done without the required options.

Unless you know the traceroute command being used the results are worthless.

Show me the output of a ** traceroute-T -p 443 api-3t.paypal.com** from your store, because I'm seeing conflicting information here.

Cheers
Rod

Wish I could show/perform a traceroute (with tcp and 443) from my store, server does not appear to have any functions enabled to perform a traceroute available to customers. I will again put a request in to host to see if they can provide a result via tcp and port 443.

I can in about 7 hours provide a traceroute from a local computer (which does not have a problem with connecting to paypal although the same ZenCart code is installed), but that too seems like it wold not be of any value.

No response back yet from AT&T after requesting investigation using TCP and port 443 with the command line provided (spaces applied applicably).

From at&t:

Please visit http://www.ehow.com/how_8619185_check-port-443-open.html for instructions to check if Port 443 is open.

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

traceroute [our ip address]
Type escape sequence to abort.
Tracing the route to [our ip address]
.
.Intentionally blank
.
6 154.54.12.85 8 msec 8 msec 8 msec
7 154.54.29.21 [AS 174] 8 msec
66.28.4.73 [AS 174] 8 msec
154.54.5.9 [AS 174] 12 msec
8 154.54.45.218 [AS 174] 28 msec
154.54.45.242 [AS 174] 32 msec
154.54.24.53 [AS 174] 28 msec
9 154.54.46.242 [AS 174] 32 msec
154.54.46.238 [AS 174] 32 msec
154.54.46.242 [AS 174] 28 msec
10 38.104.252.54 [AS 174] 32 msec 32 msec 28 msec
11 * * *
12 our ip address 28 msec 32 msec 28 msec

The issue that you are reporting is not an AT&T issue. Recommendation is to contact your hosting service provider for further support.

mc12345678:

Wish I could show/perform a traceroute (with tcp and 443) from my store, server does not appear to have any functions enabled to perform a traceroute available to customers. I will again put a request in to host to see if they can provide a result via tcp and port 443.

I can in about 7 hours provide a traceroute from a local computer (which does not have a problem with connecting to paypal although the same ZenCart code is installed), but that too seems like it wold not be of any value.

No response back yet from AT&T after requesting investigation using TCP and port 443 with the command line provided (spaces applied applicably).

From at&t:

Please visit http://www.ehow.com/how_8619185_check-port-443-open.html for instructions to check if Port 443 is open.

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

traceroute [our ip address]
Type escape sequence to abort.
Tracing the route to [our ip address]
.
.Intentionally blank
.
6 154.54.12.85 8 msec 8 msec 8 msec
7 154.54.29.21 [AS 174] 8 msec
66.28.4.73 [AS 174] 8 msec
154.54.5.9 [AS 174] 12 msec
8 154.54.45.218 [AS 174] 28 msec
154.54.45.242 [AS 174] 32 msec
154.54.24.53 [AS 174] 28 msec
9 154.54.46.242 [AS 174] 32 msec
154.54.46.238 [AS 174] 32 msec
154.54.46.242 [AS 174] 28 msec
10 38.104.252.54 [AS 174] 32 msec 32 msec 28 msec
11 * * *
12 our ip address 28 msec 32 msec 28 msec

The issue that you are reporting is not an AT&T issue. Recommendation is to contact your hosting service provider for further support.
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.

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

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.

mc12345678:

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:

mc12345678:

From at&t:
Please visit http://www.ehow.com/how_8619185_check-port-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. :)

mc12345678:

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

mc12345678:

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

RodG:

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.

RodG:

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?

RNRN:

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.

twi:

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.

mc12345678:

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

mc12345678:

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.

mc12345678:

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

Maybe.

Cheers
Rod

mc12345678:

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.

mc12345678:

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.

mc12345678:

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