OpenSSL "Wrong version number" error

[zkarj735]

I have tried to use the debugger for the first time (since working out a domain issue previously).

Certificates generated and downloaded OK and was able to start Debug Server and Debug Service. However, on trying to set a Service Entry Point for the first time, I received the error:

EQAVS1007E on port 8005 could not be connected. Message received: write EPROTO 8870656:error:100000f7:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER:....\third_party\boringssl\src\ssl\tls_record.cc:231:

No SEP was set according to the interface.

I have no idea what this error means.

[zkarj735]

No-one has any idea on this? I've found two classes of error around the 'net that have similar symptoms - one says I'm using the wrong OpenSSL, but there is an issue on this project that says this is directly addressed now, and one says I'm using HTTPS when HTTP is required, which surely cannot be the case given the generation of certificates required to get this far.

I have recreated the error with the Debug in Batch option as well, so it is not specific to the type of debug.

[zkarj735]

Well I have "progress" on this issue. What may not be clear from my copy-pasted error is that first line...

EQAVS1007E on port 8005 could not be connected.

Note the two spaces after the error code. Despite the highly generic message, this clued me in to maybe it didn't know who to talk to at all.

I had previously seen the launch.json file - it jumped into my editor at some point, and I had not closed it as I wanted to figure out what purpose it serves. I noticed in each block it has an empty host: "" definition. Curious, I filled in the one for Service Entry Points and tried connecting again. A new error!

"Self signed certificate". Well yes, because it was generated for me! OK, so more searching...

I next found issue #2190 which mentioned installing a CA-issued cert. I have one of those. We use it successfully for Apache instances and even some bash services.

I followed the import process detailed in that issue and now I get yet another error.

self signed certificate in certificate chain

No, I disagree. The certificate is issued by our company and our Windows computers trust the issuer. I proved this is the case both for my computer by issuing a curl to the server in question, and for that server by issuing a curl from it to another server with a certificate by the same issuer. Does VSCode have its own list of trust anchors??

Next I followed another tip in the aforementioned issue - using a browser to inspect the certificate returned on port 8005. I had used this approach with the original, self-generated certificate and was indeed able to view it. Now with my CA-issue certificate installed (I am led to believe), the server response on port 8005 - either from a browser or from a curl - is "empty response" (close_notify). So I cannot even validate which certificate is being offered up.

I don't know if I should have edited the host entry in launch.json as this file is not even mentioned in the limited documentation. That documentation just gives very rudimentary steps and assumes it all just works. It clearly doesn't.

This project is a great enabler... or it would be if it would just be documented fully. A lot of the time I don't know if my problem is with Code for i, or VSCode, or Windows, or the server. I have little chance of figuring this out easily because there is so little information to go on other than issues from other poor souls who trip over the seemingly endless land mines like I do.

Also... this issue was opened over a month ago and has not received any more attention than being labelled a debug issue.

[worksofliam]

@zkarj735 sorry about that. The biggest problem with the debugger is that it is not maintained by anyone who works on Code for IBM i. So when issues arise, there is not much the maintainers can do.

I've passed this issue to someone on the debug team at IBM. Hopefully they can help.

[sebjulliand]

This project is a great enabler... or it would be if it would just be documented fully. A lot of the time I don't know if my problem is with Code for i, or VSCode, or Windows, or the server. I have little chance of figuring this out easily because there is so little information to go on other than issues from other poor souls who trip over the seemingly endless land mines like I do.

Also... this issue was opened over a month ago and has not received any more attention than being labelled a debug issue.

Wow, slow down with the cheap shots here pal. All of this is provided to you by the OSS community and volunteer maintainers, and sometimes, life gets busy! You're more than welcome to take on your personal free time to improve the documentation and help other people struggling with the extension 😊

The debug client extension and debug service is provided and maintained by IBM, as closed source projects. We're dealing with the cards we were given and it's a little bit of a struggle, as you figured out.

[zkarj735]

I'm sorry if you feel that way, but here's my viewpoint.

Code for i is not just an OSS project that I might stumble on - it is actively touted to the IBM i community through multiple channels, including directly from IBM. This is a community used to the level of documentation IBM provides for the OS on this amazing platform.

Here's my problem... I would certainly consider improving the documentation (and I have already done so once before in a very minor way) but I am not trying to figure out some subtlety of a problem here... I literally have to guess at what all the pieces are. Which is why I asked the question. I asked in the hope that people who already understand a lot more of how it works than I do might at least offer some suggestions to work with. Even if that was just "sorry, the debugger isn't happy and we don't know why".

In my missive above, I asked about the launch.json file. It is clearly a significant part of the configuration yet is, as far as I could find, not mentioned at all in the Code for i documentation. Furthermore, my question about it elicited no further information on my guessed approach to it.

