It’s not unpinned at all (now at 2023-08-07 22:11 CEST, tomorrow if is unpinned, is another thing), and if you haven’t noticed it’s not my fault. https://forum.mikrotik.com/viewforum.php?f=1
Oh, I do apologise, it has NOT been unpinned. So, yeah, it really should be, like I suggested originally 8)
Look, this is silly to argue over. You expected that people had spent a lot more time on the forum than you have. We come here, see 'Report problems here, not via email', and then report problems here. We didn't know it was wrong, we were just following instructions that we thought were current!
Edit: Because I thought 'maybe I am crazy', I had a look on the wayback machine, and it did specifically say 'don't report v7 bugs to support, report them here'
Please review the following SUP tickets.
These issues persist in 7.11beta/rc and 7.10.x without resolution.
All of them are related to DNS problems.
SUP-121758 The functionality of matching regular expressions and subdomains in dns-to-address-list is not working properly
SUP-121988 Regarding the issue of adding comments to dns-to-address-list
SUP-123531 The rules of DNS static are not executed in sequential order
Well, I HATE that and I refuse to use it!
The only thing making your “private” upload private is some flag on the item in the database, and you have no insight at all in who is able to read it.
At any time they may assign outside moderators (like is happening here) which suddenly have access to your private files, and/or the forum software may be hacked and anyone may be able to download your private files.
Of course that issue more or less exists with Jira as well, but at least there we may hope/expect that they never willfully give insider access to volunteers outside the company.
Still I would prefer when stuff like uploaded supout files would get removed on closing a ticket.
My point is less about the means or methods, and more about the idea that the issues and feedback are exposed to both internal and external eyes in one place, in an attempt to eliminate duplicate posts and consolidate discussion about the issue(s). Certainly a more secure method of file transfer could be employed for transferring support files.
MikroTik forum is for the community. It is user-to-user discussion. No bugs should be reported here, no private files should be uploaded here. Unlike some others, we have actual support with an actual ticketing system. help.mikrotik.com/servicedesk/servicedesk/
There is someting like I think I found a bug and like to know if any others have the same expierence on that.
Sometimes I was just “holding it wrong” and got info to solve my “bug”. The forum is a good filter for bugs, before escalating to actual reporting it as a confirmed bug to Mikrotik.
Then it always good to report back in the forum that the confirmed bug is reported to Mikrotik to avoid multiple reporting of the same bugs by many.
I see sometimes Mikrotik reporting in the forum that a bug is confirmed an is worked on.
So the forum has a function in the bug eco-system, however don’t expect Mikrotik to scan constantly the forum to find reports on potential bugs. There are exceptions that Mikrotik picks up on a discussion and investigate.
Testing and RC treads have close attention of Mikrotik but the problem is that an itteration closes the previous tread an throws it out of focus. While there was a discussion, which so is killed off.
Now we have only a reference in the closing post link to the new tread. It would be nice that the opening post would also refer to the previous tread.
Yes, if you are not sure if it’s a bug and want somebody to do a sanity check - sure, forum is a good place. But please do not expect that MikroTik staff is monitoring all threads for possible bug reports. If you are sure it’s a bug - report directly in our support system
Normis… I have several tickets opened about pppoe crahes and bgp instability or bgp late advertisment over time.
your guys reply in months and no solution or at least analisys on all of them.
These are the tickets:
support #[SUP-123606]: CCR2216 - BGP flap session lead to router crash/reboot
support #[SUP-124445]: bgp goes in stange behavior (x86) after some seession flap
support #[SUP-120995]: BGP prefix Count broken after some days
support #[SUP-110510]: bgp ipv6 causes memory leaks and cpu consumption in 7.7 and 7.8 - ccr2216
support #[SUP-119592]: pppoe servers slow to boot and some of them are invalid
support #[SUP-115401]: ccr2216 and qsfp28 issues still persists on 7.9
support #[SUP-108462]: dst limit rule doesn’t catch anything when rate is > then 10K p/s
support #[SUP-97493]: pppoe v7 issue
I would not expect them to read all threads, but it would not be unreasonable to expect them monitoring the Announcements / x is released! and Feature requests (the one you started yourself) threads.
There are also a couple of “We at MikroTik consider to develop x” threads that lead off into a lot of discussion and suggestions, but no outcome.
Are you saying we should instead put that all in the support system for it to be monitored?
rpingar, not all issues can be reproduced easily, if you have a large and complex network, issue can be caused by many things. To fix something, we need to reliably repeat the problem. And not all issues can be fixed easily. I checked your tickets, there are long discussions with support. So you can’t say there is no response.
Hello,
I have 4 DAC-SFP+ in my Mikrotik switch which are shown with a temperature of 255C. I can set the value to disable them to 256, so they are working perfectly fine. But the fans of the whole switch are running in maximum speed. The switch is in my living room, so it is really anoying.
Obviosly 255C is an error, maybe -1 in an unsigned 2^8 integer. Please don’t use this value for system fans or give me the opportunity to ignore the value each module one by one.
The error occured with 7.10 and unfortunately wasn’t fixed in 7.11rc yet.
I don’t understand what I would need to check and what you are trying to solve.
This shows how important it is to always quote the (part of) the article you are replying to.