What's new in v3.35:

*) fixed F4 and F7 keys in Terminal;
*) fixed automatic reconnect issues for RoMON;
*) fixed crash when connecting in new window (introduced in v3.33);
*) show correct data rate for file upload/download;

If you experience version related issues, then please report them to support@mikrotik.com.

Both Winbox 32-bit and 64-bit versions are available here:
https://www.mikrotik.com/download

Seems to be working fine with an option "Open in new window" and RB4011iGS+, ROS version 6.49.2, Windows 10 x64, Winbox x64.

Unfortunately this bug introduced in 3.32 was not fixed:

Before, the QuickSet page on a wireless link (e.g. LHG) showed the signal strength over time graph when the link is up.
This no longer works.

*) fixed F4 and F7 keys in Terminal;

Key F4 now doesn't close terminal window. The same as Esc key. Bug or feature? I'm already used to closing the terminal with F4 :)
Where can i read about all winbox hotkeys? Give a link to some manual, please.

*) show correct data rate for file upload/download;

Now it writes speed at Megabits, but not MegaBytes like before, right?


Thanks.

still cloud backup file date is not timezoned correct.

What's new in v3.35:
...
*) fixed crash when connecting in new window (introduced in v3.33);
...

Thank you, but it still doesn't work properly. When connecting in a new window, Winbox takes about 20 seconds to spawn the new window. Before 3.33 everything worked properly instantly.

Thank you, but it still doesn't work properly. When connecting in a new window, Winbox takes about 20 seconds to spawn the new window. Before 3.33 everything worked properly instantly.

Works fine for me...

@ pe1chl did you notice anything as far as the order of rules is concerned ?

I am not doing this operation all the time. I only reported it because I noticed that it happened, and I had never seen this same thing happen before.

Clean cache and delete session files, if still experiencing issues with connecting to the device, write to support@mikrotik.com, we would like to get access and check.

Quickset graphs bug is not yet fixed, also the cloud backup time.

Clean cache and delete session files, if still experiencing issues with connecting to the device, write to support@mikrotik.com, we would like to get access and check.

You should understand that session files are a valuable asset that (advanced) users do not want to delete for nothing.
How about saving session files in an editable format like JSON, so problematic items can be identified and deleted without losing the entire session file?
Or releasing a session file editor that can do the same.
It appears that winbox is too sensitive to the content of session files (that it creates itself!)... it is not the first time that issues occur that appear related to session file contents.
(in the past I have worked with MikroTik on a winbox issue that could only be found after I mailed the session file to support)

@pe1chl
+1 to every word you said.
I am not using WinBox that often and only as a private user. But telling a professional using winbox all day to delete session files is like the last thing anyone would like to do. It is a proprietary, apparently binary config file format. This is so strange to see something like this these days. So when not using something readable (ini,json,xml,...) then MT should at least make sure, that upgrades do not - in any single like never ever - lead to unresolvable issues with this session configs. If you (MT) can't guarantee (for whatever stable-is-never-stable excuse) or can't resolve that programmatcially (Winbox), then switch over to some readable config file - so people can identify problematic configs and can clean up.

Clean cache and delete session files, if still experiencing issues with connecting to the device, write to support@mikrotik.com, we would like to get access and check.

This is the same as telling Windows users to do a complete reinstall of the OS just because they cannot change backgroud picture.

Anyway, I have created a new WINE prefix and started WinBox in it, so there is no cache and no old session file, and the result is the same, that is: Winbox downloads DLL's from router, then disappears, then appears 20 seconds later with message "Disconnecte, reconnecting in 5, 4, 3, 2, 1", and then at last it connects. This all only happens when "Open in new window" is checked.

BTW: +1 for readable/editable session files (XML/json/txt)

Edit: it does not disappear, but there is no new window for ~20 seconds

WInbox is not saving where you are when viewing filter rules. I view "forward" chain rules, I exit, when I open winbox and return, it shows me ""all" filter rules.
Only with 7.x.does this happen. Winbox works fine with 6.49 viewing filter rules.

