RPi and OpenWrt web SSL interface woes

I have been using OpenWrt for several years with good success and, because one of my routers is getting a bit cranky about using one of its ethernet ports, I thought I would try to replace it as my pppoe border ASDL router. I have several spare RPi2B+ boards as well as an RPi4, so I thought I would try these. As the RPi2B+ is supported in 19.07 I flashed it with that, with a similar config to the TEW732BR it's replaced. And, as a router, it works just fine. If anything, slightly faster going upstream even though that NIC is connected by USB.

However, the SSL interface runs like a snail on mogodon. In fact, possibly slower. Certain parts of it seem OK (reading syslog, bringing the basic software system dialog), but the status overview page can take minutes to appear, similar waits happen on other "dynamic" pages such the network page. Accessing via HTTP on port 80, works noticeably slower than the TEW732, but is stil completely usable.

I thought, perhaps this is a cpu thing - even though the B+ has a higher clock speed than the TEW - so I tried installing the lastest snapshot on the RPi4 (4 CPU at 1.5Ghz). This took a while as I was seduced by the installation instructions to try the nginx implementation which flat out doesn't work. Nginx simply said that //router/cgi-bin/luci is not found (400). Luci is installed fine (running it on the command line will even give html), but then I remembered that nginx doesn't support cgi programs without a secondary (u)httpd server running as well. And, of course, installing that and the relevant luci packages conflicts with nginx. So start again with uhttpd and luci. As far as I can see, luci-nginx is broken.

Except that a uhttpd installation also has problems as openssl (wanted to keep that for other purposes) seems to generate invalid certificates (according to my chromium based browsers and Konqueror). They identify OK as self signed certificates, then error on actual use. They are suspiciously smaller than ones generated elsewhere. I haven't look at them closely yet, but swapped them out for a known working pair for uhttpd and at least that then doesn't error on use. So, after disabling the port 80->443 auto "upgrade" I try the https connect and can login just fine but - yet again - the status screen just shows the titles and then the working "wurlygig". For several minutes until I got tired of waiting (yes, I refreshed a few times) and now I never seem to get any output other than a title or other leading static html on pages with dynamic content - just like the RPi2B but now NEVER getting the rest of the page - although I concede I may not have waited long enough - e.g. 30mins.

Again, accessing via port 80 works fine, and in a timely fashion, but STILL slower than the TEW.

What is going on? Is this a /dev/urandom running out of data problem? Or something I have failed to do?

developer console > network (chromium) should shed some light... sound like a js query jam or similar or perhaps some shared cpu core quirk related to the ssl engine and the query sharing an already hammered core ( use htop to identify )

also state the exact release your using...

The latest 19.07.1 for the RPi2B and last night's snapshot for Rpi4. I am struggling to see why a jquery problem would manifest on an SSL connection but not a straight HTML one. Particularly as SSL on 19.07.1 on a TEW732BR works fine, but SSL - using the same certificates - cause this problem on the Rpis. And then there is the problem of the difference between the two RPis. But that could be due to one being 32bit and the other 64....