CumulusMX on Raspberry Pi - viewing the port 8998 site using Firefox makes Cumulus process use 200% (!) CPU

[martinu]

I've got a Raspberry Pi 3B+ which has been running CumulusMX v3.0.0 (3050) for a year or so. I've been able to access the control site on port 8998 without any problems - until today. It seems that an automatic upgrade of Firefox (to V74) on my Windows 7 PC, which I use to view the Pi's status, has started to make Cumulus go into stupid mode.

I proved this by installing Firefox V73 over V74 and everything worked fine, but as soon as FF updated itself to V74, it stopped working again.

The symptom is that when I view the port 8998 site, I get no response from the browser, but the CPU usage on the Pi shoots up to about 80% on the CPU meter in the taskbar, and running "top" shows that the process is using about 250% (yes, really!) of the CPU. It stays like this forever after. If I stop and restart Cumulus with the cumulusmx.sh script, it restarts using negligible CPU - until Firefox tries to access the port 8998 site.

Accessing it using Google Chrome does not cause the problem.

I realise that I'm on an old version of Cumulus, and I might try the latest version tomorrow, but I thought I'd raise the problem here in case anyone else had encountered it and had worked out a fix.

[HansR]

I have exactly the same configuration but I don't have the problem. I keep all versions of all tools concerned always up to date.
You could try updating Raspbian, Mono and see if that sorts any effect.
And indeed, updating CumulusMX might be a good idea, but I would first updat the OS and tools.

Strange that a browser would cause such an issue.

[martinu]

Raspbian and Mono are kept up to date as part of the

sudo apt update
sudo apt full-upgrade

that I do every few weeks.

It was only laziness that prevented me updating Cumulus, because of the need to make sure that an update doesn't undo any customisations that I've made to web templates etc. But it needs to be done.

I first noticed that Firefox on my Windows PC was having problems with streetmap.co.uk yesterday (it failed to open any page on the site, giving an error message that said that FF now needed a later version of TLS, but offering to downgrade to TLS 1.1 or 1.2 which cured that site). So I checked all the sites that I have bookmarked and found that localhost:8998 (Cumulus console) was also failing to open - in this case there was no response whatsoever. I later happened to look on the Pi and found its CPU meter running at about 80% instead of barely-visible 2%, and that the Cumulus process was the one that was eating all the CPU time - since I'd restarted Cumulus earlier in the day, it had used up 700 hours of CPU time and was using (so it said) 250% of the CPU. Restarting Cumulus reduced the CPU usage to a background level until I tried to view the 8998 page again from my Windows PC, when it shot up and stayed there until I restarted Cumulus again.

I'm about to look at LAN traces from a PC running Firefox V73 and the one running V74, to see if there's anything obviously different, and to compare it with a trace using Chrome as the browser. Something that Firefox is doing is really hammering Cumulus. I'm wondering whether the fact that FF now needs a newer version of TLS security is doing something to Cumulus.

[mcrossley]

I'm wondering whether the fact that FF now needs a newer version of TLS security is doing something to Cumulus.

Shouldn't be - Cumulus doesn't use HTTPS and hence TLS.

I'm puzzled about this too, just upgraded my FF to v74 (on Windows 10) and it doesn't have any issues - what does the Firefox network trace show (Ctl-Shift-E)?

[water01]

I have Firefox Version 74 64bit running on Windows 10 talking to CumulusMX on a separate Windows 10 machine, no issues.

[zoomx]

Try Firefox with all extensions disabled, in safe mode
https://support.mozilla.org/en-US/kb/tr ... x-problems

[martinu]

I tried FF with add-ons disabled, and it made no difference, either to the displayh of the page or the sudden increase in CPU consumed by the CumulusMX.exe process on the Pi.

The LAN traces are puzzling.

FF V74 on the desktop PC that has the fault sends an HTTP GET request for "/", which seems to contain a lot of gibberish in the request, and never gets an HTTP GET response.

Chrome on that PC, and Firefox V74 on another Windows 7 Home Premium PC, (which both work fine) do a series of HTTP GETs for sub folders, but none for the root "/".

I need to examine the traces a bit more. Is it worth me posting the Wireshark capture files and/or decoded packets that are relevant (ie just the traffic between the browser and Pi computers)?

That HTTP GET "/" with a lot of gibberish after the normal stuff at the beginning, doesn't look too good. Here's a PDF of just that packet: source is Martin-7 (10.120.1.70) dest is Martin-Pi (10.120.1.72).

If there's something that prevents me using FF on that one PC to view the console, and requires me to use Chrome instead, well it's a nuisance but it's not the end of the world. But if using FF sends Cumulus into CPU-hogging mode, then that's a bit more worrying.

I've rebooted both the browser PC and the Pi, but to no avail. I've also upgraded Cumulus to the latest version v3.4.4 (3068).

[mcrossley]

It looks like it is sending a massive amount of cookie data with the request. Could you try clearing your cookies for the CMX "site"?

[zoomx]

Maybe start an anonymous windows, it's like to start a fresh installation with some or all extension.

[martinu]

It looks like it is sending a massive amount of cookie data with the request. Could you try clearing your cookies for the CMX "site"?

Many thanks. It needed the cookies clearing. Normal service has been resumed! I thought I'd cleared the cookies, but when I checked the options for "Clear History". I'd only got cache. and not cookies, selected to be cleared.

As a matter of interest, is there a way with FF of clearing cookies selectively (per site) rather than just clearing everything that is older than a designated number of days?

I wonder whether the situation might happen again to anyone, and whether Cumulus needs to be made immune to rogue cookies being sent with the HTTP GET request, to prevent its process hogging the CPU.

[mcrossley]

In Cookies and Site Data, select Manage Data... in there you can clear per site.

[HansR]

I would never have guessed this to be a problem with Cumulus.
So, where do those cookies come from? What is Cumulus doing there and why do others - including me - never have problems with this?

[mcrossley]

Cumulus doesn't create any cookies afaik.
The cookie here was huge and about encryption "stuff" nothing to do with Cumulus.
Did the author have another device on that IP address previously?

[martinu]

Cumulus doesn't create any cookies afaik.
The cookie here was huge and about encryption "stuff" nothing to do with Cumulus.
Did the author have another device on that IP address previously?

No. As far as I am aware, the only thing that's ever been on that IP address is the Pi (the router is set to allocate a fixed "reserved" IP to the Pi) and the only thing on port 8998 is Cumulus. Firefox may have updated itself to V74 at around the time I had the problem. Everything has behaved itself fine since then. Cumulus has "failed" the test of not collapsing in a heap when bombarded with a huge cookie of crap. (Not that I'd expect it to be immune against such a rare occurrence.)