This is the same as telling Windows users to do a complete reinstall of the OS just because they cannot change backgroud picture.

"Do a netinstall" if you encounter any issue with ROS is a common first suggestion.

This is the same as telling Windows users to do a complete reinstall of the OS just because they cannot change backgroud picture.

"Do a netinstall" if you encounter any issue with ROS is a common first suggestion.

Yes, but you first save config (export as text preferably). And, of course, you have backups, right? But to delete session files with hundreds of different saved Winbox layouts? No thanks.
And Yes, I know I can backup those too, and restore them when I see that deleting didn't help :)
And No, I never had to netinstall a working router, only ones that wouldn't boot.

After encountering the problem "winbox hangs when pasting into a field" (introduced in previous version) 3 times today, I went back to version 3.32 and it did not occur again.
So now this will likely become my stable version until the flurry of new releases introducing new bugs again has ended...

@pe1chl i tried to reproduce this issue with no success...
Can you give an example of winbox hanging after a copy/paste ?

Where is a CIDR addressation yellow HINT ?
I clear cashe etc. but still I cannot see in WinBox this hint who show a resolved CIDR RANGE ?! This should exist in IP Address & IP Route & Firewall rules !

This is the same as telling Windows users to do a complete reinstall of the OS just because they cannot change backgroud picture.

Have you ever tried "professional" computer services from Dell/Lenovo/HP etc.? The very first question is "have you reinstalled system?"
And if you send the computer to them there is "reinstall everything from scratch procedure" applied to your device. No matter what is the real problem.

@pe1chl i tried to reproduce this issue with no success...
Can you give an example of winbox hanging after a copy/paste ?

Today it was when pasting an IPv6 address into an added IPv6 address list item.
In 3.34 it was when pasting a network into a Routing->BGP->Networks item (see 3.33/3.34 release topic).
In 3.32 I have never seen this problem...

@SiB, honestly i did not know that if you let the mouse on the CIDR then a hint appears showing the addresses available...
Since when does this exist ?

@SiB, honestly i did not know that if you let the mouse on the CIDR then a hint appears showing the addresses available...

I discover it's still work, just my Win10 stop show a hint...

Since when does this exist ?

From long long time. This is extreme useful when I many times work with CIDR like /17 /19 /28 /29 /30 and this should work in firewall what will be best feature for me next to auto-connect :).
Special for you a one of my oldest MikroTik-s:

Indeed, i can see the hint too...

Unfortunately this bug introduced in 3.32 was not fixed:

Before, the QuickSet page on a wireless link (e.g. LHG) showed the signal strength over time graph when the link is up.
This no longer works.

Which graph do you mean? I have two devices connected to an AP using station-brige mode. On both I see the signal-graph on Quick Set.

Yes that is the graph that I mean but as you can see in your screenshot it is completely wrong.
It looks like the scaling factor that is applied to make the graph fit the size on the screen has gone haywire.

It should look like this (v 3.31):

Indeed.

