I remember quite clearly that the 2nd CPU core was enabled with an upgrade from v6 to v7. I'm not sure on how much of a performance difference the 2nd CPU core brings, unless you're doing a load of things that switches don't usually do I think it's fairly minimal." *) switch - disabled second CPU core for CRS328-24P-4S+ device in order to improve SFP+ link stability;"
This one may finally resolve my issues with the CRS328 - but I have a question - is this expected to cause any issues re: performance? Was the second core not operational in v6? The stability issues came about with the upgrade from v6 to v7, so curious if the second core was enabled as part of this.
Is it normal to see this after upgrade/reboot without touching anything else? ..*) filesystem - fixed repartition on RB5009 series devices;
/partitions/print
Flags: A - ACTIVE; R - RUNNING
Columns: NAME, FALLBACK-TO, VERSION, SIZE
# NAME FALLBACK-TO VERSION SIZE
0 AR part0 next RouterOS v7.4beta2 Jun/07/2022 09:08:00 512MiB
1 part1 next EMPTY 512MiB
/ipv6/firewall/nat/add chain=srcnat src-address=fd01::/64 action=netmap to-address=2001:db8::/64
failure: dstnat/redirect/netmap action must be in dstnat/output chains
Hi,Mkay guess i'm skipping stable again. YOLO
Ok, so quick question regarding:Is it normal to see this after upgrade/reboot without touching anything else? ..*) filesystem - fixed repartition on RB5009 series devices;
What if I had more than 512MB on it? 0oCode: Select all/partitions/print Flags: A - ACTIVE; R - RUNNING Columns: NAME, FALLBACK-TO, VERSION, SIZE # NAME FALLBACK-TO VERSION SIZE 0 AR part0 next RouterOS v7.4beta2 Jun/07/2022 09:08:00 512MiB 1 part1 next EMPTY 512MiB
[admin@badfast] > /partitions/print
Flags: A - ACTIVE; R - RUNNING
Columns: NAME, FALLBACK-TO, VERSION, SIZE
# NAME FALLBACK-TO VERSION SIZE
0 AR part0 next RouterOS v7.4beta2 Jun/07/2022 09:08:00 1024MiB
[admin@badfast] /system/routerboard> print
routerboard: yes
model: RB5009UG+S+
serial-number: ECxxxxxxxxxx
firmware-type: 70x0
factory-firmware: 7.0.5
current-firmware: 7.4beta2
upgrade-firmware: 7.4beta2
@Znevna: I think it was the partitioning bug, which was corrected. The amount of space shown was probably wrong.@woland: tried to partition before, sure, but nothing happened back then, and all the space was still there until now. Someone could've used it ..
I don't know how the partitioning script deals with it
Oh well, if nobody gets hurt, all is fine :)
Have already done some years ago, and was told that they will look at it on a later release.@Jotne: open a ticket as it's not a version-specific issue.
Have already done some years ago, and was told that they will look at it on a later release.Posted a new support request. #[SUP-84077]
What advantages does DoT have over DoH? If you had to pick one, is that the one you prefer? Why?Chateau updated without issue.
Is DNS over TLS supported yet?
There is only one big difference. DoH uses https port, so can't block by port. DoT uses a known port, so operators like it, since they can block it.What advantages does DoT have over DoH? If you had to pick one, is that the one you prefer? Why?Chateau updated without issue.
Is DNS over TLS supported yet?
SUP-84114 just filed. Thanks!memelchenkov - Works for us. Can you provide supout file from this device to support@mikrotik.com which would be generated right after you have tried to make a backup?
I noticed it used the configuration i had used to try ( in a previous version in the past ) but didn't work.Mkay guess i'm skipping stable again. YOLO
Ok, so quick question regarding:Is it normal to see this after upgrade/reboot without touching anything else? ..*) filesystem - fixed repartition on RB5009 series devices;
What if I had more than 512MB on it? 0oCode: Select all/partitions/print Flags: A - ACTIVE; R - RUNNING Columns: NAME, FALLBACK-TO, VERSION, SIZE # NAME FALLBACK-TO VERSION SIZE 0 AR part0 next RouterOS v7.4beta2 Jun/07/2022 09:08:00 512MiB 1 part1 next EMPTY 512MiB
soon! just some minor things left.return container support
soon! just some minor things left.
Maybe the user-manager could use some makeovers too?*) webfig - updated WebFig HTML files with the new MikroTik logo and removed Telnet option from index page;
NAT with IPSEC with Use IP Firewall enabled still not working correctly. Connections are freezes. Fortunately, Bridge Filter Marks now works!! So IP Firewall for some (incl. my) cases may be replaced with Bridge Filter. I'm done with IP Firewall but who cares about it, beware.*) bridge - properly process IPsec decapsulated packets through the firewall when the "use-ip-firewall" option is enabled;
So ... any more details around this? Is this an interim fix or rather permanent? And how does it affect performance?*) switch - disabled second CPU core for CRS328-24P-4S+ device in order to improve SFP+ link stability;
I can say it has "fixed" the port flapping issue I've had since 7.x was released on my CRS328. I've been running 7.4beta2 since June 7, and haven't had a single port flap since. I'd been having port flapping every 5 minutes to a few hours (once I disabled anything that wrote to NAND) prior to this release, on all versions of 7.x. It seemed to be related to NAND operations, in my case, but that may have just been one of the triggers.So ... any more details around this? Is this an interim fix or rather permanent? And how does it affect performance?*) switch - disabled second CPU core for CRS328-24P-4S+ device in order to improve SFP+ link stability;
Product code CRS328-24P-4S+RM
Architecture ARM 32bit
CPU 98DX3236
CPU core count 1
It got one extra core enabled for some reason in v7, which probably was not supposed to happen.
Same trouble. mipsbe*) mpls - fixed VPLS functionality when PW peer is an immediate neighbor;
I hoped this would fix the VPLS crash I have been experiencing - alas, it has not. One ping goes through and then one core of my device goes to 100% and it locks up and eventually reboots on its own.
I have the same issue, it would appear to be an issue with .default-originate=always function if you set to .default-originate=always. if you set to .default-originate=never or .default-originate=if-installed then issue is resolved.When BGP vrf PE-CE issue will be fix?
This is BGP configuration in v6 and v7
v6.49.6 (works)
2 name="peer-trial-bgp-ce" instance=bgp1 remote-address=172.19.2.2 remote-as=65500 tcp-md5-key="" nexthop-choice=default multihop=no route-reflect=no hold-time=3m
ttl=default in-filter="" out-filter="" address-families=ip default-originate=always remove-private-as=no as-override=no passive=no use-bfd=no
v7.3 (did not works, BGP session not established)
2 name="peer-trial-bgp-ce"
remote.address=172.19.2.2/32 .port=179 .as=65500
local.address=172.19.2.1 .role=ebgp
connect=yes listen=yes routing-table=vrf-trial-xxx vrf=vrf-trial-xxx
router-id=172.19.2.1 templates=bgp1 as=65505 address-families=ip
output.network=ebgp-vpnv4-networks .default-originate=always
.no-client-to-client-reflection=no
actually the BGP session di v7 did something in route (see attachment) , it just like leak on memory and BGP status not established.
PE-99-vrf-capture-1.jpg
PE-99-vrf-capture-2a.jpg
PE-99-vrf-capture-2.jpg
thx
So you don't have any proof that suggests two functional cores in that SoC.
If it wasn't there to start with, what would it possibly be doing ?Probably brought up by mistake, but did anyone see it doing anything? besides creating problems..
If it wasn't there to start with, what would it possibly be doing ?Probably brought up by mistake, but did anyone see it doing anything? besides creating problems..
Because several things are declared to optimize it further.If you're so familiar with this subject, please explain the two files above that I mentioned: viewtopic.php?t=186583#p939191
Why did they bother creating another file for 3336 specifying just one extra core if the kernel is so smart figuring it out on it's own?
Could it be that x86 and arm are two different beasts? no? nah, didn't think so either.
Thank you.
I don't know. I think maybe. I don't think the kernel would find another CPU that wasn't there. It could be something like hyperthreading, but I don't think these CPUs have it.Paternot:
So you mean it's a bug of linux kernel or Mikrotik OS?
Ah. Just trolling, then. Ok, carry on.I well know that I have to draw it out for you to make you understand that you are wrong, considering our past interactions: viewtopic.php?p=847956#p848050
You only dug up some even older document that claims nowhere that 3236 is dual core (but it states somewhere that some cpu has 800GHz speed, legit so far) and you're talking about x86, again, which has nothing to do with arm or this particual SoC.
So I'll get down from my high horse when needed ;)
Cheers!
Does it matter really? It's the software threading model used by things in userland that matters. And the kernel's scheduler take into account a variety of things beyond "core count" in how it divides CPU tasks.It would really be cool to get a somewhat more descriptive statement from Mikrotik regarding the CPU core topic ...
Chip binning - google it.@Znevna: seems you're right. Also this article corroborates: https://www.linleygroup.com/newsletters ... p?num=5159
So I really wonder where that second CPU core came from?
*) switch - disabled second CPU core for CRS328-24P-4S+ device in order to improve SFP+ link stability;
Interesting idea. It would explain several observed things. Although one thing strikes me as a problem to this idea: It wouldn't be very practical if the deactivation of a given core was dependent on a given pin not being soldered. Imagine the logistical nightmare, to find out if (say) pin 2 or 3 should be left alone - since the problematic core could be the 0 or 1.TLDR version - phisically there are 2 cores on the chip, but manufacturer detected issues with 2nd core, and sold it as cheaper single core part to MikroTik. Probably it was not locked in any way, so it just showed up when you solder all pins. so it needed to be disabled in software.
i saw that many people have the same experience and i don't know how to make mikrotik listen.Another release without full VRF functionality (as attested by posts from buset1974 and loloski above).
I'm perplexed that we're up to a dot-four release, but there still appear to be chunks of L3 VPN functionality missing. These are not bugs; they are things that haven't even been implemented. Specifically, output filters don't work and it's not possible to use the mangle to look up routes in a VRF.
Can MikroTik provide some indication of when this might be addressed?
well we are in the world of chip shortage now, so manufactuers are soldering anyting on the boards that they actually get. It wouldn't suprize me that some part of these devices have actual 2 core CPU on them, just to be able to produce them.
Interesting idea. It would explain several observed things. Although one thing strikes me as a problem to this idea: It wouldn't be very practical if the deactivation of a given core was dependent on a given pin not being soldered. Imagine the logistical nightmare, to find out if (say) pin 2 or 3 should be left alone - since the problematic core could be the 0 or 1.
By the way, just remembered: The CRS326 use the very same CPU. Are they showing two cores on RoS V7.x? Are they affected by the same problem?
True. But this practice isn't new - far from it. It stands to reason that the CPU would have a simple way to be shipped with one of this cores disabled at factory. Better to the manufacturer (no one can cheap out and buy one core to use two) and better to the buyer (easier to use, just put it on the board and the chip says it only has one core).well we are in the world of chip shortage now, so manufactuers are soldering anyting on the boards that they actually get. It wouldn't suprize me that some part of these devices have actual 2 core CPU on them, just to be able to produce them.
Assume that you not remember jumpering motherboards. Setting speeds, dividers/multipliers, cache sizes ... Freedy Kruger wasn't the most frightening nightmare those timesAlthough one thing strikes me as a problem to this idea: It wouldn't be very practical if the deactivation of a given core was dependent on a given pin not being soldered. Imagine the logistical nightmare, to find out if (say) pin 2 or 3 should be left alone - since the problematic core could be the 0 or 1.
I have the same issue, it would appear to be an issue with .default-originate=always function if you set to .default-originate=always. if you set to .default-originate=never or .default-originate=if-installed then issue is resolved.When BGP vrf PE-CE issue will be fix?
This is BGP configuration in v6 and v7
v6.49.6 (works)
2 name="peer-trial-bgp-ce" instance=bgp1 remote-address=172.19.2.2 remote-as=65500 tcp-md5-key="" nexthop-choice=default multihop=no route-reflect=no hold-time=3m
ttl=default in-filter="" out-filter="" address-families=ip default-originate=always remove-private-as=no as-override=no passive=no use-bfd=no
v7.3 (did not works, BGP session not established)
2 name="peer-trial-bgp-ce"
remote.address=172.19.2.2/32 .port=179 .as=65500
local.address=172.19.2.1 .role=ebgp
connect=yes listen=yes routing-table=vrf-trial-xxx vrf=vrf-trial-xxx
router-id=172.19.2.1 templates=bgp1 as=65505 address-families=ip
output.network=ebgp-vpnv4-networks .default-originate=always
.no-client-to-client-reflection=no
actually the BGP session di v7 did something in route (see attachment) , it just like leak on memory and BGP status not established.
PE-99-vrf-capture-1.jpg
PE-99-vrf-capture-2a.jpg
PE-99-vrf-capture-2.jpg
thx
Doesn't help much but shows where the issue is.
Don't You talk to me about jumpering motherboards - I have had my fair share of IRQs and addresses with 386s...Assume that you not remember jumpering motherboards. Setting speeds, dividers/multipliers, cache sizes ... Freedy Kruger wasn't the most frightening nightmare those times :)
1) YesTwo quick questions about containers:
1) are veth interfaces mandatory, or can host networking be used?
2) the docs state that ext4 is supported, is this new? Any plans to add ext4 support to Disks > Format Drive?
Two quick questions about containers:
1) are veth interfaces mandatory, or can host networking be used?
2) the docs state that ext4 is supported, is this new? Any plans to add ext4 support to Disks > Format Drive?
Thank all very nice Jon, just why you all not considering adding the from-src-address: or from interface option to Netwatch, is there any limitaion?Netwatch now has extended functionality for ICMP, along with new probe types for TCP and HTTP GET. More information can be found here: https://help.mikrotik.com/docs/display/ROS/Netwatch
Would be nice if specifying a local address or a routing mark is allowed too...Thanks for the Netwatch improvements, specifically the VRF support! :D
Erm yeah... Me neither. Oh MikroTik, what have you done...I can't access netwatch from command line on 7.4beta4
/tool/netwatch
bad command name netwatch (line 1 column 7)
Anyone else can confirm?
Do you have advanced-tool installed?Erm yeah... Me neither. Oh MikroTik, what have you done...I can't access netwatch from command line on 7.4beta4
/tool/netwatch
bad command name netwatch (line 1 column 7)
Anyone else can confirm?
That's v6 stuff isn't it? Last I knew, you'd done away with separate packages for core functionality with v7.Do you have advanced-tool installed?
Erm yeah... Me neither. Oh MikroTik, what have you done...
For me, I'm running a CHR with v7.4beta4What device it is? Architecture?
[ali@<redacted>] > /system/resource/print
uptime: 14m46s
version: 7.4beta4 (testing)
build-time: Jun/15/2022 11:04:34
factory-software: 6.49.3
free-memory: 1829.4MiB
total-memory: 1920.0MiB
cpu: Intel
cpu-count: 1
cpu-frequency: 2394MHz
cpu-load: 0%
free-hdd-space: 39.7GiB
total-hdd-space: 39.7GiB
write-sect-since-reboot: 460272
write-sect-total: 460272
architecture-name: x86_64
board-name: CHR
platform: MikroTik
[ali@<redacted>] > /tool/netwatch
bad command name netwatch (line 1 column 7)
[ali@<redacted>] >
What you experience is something else, the fix is only for export.is this
*) route - made export run faster on tables with a large number of dynamic routes;
helping about support #[SUP-83756]: ccr2216 with 3xBGP_fullroute not able to sort route when rpki is checked??
regards
Ros
/tool/netwatch
bad command name netwatch (line 1 column 7)
/system/device-mode/update container=yes
update: please activate by turning power off or pressing reset or mode button in 4m55s
You'll need to force power-off or force reboot the CHR VM. Do that from your hypervisor/VPS dashboard.how to update the device mode to enable the container under CHR ?
Code: Select all/system/device-mode/update container=yes update: please activate by turning power off or pressing reset or mode button in 4m55s
That's good news! As of 7.3.1, Disks > Format Disk in WebFig only offers ext3 though, and the formatted disk also appears as ext3? Is this a WebFig text label issue only?2) Disks are formatted from RouterOS as ext4 for a while now.
I think that may be doing it "gracefully". What you need to do is force power-off/force reboot. I think they're called Hard stop and Reset respectively with ESXi?In fact ,I tried. but the problem remains.
I am running it on esxi 7.03. I can easily shut down or restart it. not sure if that is "forced way"
I am running it on esxi 7.03. I can easily shut down or restart it. not sure if that is "forced way"
Happy to help!Thanks
@aliclubb @tangent
problem solved.
Settings are also missing from the export. If that is unrelated, please fix that as well.Sorry for any inconvenience caused regarding the Netwatch service unavailability under CLI. This will be fixed in the next beta release.
I wish you wouldn't use these combined ipv4@vrf, ipv6@vrf formats. Back when I started with RouterOS (WinBox), the thing I really liked was that everything was so clear and self documenting, I was able to use it without even looking in manual. If there was separate field for VRF, then everyone would immediatelly see that it's there. If it's <address>@<vrf name>, then every new user has to look that up in order to know that VRF support exists there (ipv6-linklocal%interface is at least expected, because it's common standard). And even when you know about it, wouldn't it be convenient to select existing VRF from dropdown, instead of having to type the whole name?*) netwatch - added support for more advanced probing;
Ok, did some tests, some observations:Netwatch now has extended functionality for ICMP, along with new probe types for TCP and HTTP GET. More information can be found here: https://help.mikrotik.com/docs/display/ROS/Netwatch
Support for fast BSS transitions can be enabled with*) wifiwave2 - added initial support for roaming (802.11r) between local AP interfaces;
Anything special to be configured for this to function ?
Further testing shows that this VRF issue is ONLY present when Routing > BGP > VPN entries are enabled. More specifically, if I select 'redistribute ANY routes' in a BGP VPN Instance.I have encountered a strange issue.
If there are additional VRF's present in the configuration (IP > VRF), OSPF will not form an adjacency using the MAIN routing table and errors out with "routing table is not active". (picture attached).
The Router ID entries become invalid for all VRF's. (picture attached)
If I disable the other VRF's, the adjacency is formed after a reboot.
The Router ID entry for the MAIN VRF is once again restored.
Some more observations:Ok, did some tests, some observations:Netwatch now has extended functionality for ICMP, along with new probe types for TCP and HTTP GET. More information can be found here: https://help.mikrotik.com/docs/display/ROS/Netwatch
"done-tests" counter only updates when there's a status change from up<>down or when you hit refresh in WinBox on the Netwatch window. (probably other fields update in the same way), you can hit refresh in WinBox, but in WebFig it's not so fun to hit refresh.
What is "failed-tests" used for? I thought it counts how many .. you know, tests failed, but it never increases, remains 0.
:log info "netwatch: $host up $status $since"
You are in my mind.I wish you wouldn't use these combined ipv4@vrf, ipv6@vrf formats. Back when I started with RouterOS (WinBox), the thing I really liked was that everything was so clear and self documenting, I was able to use it without even looking in manual. If there was separate field for VRF, then everyone would immediatelly see that it's there. If it's <address>@<vrf name>, then every new user has to look that up in order to know that VRF support exists there (ipv6-linklocal%interface is at least expected, because it's common standard). And even when you know about it, wouldn't it be convenient to select existing VRF from dropdown, instead of having to type the whole name?*) netwatch - added support for more advanced probing;
Indeed, MikroTik is really going on the wrong track lately.And exactly that, is the reason why I hate the new routing filters syntax.
Can confirm that beta4 fixes the boot-loop. IPv6 NAT netmap still broken though :'(Is the boot-loop fix for the RB3011 included in beta4? I had tried beta2 to check if IPv6 netmap was fixed in this version (see viewtopic.php?p=940066#p940066 for the issue) but it looks like this version possibly did not yet include the 7.3.1 fix so it entered a boot-loop.
"this has been addressed in v7.3 , using pe-ce bgp , however run this in the lab before any live deployments "When BGP vrf PE-CE issue will be fix?
This is BGP configuration in v6 and v7
v6.49.6 (works)
2 name="peer-trial-bgp-ce" instance=bgp1 remote-address=172.19.2.2 remote-as=65500 tcp-md5-key="" nexthop-choice=default multihop=no route-reflect=no hold-time=3m
ttl=default in-filter="" out-filter="" address-families=ip default-originate=always remove-private-as=no as-override=no passive=no use-bfd=no
v7.3 (did not works, BGP session not established)
2 name="peer-trial-bgp-ce"
remote.address=172.19.2.2/32 .port=179 .as=65500
local.address=172.19.2.1 .role=ebgp
connect=yes listen=yes routing-table=vrf-trial-xxx vrf=vrf-trial-xxx
router-id=172.19.2.1 templates=bgp1 as=65505 address-families=ip
output.network=ebgp-vpnv4-networks .default-originate=always
.no-client-to-client-reflection=no
actually the BGP session di v7 did something in route (see attachment) , it just like leak on memory and BGP status not established.
PE-99-vrf-capture-1.jpg
PE-99-vrf-capture-2a.jpg
PE-99-vrf-capture-2.jpg
thx
:put [ :terminal inkey timeout=5 ]
This was mentioned in the previous beta, yet you're saying this is new in beta5. Has something changed?What's new in 7.4beta5 (2022-Jun-27 10:39):
*) wifiwave2 - added initial support for roaming (802.11r) between local AP interfaces;
For what action specifically? I know dst-nat already had it, src-nat maybe? It still seems to be missing for netmap though. Which itself is also still broken in this version as well.*) winbox - added "to-address" and "to-ports" parameters under "IPv6/Firewall/NAT" menu;
FYI this is necessary for Google Nest Doorbell (Battery) to work, as ROS 7.3.x changed the DHCP options order and the Google doorbell refuses DHCP offers if option 53 isn't first.What's new in 7.4beta5 (2022-Jun-27 10:39):
*) dhcpv4-server - placed option 53 as the first one in the packet;
Then again in beta5*) container - added support for running Docker (TM) containers on ARM, ARM64 and x86;
They apparently added docker support twice. Niceeee. Twice is better than once. Always good to have a spare docker. Quite an efffort to add the support two times, even if supporting docker once would be sufficient.*) container - added support for running Docker (TM) containers on ARM, ARM64 and x86;
actually means this:*) container - added support for running Docker (TM) containers on ARM, ARM64 and x86;
Then I feel confirmed. I already criticized "Improve stability", "add support", "fix the thing", "fix all" changelog entries. They do not add any value. Such changelog entries can be in fact omitted.So a more complete changelog for 7.4beta5 would be this: viewtopic.php?t=186583#p942098 + this:
*) container - (!)ALL CONTAINERS FROM THE PREVIOUS BETA WILL HAVE TO BE RECREATED, due to the changes below, sorry about that;
*) container - fixed pulling remote images to internal storage, now they get pulled in the destination set as "tmpdir" in /container/config;
*) container - implemented workaround for sudo issues;
*) container - environment variables changed syntax, "list" is now "name", "name" is now "key":
so this from 7.4beta4: /container/envs/add list=pihole_envs name=WEBPASSWORD value="mysecurepassword"
became this in 7.4beta5: /container/envs/add key=WEBPASSWORD name=pihole_envs value="mysecurepassword"
(!)settings don't get migrated to the new syntax, so please export the settings before updating to beta5;
*) container - memory limit can only be set via WinBox (container->config), it is not visible in an export, sorry about that, we'll try to fix it in future releases;
*) container - fixed adding comments;
Dictionary for MikroTik changelog entries:Then I feel confirmed. I already criticized "Improve stability", "add support", "fix the thing", "fix all" changelog entries. They do not add any value. Such changelog entries can be in fact omitted.
I think they should start by fixing wwave2 on supported products before porting it elsewhere.Hi, haven't followed updates for a while. Are there any plans to backport wwave2 features to currently unsupported AC devices?
Thanks, that is actually quite close explanation.Dictionary for MikroTik changelog entries:
"improved stability" = under certain circumstances the router crashed. we have made changes to hopefully prevent that. we will not tell you exactly how it crashed.
"add support" = a first attempt at supporting a new feature has been added. it likely requires several more iterations. probably it works only in commandline mode.
"fixed" = one more iteration towards a working situation has been made. please test and report. we will probably not read your report here, so make a support ticket (we like to be overwhelmed by similar tickets!)
I wouldn't put money on this statement.Nothing is added twice. BETA releases always include ALL changes since last non-BETA. This is how it's always been. The reason is that when 7.4 will be released, it will have all changes from last stable
Not true at all. How do you then explain that change log for beta2 is much larger than beta4 and beta4 change log is larger than beta5 change log.Nothing is added twice. BETA releases always include ALL changes since last non-BETA. This is how it's always been. The reason is that when 7.4 will be released, it will have all changes from last stable
*) dhcpv4-server - disallowed overriding message type option;
*) dhcpv4-server - log message when user option updates existing option;
*) dhcpv4-server - placed option 53 as the first one in the packet;
*) health - fixed requesting data from sensor when issuing "get" command;
*) health - fixed voltage reporting on some RBmAP-2nD devices;
*) lte - validate LTE attached IP type in MBIM mode;
*) poe - hide "poe-voltage" parameter on devices that do not support it;
*) route - expose all valid routes to route select filter from OSPF and RIP;
*) route-filter - fixed route select filter rules;
*) upgrade - ignore same version packages during upgrade procedure;
*) winbox - added "name" parameter under "Routing/BGP/Session" menu;
*) winbox - added "to-address" and "to-ports" parameters under "IPv6/Firewall/NAT" menu;
*) winbox - added support for "Routing/GMP" menu;
*) winbox - added support for "veth" interface types;
*) winbox - fixed "inactive" flag naming under "MPLS/Local Mapping" menu;
*) winbox - fixed minor typo under "Interface" stats;
*) winbox - fixed units for "reachable-time" parameter under "IPv6/ND" menu;
*) winbox - removed "TLS Host" parameter from "IP/Firewall/NAT" menu;
*) winbox - removed duplicate signal strength column under "Wireless/Registration Table" menu;
*) container - added support for running Docker (TM) containers on ARM, ARM64 and x86;
*) netwatch - added support for more advanced probing;
*) wifiwave2 - added initial support for roaming (802.11r) between local AP interfaces;
*) defconf - fixed default configuration loading on devices with WifiWave2 package;
*) dhcp-relay - fixed DHCPv6 relay forward and reply creation (introduced in v7.1.3);
*) dhcp-server - change "vendor-class-id" matcher to generic option matcher;
*) dot1x - fixed "undo" command for server instances;
*) l2tp - improved stability when establishing l2tp-ether connection (introduced in v7.3);
*) leds - fixed GPS LED configuration on LtAP LTE kit;
*) leds - fixed LTE signal strength LED configuration on LHGG LTE kit;
*) leds - fixed LTE signal strength LED configuration on LtAP LTE kit;
*) lte - added AT chat support for Dell dw5821e modem;
*) lte - fixed LTE interface running state after modem reconnection;
*) mqtt - fixed socket error handling;
*) ovpn - fixed "called-station-id" RADIUS attribute value for OVPN server;
*) ppp - do not fail connection when trying to add existing IP address to address list;
*) ppp - log warning message when remote IP address can not be added;
*) route - changed "mode" setting to "exclude" for group management protocol (CLI only);
*) route - made export run faster on tables with a large number of dynamic routes;
*) routing-filter - added origin matcher to match for example routes of a specific OSPF instance;
*) routing-filter - made "do-jump" work in select rules;
*) ssh - fixed host key generation (introduced in v7.3);
*) switch - fixed multicast flooding when HW offloaded bridge port gets disabled;
*) system - fixed configuration reset with "run-after-reset" with file stored on ramdisk;
*) upgrade - improved RouterOS upgrade stability with attached USB modem on MIPSBE, SMIPS and MMIPS devices;
*) w60g - improved interface initialization after being inactive for a while;
*) winbox - fixed filename dropdown value filtering;
*) x86 - fixed Broadcom NIC support;
OK, but what is the answer to my question. You do say that every new change log do show all added stuff since main release. My post clearly that what is sad, does not add up.Please stay on topic. Deleting offtopic now
https://help.mikrotik.com/docs/display/ ... p+FeaturesRB760 iGS
switch -> L3 HW Offload
it is some mistake?
or 750gr3/760igs will be "special" in small device category ?
vlan filtering is L2 feature, and yes, i was glad when MT enabled this option on mt7621https://help.mikrotik.com/docs/display/ ... p+Features
Bridge HW vlan-filtering was added in the RouterOS 7.1rc1 (for RTL8367) and 7.1rc5 (for MT7621) versions. The switch does not support other ether-type 0x88a8 or 0x9100 (only 0x8100 is supported) and no tag-stacking. Using these features will disable HW offload.
RB760 iGS
switch -> L3 HW Offload
it is some mistake?
or 750gr3/760igs will be "special" in small device category ?
Because you are missing the point. Only new features repeat. Fixes do not.OK, but what is the answer to my question. You do say that every new change log do show all added stuff since main release. My post clearly that what is sad, does not add up.Please stay on topic. Deleting offtopic now
all my hopes are gone now :(
That looks like a visual issue in WinBox. RB760 iGS does not support L3 HW Offloading.
Change notes should be put on a dynamic website where you can query "what has changed between version X and version Y", with a link to that website in the forum release topics and the same query being made from the "check for upgrades" function of the router (where it will show changes between the version you are currently running and the offered version).Because you are missing the point. Only new features repeat. Fixes do not.
thx :)scroll back to reply #115
Mikrotik this morning sent me an internal test version and it has fixed my issue - no more VPLS crash.Same trouble. mipsbe
:local currenthost $host;
:local comment [/tool/netwatch/get [find where disabled=no and host=$currenthost] value-name=comment];
:local status [/tool/netwatch/get [find where disabled=no and host=$currenthost] value-name=status];
:local since [/tool/netwatch/get [find where disabled=no and host=$currenthost] value-name=since];
:log info "netwatch: $currenthost ($comment) is $status since $since";
The entire reasoning behind this feature is that it should not work for remotely deployed devices! It should only work for devices with a physical operator present at the device.Not sure if this is specific to the RB1100AHx4 or not, but when enabling the container functionality in device-mode, power cycling doesn’t successfully enable it. Using the reset button does, but this isn’t going to work well for remotely deployed devices.
Have you tried it wit a foreach where $i is containing the .id? This way you can read multiple values in one go, sequential. Not having to do a new find for each value.Anyone managed to find a better way to use the data provided by netwatch (status, since etc) I currently only had successful results with something like this:
snip...
Not the best way to do it, if you have multiple monitored hosts with the same IP it will obviously fail to work properly.
I've tried to use $host directly in the get commands but it only works for one host, once you start adding the same script for other hosts it fails to work for every host.
{
:foreach i in=[/tool/netwatch find] do={
:set $host [/tool/netwatch get $i host ]
:set $comment [/tool/netwatch get $i comment]
:set $status [/tool/netwatch get $i status]
:set $since [/tool/netwatch get $i since ]
:put "Netwatch: host $host ($comment) is $status since $since";
}
}
It seems to me that when changing device mode, command itself actually installs some kind of command file which executes at boot time ... but gets removed either after time out or when executing reboot/shutdown command. So "surprise" reboot is necessary and either reset (via button) or power cycle should do. However, my own experience is as well that power cycle doesn't do it, could be due to some flash controller/drive write cache which flushes with reset button but doesn't before power is cut (tried on arm device and mipsbe device, fails in both cases).That hard reset may not be so desirable, especially because the button (contrary to other devices) is easy to press and does not require fiddling with a pin.
Could be. When I tried it, the delay between device mode set command and power cut was around 30 seconds if not more as devices were not in the same room as management chair. But even if it's a matter of delay, it should either be improved (so that no additional delay is needed) or clearly documented.Maybe you need to wait a little longer before doing the powercycle?
Ok, this expression must be worth something !!...not in the same room as management chair.
That’s a short-sighted approach. Devices are increasingly being deployed in situations where a physical operator will almost never be present. Having to physically go to a remote site to replace hardware is one thing. Having to do it to enable a software feature is another.The entire reasoning behind this feature is that it should not work for remotely deployed devices! It should only work for devices with a physical operator present at the device.
There’s the problem right there. This device is being controlled from a network-controlled power distribution device (PoE off of the management switch) and hard power cycling the device doesn’t change the device mode like it should.But of course, when you have powered your device from a network controlled power distribution device where you can remotely toggle the power, it would still be possible.
It is well motivated by security concerns. The feature was introduced to prevent people who had some way obtained remote access to a router to be ableThat’s a short-sighted approach. Devices are increasingly being deployed in situations where a physical operator will almost never be present. Having to physically go to a remote site to replace hardware is one thing. Having to do it to enable a software feature is another.The entire reasoning behind this feature is that it should not work for remotely deployed devices! It should only work for devices with a physical operator present at the device.
Others have reported it as well. It looks like a bug that should be fixed.There’s the problem right there. This device is being controlled from a network-controlled power distribution device (PoE off of the management switch) and hard power cycling the device doesn’t change the device mode like it should.But of course, when you have powered your device from a network controlled power distribution device where you can remotely toggle the power, it would still be possible.
VPLS has been broken for a long time in ROS7, I've disabled it and switched to VxLAN which has been working well so far (and it's easier to use too).Mikrotik this morning sent me an internal test version and it has fixed my issue - no more VPLS crash.
VxLAN makes more sense in a datacenter environment where you want to interface with virtual machines. MPLS and VPLS and SR-MPLS make more sense in the service provider space.VPLS has been broken for a long time in ROS7, I've disabled it and switched to VxLAN which has been working well so far (and it's easier to use too).
This looks like the PMKSA generated as last step of EAPOL (which in 802.11r is kept by the client to be reused for future (re)associations with the same AP, skipping time consuming 802.1X EAP) gets lost on AP reboot. If the client tries to reconnect with the cached PMKSA, it is not known to the AP anymore and it "can't find PMKSA".> *) wifiwave2 - added initial support for roaming (802.11r) between local AP interfaces;
If 802.11r is enabled (`security.ft=yes`) some devices can't reconnect to an AP after the latter gets rebooted. In my case it was an iPhone with iOS 15.5. Logs show the following:
mac-address@wifi2 rejected, can't find PMKSA
Yes, obviously that is what's going wrong.I would think the AP would send an appropriate errormessage and the clients would then go through the complete authentication cycle instead of using the fast PMKSA.
The is a very good reason to strongly advise the operator to secure the device properly. It isn't a good reason to require the operator to physically travel hours to a site after they have already secured it. Ensuring that the means to secure a device properly is the responsibility of the vendor. Locking the operator out of the proper operation of the device because the vendor supposedly knows better is another matter entirely.It is well motivated by security concerns. The feature was introduced to prevent people who had some way obtained remote access to a router to be ableThat’s a short-sighted approach. Devices are increasingly being deployed in situations where a physical operator will almost never be present. Having to physically go to a remote site to replace hardware is one thing. Having to do it to enable a software feature is another.
to further take it over for their malicious purpuses entirely using commands on their remote session. So it requires an operator with physical access to
do some major mode changes. Container is just one of them. Consult the appropriate documentation.
Definitely. In the meantime, I'll continue looking for a workaround for the "feature" above.Others have reported it as well. It looks like a bug that should be fixed.There’s the problem right there. This device is being controlled from a network-controlled power distribution device (PoE off of the management switch) and hard power cycling the device doesn’t change the device mode like it should.
This feature is not intended to protect the operator that knows how to secure a device properly. It is intended to protect the "unpack, plug-in, use" type of operator that uses the device in a home network.The is a very good reason to strongly advise the operator to secure the device properly. It isn't a good reason to require the operator to physically travel hours to a site after they have already secured it. Ensuring that the means to secure a device properly is the responsibility of the vendor. Locking the operator out of the proper operation of the device because the vendor supposedly knows better is another matter entirely.
It is well motivated by security concerns. The feature was introduced to prevent people who had some way obtained remote access to a router to be able
to further take it over for their malicious purpuses entirely using commands on their remote session. So it requires an operator with physical access to
do some major mode changes. Container is just one of them. Consult the appropriate documentation.
This feature is not intended to protect the operator that knows how to secure a device properly.