Hello,

I have a problem with the PhpED debugger.

I upgraded from PhpED 19.5 to PhpED 20.0 about one month ago.
Since then, I spent hours trying to understand why I am no longer able use the debugger.

I use this debugger by connectivity through SSH tunnel, but it seems no longer able to connect at all.

This clearly appears as a failure from the last step of Project's setting wizard.

On all relevant projects.

From all of my eight remote servers at once.



Setting debugger.fail_silently to On or Off do not make any difference.

Of course, I suspected an issue with my main computer at first.

But after some time, I nevertheless made another test.

I took another computer which still had an older PhpED version installed (19.1 if I remember well).
And I found that this one worked properly with my remote servers that still have a PHP version compatible with it.

Then I upgraded on this other computer with the intermediary version 19.5.
It still worked, with more PHP versions.

Then I upgraded, still on this other computer, with my last PhpED version, 20.0, same as on my main computer.
No configuration change.
And there also, the remote debugger module stopped connecting with the computer, likely on all servers (I didn't want to spend more time testing all of them).

Of course, I switched the remote debugger module version each time.
I even wrote a BASH script to quickly make this change, as it is so common that I need to do this kind of manipulation.

I now need a PhpED version able to debug PHP 8.2.

Is there an intermediary version between 19.5 and 20.0, supporting PHP 8.2 and that I could install with the new key that I just bought?

I also posted this demand through the contact support form, but I didn't get any answer so far.
Not being sure this form works properly, I duplicate the demand here.

Regards,

Gingko

P.S : My main computer as well as the second one runs Windows 10 Professional with all latest updates.
My servers run Linux Debian 10, 11 or 12 or Ubuntu 22 LTS, with PHP version 7.3, 7.4, 8.1 or 8.2.
Also tried with a Raspberry Pi 3 or with Windows Subsystem for Linux on my main computer.

it may have something to do with custom settings on your server. Let's proceed with support ticket you've already opened

Please, don't try to minimise by using singular on the word “server”.
I wrote about eight servers.

Which are the followings :

• One Bare metal server running Linux Debian 10 “buster” and PHP 7.3
  
• One Bare metal server running Linux Debian 11 “bullseye” and PHP 7.4
  
• One Bare metal server running Linux Debian 12 “bookstorm” and PHP 8.2
  
• One Virtual private server running Linux Debian 12 “bookstorm” and PHP 8.2
  
• One local test computer (rather old, Intel Core 2 duo processor) running Linux Debian 12 “bookstorm” and PHP 8.2
  
• One Windows Subsystem for Linux on my main machine running Linux Ubuntu 22.04.3 LTS and PHP 8.1
  
• One Raspberry Pi 3 system running Linux Raspbian “bullseye” and PHP 7.4
  
• One VMWare Worstation Virtual Machine running Linux Ubuntu 22.04.3 LTS and PHP 8.1
  

And about clients, I used PhpED 19.5 and PhpED 20.0 on three different Windows 10 x64 Professional 22H2 French edition systems:

• One with Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz 4.01 GHz, with 32 Gb RAM.
  
• Another one with Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz 4.01 GHz, with 32 Gb RAM.
  
• One rather old laptop, Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz 2.40 GHz, with 4 Gb RAM.
  

This makes 24 possible combinations.

All of them gave the same results :

When running PhpED 20.0, the debugger was unable to connect, on all 24 combinations.
When running PhpED 19.5, it worked perfectly (but actually only on 3 of these remote systems as PhpED 19.5 do not support PHP 8.1 and 8.2, thus 9 combinations only).

And the support ticket is currently pending on the following answer:


Meaning that I bought an upgrade from a working system, the upgrade doesn't work properly, and I am asked to pay more for having it working because my licence do not entitle me to technical support.

This is something that I will definitively NOT do.

Here, I'm not asking for technical support.
I'm asking for Software Application Warranty.

If you don't know the difference, there are many pages on the web explaining it.



Buying an upgrade from a working product and having this product drily no longer working after having made only this upgrade is something which should never happen.

Asking customer to buy a higher license because of such problems, after they bought a lesser license, looks very much like "forced sale".

You can say that “there is no such problem on our side”, but here, “your side” is definitively not “my side”.

Gingko

P.S. : I didn't write it, but I bought PhpED 20.0 on build 20035.

Still not having received any additional answer to this.

But in the meantime, I just noticed some interesting facts.

The PhpED 20.0 build I was using was 20035.

But a new build, 20036, was published on 2023-09-17 (if I refer to the latest binary timestamps inside it).
Discretely.
I haven't received any “NuSphere PhpED 20.0.0 build 20036 is released” email notification on this, like the ones I sometimes receive.

Thus after the initial warranty request I sent on 2023-09-08, and before the only answer I got on 2023-09-20.

Of course, I thought first about a discrete update in order to make me lying.

Nevertheless, I hoped being able to get, that way, a finally working version.

But unfortunately no.

After installing and checking, build 20036 appears not less flawed than 20035 on the reported problem.

For the sake of curiosity, I then check the following.
The changelog for 20036 indicates this:



Especially interested by 0005706, I put debuggers 11.0.24 (from 20035) and 11.0.26 side by side, I made hexadecimal dumps for each of them, and I made a diff compare on these dumps.

The result is the following (here for x86_64, php 8.2 versions, but I also made the same for 7.3 with similar results):
(note that I use to rename these debugger libraries by adding version numbers inside their names in order to differentiate them more easily when I want to switch them; this never have made them not working, as far as I use the same name in php.ini)

If you look closely inside this, you can see that these files differ only on eleven points, all of them being related to version number.
Either in ASCII ("24" becomes "26") or in binary (0x18 becomes 0x1A).

Anything else is otherwise absolutely identical.

Although this is enough for having the IDE rejecting the version not corresponding to it, I'm wondering how is it possible to fix any bug by making only this kind of change?

Regards,

Gingko

Correlation does not mean causation.

We delayed with 20036 only because of unrelated issues problems with pipelines. There are not fixes for your problems planned or delivered, at least no intentional as we don't know what happened on your side. Announcement about this update is still going through the list of customers, which is large enough to be sent instantly. You'll receive yours, eventually. It wouldn't be even possible to sync releases with customer issues with given number of customers.

If you have problems with tunnels you need to turn your server logs and go from there. Ssh daemon rarely returns anything useful at all -- in case of problems it just returns unauthenticated response, that's it. Support engineers have good enough expertise and would help you investigate the problem but you refused it. It's your decision and we honor it.

In your place I would not judge based on number of servers your running and using single Personal license against them all. If you have only one system administrator for them or one policy for them, there is good chance that the same mistake is on your side on all your 8 servers. On the other hand, it's possible that the problem on our side, but no one can tell until it's properly investigated. We can't do this on our own as it works fine in our test environments.

Comparing with previous version of PhpED like 19.5 or 19.1 is irrelevant because there are significant security related updates in v20. Enforced security in v20 may not allow PhpED to work with them by default if all eight your servers have the same flaw/misconfiguration and/or there is something with authentication you're using. If you post here details from the server side , we'll figure out what's going on, eventually.

You don't have to compare debugger binaries, you could just ask and I'd confirm that there are _no_ changes in the debugger server side between 11.0.24 and 11.0.26 other than building with openssl 1.1.1v vs openssl 1.1.1w, which is not bundled in your case. So they are identical.
You don't have to make wrong statements about IDE rejecting debugger. It does never reject sub-minor version changes in debugger. Wizard only warns in case of mismatches because there could be some needed fixes, but never blocks. That's it.

Warranty does not exist in software market. You don't have warranty for any software you're running. You can read software license agreement to see it. You have right to run software under certain conditions, but no one would ever guarantee that it will work. Nor any one can even expect it to work with all possible environments on customer sides. PhpED is not an exception.

I agree with you that our documentation has couple of gaps and could be improved. There is always space for improvements. We provide FAQ and update it time after time when we see the need. If / when we come to the point and know for sure what happened in your case, we'll provide more items in FAQ and/or update shipped chm file(s).

My SSH configurations are the raw configurations provided with the Linux distributions I use, I do not made unusual changes on them, and I work like this for more time than my first PhpED buy time.

I don't have problems with tunnels. I frequently use tunnels on my own (without any relationship with PhpED), and they work perfectly for the usage I made of them.

But PhpED tunnels are created by PhpED as client (rather than with PuTTY on my side). Thus using a client software library which is included inside PhpED, and is upgraded with it. I don't have any control on this, an it provides very few settings: apart “compression”, there are the common SSH defaults on which I keep, like it is said, the defaults.

This upgrade is the ninth upgrade I made since my first buy in 2014. Even if you can't see all of them in my account: there was a four years period during which I used a Pro version paid by the company where I was working, using another account (that I still can access if needed). Now I quit this job because retirement, so I reverted to my previous own personal account. Anyway.

This is for telling that my configurations were working for a veryyyyyyyyy long time, and that I am very comfortable with them.

If there are protocol changes, they are between your debugger and your application, and they are expected to be upgraded all at once, so this should be transparent to users, especially at raw upgrade time.

You are not expected to make any protocol changes which could be incompatible with the basic SSH ones, external to PhpED, which can be found in most current operating systems.

Of course.

You explicitly said in your changelog that “Debugger is updated to version 11.0.26”, you explicitly said that this is related to a “Bug report”, but nothing is different.

Everything is normal.


Where did you see that warranty does not exist in sofware market? Are you creating your own laws?

In France we have “Décret n° 2022-946 du 29 juin 2022 relatif à la garantie légale de conformité pour les biens, les contenus numériques et les services numériques” which is very explicit on this.

In US, it seems that you have “Magnuson-Moss Act” on which I cannot find anything telling it doesn't concern software market. It seems that it excludes services. But a software application is not a service.

About this, I found:
I did not find any disclaimer like this around your product.

Not even in the Licence Agreement that I have to accept when installing the software.

The only softwares that we expect to get without warranty are free and/or open source softwares.

Despite being less expensive than its Pro version, NuSphere PhpED 20.0 Personal for Windows is not a free software.

NuSphere PhpED 20.0 Personal for Windows is not an open source software either.

If there is something that changed with the upgrade that I cannot solve without documentation, this documentation should be available not later than the upgrade itself.
_______________________________________________________

And apart of that, I can read this in the Licence Agreement that I have to accept when installing the software:

Ok. Let's say that I didn't click the “Deny” button, and that I that I didn't proceed with the installation of the product. After all, this makes no difference about if I uninstall it right after (and even if I did click the “Deny” button … I still have the product key that I must return and forgot while being sure I will not retrieve a copy of it later…).

My buy is not as old as 60 days. I already asked you — privately — to refund. Why haven't you proceeded with this yet?

I'd be happy to provide links on the pages where I've found legal informations.

But unfortunately your forum prohibits any external link. I'm not sure I want to spend time providing them as pictures.

Congratulations with your retirement. Mine is not too far away.

From the original screenshot, I can tell that the tunnel is running (see 2nd line with green check). You can double check it with command below
`sudo netstat -naop | grep '^tcp' | grep -w 7869`
^^ If tunnel is established, it will show you one or multiple lines: 7869/TCP port in LISTENING state, connections to it if there are any and corresponding PIDs that own the listening socket and the connections.

It's clear that the sample.php script is running and returning correct output, so https protocol from the Wizard client is working and GET request for the page is delivered.

What is not working, I'm just guessing, is DBGSESSID cookie. It's either stripped off or somehow else corrupted so debugger didn't see it or debugger didn't have a chance to see it.

If you just finish wizard and save the results, you can check if cookie from a _browser_, rather than from the Wizard client, is delivered. If not, you can try to set DBGSESSID in the URL and check again.
Details on how to do it and what syntax is there is in the FAQ http://www.nusphere.com/kb/technicalfaq/howto_run_dbg.htm
Finally you can try non-SSL web site. And let me know what fixed the problem.

I will check on this later, but in the meantime, I made several Wireshark network captures on the client sides, filtered on localhost port 7869.

If ever you are interested by a copy of them.

Based on the screenshot at the top, debugger didn't try to connect to tunnel. I'd expect no traffic there at all.
If it tried and failed, it would return very different content, not sample.php script output. If it succeeded, we'd see debug session. So it didn't try and therefore it didn't see debug request.
If you saw some traffic on 7896, it's likely keep/alive packets from the client side. If you see anything else. let me know, but anyway I'm primarily interested in cookie delivery and it's all about Web server. Can you log cookies passed from the client side and see if the Wizard's DBGSESSID make it through?

Actually yes, there is.

I can see nearly the same tunnel traffic start using 20.0 than with 19.5.

Apparently it's the IDE which responds only barely to some requests and ignore the others.

So the dialog never completes.

7869, not 7896.

I will eventually look at cookies later, especially knowing that I'm not even sure about where to see these cookies and how to log them.

But for know I have something even stranger to report, after my latest tries:

I mainly have two kind of projects :

• Projects with both HTTP and CLI scripts
• Projects with only CLI scripts

The first ones produces two tunnel attempts, one for HTTP, one for CLI.

The above failing test was the HTTP tunnel attempt of one of my first kind scripts.
It fails after the succeed of the two first tests, in HTTP and CLI, without tunnel.
And actually, it fails after about 2 minutes hanging.

But if I proceed right after to the following test (CLI with tunnel), this one succeeds.

The second kind (only CLI) have, strangely, a very different behaviour:
It succeeds in the console part, but it fails in the tunnel part.
Differently than in the first kind:
That time, there is no tunnel traffic at all.

Here you can see the wizard result of this one:



This is not a matter of other differences between the two kind of scripts:

I can just take any of my dual mode scripts, only uncheck the HTTP part, keep the CLI part, and run.
And there also, the CLI tunnel part, which just previously worked, fails without any tunnel traffic.

And finally, having a project with HTTP and no CLI fails also. Like HTTP + CLI.

All of these behaviours seem to be fully reproducible using 20.0, across changing server and across changing client computer.

And of course, all of these tests work properly using 19.5.

I think what makes difference is SSL on your servers. Can you check non-SSL, just plain HTTP?

Ok.
This seems to work (tested on two servers, by just removing the http:// to https:// redirection in Apache config on server side, and using http:// instead of https:// inside the wizard).

In dual mode projects only.

In CLI-only projects, wizard still fails, without any traffic in tunnel.
It seems to me that CLI debugging is not expected to use SSL at all, anyway.

I use SSL now anywhere I can.
I use Let's Encrypt for SSL (because it is the only one that I can use without huge fees).

Not all my debugging spaces domains are fully registered in SSL (only the production ones and some others), but it's normally not a problem if I just say that I want to bypass this security risk.

I hope you won't tell me to stop using SSL.
Previous versions worked fine using SSL, if I except, sometimes, some warnings.