I even have these random very off signal strength label:
And another thing: why does Winbox not offer wifi frequency above 2452? I have configured 2462 via CLI. Once I open wireless-settings in winbox or Quick Set, it shows "frequency" in blue-color (which means CHANGED". If I would hit the OK-button, I would change the frequency to "auto". That is one of the reasons, why I do not trust Winbox anyways.

That is probably a local regulations thing. Also, depending on the channel width and layout the channel can extend either further up or further down than what you configure, and this affects the allowed channels.

You are right!

When I select:

* Channel Width: 20/40MHz eC: I see 2462
* Channel Width: 20/40MHz Ce: missing
* Channel Width: 20/40MHz XX: missing

I agree, that when using "Ce" - it should clearly not show 2462. As there is no remaining channels "right side". But using "XX", where the device itself decides channel alignment - why should I am be limited beforehand? Or is the explanation like: "If selecting XX and choosing a channel like 2462, you can only end up using eC - as Ce would not possible anyway"?

Apparently when specifying an XX channel you tell it what the lower channel (frequency) is, and then it still can choose Ce or eC depending on channel occupancy.
So you select 2452 and it will use 2452 and 2462, either in Ce or eC layout.
When it chooses eC, it would be the same as when you select eC manually with frequency 2462.

Pun1sh3r - Yes, now there are Megabits, not bytes. IF4 should enable/disable safe mode.
freemannnn - This will be fixed more in the next release of RouterOS, not WinBox.
tomaskir - Opens up for me right away. Have you tried the same on a different computer just for testing purposes?
pe1chl - My colleague did want to ask that you test without using any sessions. You can simply choose "<none>" under sessions menu in the WinBox loader and re-check if that makes any difference. If the session file triggers the problem, then send it to support@mikrotik.com. I am not referring to a particular issue, but to any issue that is triggered by the session file.
rgraham - We will look into this.
infabo - First suggestion in user forum maybe. If you write to support@mikrotik.com then Netinstall is advised only if there is a reason to believe that it might help.
pe1chl - Can you provide an example of what exactly and where did you try to paste? Does it happen each and every time with the same string that you copy and the same input field?

Pun1sh3r: press F1 twice to display key bindings:


And since Winbox is a MDI application, you can use CTRL-F4 to terminate session regardless of whether the prompt is empty or not.

pe1chl - My colleague did want to ask that you test without using any sessions. You can simply choose "<none>" under sessions menu in the WinBox loader and re-check if that makes any difference. If the session file triggers the problem, then send it to support@mikrotik.com. I am not referring to a particular issue, but to any issue that is triggered by the session file.

Ok but you should understand that this was about a mishap that happened during an edit of the route filters, which did not happen again when I repeated the operation, and that I am not prepared to just play around with the filters in our production environment just to see it happen again and maybe lock me out or upset the whole network.
When I report things like this I hope that the responsible programmer reads it and thinks "hey, the user apparently moved lines and saw that Ok on screen but the move did not happen in the underlying system, what could be the cause of that?" and with his understanding on how it actually works (which I don't have full knowledge of) can zoom in to an area where this problem could be caused by a recent change.
"just try if you can reproduce it with an empty session file" does not help a lot in this, especially as when my reply is "no, it is not reproducible" the next advise would probably be to start with a fresh session file. I already expressed my worries about the influence of session files on the behavior of winbox. In my understanding, session files hold window sizes/positions and column sizes/positions, but in practice they appear to influence the visibility of very subtle bugs. That is why I suggest making session files readable and editable, so I could for example decide to remove the section describing the route filter window and keep all other info.

pe1chl - Can you provide an example of what exactly and where did you try to paste? Does it happen each and every time with the same string that you copy and the same input field?

I already provided that in the winbox 3.33/3.34 topic...:

Doing some more work in winbox 3.34 I found that it has a tendency to hang when I paste copied text into a field. I never noticed that in 3.32 so I guess it is a new problem.
E.g. I go to IP->Addresses, copy one address/mask item, then go to Routing->BGP->Networks (this is on a router running v6), add a network and paste that copied value into the network field (of course with the intention to fix it up to become a network address rather than the router address).
At that point winbox became completely unresponsive and I had to forcibly close it.
That happend to me several times in other places as well, but I think every time it was when pasting something that by itself would not be allowable there but would have to be fixed up.

After that I had the same issue when pasting IPv6 addresses into a newly created address list item.

When Torch windows is started don't show anything, is necessary press stop for that show information, I saw this since version 3.34, I'm using windows 64 bits version

When Torch windows is started don't show anything

When Torch is started it always opens with the same (not so useful) defaults, and starts running.
Then you need to change the settings, stop it and start it again, to see your data.
Unfortunately these settings are not saved (never have been...) and so you need to repeat this every time you use Torch.
The only thing that now changed is that this initial "running" state is now reflected by the Start/Stop buttons.

When Torch windows is started don't show anything

When Torch is started it always opens with the same (not so useful) defaults, and starts running.
Then you need to change the settings, stop it and start it again, to see your data.
Unfortunately these settings are not saved (never have been...) and so you need to repeat this every time you use Torch.
The only thing that now changed is that this initial "running" state is now reflected by the Start/Stop buttons.

I agree with this..I also think that Torch is so important that it’s location in the tools menu of WinBox should be moved to the top of the menu making it simpler to open. 😎

When you open interface, you have direct button "Torch"
If I open a Tools > Torch then default is stop, I can change parameters if want and press Start.
For me WinBox works as always.

When you open interface, you have direct button "Torch"
If I open a Tools > Torch then default is stop, I can change parameters if want and press Start.
For me WinBox works as always.

Yes, I know..Still doesn't change my request though.. 😎

I notice /ip/route/print uses a new "m" flag, based on modem=yes in route properties. But in winbox, it doesn't seem to know about the new "modem" flag.



Took a minute to figure out, but I *think* it's based on "Use Default Gateway" in an LTE APN Profile... Since LTE interface/profile doesn't, generally/seemingly, use /ip/dhcp-client to insert a default route for LTE (e.g. that be "d" for dhcp=yes on the route properties), it kinda make sense it have it's own flag m for "modem". Just missing in winbox.

Not a big deal, but debugging of recursive routes does make one sensitive to even slightly askew results ;).

Pun1sh3r - Yes, now there are Megabits, not bytes. IF4 should enable/disable safe mode.

Hi, at first hitting F4 closes all windows except terminal sesion, and it is really annoying for me. I have used to closed terminal by F4 key and I really miss this feature. I think I am not alone. Can you revert this update? For enable/disable safe mode always used ctrl-X shortcut.

Maybe this is a Mac/wine thing...

I often get "multiple selection" behavior when there is only one choice. Specifically, in Winbox's login screen's neighbors. Multiple routers can be selected, even with using just "a single click". It does seem to use the last one selected, but the previously selected one are still highlighted. Curious if it's just my setup or this is generic problem.

ArchGabriel write:

Hi, at first hitting F4 closes all windows except terminal sesion, and it is really annoying for me.

Easy, I always use ESC key to close all winbox windows and CTRL+D for close any Terminal windows. I not see any new needs in this.

ArchGabriel write:

Hi, at first hitting F4 closes all windows except terminal sesion, and it is really annoying for me.

Easy, I always use ESC key to close all winbox windows and CTRL+D for close any Terminal windows. I not see any new needs in this.

For me is the step back:(

Maybe this is a Mac/wine thing...

I often get "multiple selection" behavior when there is only one choice. Specifically, in Winbox's login screen's neighbors. Multiple routers can be selected, even with using just "a single click". It does seem to use the last one selected, but the previously selected one are still highlighted. Curious if it's just my setup or this is generic problem.

Same here, from time to time, with winbox-mac : https://github.com/nrlquaker/winbox-mac
A colleague also suffered from this bug on Windows !

Very dangerous, as you may disable / delete configuration items by mistake...

Maybe this is a Mac/wine thing...

I often get "multiple selection" behavior when there is only one choice. [...] Curious if it's just my setup or this is generic problem.

Same here, from time to time, with winbox-mac : https://github.com/nrlquaker/winbox-mac
A colleague also suffered from this bug on Windows !
[...]

Yup, happens in a few places. But also same winbox-mac... The multi select issue seem like it might be generic bug...but was hoping for 1st hand Window users to confirm ;-).

winbox-mac uses wine6, but Mikrotik has a pretty specific setup for Mac+wine7. The "official" instruction include some have some font fixes, and other specific settings for wine7, maybe related. I'm otherwise happy with winbox-mac package, since Cmd-Space/spotlight search just works with winbox-mac. (Now the fonts relatively small, so Mikrotik's tweaks might fix that but might also do something to make multi select work...)

I have a 4K screen on my laptop and Winbox is too small to be seen or read on my 4K screen.

Short of changing the screen settings on my laptop, how can I make wWinbox more easy to view?

Ctrl =

ctrl+- is for zoom out and ctrl+= is for zoom in

The "Open In New Window" bug is not fixed in v3.35 for me on Linux (Ubuntu 20.04.4 LTS + Wine).
Winbox does nothing on connecting, after ~30s a new Window spawns, times out and automatically reconnects.

This is really annoying considering it worked prior v3.33(?)?

Is there any way to fix this?

Connecting without ticking the box connects immediately.

The "Open In New Window" bug is not fixed in v3.35 for me on Linux (Ubuntu 20.04.4 LTS + Wine).

It works fine for me in Debian Buster, which should be comparable.

Hi MT Devs
i don't know if this is right place, but, .. lets try

few years ago, when VLAN filtering is introduced, Bridge, port, PVID field become essential.
but ... it is always hidden in new Winbox session
and yes, it IS annoying to every time right click, show columns, select PVID ...
and when you in hurry, and PVID is hidden, it is great chance to left it out of config and then scratch your head, why something is not working
so, hope it is a Winbox matter
please, please make Port / PVID visible by default, please

please, please make Port / PVID visible by default, please

I agree. In fact I think this field should go and be auto-filled by the selection "untagged ports" in the VLANs tab. It is ridiculous that a port can be untagged for a VLAN and the input from that port is not auto-marked with that same VLAN tag.
Maybe for people who really want ridiculous configuration there could be a checkmark "manual PVID configuration" below Bridge->VLAN->VLAN filtering which you have to set when you want strange asymmetric VLANs.