We all know that documentation comes last. Heck, I used to be "that guy". Until I realised that documentation is as important as the code. This is why my team has a knowledgebase that has, last time I counted, well over 600 detailed articles on any tools and processes we have created as well as many that came before our time that we have figured out. We're sysadmins, not programmers, but we do use code (RPG, CL, SQL) to help automate stuff.

I understand the debugger is closed source and the Code for i maintainers are in the dark on its secrets, but this is not the first time I've had to guess at how Code for i works because the documentation is still very much in a "happy path" stage. If it explained all the pieces and where and why they are used, I might have a fighting chance at figuring out the issues on my own - and updating the documentation where there are gaps.

[worksofliam]

@zkarj735 Obviously you're very passionate about this project, and I am grateful for that. But, open-source is like a birthday present. You can use it and enjoy it, or you can get rid of it and never used it again. It's your to do as you wish.

There are 4 core maintainers of the project and Code for IBM i, and subsequent extensions, are not our full time jobs. IBM do commit my time to working on it, which is great, but it's not 100% of my time, and priorities are spread out to make sure things get fixed and improved across the board. None of the maintainers are paid (other than me, by my employer) to work on Code for IBM i. They do it when they are able to, because they want to.

For the record, I fully agree that our documentation could do with more enhancements. But, in this project, documentation is just like code; we have to prioritize and find the time to work on it. I can guarantee that documentation is updated as we work on new features, but perhaps it doesn't go in depth enough.

It seems like the project is not up to your standards, which does make me sad, and we don't expect you to use it. You are free to not use it as much as you are free to use it. Of course, the maintainers want to help solve issues as fast as we can. For the sake of this issue, specific to the debugger, there wasn't much we can do. It was tagged debug so someone from IBM could take a look at it (which they didn't, I am looking into this).

I can appreciate that you have told us what needs to be improved, and this is something I will hold onto as I work through my priorities for the projects. With that said, you are also welcome to contribute more. Sometimes, I find that the time spent replying to issues could be time spent contributing to docs or code to solve the issue.

I hope we can work on improving based on your suggestions, and better yet, having more documentation contributions from you so we can make improvements for all our users.

---

I thought it might be worth me explaining some specific parts.

I asked in the hope that people who already understand a lot more of how it works than I do might at least offer some suggestions to work with.

I am trying to get someone from IBM to look at this.

In my missive above, I asked about the launch.json file. It is clearly a significant part of the configuration yet is, as far as I could find, not mentioned at all in the Code for i documentation.

That is because Code for IBM i does not do anything with the launch.json file, so therefore we don't document anything. It is used by the debugger and not anything involved with us. It is documented in the VS Code docs, though.

[mkwan01]

@zkarj735 We recommend the users to use the integrated debug actions in Code for IBM i to start a debug session. Please follow the steps below:

1. Create an object filter in the Object Browser view
2. Expand the filter to show the program you want to debug
3. Right click on the target program and select Start Debugging > Debug as Batch

[mkwan01]

@zkarj735 If you use the launch template in launch.json, please add the following parameters into the launch entry and try again:

        "secure": true,
        "ignoreCertificateErrors": true,

[zkarj735]

Thank you @worksofliam for acknowledging my concern. I'd go so far as to say that documentation should be prioritised higher than it is. The best and most capable code is only as good as what people know it to be.

I have seen updates made on the project that mention "doing x smarter". If this approach was taken to documentation I think it would be in a better place. I appreciate that the maintainers don't necessarily have the time to do everything but, by the same token, everyone who uses this tool will also have limited time to try to understand how to use it. We're all professionals with a job to do that's not diving into the complexities of this.

@mkwan01 thanks for the info on launch.json. I added those and got past the next issue. However it then wanted the user, program name, and library all specified in the file. That kind of blunts this approach unless there are variables that could be used. I did get it to the stage where the debug view reckoned something was running, though I could not get the SEP to activate.

Given the futility of having to edit the file for every debug, I looked at the alternative method, using the integrated actions, but these have an important limitation. They require that the source both be present on the server (which I suspect may be a hard limitation) and that it be in a SRCPF.

One of the main reasons we are using VSCode is to enable local development based off Azure DevOps git repositories. We have this working smoothly now with a solid process around multi-user work. Gone are the days of massive comment blocks at the top of every source member! We even have a compile processor that handles source types from a stream file the OS does not.

It seems, however, that this local development approach is a thorn in the side of being able to run the debugger.

[mkwan01]

@zkarj735 Yes, we do have a requirement that the source need to be present on the IBM i. This is currently a hard requirement and built into multiple levels of dependencies. Using the launch.json file is not able to solve this limitation right now.

Given the increasing importance of local development, we will work with other teams to look for ways to address this limitation in the future.

[zkarj735]

Thanks @mkwan01. Given we have to deploy the locally edited source (to the IFS) to compile, I think it would be a reasonable interim step to support debugging from the IFS browser if there are no other technical impediments for that.