How to open port 1129?

DrByte:

I just wanted to ensure that you were in fact using v1.3.7 and the built-in version, and had not downloaded the older version and overwritten the good one built-in to v1.3.7.Hey, wait a second... you mean I could've overwritten it? That was what I was asking before.

So how would I know if it's been overwritten or not?

Assuming you're using the v1.3.7 edition of the module, we should be able to get some communications debug data:
Try this:

1. Admin->Modules->Payment
2. Click on Linkpoint API
3. Click on Edit
4. Edit the URL in your browser, and add this to the end: &debug=on and press Enter
5. Scroll to the bottom of the list, and change the Debug mode to Log File or Log and Email.
6. Go to the store and attempt a transaction.
7. Look in your /cache folder for a log of what data came back from the communication attempt, or check your email (store's email address) for a copy of the debug data.

theapeman:

Hey, wait a second... you mean I could've overwritten it? That was what I was asking before.

So how would I know if it's been overwritten or not?

I think you're paranoid.

1. DID you download the older module?
2. DID you upload it to your site?

EITHER WAY, it doesn't affect whether the module can talk to Linkpoint.

I was only looking for knowing what features were in the module. ... NAMELY so I could maybe get you to enable debug logging so we can get the module to tell you that it can't talk to Linkpoint ... so that you'll believe me when I tell you the problem isn't the module, but has something to do with your firewall or CURL ... which would likely be my next post...

theapeman:

So about that form: Am I meant to fill it out or aren't I?

No.

But if you strongly believe you should, then use this:

Submission URL: https://your_site.com/index.php?main_page=checkout_confirmation
completion page: blank
failure page: blank

EDIT: It's possible that Linkpoint might require filling in the Submission URL as part of their security protections. But, normally, the information they're asking for on that page is related to "Linkpoint Connect" module, not the API module.

DrByte:

I think you're paranoid.

1. DID you download the older module?
2. DID you upload it to your site?

EITHER WAY, it doesn't affect whether the module can talk to Linkpoint.Paranoid? I don't think I understand that remark. But I clearly wrote> theapeman:

and I have no memory of installing the modulewhich of course is very different from saying for sure that I didn't install it, and I only equivocated about it because you raised the question in the first place, so I assumed it mattered, not that you were asking a question whose answer made no difference either way.

DrByte:

No.

But if you strongly believe you should, then use this:

Submission URL: https://your_site.com/index.php?main...t_confirmation
completion page: blank
failure page: blank
Holy cow, I don't strongly believe anything, I was just asking. I only kept asking because I never got an answer.

Anyway, thanks for the debugging info. I will try it and report back results. It seems like maybe I annoyed you by saying I wish there were instructions, so sorry about that. But if there had been instructions, I wouldn't be here annoying you! :yes:

Sorry, not annoyed. Just been a long day.
My apologies for the frustrated tone.
Let's hope the debug output is helpful.

Just to follow up, as I was re-reading your instructions about how to debug, I noticed (in the same post in which you called me "paranoid") that you wrote:

DrByte:

... so that you'll believe me when I tell you the problem isn't the module, but has something to do with your firewall or CURLand then I realized I must have missed a post of yours somewhere, because at no time previously had anyone told me what the problem was. If you had told me that, I would have no reason to doubt you. So I don't know what happened there. Maybe your post got lost somewhere between "Submit Reply" and wherever it goes after that.

And as I read your quote it struck me that that might be another reason you seemed annoyed, in other words, maybe it sounded to you as if I were ascribing "blame" to the module, rather than where you felt it belonged, namely firewall or cURL. But I wasn't assigning blame to the module, and not because it would be silly to blame an inanimate object like a firewall or a module, but because I don't really care that much about the source of the problem, only about fixing it.
Makes sense, right? So do we need to hug it out now, or what? :yes:

DrByte:

Sorry, not annoyed. Just been a long day.
My apologies for the frustrated tone.
Let's hope the debug output is helpful.

Oh, hey, didn't see that last post, but no problem. Just ask merlin: I recently had to make the exact same apology to him, practically word for word, in fact.

It's all good, and I really appreciate your help.

Possible causes of failure to complete a CC authorization using Linkpoint include:

1. Port 1129 not open on firewalls or blocked by proxy limitations
2. CURL not installed/compiled on server
3. SSL support not enabled for CURL on server
4. Bad account settings in Zen Cart admin area
5. Bad PEM file upload to server
6. Linkpoint site down
7. Attempting to do test transactions on production account or vice versa.

The debug output will hopefully give us clues as to what may be failing.

DrByte:

Possible causes of failure to complete a CC authorization using Linkpoint include:
..
7. Attempting to do test transactions on production account or vice versa.Really? That's the first I've heard of that. See what I mean about instructions?

DrByte:

Assuming you're using the v1.3.7 edition of themodule, we should be able to get some communications debug data:
Try this:

1. Admin->Modules->Payment
2. Click on Linkpoint API
3. Click on Edit
4. Edit the URL in your browser, and add this to the end: &debug=on and press Enter
5. Scroll to the bottom of the list, and change the Debug mode to Log File or Log and Email.
6. Go to the store and attempt a transaction.
7. Look in your /cache folder for a log of what data came back fromthe communication attempt, or check your email (store's email address)for a copy of the debug data.Anyway, when I modified the url as described, I didn't see anything about Debug mode, but I did see a Communications Check Mode that wasn't there before, which promised to "display large amounts of communication information" on my checkout pages, so I enabled it and did another test transation with the same results as before. Nothing was logged in my cache file, I didn't receive an email and there were only the normal amounts of information on my checkout page. So it seems that I must have installed the download version at some point, because this doesn't seem to match what you described. But I know now that it wasn't going to work anyway, because I was trying to do a test transaction on a production site. That confuses me. Is a live customer supposed to be the guinea pig?

One more thing, and believe me I debated whether I should say something about this or just let it slide, because I really do appreciate your help, not to mention the fact that since you're obviously some kind of big Kahuna around here, I'll probably end up getting banned.

But here it is: The thing is, when posting on forums I often edit my posts after I post them. Generally it's for clarity, grammar, punctuation, typos, or maybe I want to punch up my jokes a little bit, you know, make them funnier. However, I've never gone back and changed one of my posts in order to make myself sound better: smarter, more knowledgeable, less grumpy, whatever. That would just be lame. It be like I was trying to cover up something I was ashamed of, and I assume someone else would notice and call me on it, and I'd be even more embarrassed. Besides, what difference does it make? If I'm going to be grumpy, I'm going to stand behind my grumpiness, not go back like a thief in the night and try to erase it as if it never happened.

But whatever. That's me. Do what you want with your own posts.

Where I have a problem is that you apparently took advantage of your Big Kahuna status to go back and not only alter your own post to make yourself sound less grumpy, but also to delete portions of one of my posts as well, since I both quoted and directly responded to your grumpy remark.

I have a problem with that because you used power that others don't have to alter one of my posts in a way that reflects negatively on me, for the purpose of making yourself look better. Future readers will see this thread and say "Boy, that ape man sure made a big deal about nothing. DrByte wasn't grumpy at all!" And I think that's totally uncool and I have a problem with it.

For what it's worth, the original, unredacted posts are available here:

http://afrobacon.info/index.html#post384186

It's posts #24 and #25. I assume when I'm banned this post will be deleted, so anyone interested in reading it should move quickly. You'll be disappointed, though. If anything, what you'll be struck by is the utter banality of the remark. Dr Byte, as they say, it's not the crime, it's the cover-up. Ironically, you end up looking worse for trying to cover up your relatively innocuous grumpiness than for the grumpiness itself.

And to be clear, the point is not the whether or not it's wrong to be a grouch. I really don't care about that. It's about the abuse of power in pursuit of shallow, self-serving ends, at the expense of others who don't have the same privileges.

What sucks the most is that getting banned for saying this is going to make it really hard to get my Linkpoint module working. But a guy has to speak his mind, and there, I've done it.

Okay, let's try it this way. (since I think you must be using the older downloaded module, instead of the default v1.3.7 module ... or else the debug option would appear as described earlier).

Attached is an updated /includes/modules/payment/linkpoint_api.php file.
Unzip it and upload it to your server.
Then edit the settings and add the &debug=on to the URL again.
What does it give you for debug options? Enable logging and/or email.
Try a test transaction.

DrByte:

Possible causes of failure to complete a CC authorization using Linkpoint include:
...
7. Attempting to do test transactions on production account or vice versa.

theapeman:

Really?
... I know now that it wasn't going to work anyway, because I was trying to do a test transaction on a production site. That confuses me. Is a live customer supposed to be the guinea pig?

When I said "production account", I meant "a linkpoint account that's not in test mode". I was referring to the "account", not the "site".

The premise behind my point #7 was that ... sometimes folks don't remember to set both their "account" and their "shop" to be in the same mode.
ie:
If you set your Account to be in Test mode, but leave your Zen Cart module set to "production", then ... Zen Cart attempts to tell Linkpoint that you want to do a real transaction. But, if your account is in Test mode, then the "real transaction" system is going to reject the request because it doesn't have access to the account, since it's in test mode. Gads, that's a run-on thought.
The same can happen vice-versa. Hence point #7.

I doubt very much that point #7 is your problem at this stage. I added it as an afterthought just before I posted that list ... not because I thought you were running into it, but for the benefit of future readers of this discussion. Hence the wording saying "Possible causes ..."

Problem solved. Thank you, DrByte.

Using the version of the module you provided I was indeed able to activate debug mode, which immediately showed that cURL was trying to connect to Linkpoint via 64.202.165.130:3128, the IP address of GoDaddy's proxy server. This is because when I first started trying to set this module up a couple of weeks ago I was on a GoDaddy shared hosting plan, and it seems that following a suggestion found elsewhere in these forums I had gone into /includes/extra_datafiles/curl_proxy_info.php and changed the setting there to 'True'. Of course this made no difference at all because that had nothing to do with port 1129, but I forgot to set it back to 'False' and it had been set that way ever since. As soon as I fixed that I was good to go.

Let me, if I may, make an observation meant to purely constructive. If I'm not mistaken, the only time you would need to go through GoDaddy's proxy server is if you were on a GoDaddy shared hosting plan; but if you're on a GoDaddy shared hosting plan you do not have access to port 1129 so changing the setting in /includes/extra_datafiles/curl_proxy_info.php isn't going to do anything. Therefore it seems to me that that file at best serves no purpose at all, and at worst can potentially cause problems as it did in my case. On the other hand, if the file is there simply as a template for situations where it is necessary to go through a proxy in general, perhaps it would be less confusing if it didn't refer specifically to GoDaddy and use GoDaddy's proxy server address.

I offer this comment only in an effort to be helpful based on my recent experience. If it's way off base, well, it wouldn't be the first time. :D

Dr.Byte, for hanging in there with me this long and seeing this issue through to its resolution, you have my thanks and my respect. Cheers! :thumbsup:

theapeman:

Problem solved. Thank you, DrByte.

...

Dr.Byte, for hanging in there with me this long and seeing this issue through to its resolution, you have my thanks and my respect. Cheers!You're welcome. Glad it's solved !

theapeman:

Let me, if I may, make an observation meant to purely constructive. If I'm not mistaken, the only time you would need to go through GoDaddy's proxy server is if you were on a GoDaddy shared hosting plan; but if you're on a GoDaddy shared hosting plan you do not have access to port 1129 so changing the setting in /includes/extra_datafiles/curl_proxy_info.php isn't going to do anything. Therefore it seems to me that that file at best serves no purpose at all, and at worst can potentially cause problems as it did in my case. On the other hand, if the file is there simply as a template for situations where it is necessary to go through a proxy in general, perhaps it would be less confusing if it didn't refer specifically to GoDaddy and use GoDaddy's proxy server address.

You're absolutely right.
In fact, that file came from the older downloaded module (or maybe older instructions posted on the forum), and is not part of the core distribution fileset.
In the core fileset, you'll find that those proxy settings have been moved into Admin->Configuration->My Store, and while GoDaddy is listed as an example proxy, the default is to leave the address blank, and proxy status to false.
Thanks for the feedback to help minimize confusion.

I am having a connection problem similar to the person who started this thread, however, I'm not with godaddy.

When I put linkpoint in debug mode and then submitted a transaction, the next page gave me a bunch of info (I did not have to go to my cache directory.

I do not have an ssl installed yet (I plan to but but wanted to get other things setup and a little short on cash :blush: )

Can someone tell me if I am understanding this correctly? It is trying to send using https: but because curl was built with ssl disabled, it is not sending the file to linkpoint? If that is the case, where do I modify the code to tell it to send just using http: ? Or maybe I'm really far off... :huh:

I would appreciate any help.... maybe this is an issue that others are experiencing. I'm sure this thread will get a lot of traffic when people search for linkpoint problems.

ECI1109983/home/watchservice/public_html/includes/modules/payment/linkpoint_api/1109983.pemsecure.linkpt.net11290.01 server responds: libcurl was built with SSL disabled, https: not supported! ErrNo:1 server responds: FAILURECould not connect.
Warning: Cannot modify header information - headers already sent by (output started at /home/watchservice/public_html/includes/modules/payment/linkpoint_api/class.linkpoint_api.php:178) in /home/watchservice/public_html/includes/functions/functions_general.php on line 44

an update on my issue..

I am up and running without any problem.

I would like to share my solution with others as you may have the same problem as me.

My host had to recomplie PHP with OpenSSL support as cURL was not accepting ssl protocol. ( hope I'm saying that correctly).

You can see my error in the post above.

:clap:

theapeman:

This is because when I first started trying to set this module up a couple of weeks ago I was on a GoDaddy shared hosting plan
Is there a way around the ability to open port 1129? I've not been able to find it and would really appreciate any info.

no there is NO way around port 1129
if your host will not open it then you have 2 choices,
1 dont use linkpoint
2 get a host that has this port open

Ahh...I figured that would be the answer. Oh well. I already set up a new host, SSL & dedicated IP.

Thanks for the reply though :cool: