Hey guys,

First, a few disclaimers:
1) This is not an official list, and is not in any way affiliated with MikroTik
2) Only bugs that are still present in current versions of Winbox and RouterOS will be kept here.
3) This is a user forum, and MikroTik is not required to view/acknowledge anything that is written in here.
4) If you report a bug here, please also report it to support@mikrotik.com
5) This is not a "doesnt work for me" list, but a list of reproducable issues/bugs.
6) Please do not request new features in this topic.

How to get a bug/issue added to the list:
See this post for instructions and a template:
http://forum.mikrotik.com/viewtopic.php ... 86#p411886


Here is the current list:
1) Ctrl+C does not work on read-only fields
- http://forum.mikrotik.com/viewtopic.php ... 70#p411887
2) You can not deselect a selection in a field with the right arrow key
- http://forum.mikrotik.com/viewtopic.php ... 88#p411888
3) Menus in winbox can get stuck - mouse stuck in button-down position
- http://forum.mikrotik.com/viewtopic.php ... 89#p411889


This list is current for Winbox v2.2.18 and RouterOS v6.10 release.

If you have anything to contribute, please do!

How to get an issue added to the list:
1) Post in a separate post
2) Post the exact symptoms, and exact steps required to reproduce and test the issue
3) Make sure you are testing with the newest versions of Winbox and RouterOS
4) Please post the ticket number from Mikrotik Support under which the bug is submitted.
5) If support has acknowledged the bug, you can update your post with details / info if it will be fixed.

Here is a template you can use to structure you bug report posts:

----- ----- -----
Issue:
[Insert a short name/description for the issue here]

Description:
[Insert a more detailed description of what is wrong here]

Expected functionality:
[Tell us how the functionality should behave normally]

How to reproduce:
[Provide step-by-step instructions on how to reliably reproduce the issue]

OS used:
[Your OS brand, version and flavor - example "Win 7 64bit"]

Notes:
[Provide any notes or additions you would like]

Support TicketID:
[Ticket ID from support@mikrotik.com]
----- ----- -----

Issue:
Ctrl+C does not work on read-only fields

Description:
You can not copy with Ctrl+C from read-only fields, but read-write fields work
You can copy from a read-only field by highlighting it -> right click -> click copy

Expected functionality:
When you highligh a read-only field, Ctrl+C should copy its contents

How to reproduce:
Highlight any read-only field value in Winbox
Press Ctrl+C - the content will not be copied

OS used:
Win 7 64bit

Notes:
This being fixed would save me a lot of clicking
It breaks work-flow when you have to copy differently from read-only fields then from read-write fields

Support TicketID:
[Ticket#2014022766000618]

Issue:
You can not deselect a selection in a field with the right arrow key

Description:
When you highligh a selection in a field with double-click, you can not deselect and move to the end of the string by pressing the right arrow key.
So when you want to add text to the field, you have to click it again to deselect, or left arrow key and right arrow key again to get to the end

Expected functionality:
When a string in a read-write field is highlighted and the cursor is at the end, pressing the right arrow key should still deselect the string

How to reproduce:
Double-click on any read-write field to select its contents
Press the right arrow key, the string is not deselected

OS used:
Win 7 64bit

Notes:
Hitting the "End" key on the keyboard actually properly deselects
It works like this (deselecting with the right arrow key) in every other software I ever used
It breaks workflow when you want to add text to the end of a string and this doesnt work

Support TicketID:
[Ticket#2014022766000636]

Issue:
Menus in winbox can get stuck - mouse stuck in button-down position

Description:
Under certain circumstances, you can get buttons in winbox to be stuck in a mouse-down position, even if the mouse button was released.
See the "How to reproduce" section on details

Expected functionality:
It should not happen.

How to reproduce:
Press the mouse button on the "IP" menu in the main left-side winbox toolbar - do not release the mouse button
Alt-Tab to a different software
Go back into winbox and try to click on any sub-menu in the IP menu, it will not work
When you mouse-over other menus in winbox, they will scroll-out automatically, since the mouse it stuck in a button-down mode

OS used:
Win 7 64bit

Notes:
I personally run into this issue A LOT
You can fix it by clicking on any non scroll-out menu item in the main left-side toolbar
It really break work-flow when I try to click on something, and then have to figure out - "Oh, its the mouse-stuck issue again"

Support TicketID:
[Ticket#2014022766000645]

This seems like a winbox bug, but I can't say for sure.

Issue:
When adding a new Access List item comment before adding the item, all associated clients reconnect.

Description:
Adding a comment to a new wireless Access List item before OK-ing the new entry causes all associated wireless clients to reconnect and all statistics are reset. If you add the item first and click Apply or OK, and then add a comment, this does not happen.

Expected functionality:
All wireless clients should not reconnect when adding a comment.

How to reproduce:
In winbox, open Wireless, Access List tab. Click + to add a new entry. Click the Comment button, type something and click OK. All associated clients reconnect.

OS used:
Windows 7 64bit

Support TicketID:
[Ticket#2014022766000994]


[ FINAL UPDATE ]
Official word from support is that "this is not a bug - it is how wireless access-list/connect-list is working. The wireless interface needs to be reloaded with the new entries as some of the entries could effect the already connected users."

Issue:
When adding a new Access List item comment before adding the item, all associated clients reconnect.

Completly normal functionality, when you add an Access-list rule, all clients get disconnected always.

So when adding a comment to a non-existent item, the item is first created (and all clients are dropped like normal), and then a comment is added.

I agree its a bit strange functionality, but works as expected when you look into it closer.

Issue:
When adding a new Access List item comment before adding the item, all associated clients reconnect.

Completly normal functionality, when you add an Access-list rule, all clients get disconnected always.

So when adding a comment to a non-existent item, the item is first created (and all clients are dropped like normal), and then a comment is added.

I agree its a bit strange functionality, but works as expected when you look into it closer.

I don't understand why adding an Access List item causing all wireless clients to disconnect would be normal functionality. It resets all statistics for these clients and causes a blip in service. Can you further explain how you see this as normal?

Completly normal functionality, when you add an Access-list rule, all clients get disconnected always.

All clients do not get disconnected always. The first two methods below do not disconnect any associated clients.

All existing associated wireless clients stay associated

• Click + to add a new Access List item. Change MAC, etc, click OK. Then add a comment, click OK.
• Click + to add a new Access List item. Click Apply to add the item. Then add a comment, and click OK.

All associated wireless clients are disconnected and reconnect

• Click + to add a new Access List item. Click the Comment button, type something and click OK. Click OK to add the All associated clients reconnect.

As I see it, the easiest, most straight-forward way to add a new Access List item is to click +, edit the MAC, and click OK. Using these steps does NOT cause any other wireless clients to disconnect. Therefore, I come to the conclusion that this is the normal functionality. Therefore, adding an item in such a way that causes ALL associated clients to disconnect would not be normal.