HTTPS uses CPU to do encryption such that even a brute force attempt on SSH can be CPU consuming unless the CPU has hardware encryption support which routerOS uses. What routerboard are you using? How many clients do you serve at a time and how often is HTTPS used on your network in terms of bandwidth and packets per second.
might also be helpful to show your hotspot rules too.
TY For the Reply - Fair Call On the Info - Was just getting a general idea of the Workings and what could be causing the Issue.
The RB's Affected are RB411's, RB532's, RB751U and RB600.
RB600 is a Major Node - and has been for many years - Tweaks are made constantly - up to 150 users via multiple nodes (maybe 80 users direct - rest via other RB's)
RB751U's are Newer (last 12 Months) - Most are Direct to Web, only a couple of them have had the issue - Around 20+ users
RB532's - have a lot of these still in service - yet only 1 so far has been affected
RB411's. Most of these are gone now - but the last one I pulled was due to this issue.
So, we have Mipsbe and Mipsle CPUs of varied Speeds. Different Ram Levels, yet a fairly universal config for the Hotspot - apart from the RB600 - which is running 3 Hotspots on itself, and one of the 751's which has 2.
The RB532 was emergency replaced with a Groove A-52HPn (this covers 20 Clients) - We are continuing to Monitor that, and a 751 has been replaced with a 951Ui (this covers up to 100 Clients) - checking if power and ram being thrown at the issue will help to resolve.
A 751 came up with the error today, so have rebooted and am monitoring him... but the thing that gets me, especially with the 751's is that we have a Standard Config... I had an Old 951 (the 233mhz, 32mb ones) Running a hotspot with anywhere from 60 to 180 clients connected at one time - pumping through up to 65 Mbps across a UBNT backbone. This was configured after the 751 I am now monitoring and a few weeks before the 751 I just replaced with a 951U. No Config changes were made to the base script.
The only change that has been made is that we have installed new SSL Certs - But that has happened across the board and I have another site with a 532a that is still cracking along fine - up to 50 clients.
Either way - here is our Default HS Config (I take it this is what you meant from Rules) -
# nov/06/2014 13:33:57 by RouterOS 6.13
# software id = D4Y0-VID3
/ip hotspot profile
add dns-name=XXXXXXX.co.nz hotspot-address=10.5.XXX.XXX html-directory=hotspot4.4_t2 login-by=mac,cookie,http-chap,https,http-pap,trial name=hsprof1 \
radius-interim-update=2m trial-uptime=2m/1d use-radius=yes
add dns-name=XXXXXXX.co.nz hotspot-address=10.5.XXX.XXX html-directory=hotspot4.4_t2 name=hs-trial rate-limit=\
"256k/1M 512k/2M 384k/1500k 20/20 6"
add address-pool=hs-pool-1 disabled=no idle-timeout=8h interface=hotspot name=hs-XXXX profile=hsprof1
/ip hotspot user profile
set [ find default=yes ] idle-timeout=none keepalive-timeout=8h mac-cookie-timeout=3d shared-users=25
This is from a 751 - the ROS Versions that we have the issue with vary from 5.18 through 6.19
in saying that, the idle timeout and Keepalive were also recently updated fro 2 mins and 5 mins to 8 hours - we have done away with the time card system, and were getting complaints about being logged out from client guests.
... and how often is HTTPS used on your network in terms of bandwidth and packets per second.
not too sure where to find this info bud - I bet it's in the Supout huh... lol.
Either way - TY for the info. Because of the varied range of units affected, it appears it is one of 3 things:
1: Freak Coincidental Hardware Failure... Possible and not unheard of, but unlikely
2: Cert issue - Possible - yet due to the changes being made on around 100 radios of numerous capacity - once again, unlikely unless we really screwed something up on these ones - however they do as intended after reboot - until the blow out the CPU/Ram again
3: Hotspot Config error - somewhat likely - however this has been changed across the board, so theoretically would cause that same issue on most of my routers.
I guess the only real question I have for SystemErrorMessage is that is there a way that this hardware encryption could have been disabled - and if so, where would that be. An accidental switch off here does seem to be a good place to look.
Cheers again for the info bud - will keep digging.