When I try to move the "#" column (rule order) in the Firewall window (Filter or NAT) to another place on the right, I get the following error:

At some point in winbox versions, the route table selector column in IP>Routes went missing in the default session. Is this by design?

With multiple routing tables, the IP>Routes view is extremely confusing without always applying a filter.

@Amm0: It's not WinBox, it's RouterOS, in v6 it's there, but it's missing in v7.

When I try to move the "#" column (rule order) in the Firewall window (Filter or NAT) to another place on the right, I get the following error:

I confirm that because I have reproduced exactly the same issue,
and ca I add this:
moving, on ANY menu, any moveable "#" columns or any "blank" colums (for status letters) give that error
Both winbox 32 or 64, same line, same error
Tested on 6.48.6 mipsbe, arm and tile
Tested on 6.47.10 on mipsbe

At some point in winbox versions, the route table selector column in IP>Routes went missing in the default session. Is this by design?

With multiple routing tables, the IP>Routes view is extremely confusing without always applying a filter.

You can still select the Routing Table column but it does not appear by default.

@pe1chl: This thing, v7 doesn't have it:

That is not the correct menu to pull down. Click the arrow one row lower and then click "show columns" and enable the checkmark alog "Routing Table".

It's possible that I misunderstood and @Amm0 is really after the column. I think it should be shown by default, but if not, it's just few clicks to get it back. The dropdown (as quick filter) being gone in v7 is more annoying. There's still regular filter with other parameters, but it takes ages to select routing table there.

Well, the Routing Table column is not shown by default, and I guessed that he saw all those routes without indication to which table they belong, and only knew how to see the correct ones using filters.
When the Routing Table column is shown, you can sort on it.

The "Open In New Window" bug is not fixed in v3.35 for me on Linux (Ubuntu 20.04.4 LTS + Wine).

It works fine for me in Debian Buster, which should be comparable.

Thanks for the reply. Sadly I can replicate this issue on said PC (Ubuntu 20.04.4) and my laptop (Fedora 36). Something seems to still be off about this build.

The "Open In New Window" bug is not fixed in v3.35 for me on Linux (Ubuntu 20.04.4 LTS + Wine).
Winbox does nothing on connecting, after ~30s a new Window spawns, times out and automatically reconnects.

