This has been explained before. Why Bugzilla interface will not work.
In support emails, 90% of bugs are not bugs, but mistakes. Imagine what will happen, if they will all be listed publicly as “bugs”.
Normis, a question:
Does “Submit this post as a bug report to MikroTik Technical Support” here in the forums work? Is sending a ticket directly to support preferable?
It works, but it is preferred that you include a supout.rif file and full description, because we only receive this one post, not whole thread.
Your e-mail-support is very good, but getting an answer takes way to long. I do not have the time to wait 1 week for each reply of the same case number. Sorry…
Tested on a few devices here on my end as well, confirmed. Added to the list, thanks!
Please remember to use the format outlined in the 2nd post if you want a bug added. Also, please remember to use newest ROS, which is 6.6.
Also, please remember, the bugs/issues in here have to be reliably reproducable.
Normis,
I respectfully disagree with the conclusion of what Bugzilla will do for MikroTik. If you’re truly getting 90% configuration mistakes then you have just identified a big problem: communication.
Us techies are here to help your brand for free and I can tell you that they are asking for the simplest of things. I wish there was a place I could send them, a link for the same questions over and over. Bugzilla, at least for me, would show them proof there is not bug.
The perception I’m getting from others about your brand is that, it is buggy. Bugzilla is not your problem. Small thinking will be the death of you guys. Think big!
RouterOS is very complex, there are huge configurations that can be made. Sometimes finding this configuration mistake takes days. There will be no “one place” to send them to, as every case is unique. RouterOS is not something like “Firefox”, where all solutions are “click here, not here”. It is very rare that two people will have same problem and same solution.
Normis,
You know more about MikroTik than I do, so I won’t argue your points. However, understand that I’m personally responsible for people purchasing seven different MikroTik products in the last months and I did not make a dime on that.
Give us something to help your brand. Make videos of the most common questions. If it was not for Greg Sowell’s outdated videos on YouTube I would be lost. The MUM videos are way too hard to hear or understand. This is not an insult but those people are not gifted teachers, they are techies.
MikroTik can do better. We are on your side. Open up some more … nothing bad will come of that.
On the issue of bugzilla, or a similar public web-interface, I am also against it. It would get bloated to death with millions of posts that are not bugs, but problems in configs, people not understanding how something works, etc. Also, you have to realize that implementing something as bugzilla into their system, MikroTik is opening more potential security holes into their systems, has another system for maintanance, etc. You have to look at it from MikroTiks point of view as well, it would be a lot of work, testing, verification and QA needed to implement it, for potentionally small benefits.
I do agree that there really should be an official bug/issue tracker, but that has been discussed on the forums forever… so lets not go into that. If/when MikroTik chooses to make one, it will happen, untill then we can only hope.
I would really like if wiki was more often updated tho. Also, in some sections, its bloated with not-needed material, while in others, it lacks details. But again, MikroTik is what it is in that regard, its the same as with ROS change-logs, people have been asking for more detailed change-logs forever now.
To pcunite:
Send those people to wiki. I often find that people just refuse to read, when most of MikroTik is actually fairly well described and documented on the wiki.
Since official “manual” content on the wiki can not be edited by users, maybe a system where edits can be offered, considered and then approved by official MikroTik staff would help. You know, wiki’s are kinda made for that.
Wiki is open for registration by request. I will gladly offer you editing rights to our Wiki. Public registration was closed because of spam, and people promoting their services. If you only wish to correct the occasional mistake in our content, you are welcome to contact us for an account
Normis,
I agree that an open public bug system is a bad idea.
HOWEVER, what I wish Mikrotik would do is have some form of public list of EXACTLY what known bugs are currently in the firmware, what kind of fixes are being applied, and what is the ETA of each one.
There needs to be a single, up-to-date reference for people to check so they may become aware of what are the known issues.
If someone sends you a support file, and you find a bug, POST IT!
If you’re working on a bug that you found, and it’s scheduled to be in update XX, POST IT!
There needs to be more clear communications from the development team regarding issues/bugs/problems/fixes/ETAs/etc.
Currently they are a mess of spread out topics on a forum, they are nearly impossible to search without wasting a lot of time.
The forum is NOT a good method for dealing with this, unless it is a locked topic that is sticky to the top of each page (And it actually gets updated on a regular basis! Every morning for example)
I agree with Voxframe. We currently post very widespread issues on the Download page in a “Note”, but this is not always the case. We will try to improve in this area. We would like to avoid scaring people from upgrading, if the known bug is specific only to some configurations, it’s one of the reasons we haven’t made such list yet.
Are you talking about actually editing the topics uder Manual? http://wiki.mikrotik.com/wiki/Manual:TOC
I have a wiki account from the days of old, and I have written a few wiki articles. However, currently on the wiki there is only editing, there is no way to offer and edit that can be discussed and then approved by you (MikroTik).
I would be happy to offer some edits and changes from my perspective. I would happily spend time going through the wiki, looking for for things that can be clarified, potential errors, etc.
But I do not want to touch the official documentation without my changes first being reviewed and approved by MikroTik staff, and afaik, that functionality is not on the wiki.
EDIT: Also thank you for joining us and actually discussing these things with us Normis.
I’m really scared to edit the wiki because I need my writings to be verified. For example my VoIP QoS article has not been verified by experts. It’s almost like we need a separate area for document writers and testers to share their experiences and get feedback from experts at MikroTik. Keep out the newbs in this area. MikroTik is not going to scare me personally away from their products because I’m made aware of bugs. I already know about your bugs! 
Here is what MikroTik needs to work hard on and get us all on board with.
I’m not an Apple fan boy (I use Android) but they control the software and the hardware and that makes for a great experience. MikroTik needs to control the platform for the education and support of their users. By platform I mean a great website where I can help others, where MikroTik helps me. Why is VoIP optimization sold by a third party individual for $200 when MikroTik knows how to do this better than anyone? I can make money and so can MikroTik if we open up the communication better.
You have true. If bugzila not suitable, suggest a way to inform the (forum) Mikrotik users.
For example: Official topic on forum → you want to edit it as needed.
For example, in the current version 6.6 is a bug when using the VLAN on Bridge. But how does it know? Read Topic 6.6 and browse and search all sides who reported what …
Issue:
DHCP Not work with intel i350-t4
Versions affected:
6.6->6.2,5.26 ok
How to reproduce:
Enable dhcp server on any of 4 eth ports of card,add lease for test pc or config dynamic pool and try to receive ip.
Issue:
DNS cache does not update for static DNS name change
Description:
DNS cache will add new record instead of update when you change a static DNS name.
Versions affected:
6.6
How to reproduce:
Add a static DNS record with name “test.local” and address “192.168.8.1”, then change name to “test1.local”. You will see a new record “test1.local” added to cache, and “test.local” is still there.
Notes:
I can’t find any way to delete “test.local” in DNS cache, except router reboot.
Support TicketID:
None, not report to MikroTik Technical Support
Verified and added to the list.
PLEASE submit this to support@mikrotik.com and update your post with a support ticket ID.
Just copy your post from here to the email, it should be enough.
I checked this several times, and can’t get it to repeat. Please submit to support with detailed steps how to repeat.
Here is a ticket with exact steps: Ticket#2013112266000451
Any more info on all the discussion about the wiki? I think that was actually a fairly fruitful and useful debate