Ok, I didn’t clear it. I created a new bridge with vlan filtering and switched the ports to it later. Your feedback raises two questions to me:
Looking ar routing process stats hints to crashes of RIP process as PID for this process changes after autosupout is created and new redundant set of route instances appears in route list. It is not possible to predict how much time it takes for next crash to happen as sometimes it is possoble to get to 48+ hours uptime and sometimes it is less than 10 hours before everything related to routing becomes unresponsive and one core is maxed out (necessitating a reboot). Only thing left is to try to use “single-process” option in routing settings, but is not clear can it help with this or not.
Is this thread for 7.13.4 or 7.13.5. I see when you quote posts it uses the tilte for that post, not title for the thread, so posts above show 7.13.4 even if it should show 7.13.5.
So once again MikroTik. Use a new thread for every new Stable/Long Term a before.
Why? What if there is bug in 7.13.4 and 7.13.5 did not fixed this problem??? Think a bit…They will mention the problem in one thread(7.14.4) and then will jum to another thread (7.13.5) without any history of the problem???
Make something useful then bad idea on forum…
In this thread i may mean something for that specific conversation. But its in anyway better to use new thread for every new version, as it was done before.
So you are saying that we should just forcefully set an Admin MAC to workaround the issue? Still the question remains why this suddenly is a problem as it may be a bug? In any case I reported to support@ and waiting for feedback.
AFAIK a Bridge has no own MAC address, and it takes the interface MAC address of the first active Port.
Devices with wireless interfaces, may show changing MAC addresses, as wireless interfaces by default are “down” when no wireless client is connected.
So the bridge then picks another interface MAC address. It might change again when a client connects to the wireless interface.
Setting a MAC address as Admin MAC avoids problems when the bridge MAC is needed.
Wireless interfaces (WLAN) can be set to disable the down state when no clients connected , default is “disable-running-check=no”
Maybe read “Since 7.13.4 the vlan bridge is changing its MAC address multiple times. After the last reboot this was going on for 5 minutes until it stabilized on one MAC. During that time CAPsMAN connection breaks after every change.” as
“Since 7.13.4 the vlan bridge is changing its MAC address multiple times. After the last reboot this was going on for 5 minutes until it stabilized on one MAC. During that time the MAC address changed after every CAPsMAN connection break or make.”
Upgraded 2x CRS326. 16Mb devices.
After upgrade from 7.12.1 to 7.13.5 (but surely it will be the case with any 7.13.x version), wireless package was also present, eating away precious storage space. Why ? On a switch ?
Because upgrader is obviously pretty stupid (as it can’t only install e.g. wireless driver for device’s chipset) and installer in 7.12 is only smart enough to select one additional package … regardless the device model.
But then: are you sure you don’t want to run legacy CAPsMAN on your switch? 
I don’t even run zerotier on it.
But EOIP to central RB5009 runs just fine :doublewink:
You can just delete that extra package in the /system/packages menu and reboot. It will not come back.
I am well aware of that (and that’s also what I did, obviously).
But you might run into a situation where the extra wireless package (which is completely useless for normal operation on that device) totally bunks the upgrade.
And what then ??
I know how to deal with it.
But I’m pretty sure there will be quite some users freaking out at that point when such a thing happens.
Because wireless was part of the main routeros package in 7.12. If wireless package wasn’t installed by default during update to 7.13, you would lose features like legacy capsman.
But now that it’s a separate package, you have the possibility to uninstall wireless if you know you don’t need it.
I know why it got installed (way too broad default upgrade behavior) but my point is that this happens on a device NOT using wifi and normally NOT being used as capsman controller (but it can, I do realize that).
If capsman wasn’t enabled, there is 0.0 reason for having that wireless package installed.
My take:
Don’t install it by default on a switch.
If needed, device’s admin can always add wireless him/herself. But at that point I suspect it’s an admin knowing what he/she is doing.
If you don’t install it by default, you will have people complaining that the update broke their capsman setup. Even if capsman was inactive, people might want to retain their wireless config for future use.
Tl;dr: Some people will always complain, no matter how Mikrotik decides to handle the update.
Packages are upgraded before configuration is parsed so there is no way to know if you are using CAPsMAN or not, and as it was already explained to you wireless was the part of previous bundles so in order not to brake anything it is installed as the part of the upgrade process. Once you uninstall wireless package in version 7.13 it will not be installed on subsequent upgrades. And since you obviously didn’t have any problems associated with it I don’t see the point of your ranting…
How do I use grep command? Cannot find any reference in the docs or forums.
Would be nice to be able to do something like
:grep pattern [/ip/firewall/address-list export]
The F1 key for help does give some clues for :grep:
:grep
-- source of the script to execute after -- lines to be printed leading context as-array -- put output in an array before -- lines to be printed trailing context filename -- save output to file pattern -- extended regular expression pattern
The part is confusing. But since it’s the ugly ducky of scripting with odd syntax… :grep is a UNIX thing, so the is the command as a string, not RouterOS syntax. But real grep takes the pattern as default… make this even more confusing.
But I think this is how you’d grep the address-list:
:grep "/ip/firewall/address-list export" pattern=".*"
While perhaps some use case for :grep — but using “print where” and “find” is better/richer ways to search address-lists. It’s like if you have a SQL database (e.g. “print where”) and instead of using SELECT (RouterOS’s where/find) on the real data, you’re grep’ing a CSV export.
I do like the “as-array” instead of a generic “as-value” used on grep however — helpful to control the type returned from commands. But “as-array” is how you’d store the results of :grep to a variable.
On note, If you want to use grep a string variable, you need to “:put” it as part of the to cause the variable to go via stdout which grep is using.
:global multilineString "hello\nworld\nhello world"
:global hellos [:grep ":put \"$multilineString\"" pattern="hello.*" as-array]
:put $hellos
# hello;hello world
:put [:len $hellos]
# 2
It’s “sed” that been more useful if they were going to import POSIX commands. Modify strings in scripting is hard.
Someone must have had some use case for the “:grep” — I just wish I knew what it was. RouterOS is not UNIX with files and text streams, so grep odd addition to RouterOS IMO.
Guessing, because before grep was broken out as a program (we’re talking Ye Olden UNIX Days) it was a common usage pattern in ‘ed’/‘ex’ - ‘:g/re/p’ where ‘re’ is your regular expression, same as is commonly used in (neo)vi(m); its the more generic form of what ‘sed’ can do, and it refers to a command/usage pattern as well as the cli program, where ‘sed’ is only a cli program that applies a subset of grep functionality to streams.
Well, I recall DEC VMS too. Mikrotik went down that road in shell, instead of Bourne and pipes – ending in even IS-IS now. Why “grep” is odd.
But regex is TOTALLY useful. Just in form of “:grep” on RouterOS, not sure. Scripting already has ~= regex matchers and other primitive to search a file using a regex - it’s regex [named] grouping and sed/vi/etc regex replacement that’s actually missing. e.g. getting an as-array with matched groups from regex parsing a routeros string is BIGGER problem that using a regex stdout of a routeros command…
But Mikrotik should add some docs on :grep…