This is really annoying considering it worked prior v3.33(?)?

Is there any way to fix this?

Connecting without ticking the box connects immediately.

Can confirm. Arch Linux wine 7.4

Tested in Debian Bullseye (the most recent version). Works OK.

Can confirm. Arch Linux wine 7.4

Did you really test version 3.35? Note that winbox from AUR is still at 3.34...

Log output is probably broken for some types of action - this (no message about action, just the "by username") happens when I delete a static route:

That is not a winbox issue, it is a RouterOS v7 issue.

Maybe this is a Mac/wine thing...

I often get "multiple selection" behavior when there is only one choice. Specifically, in Winbox's login screen's neighbors. Multiple routers can be selected, even with using just "a single click". It does seem to use the last one selected, but the previously selected one are still highlighted. Curious if it's just my setup or this is generic problem.

Same here, from time to time, with winbox-mac : https://github.com/nrlquaker/winbox-mac
A colleague also suffered from this bug on Windows !

Very dangerous, as you may disable / delete configuration items by mistake...

Wow, I'm not alone! It's like pressing Ctrl in Windows and clicking for multiple choices. Well, I solve this by pressing Control, Option, Command in a row - don't remember exactly which one helps, but problem goes away for this run of WinBox.

That is likely an issue with Wine or your OS, not with winbox. It is a "commonly known" problem that modifier keys sometimes get stuck on such environments, also in programs like VNC.
When you see unexpected behavior, indeed it can often be fixed by pressing all of the keys one by one so they get reset to the "off" state.

Mmmmh, a colleague told me he also suffered from this on Windows, when I showed him the bug on macOS.
Not sure then it is strictly Wine related.

It would mean that winbox reads the keyboard in a very unusual way. I don't expect that they do that, it is not required for the functionality.
Normally the OS keeps a state of each modifier key (PC keyboards send a code when a key is pressed and another code when it is released).
The application normally uses that kept state.
Exceptions are applications like VNC that try to emulate this press/release coding towards the OS at the other end.

Note that on Windows, my colleague suffered from this with old WinBox versions, and did not have "the chance" to trigger it with last versions.
Can't remember to have reproduced it with WinBox 3.35 on macOS yet, but as per my understanding, @Amm0 did, as well as @Chupaka.

I have never seen it in wine under Linux (Debian)... no matter what WinBox version. And I have experienced quite my share of winbox bugs.

Can confirm. Arch Linux wine 7.4

Did you really test version 3.35? Note that winbox from AUR is still at 3.34...

yes, 3.35. Winbox self-update works fine.

It's possible that I misunderstood and @Amm0 is really after the column. I think it should be shown by default, but if not, it's just few clicks to get it back. The dropdown (as quick filter) being gone in v7 is more annoying. There's still regular filter with other parameters, but it takes ages to select routing table there.

Well it's the selector too! Should have been clearer. But either one – default route table column, or the selector with the route table - ideally both? Yes, somewhat solvable by "Select Columns" and/or saved sessions – it's the "extra clicks" it takes. I've saved a session with a filter active set to search for "main", to "solve" my issue. But now I'm always loading a session file when before it just used what I'd left before on that device.

I just think it's usability issue. While I know I'm using route tables, since I configure them... it be awfully confusing to someone else looking at the IP>Routes, without any obvious clue why there be multiple "overlapping"/duplicate/different routes appearing. Basically you'd kinda expect route list view to be linear top down, by default. With various route tables in use, which are kinda need for dual+ WANs, it really does always look "wrong".

I have never seen it in wine under Linux (Debian)... no matter what WinBox version. And I have experienced quite my share of winbox bugs.

The multiple select is a relatively new thing. BUT now that I think about @pe1chl...seemingly around when the Mac's "Command-C" for "copy" started to work... [Mac Command key = Windows key]

So I'm actually think this issue is I use the nlquaker brew package – which is just one "brew" command to get wine+winbox, so it's handy... But it uses Wine 6 internally.

