Regarding the ongoing stability improvements in the 7.21/7.22 branches, I have a feature request that could significantly speed up the debugging process:
Could you implement an option for automatic submission of the autosupout.rif file directly to MikroTik's servers whenever a crash or kernel panic occurs?
To address privacy concerns from the start:
This feature should be strictly opt-in (disabled by default).
It should comply with GDPR/privacy standards, ensuring that sensitive data is handled according to MikroTik’s privacy policy.
The user should be able to see a log entry whenever a report is sent.
Having this automated system would be a game-changer for fixing edge-case bugs on devices like the RB5009, as the dev team would receive diagnostic data instantly without waiting for users to manually generate and attach files to support tickets.
What do you think about adding this to the development roadmap?
It is proposed to be opt-in. Maybe it should also be time-limited. E.g. once you opt-in, it is only enabled for next 30 days and disables afterwards. Something like that. But I am sure that Mikrotik knows to concept of rate-limiting.
But there should be no user-facing thing that causes RouterOS generates a autosupout.rif since it's a kernel panic or process crash. And if there was something you could do that caused a autosupout.rif, that something that be good to know if you were MikroTik. They don't have to go into a ticket, just a searchable database (i.e. someone reports a crash, support/dev could search to see if it one-off or repeated thing). MikroTik cannot fix something they don't know about...
I just ran into this as I was got a couple console crashes a couple days ago testing /app. I suspect it was related to trying /app enable [find] to start all containers at same time, which likely is intensive operation creating pressure somewhere.. But debated whether it was worth the trouble to open a ticket...
So even some semi-automated thing like /system/sup-output report=yes include-auto-generated=yes might get a few more reports to MikroTik.
This is pure pessimism. The error-reporting client is under the control of ROS. When receiving appropriate HTTP status code like 429 - it just stops sending. It could even discard reporting the autosupout.rif after x unsucessful attempts.
Not debating about a potentially helpful reporting feature, instead providing killing arguments like DDOS does not help the discussion. Currently there are 2 ways to report errors to Mikrotik: create support ticket or comment here in forum. Most users don't do neither. And some dump their thoughts here in the forum, but must not attach a supout.rif because of privacy concerns. Writing a support ticket - very few people left.
One problem is that once there is a steady feed of such support files, the chance reduces that anyone will still look at them actively. The wellknown competitor has such a feature, and it seems they don’t use it and wait for you to make a ticket and provide a gigantic support file that in their case is full of personally-identifyable information. Without that they won’t even look at your case.
Some automation tool to process .rif files can be developed for internal use by MT which can have for eg. features like summarize occurrences of same crashes on different devices which can be useful for easier detection of some common issue; or to create automatic internal tickets for new crashes to be investigated by support team, etc…
But this is for another topic as @normis mentioned…
Alternatively, active beta testers must enable this feature. Link it to your Mikrotik account. If you catch a kernel panic, the developer already has the file.
Yes, sure. But that would have to be done, and the summaries would have to be read by support people.
I fear that support people are always busy reading tickets and would usually spend no time reading those summaries and trying to find out what is going on.
I already mentioned the competitor. It has a feature to send small “crash dumps” to a cloud server, containing the kernel oops and the locally used configuration file on the device. I suffered from regularly occurring kernel crashes, which I discussed on the forum, and which were also being auto-reported. But they made it very clear that those auto reports meant nothing, posts on the forum also meant nothing, I had to submit a support file from the controller, which would be an opaque 20MB file that would contain all user database entries, all traffic statistics, etc etc that were not relevant and would be a violation of GDPR rules to send to an American company.
Fortunately RIF files contain much less of that kind of information, although it of course depends on the kind of device and position in the network what it exactly contains.
Ofc, all depends how much MT wants to invest for improving product quality. For .rif files analysis there is no need for large team, few competent people which will triage reports and prioritize them for fix.
As it is a discussion "what-if-type", then there is no "killing" arguments. Do not kill discussion killing the killing argument with killing argument too, please
On the other hand: if something crashes because of an error then assumption that there would be a clear connection available is very optimistic assumption.
It's as ability to report a problem with Internet via WWW page. Seems resonable till there is no Internet.
Maybe I have been lucky but I have not seen that many crashes, that generated an autosupout.
When I see autosupout files on a device they usually are caused by winbox. It can hang in an unexpected way e.g. during display of very large tables, crashes, and the router generates an autosupout.
Probably known and not very useful to send them. Note that autosupout also can be triggered by a watchdog, for example. Users who have ticked that option without knowing what it is for will send unnecessary supout files that were not about crashes at all.
Still, when this is wanted, MikroTik could make a service (easiest probably a mailbox, but a post URL could do it too) where a script can submit it, and somehow provide it to the users who want to use it. No change required in RouterOS.
If one accepts AI actually likes a lot of data, having a central repository of many crash reports be useful for it. Or, if you a dev/support at MikroTik, even running a simple grep for an error message against all crash report/RIFs, let someone know there if it a common or rare occurrence.
Now I'm not sure there should be an expectation that MikroTik respond to some future automatically submit crash report. If you want a response, you should a file a ticket with context. I know Microsoft used have some complex system that provided followup on crash reports (and likely still do) but I'm not sure that necessary... baby steps be okay.
But I do sometimes come across some one-off autosupout.rif, perhaps weeks/months latter. And, in many I'd fine to "contribute" those so MikroTik have more data on issues, but may not want to file a bug report since, often the version has been upgrade since that issue and/or you're kinda on the hook to help troubleshoot if file a report.
So whether it was a semi-manual way to "share with MikroTik", or some automatic with opt-in system ("always share crash report"), it does matter to me. And it's really up to MikroTik whether they want to collect more data.
Our defconf uses watchdog email. In some cases, it spotted some kinda device issue since otherwise identical devices/config did not report a crash. So just the subject line with device name/model/version was useful (and lack/presence of more watchdog reports from other devices), was telling. Now sometime they don't get sent, since the crash may be occasioned with a lack of internet and there is no/limited retry.
I was more aiming that MT can have some internal tool for crash analytics like Apple Appstore have for .ips files or Firebase Crashlytics or Sentry with ability to mark and ignore fixed reports, etc… But that’s long shot I know, all depends how much MT wants to invest in product quality to develop such process of automatic crash report submission and analysis on their end.
