I have an SRK60 plus 2 Satellites - so Router + 3 Satellites in all
I've had this just 5 days and have experienced issues this last two days whereby the Router will stop responding, the lights will go pink and it will remain hung in that state until I manually power off, wait, power on. I have raised a case and will see what support responds with - if this is not fixable the whole caboodle will go back, but I'll give them a chance this week.
So given I have issues I decided to look at capturiung the logs via syslog in case there was something like a recurring message indicating memory leaking through a bug causing the eventual crash. I've got a couple of media servers so installed KIWI syslog server and TFTPD to see what came through - configured the syslog forwarding on the Orbi Pro Router and I get this...
I've got a couple of media servers so installed KIWI syslog server and TFTPD to see what came through - configured the syslog forwarding on the Orbi Pro Router and I get this...
Are these just random extracts from the syslog, or is this around the time where the router stoppd working and the status LED does change the colour away from white?
Its well possible some of the services like UPnP PMP remain active and "handle" the client(s) requests even something else does go mad.
That is nothing like what is displayed in the ORBI PRO Router log and makes no sense to me at all.
The router log is showing say "synthetic" application messages in a user friendly form, while the syslog does collect anything feeding to the internal syslog capability internally.
@zackunseasoned "same" == router inop/LED change or talking of the syslog content?
The answer I got was to unlink from Insight, reset the devices back to factory settings and start again. I did this yesterday and am waiting to see if it has helped.
As for Syslog, it still spews the same meaningless gibberish out constantly - even if I change the which logs to capture settings in the Advanced>Administration>Logs page.
schumaku, they are random messages as I only started collecting Syslog externally after the crashes began happening - it was an example of what I see.
I would ask what is the point of having syslog collect things internally if I cannot view them once the log is overwritten? The whole point of an external Syslog server is to capture all events so they can be viewed for diagnostic or security auditing off-device if something goes wrong. In the business context the feature is worthless if it does not provide that capabiility of filters it in any way, wouldn't you agree?
@terminaljunkie For what is offered as a Pro device for SOHO and SMB I agree - for audit reasons - that the router application log messages must be sent to the syslog mainly because these are not going to a flash, but to a volatile memory only.
This is part of Netgear's and many other router makers decades old design, typically paired with the ability to email - what a useless idea - to share the logs if the buffer is full or on a defined schedule. And long before Netgear started to make their own. When I remember right I admit I had promoted this idea to a major modem maker around at the time when POTS and ISDN modems started to make their first steps to become dial-up routers in 1995 or early 1996. There was simply no better commonly available better choice back then.
I've suggested Netgear a loooong time ago on how to enhance the event handling system a long time ago in a flexible way where the user could define what kind of data to be collected and to what kind of destination it should be sent to ... no luck, no progress. And yes, this includes the control for allowing to feed the application events and select Kernel output eg. to the syslog.
Much more useful information about the ongoing activities from these embedded Linux systems could be taken from two sources:
syslog ... permitting all processes and features do feed to it (nooo this is in no way "meaningless gibberish " as you state!), and
the Kernel output from the console, which does go to a ring buffer (volatile, too)
Evaluating the console/Kernel output (where the most useful information on a process crash cause would show up!) is kind of clueless, in the case of a crash it's very unlikely that the process supposed to forward eg. useful and informative data like OOM and process crash conditions are able to continue, so it would be lost anyway. Except where dedicated physical serial console management systems are still in place - what would be ways beyond of what the average SOHO or SMB does operate in 2021 - something given up in many mid and large scale data centers for cost reasons. So we're back there on the syslog for U**x-lik systems and the Windows audit and event log (shamelessly borrowed from OpenVMS).
Back to these small embedded routers: The mass of information does make it difficult to impossible to log into a non-volatile memory ... for cost reasons, and for reliability reasons. The small flash section won't make it long. So it's hard to keep useful post-mortem information...