Since Mikrotik now has documented support for wine, with specific steps for Wine 7... I'm going to give those a shot since yeah this "multiple select" thing is pretty common. Maybe be case of FTFM – but there was no manual for wine when I started using it ;).

@Amm0: I don't think that with the routing table it's fully intentional, it's just that they were changing stuff in there. First they had this bad idea to drop separate routing-mark parameter that v6 had and replaced it with gateway=<gateway>^<routing table> syntax. Fortunately, later they added routing-table parameter, but it was missing from WinBox for a while. So current state is probably result of that, and they'll probably fix it and polish it later.

@Amm0: I don't think that with the routing table it's fully intentional, it's just that they were changing stuff in there. First they had this bad idea to drop separate routing-mark parameter that v6 had and replaced it with gateway=<gateway>^<routing table> syntax. Fortunately, later they added routing-table parameter, but it was missing from WinBox for a while. So current state is probably result of that, and they'll probably fix it and polish it later.

Fair point, I tried to forget the g@tew%y syntax. But likely right the side-effect is they didn't add the routing-table UI back...

Been adapting from "check-gateway"+"dynamic-in filters" in V6 to unwinding recursive routing & DHCP client scripts in V7 – so been in IP>Routes more as a result ;)

Sob write:

polish..

and I here :).
#Joke.

back to discution. I hope that we can remove not used Route Tables entry bcs some my customers have few wan1, isp1, isp1_orange etc... bcs some few consultant's help them :)

@SiB: So you're not like a magic lamp genie who comes and grants wishes? You come and have wishes. ;) It looks like yours was already granted, unused routing tables can be removed (/routing/table in CLI, Routing->Tables in WinBox).

If nothing is selected, why CTRL+C clean the clipboard?...
CTRL+C used for stop the script or instruction...

Bug
Using bridge filters with IP protocol, a port based protocol is needed for src and dst port settings to be enabled/selectable but once such IP protocol has been selected you can disable the protocol selection again and src/dst port settings stay active. It is a minor cosmetic bug since you can't click OK, it will complain about for ports to be specified the protocol needed to be TCP or UDP.

There's OT in 7.2 thread about clipboard shortcuts, and I don't want to continue it there, but I'm interested in this:

As an alternative, you can use CTRL+INS / SHIFT+INS for copy/pasting in Winbox terminal.

That's what I'd very much like to use (mainly because I use it everywhere else), but only Shift+Ins (paste) works here, no luck with Ctrl+Ins (copy), it doesn't do anything. WinBox 3.35 (both 32 and 64 bit, not that it should make any difference) on Windows 10. Since @raimondsp is from MikroTik, I take it that it's supposed to work. Can anyone else confirm if it works? It's fine in other parts of WinBox, but not in Terminal.

Sob write:

Can anyone else confirm if it works? It's fine in other parts of WinBox, but not in Terminal.

Sorry, I not remember that will work anytime at Win with WinBox. I use that's type of key combination often and only Shift+ins works.

SHIFT+INS pastes clipboard content on terminal.
CTRL+INS does not copy text on terminal.

I don't know if it's a known issue, but it was wasting my time.
When we change pvid to a bridge, it creates a dynamic rule in the VLANs tab, but it doesn't update, instead it creates another one and the previous one that doesn't exist anymore (I know because I see it in the terminal) is still there, I change again and more rules keep popping up instead of updating the old one.

Normally in such cases (that seem to have become more prevalent in v7) you need to "refresh" the window by pressing F5 or close/reopen it.
The data shown in the window does not actually reflect the internal state of the router anymore, and somehow the router forgot to tell winbox to refresh it.

Normally in such cases (that seem to have become more prevalent in v7) you need to "refresh" the window by pressing F5 or close/reopen it.

I'd also see this occasionally in the bridge when changing PVIDs. F5/refresh fixes winbox & CLI seems always right. Dunno how the update works, but winbox seem particular bad at removing "stale" dynamic ("D") entries, until you refresh.

I'm hopeful need for F5/refresh will go down, but basically RN if you think something is right BUT winbox disagrees: trying hitting F5.

If anyone is having issues pasting to terminal where the data corrupts, were you on Windows 11 and copying from notepad, or from some other source? I noticed that the problem happened to me when copying from notepad. If I pasted to MS word and then copied from word to winbox terminal, it pasted fine

I'm hopeful need for F5/refresh will go down ...

There have been reports of ROS devices with high CPU load when winbox was connected. Possibly this was due to (too aggressive) auto refresh. I guess MT devs stepped back to a very lean refresh rate ... for some users too far it seems.

If anyone is having issues pasting to terminal where the data corrupts, were you on Windows 11 and copying from notepad, or from some other source? I noticed that the problem happened to me when copying from notepad. If I pasted to MS word and then copied from word to winbox terminal, it pasted fine

This also happen to me on Windows 10 last version, last updates.
WinBox 3.35 64 or 32 bit corrupt / delete clipboard when terminal is open or take focus
No matter what version of RouterOS is (tested on 6.46.8, 6.47.10, 6.48.6, 7.2)

If anyone is having issues pasting to terminal where the data corrupts, were you on Windows 11 and copying from notepad, or from some other source? I noticed that the problem happened to me when copying from notepad. If I pasted to MS word and then copied from word to winbox terminal, it pasted fine

FWIW I do not have this problem on Win11 copying from Notepad++
I do seem to have a problem where the initial copy apparently did not "register" but I think that's a Win11 issue (I also see it in other applications, I already do CTRL-C multiple times just to be sure).

There have been reports of ROS devices with high CPU load when winbox was connected. Possibly this was due to (too aggressive) auto refresh. I guess MT devs stepped back to a very lean refresh rate ... for some users too far it seems.

Well, of course I am familiar with "load" caused by open winbox, in my case mainly network traffic. I have 100-200kbps of traffic due to two open winbox sessions to v6 routers with a log and bgp peers window open.
But in v7 the bgp session window no longer refreshes. As long as you do not hit F5 is shows no updates expect "fake" uptime counters ticking independently from actual session status. However, the Log window still refreshes.
For such windows as shown in this topic (and also things like "IP address" etc) there basically is no removal of existing info. When new info is added, it shows up, but older info never gets deleted. So you get the impression that it auto-refreshes but it gets out of sync with reality over time. Maybe a "some info has been removed, you need to refresh!" message is still lacking.

When doing recursive routing in v7.2.X it works properly but IP -> Route (route list window) there was a cosmetic bug that the active route still marked as blue minor annoyance no biggy

I'm hopeful need for F5/refresh will go down ...

There have been reports of ROS devices with high CPU load when winbox was connected. Possibly this was due to (too aggressive) auto refresh. I guess MT devs stepped back to a very lean refresh rate ... for some users too far it seems.

I think they may be separate things. While how long the winbox session wait before terminating after the last "winbox protocol message" (and if you "auto-reconnect" how long before it start to retry that...) has changed a few times, that's not what I'm talking about.

It's how often/well winbox windows "poll"/"listen"/etc. for changes, like IP routes, address, and apparently BGP. I'd guess this class of issues is related to route cache being removed. Without that, winbox doesn't have a definitive/single source for the route table, so it has to reach out/calculate stuff from the "nexthop" data, but doesn't wait for long enough for it to be updated from a change. Anyway, I think polling interval is 0, so not the CPU ;), issue seem to be some "data refreshes" are only triggered by closing/open window and/or hitting F5.

You can always connect it on the MANAGED tab (vs the NEIGHBORS tab) via its IP address. Manually enter that in a new config item and hit add/set and it will be there the next time you connect.

That is not a winbox problem then. It doesn't belong in this topic.

WinBox v3.36 is released:
viewtopic.php?t=186479