Quite a lot of devices will lack new stack.!) completely new alternative wireless package "wifiwave2" with 802.11ac Wave2, WPA3 and 802.11w management frame protection support (requires ARM CPU and 256MB RAM);
Yep, it is a shame, but at the same time understandable.Quite a lot of devices will lack new stack
Ok so this is basically 7.1rc7 with a new version number? No need to install it when you already have 7.1rc7?Due to the fact that we have made a huge progress in RouterOS v7 stability, we have decided to release it in the testing channel.
Did you read all feedback on the previous v7.1rc forum pages and at least put the remarks about lacking or nonworking sub-features on a work-to-do list?Please test it where you can and report your feedback on this forum page
that looks exciting but unfortunately there are some critical omissions in the current status that make it unfit for production use.ROUTING
----------------------
!) completely new BGP implementation with performance improvements;
I have a RB4011 which fulfills the requirements for wifiwave2 but still I cannot use it because it doesn't co-exist with the normal package that is required to support 2.4 GHz WiFi.Quite a lot of devices will lack new stack.!) completely new alternative wireless package "wifiwave2" with 802.11ac Wave2, WPA3 and 802.11w management frame protection support (requires ARM CPU and 256MB RAM);
What about the cAP XL ac, it was lauched months ago, after the wifiwave2 was around?CAPsMAN does not support WW2 at the moment.
Note that WW2 is planned for future devices, that's why there are additional requirements in terms of hardware.
In other words, the 7.1 is a exact copy (as there is changelog between) of 7.1rc7, as the same well reported bugs are still here...v7.1 contains routing fixes and improvements in order to fully comply with 6.x setups.
Please give us more detailed changelogs, even if it only says briefly like you wrote now, if we have related issue, we than know to flash new version and check if issue is resolved..v7.1 contains routing fixes and improvements in order to fully comply with 6.x setups.
no, like Sergejs clearly wrote, it contains several routing fixes, compared to rc7
In other words, the 7.1 is a exact copy (as there is changelog between) of 7.1rc7, as the same well reported bugs are still here...
/interface/wireguard/peers/print
# INTERFACE PUBLIC-KEY ENDPOINT-PORT ALLOWED-ADDRESS
0 wireguard1 editedpubkeypeer0= 0 172.22.88.12/32
edited:7:0:12/128
1 wireguard1 editedpubkeypeer1= 0 172.22.88.13/32
edited:7:0:13/128
ping edited:7:0:12
0 edited:7:0:12 56 64 90ms951us echo reply
ping edited:7:0:13
0 edited:7:0:12 104 64 75ms476us net unreachable
/interface/wireguard/peers> enable 1
ping edited:7:0:12
0 edited:7:0:12 timeout
ping edited:7:0:13
0 edited:7:0:13 56 128 10ms730us echo reply
I think that everyone would be happy to have, somewhere the full changelog, because sometimes, there is some "edge-case" that may affect someone and that person could see if this was solved...no, like Sergejs clearly wrote, it contains several routing fixes, compared to rc7
In other words, the 7.1 is a exact copy (as there is changelog between) of 7.1rc7, as the same well reported bugs are still here...
About the useless switch of the RB4011, here are the tests showing that the issue isn't solved.
With bridge vlan filtering on:
Screenshot 2021-12-02 133319.png
With bridge vlan filtering off:
Screenshot 2021-12-02 133101.png
Yes simple features like BFDOk so this is basically 7.1rc7 with a new version number? No need to install it when you already have 7.1rc7?Due to the fact that we have made a huge progress in RouterOS v7 stability, we have decided to release it in the testing channel.
Did you read all feedback on the previous v7.1rc forum pages and at least put the remarks about lacking or nonworking sub-features on a work-to-do list?Please test it where you can and report your feedback on this forum pagethat looks exciting but unfortunately there are some critical omissions in the current status that make it unfit for production use.ROUTING
----------------------
!) completely new BGP implementation with performance improvements;
and we all know that until it is fit for production use, it cannot really be tested either.
It is your misunderstanding. Switch hardware accel has nothing to do with fastpath or fasttrack! It concerns L2 forwarding between switchports.What I said on the 7.1rc7 topic (viewtopic.php?t=180675#p894492), still valid, the RB4011 switch is still useless.
Yes. output.network is the replacement for /routing bgp networks. It has nothing to do with filtering.Do I need to mention outpu.network in bgp if I use out filter?
So it now does support "unreachable" routes and is not converting them to "blackhole"?v7.1 contains routing fixes and improvements in order to fully comply with 6.x setups.
Missing functionality in BGP:Yes simple features like BFD
He did not mention rc7 actually so I dident find it very clear.no, like Sergejs clearly wrote, it contains several routing fixes, compared to rc7
In other words, the 7.1 is a exact copy (as there is changelog between) of 7.1rc7, as the same well reported bugs are still here...
7.1 shows connection uptime and works with interface names.- display of connection uptime or time of last reconnection
- use of interface name as update source (in addition to a specified IP)
Impressive changelog – nice to see all the new stuff in one place!I think that everyone would be happy to have, somewhere the full changelog, because sometimes, there is some "edge-case" that may affect someone and that person could see if this was solved...
no, like Sergejs clearly wrote, it contains several routing fixes, compared to rc7
Since it is not possible to guess what problem you are referring to, all I can say is that even rc7 compared to rc6 had OSPF fixes, and 7.1 compared to rc7 includes even more OSPF fixes.Our problems are mainly related to the OSPF issues in rc6
Tested local.address with interface name and it works.7.1 shows connection uptime and works with interface names.- display of connection uptime or time of last reconnection
- use of interface name as update source (in addition to a specified IP)
Thanks mrz for clarifying even more OSPF fixes is there. I think our main problem was with large LS updates since the issue with the routers next to a rebooting one getting unstable is gone since rc7.Since it is not possible to guess what problem you are referring to, all I can say is that even rc7 compared to rc6 had OSPF fixes, and 7.1 compared to rc7 includes even more OSPF fixes.
!) updated Linux Kernel based on version 5.6.3;
!) completely new NTP client and server implementation;
!) completely new User Manager implementation;
!) merged individual packages, only bundle and a few extra packages remain;
!) new Command Line Interface (CLI) style (RouterOS v6 commands are still supported);
!) support for Let's Encrypt certificate generation;
!) support for REST API;
!) support for UEFI boot mode on x86;
!) completely new ...
!) completely new ...
!) completely new ...
!) completely new ...
!) completely new ...
. . .
. . .
Look more more closely, /routing/bgp/session has "uptime" parameter.Connection uptime is nowhere to be found...
Ah I just edited it: it apparently only exists in commandmode... not very useful, would like to see this in the winbox peer cache overview.Look more more closely, /routing/bgp/session has "uptime" parameter.Connection uptime is nowhere to be found...
And regarding received prefix count, it will be added eventually, but if you really need to see how many prefixes are received then there is a workaround you can /routing/route/print count-only where received-from="...."
"Crossfig" works like magic when you upgrade from V6 to V7 - changing any config from V6 to V7 version. This includes most of the /routing/filters, which have a radically different way of working in V7, and generally pretty complex config to start..."Filters
Convert routing filters after upgrade from v6.x"
This is true? Has anyone tested it? Does it work exactly?
dynamic-in route rules, as stated previously. Functionality is gone in V7 - essentially what was a working config in V6 won't work V7. That ain't specifically "crossfig" problem, but a factor someone like to consider BEFORE upgrading.It would be nice to know what are those 5% that did not convert properly in your config?
/ip firewall filter add chain=separator comment="--- input chain above ---" disabled=yes
I'll second this....y'all don't get enough credit. It's very exciting times!Thanks for getting this out in 2021 MikroTik!
I know sometimes it probably feels like all you get is negative feedback but the pace of development has really stepped up for v7 and it is both noticed and appreciated :)
I actually don't want to look at the source – if I did I could run OpenWRT et'll on something with a Wi-Fi 6 chip. I do think Mikrotik does an EXCELLENT job at putting common interface over all the services, while still curating what are no doubt a lot of custom drivers/hardware – certainly work we'd rather not do ourselves. So I accept that means there might be incomplete features over the latest Linux builds & RFC/IEEE protocols. In fact, the main think I like ROS table-driven – in fact I describe is like putting SQL over OpenWRT.I would expect that to be a table-driven system and it would be best when it is a single table were a cmdline addition has some winbox and webfig definition as well...
WiFi devices with at least 256MB RAM:Quite a lot of devices will lack new stack.!) completely new alternative wireless package "wifiwave2" with 802.11ac Wave2, WPA3 and 802.11w management frame protection support (requires ARM CPU and 256MB RAM);
I have tested with the interface names, but it does not work properly.7.1 shows connection uptime and works with interface names.
Yeah, you forgot to mention the FREE DISK SPACE requirement.WIRELESS
----------------------
!) completely new alternative wireless package "wifiwave2" with 802.11ac Wave2, WPA3 and 802.11w management frame protection support (requires ARM CPU and 256MB RAM);
----------------------
No, read the requirements more carefully (from the help site):WiFi devices with at least 256MB RAM:
Quite a lot of devices will lack new stack.
hAP ac3
Audience
Chateau
RB4011
SXTsq 5 ac
LDF 5 ac
DISC Lite5 ac
LHG XL 5 ac
NetMetal ac²
Cube 60G ac
I'm not sure there's that many missing, apart from cAP ac and wAP ac, and hAP ac2?
/ip smb users
add name=guest
add name=guest
They'll likely point to https://help.mikrotik.com/docs/display/ROS/RouterOS – but the better question is what's the status of them, some look incomplete IMO WRT V7.Ok, one more time: when and where are the docs for 7.1 to be found?
They'll likely point to https://help.mikrotik.com/docs/display/ROS/RouterOS – but the better question is what's the status of them, some look incomplete IMO WRT V7. Some of this causes unnecessary posting in the forum, to find out answer that should just be documented....
/routing/pimsm/igmp-interface-template> print
That is an interesting observation - it may be related to a problem I have reported to MikroTik before. Did you get this issue after upgrade for sure? Or could it have been introduced by another change? And what was your previous version?After upgrading my RB4011 home router, SSH sessions to remote servers don't work. To make them work again, I have to set on the SSH client another IPQoS (e.g. cs1). Is it normal?
You should put that in the release notes / what's new message shown on package upgrade!We know you guys are as much hyped as we are for this release! As much as we appreciate your passion about your particular needs and bugs fixed as soon as possible, note that RouterOS v7 is still actively being developed in most parts and is not a direct replacement for RouterOS v6 yet. We highly value every feedback received and can assure you that every single post you make in RouterOS version release topics is read by MikroTik staff and taken in account.
I have hAP ac^2 with 256 MB RAM as mentioned and required. But I still can not install due to bulky wifi wave2 installation file. :-)WIRELESS
----------------------
!) completely new alternative wireless package "wifiwave2" with 802.11ac Wave2, WPA3 and 802.11w management frame protection support (requires ARM CPU and 256MB RAM);
----------------------
Totally don't want to mare the accomplishments in V7 and no doubt the long push it's taken on Mikrotik's end – easy to write about a problem, it's much hard to fix the code.You should put that in the release notes / what's new message shown on package upgrade!We know you guys are as much hyped as we are for this release! As much as we appreciate your passion about your particular needs and bugs fixed as soon as possible, note that RouterOS v7 is still actively being developed in most parts and is not a direct replacement for RouterOS v6 yet. We highly value every feedback received and can assure you that every single post you make in RouterOS version release topics is read by MikroTik staff and taken in account.
That is what people read who try a testing version upgrade...
Due to the fact that we have made a huge progress in RouterOS v7 stability, we have decided to release it in the testing channel. Please test it where you can and report your feedback on this forum page or send an e-mail to support@mikrotik.com.
We need some outdoor equipment that will be supported. rb922 and rbM11 are unfortunately not supported :(CAPsMAN does not support WW2 at the moment.
Note that WW2 is planned for future devices, that's why there are additional requirements in terms of hardware.
Yes, the issue is 100% related to upgrade, from version 6.49.1 to 7.1. I didn't change any setting after the upgrade.That is an interesting observation - it may be related to a problem I have reported to MikroTik before. Did you get this issue after upgrade for sure? Or could it have been introduced by another change? And what was your previous version?
Don't take me wrong, but this has to be said clearly for RB5009, because there is no 6.x Version ...note that RouterOS v7 is still actively being developed in most parts and is not a direct replacement for RouterOS v6 yet.
Well that's one way to disappoint the Chateau owners.No, read the requirements more carefully (from the help site):
WiFi devices with at least 256MB RAM:
hAP ac3
Audience
Chateau
RB4011
SXTsq 5 ac
LDF 5 ac
DISC Lite5 ac
LHG XL 5 ac
NetMetal ac²
Cube 60G ac
I'm not sure there's that many missing, apart from cAP ac and wAP ac, and hAP ac2?
Requirements
The wifiwave2 package is compatible with IPQ4019 and QCA9984 wireless interfaces and is only available for ARM builds of RouterOS v7. It also requires 14MB of free space and at least 256MB of RAM.
As of the release of RouterOS 7.1, this means it is compatible with 4 devices:
hAP ac³ (non-LTE)
Audience*
Audience LTE6 kit*
RB4011iGS+5HacQ2HnD**
* The wifiwave2 package is not compatible with CAPsMAN. And does not yet offer wireless meshing (4-address mode).
** The 2.4GHz wireless interface on the RB4011iGS+5HacQ2HnD is not compatible with the wifiwave2 package. It will not be usable with the package installed.
Calling the RB4011 compatible is a bit stressing the reality, I think. So that leaves only hAP ac3 and Audience.
My goodness. Finally someone seems like has problem with socks5 like me.(SUP-61733) socks 5 does not work with authorization.
++Please add:
- "Old style" routing filters add (like v6), not only syntax
- BFD (for OSPF and BGP)
- MPLS Fast-Path
- BGP session show number of prefix
Thanks MK.
Or the cAP ac XL buyers.Well that's one way to disappoint the Chateau owners.
No, read the requirements more carefully (from the help site):
Requirements
The wifiwave2 package is compatible with IPQ4019 and QCA9984 wireless interfaces and is only available for ARM builds of RouterOS v7. It also requires 14MB of free space and at least 256MB of RAM.
As of the release of RouterOS 7.1, this means it is compatible with 4 devices:
hAP ac³ (non-LTE)
Audience*
Audience LTE6 kit*
RB4011iGS+5HacQ2HnD**
* The wifiwave2 package is not compatible with CAPsMAN. And does not yet offer wireless meshing (4-address mode).
** The 2.4GHz wireless interface on the RB4011iGS+5HacQ2HnD is not compatible with the wifiwave2 package. It will not be usable with the package installed.
Calling the RB4011 compatible is a bit stressing the reality, I think. So that leaves only hAP ac3 and Audience.
Routing config cannot be upgraded if any other older v7 version was already installed previously. Config is converted only once.Unfortunately, neither BGP settings nor filters are converted to ROSv7
Yes, for the first time these devices were updated from 6.48.5 long-term to ROSv7.1 (testing), BGP parameters were not converted on any device, and also, when trying to register them, the devices simply stopped responding, did not hang, namely did not accept either template or peerRouting config cannot be upgraded if any other older v7 version was already installed previously. Config is converted only once.
➜ ~ iperf3 -u -b 200M -c iperf.scottlinux.com
Connecting to host iperf.scottlinux.com, port 5201
[ 7] local 192.168.0.249 port 62324 connected to 45.33.39.39 port 5201
[ ID] Interval Transfer Bitrate Total Datagrams
[ 7] 0.00-1.00 sec 23.8 MBytes 200 Mbits/sec 17255
[ 7] 1.00-2.00 sec 23.8 MBytes 200 Mbits/sec 17267
[ 7] 2.00-3.00 sec 23.7 MBytes 199 Mbits/sec 17163
[ 7] 3.00-4.00 sec 21.7 MBytes 182 Mbits/sec 15697
[ 7] 4.00-5.00 sec 24.4 MBytes 204 Mbits/sec 17654
[ 7] 5.00-6.00 sec 25.1 MBytes 210 Mbits/sec 18167
[ 7] 6.00-7.00 sec 23.9 MBytes 201 Mbits/sec 21984
[ 7] 7.00-8.00 sec 15.7 MBytes 132 Mbits/sec 18162
[ 7] 8.00-9.00 sec 27.3 MBytes 229 Mbits/sec 22112
[ 7] 9.00-10.00 sec 25.8 MBytes 216 Mbits/sec 89795
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 7] 0.00-10.00 sec 235 MBytes 197 Mbits/sec 0.000 ms 0/255256 (0%) sender
[ 7] 0.00-10.26 sec 219 MBytes 179 Mbits/sec 0.060 ms 51430/210322 (24%) receiver
iperf Done.
➜ ~ iperf3 -u -b 100M -c iperf.scottlinux.com
Connecting to host iperf.scottlinux.com, port 5201
[ 7] local 192.168.0.249 port 64466 connected to 45.33.39.39 port 5201
[ ID] Interval Transfer Bitrate Total Datagrams
[ 7] 0.00-1.00 sec 11.9 MBytes 99.9 Mbits/sec 8628
[ 7] 1.00-2.00 sec 11.9 MBytes 100 Mbits/sec 8634
[ 7] 2.00-3.00 sec 11.9 MBytes 100 Mbits/sec 8634
[ 7] 3.00-4.00 sec 11.6 MBytes 97.4 Mbits/sec 8409
[ 7] 4.00-5.00 sec 12.2 MBytes 103 Mbits/sec 8859
[ 7] 5.00-6.00 sec 11.9 MBytes 100 Mbits/sec 8635
[ 7] 6.00-7.00 sec 11.9 MBytes 100 Mbits/sec 8634
[ 7] 7.00-8.00 sec 11.9 MBytes 100 Mbits/sec 8635
[ 7] 8.00-9.00 sec 11.9 MBytes 100 Mbits/sec 8634
[ 7] 9.00-10.00 sec 11.9 MBytes 100 Mbits/sec 8633
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 7] 0.00-10.00 sec 119 MBytes 100 Mbits/sec 0.000 ms 0/86335 (0%) sender
[ 7] 0.00-10.04 sec 119 MBytes 99.3 Mbits/sec 0.126 ms 241/86334 (0.28%) receiver
the future from now on. cap xl ac was not a future device. it was just a XL version of some old existing model.What about the cAP XL ac, it was lauched months ago, after the wifiwave2 was around?CAPsMAN does not support WW2 at the moment.
Note that WW2 is planned for future devices, that's why there are additional requirements in terms of hardware.
nonsense. nonreasonable.Routing config cannot be upgraded if any other older v7 version was already installed previously. Config is converted only once.Unfortunately, neither BGP settings nor filters are converted to ROSv7
I have a ticket open regarding this: SUP-63430After upgrading my RB4011 home router, SSH sessions to remote servers don't work. To make them work again, I have to set on the SSH client another IPQoS (e.g. cs1). Is it normal?
[admin@MikroTik] /system package> print
Flags: X - disabled
# NAME VERSION SCHEDULED
0 ipv6 6.49.1
1 dhcp 6.49.1
2 advanced-tools 6.49.1
3 system 6.49.1
4 routing 6.49.1
5 multicast 6.49.1
6 security 6.49.1
7 wireless 6.49.1
I have a ticket open for DSCP trouble on the RB4011 as well! It is SUP-64360. I thought it is related to the complicated stack of interfaces, just like yours: internet connection via PPPoE over 802.1p/q VLAN (where I use DSCP to set the 802.1p priority for use by my VDSL modem), then on that internet connection I use GRE/IPsec tunnels with "inherit DSCP", now certain DSCP values in traffic are dropped. I can work around the problem by resetting DSCP to zero at the end of the mangling.I have a ticket open regarding this: SUP-63430After upgrading my RB4011 home router, SSH sessions to remote servers don't work. To make them work again, I have to set on the SSH client another IPQoS (e.g. cs1). Is it normal?
Support is saying they cannot reproduce it.
My debugging so far tells me this has something to do with the DSCP value of packets as there are a number of devices in my house that start to fail when this bug is present. These are mostly VoIP and Video Conferencing devices that use non-default DSCP values.
+1I really wish there was a wifiwave2 "light" package to be installed on early hap ac2 revisions with 256 MB RAM. Free disk space is the only thing preventing it.
[admin@rw01] > /system/resource/print
uptime: 4m48s
version: 7.1 (testing)
build-time: Dec/01/2021 14:07:27
free-memory: 24.7MiB
total-memory: 64.0MiB
cpu: MIPS 24Kc V7.4
cpu-count: 1
cpu-frequency: 650MHz
cpu-load: 9%
free-hdd-space: 4000.0KiB
total-hdd-space: 16.0MiB
write-sect-since-reboot: 54
write-sect-total: 4664
bad-blocks: 0%
architecture-name: mipsbe
board-name: mAP lite
platform: MikroTik
You will have to netinstall it. Upgrading from separate packages (not the bundled package) to v7 (or to v6.xx bundled package, for that matter) does not work on small devices!hAP Lite stuck in "calculating download size..." since hours.
A reboot didnt help.
How did you configure that? There are of course several ways to do it. I think configuring the vlan in the wireless interface settings is being deprecated.My hAP ac2 that I use as ap after the upgrade from 7.1rc7 now fowards every single vlan traffic to the wireless interfaces
I use the hAP ac2 as a switch as well, but, I cannot use vlan-filtering because my IPTV traffic will not work properly (it pass through it), so I've configured each wlan interface withHow did you configure that? There are of course several ways to do it. I think configuring the vlan in the wireless interface settings is being deprecated.My hAP ac2 that I use as ap after the upgrade from 7.1rc7 now fowards every single vlan traffic to the wireless interfaces
I use a vlan-filtering bridge with the wifi interfaces as untagged ports on the VLANs and the appropriate PVID and the ports. It appears to work.
vlan-id=110 vlan-mode=use-tag
No, RB5009 fails. CCR2004 works.Doest this testing version fix the DHCP-PD over PPPoE VLAN interface?
A lot of the V7 stuff is in the the newer help.mikrotik.com site, than the now older wiki, including VRRP:> !) support for VRRP grouping and connection tracking data synchronization between nodes;
Can anyone shape a example (may be config) that features?
HiYou will have to netinstall it. Upgrading from separate packages (not the bundled package) to v7 (or to v6.xx bundled package, for that matter) does not work on small devices!hAP Lite stuck in "calculating download size..." since hours.
A reboot didnt help.
This is why you should before upgrade.Im wondering why the upgrade is then offered ? It should not be offered at all then.
v7.1 [testing] is released!
Port 1-5 are gigabit2011UiAS-2HnD here, all ports 6-10 are now only negotiate at 100mbit.
You have to download the package yourself and upload it to your HAP and then reboot.You will have to netinstall it. Upgrading from separate packages (not the bundled package) to v7 (or to v6.xx bundled package, for that matter) does not work on small devices!hAP Lite stuck in "calculating download size..." since hours.
A reboot didnt help.
Or perhaps problem in how ROS configures RTL8367 switch chip? Handling of switch chip has been vastly improved in v7 (previously that switch chip was next to useless as a piece of hardware), but it's likely there's room for improvement.Reading what you write above, it appears to be the same bug! Affects the RB4011 under 6.x and 7.x, does not affect the RB2011 and likely also not the TILE and MMIPS architectures as I use similar setups on routers of those architectures and I never encountered a problem.
It seems to be an architecture bug (endianness, alignment, compiler bug, ...) not a v7.1 bug.
Yep, still a problem on the RB5009No, RB5009 fails. CCR2004 works.Doest this testing version fix the DHCP-PD over PPPoE VLAN interface?
That would be the method that should work, but it doesn't. It works only on devices with more than 16MB Flash. Reported to MikroTik some time ago, they would investigate. But to fix it, they would first have to release a new 6.49.x version that includes the fix and that you could install as an upgrade, and only then the upgrade to a combined package (and thus also to v7.1) would succeed.You have to download the package yourself and upload it to your HAP and then reboot.
You will have to netinstall it. Upgrading from separate packages (not the bundled package) to v7 (or to v6.xx bundled package, for that matter) does not work on small devices!
This could be related to the issue with DSCP in combination with PPPoE over VLAN described above.Yep, still a problem on the RB5009
No, RB5009 fails. CCR2004 works.
which version is actually stable, from all RouterOS versions?So, are we gonna see 7.x in a stable channel by the end of q1 2022?
I am not meaning that it will be actually stable, just released in a 'stable' channel.
hi mr normiswhich version is actually stable, from all RouterOS versions?So, are we gonna see 7.x in a stable channel by the end of q1 2022?
I am not meaning that it will be actually stable, just released in a 'stable' channel.
6.48.4 and 6.47.10 were rock solid for me. Credit where credit is due. You at MIkrotik do make nice equipment for cheap, despite the occasional problem.which version is actually stable, from all RouterOS versions?So, are we gonna see 7.x in a stable channel by the end of q1 2022?
I am not meaning that it will be actually stable, just released in a 'stable' channel.
7.1 has been stable since yesterday for me on several boxes :)which version is actually stable, from all RouterOS versions?
The problem occurs in v6 as well. But you are right, it could be in the switch chip. I have no explicit config for it, I run a vlan-aware bridge on ports 2-10 and have ether1 outside of that bridge, a VLAN stacked on top of that, and PPPoE on that.Or perhaps problem in how ROS configures RTL8367 switch chip? Handling of switch chip has been vastly improved in v7 (previously that switch chip was next to useless as a piece of hardware), but it's likely there's room for improvement.It seems to be an architecture bug (endianness, alignment, compiler bug, ...) not a v7.1 bug.
Workaround to put VLAN interface over switch instead of dedicated port is working.Yep, still a problem on the RB5009
No, RB5009 fails. CCR2004 works.
Netinstall is the only way to comfortably upgrade a hAP Lite or Mini for testing purposes.hAP Lite stuck in "calculating download size..." since hours.
A reboot didnt help.
Current packages
Code: Select all[admin@MikroTik] /system package> print Flags: X - disabled # NAME VERSION SCHEDULED 0 ipv6 6.49.1 1 dhcp 6.49.1 2 advanced-tools 6.49.1 3 system 6.49.1 4 routing 6.49.1 5 multicast 6.49.1 6 security 6.49.1 7 wireless 6.49.1
+1I really wish there was a wifiwave2 "light" package to be installed on early hap ac2 revisions with 256 MB RAM. Free disk space is the only thing preventing it.
Nice that you narrowed it down to that! I reported the bug, of course got "we cannot reproduce it", but maybe they tried to reproduce it on a wired device?On devices with only 16M of flash I always use the minimum packages needed. The upgrade worked on most devices, but any with the wireless package installed it failed with the space error.
That would have to be both ARM and ARM64 because the RB4011 is 32 bit and the RB5009 is 64 bit.This problem appears to occur only in the ARM architecture, I bet that when you copy your entire config to a RB2011 or CCR1009 it will work just fine.
The actual issue here is the multicast package. It's from the extras zip. Remove the multicast package and it should upgrade.Netinstall is the only way to comfortably upgrade a hAP Lite or Mini for testing purposes.hAP Lite stuck in "calculating download size..." since hours.
A reboot didnt help.
Current packages
Code: Select all[admin@MikroTik] /system package> print Flags: X - disabled # NAME VERSION SCHEDULED 0 ipv6 6.49.1 1 dhcp 6.49.1 2 advanced-tools 6.49.1 3 system 6.49.1 4 routing 6.49.1 5 multicast 6.49.1 6 security 6.49.1 7 wireless 6.49.1
My RB941s reboot after 24 hours running anything v7, so mine are on long-term.
Does it have the separate packages instead of the routeros bundle package with sub-packages under it?Tried to install 7.1 on wAP R ac r2 with 256MB ram. This AP have 2392 kB free HDD space but got "not enouth space for upgrade".
HiThe actual issue here is the multicast package. It's from the extras zip. Remove the multicast package and it should upgrade.
Netinstall is the only way to comfortably upgrade a hAP Lite or Mini for testing purposes.
My RB941s reboot after 24 hours running anything v7, so mine are on long-term.
7.1 can only be upgraded if no extra packages are installed.
CCR1009, RB4011 also work fine. It’s only on RB5009. As the ccr2004-1g-12s+2xs without a switch chip works fine, I guess it’s more a problem with the RB5009 switch.This could be related to the issue with DSCP in combination with PPPoE over VLAN described above.
Yep, still a problem on the RB5009
For me, the DCHPv6-PD over PPPoE over VLAN works, on a RB4011. But DSCP-marked traffic over PPPoE over VLAN (certain DSCP values) does not.
Maybe in your case the DHCPv6-PD traffic (I think that also has a DSCP marking by default) falls victim to that.
This problem appears to occur only in the ARM architecture, I bet that when you copy your entire config to a RB2011 or CCR1009 it will work just fine.
I tried that workaround but it does not seem to solve it for me...The bug appears (on my device) when the Internet connection is a PPPoE connection that sits on top of a VLAN interface. The problem goes away if I create a bridge and let it handle the VLAN tagging by placing only the ether1 interface, which is connected to my ISP's ONT, as tagged onto the bridge and then point the PPPoE interface to that bridge.
Look more more closely, /routing/bgp/session has "uptime" parameter.Connection uptime is nowhere to be found...
And regarding received prefix count, it will be added eventually, but if you really need to see how many prefixes are received then there is a workaround you can /routing/route/print count-only where received-from="...."
> /routing/route/print count-only where received-from bgp
0
Thanks! I changed my configuration with the bridge, and this issue is fixed. I remark that I didn't have this problem with any 6.x release, so, at least for my case, it is a "v7" only bug. Nevertheless, I opened a support ticket, attaching the supout.rif file related to the "old" setup, and referencing your bug report. While I understand that probably the "MikroTik suggested" way to configure is using a bridge instead of a VLAN interface, this is still a big issue, that many other users may experience as well when they upgrade to v7.I have a ticket open regarding this: SUP-63430
Support is saying they cannot reproduce it.
My debugging so far tells me this has something to do with the DSCP value of packets as there are a number of devices in my house that start to fail when this bug is present. These are mostly VoIP and Video Conferencing devices that use non-default DSCP values.
I have an Excel sheet of the DSCP values that work and the DSCP values that don't that I have provided to support.
The bug appears (on my device) when the Internet connection is a PPPoE connection that sits on top of a VLAN interface. The problem goes away if I create a bridge and let it handle the VLAN tagging by placing only the ether1 interface, which is connected to my ISP's ONT, as tagged onto the bridge and then point the PPPoE interface to that bridge. Note that you will lose hardware acceleration on that particular interface for this bridge then if you set it up that way.
The problem also goes away when letting an external switch handle the VLAN tagging.
Since support cannot reproduce the problem and I have given them all the detailed information about my findings on both RB5009 and RB4011 I was able to dig up, I have decided to no longer pursue a fix for this bug and stick to the workaround using the bridge, as I don't think it is worth my time at this point.
I think it may be related to the problem that people are seeing with using a DHCPv6 client on top of a PPPoE connection that requires VLAN tagging.
Feel free to open a ticket with support and reference my ticket number above. Maybe the scenario you have is easier for them to reproduce than mine.
Please implement a similar route targets from Cisco to VRF-Lite.https://help.mikrotik.com/docs/display/ ... col+Status
Some kind of mechanism to import/export routes from one vrf to another within same router. N/A
Did you put your PPPoE VLAN on the same bridge as your LAN? I made a new bridge with only ether1 as a port, and experimented with some differentThanks! I changed my configuration with the bridge, and this issue is fixed.
No, I created a new bridge. This is part of my configuration:Did you put your PPPoE VLAN on the same bridge as your LAN?
/interface bridge
add name=bridge-lan
add name=bridge-wan pvid=835 vlan-filtering=yes
/interface pppoe-client
add add-default-route=yes disabled=no interface=bridge-wan name=pppoe0 user=username
/interface bridge port
add bridge=bridge-lan ingress-filtering=no interface=ether2
add bridge=bridge-lan interface=wifi1
add bridge=bridge-wan interface=ether1
/interface bridge vlan
add bridge=bridge-wan tagged=ether1 untagged=bridge-wan vlan-ids=835
It doesn't work at all
Look more more closely, /routing/bgp/session has "uptime" parameter.
And regarding received prefix count, it will be added eventually, but if you really need to see how many prefixes are received then there is a workaround you can /routing/route/print count-only where received-from="...."
It doesn't work.
Code: Select all> /routing/route/print count-only where received-from bgp 0
> /routing/route/print count-only where received-from static
0
> /routing/route/print count-only where received-from dhcp
0
system/resource/print
uptime: 5h36m25s
version: 7.1 (testing)
build-time: Dec/01/2021 14:07:27
factory-software: 7.0.4
free-memory: 812.5MiB
total-memory: 1024.0MiB
cpu-count: 4
cpu-frequency: 1400MHz
cpu-load: 3%
free-hdd-space: 991.6MiB
total-hdd-space: 1025.0MiB
write-sect-since-reboot: 2183
write-sect-total: 3004
bad-blocks: 0%
architecture-name: arm64
board-name: RB5009UG+S+
platform: MikroTik
I am also seeing the same problem.I saw my ccr1009 had 95+% utilization on 4 cores (represented as "networking" in the profile tool) and l2tp/ipsec (looked more like an ipsec issue) would not connect as a client. A reboot had everything back to normal.
I did not get a supout.rif, but I will get one if I see the issue again.
interface/6to4/add name=6to4
ipv6/address/add interface=6to4 address=2002:101:101::1/16
ping 2002:1::1
Also lost access to my SD card.Looks like I lost access to SD cards on my CCR1009 with this release. My existing sd card is not visible and a new card is also not visible.
無題.pngI saw my ccr1009 had 95+% utilization on 4 cores (represented as "networking" in the profile tool) and l2tp/ipsec (looked more like an ipsec issue) would not connect as a client. A reboot had everything back to normal.
I did not get a supout.rif, but I will get one if I see the issue again.
I am also seeing the same problem.
In my environment, restarting CCR1009 did not improve the CPU usage.
If I could migrate my entire environment to WireGuard, that would certainly solve the problem.
無題.png
I am also seeing the same problem.
In my environment, restarting CCR1009 did not improve the CPU usage.
Same here, I disabled ipsec and some routing filters that were migrated over, and everything is OK for now. Before that a reboot would help for a little, but then the IPSec connection would die and 8 of the 9 cores would be at 100%.
I've moved my IPSec connection to Wireguard and the problem hasn't come back. But clearly there is something wrong I've just been able to avoid it.
If I could migrate my entire environment to WireGuard, that would certainly solve the problem.
Same here, I disabled ipsec and some routing filters that were migrated over, and everything is OK for now. Before that a reboot would help for a little, but then the IPSec connection would die and 8 of the 9 cores would be at 100%.
I've moved my IPSec connection to Wireguard and the problem hasn't come back. But clearly there is something wrong I've just been able to avoid it.
But circumstances make it difficult to migrate all IPsec connections to WG right away.
However, it is worth considering moving to WG earlier in the schedule.
Have it running on mAP with mAPlite as cap in lab setup.Did anyone try to use capmans on v7.1? I am trying to get it working but with no joy. Have v7.1 on router
[admin@R1] /routing/ospf/neighbor> /ip address/print
Columns: ADDRESS, NETWORK, INTERFACE
# ADDRESS NETWORK INTERFACE
0 10.20.0.0/31 10.20.0.0 ether4
1 10.100.0.1/32 10.100.0.1 BR0
[admin@R1] /routing/ospf/neighbor> /routing/ospf/neighbor/print
Flags: V - virtual; D - dynamic
0 D instance=OSPF-INST-DEFAULT area=0.0.0.0 address=10.20.0.1 priority=128 router-id=10.100.0.2 dr=10.20.0.1 bdr=10.20.0.0 state="Exchange" state-changes=4 timeout=37s
[admin@R1] /routing/ospf/neighbor> /routing/ospf/export
# dec/04/2021 07:57:06 by RouterOS 7.1
# software id =
#
/routing ospf instance
add name=OSPF-INST-DEFAULT
/routing ospf area
add instance=OSPF-INST-DEFAULT name=0.0.0.0
/routing ospf interface-template
add area=0.0.0.0 networks=0.0.0.0/0
ospf neighbor reset func does not work also:Code: Select all[admin@R2] /routing/ospf/neighbor> /ip address/print Columns: ADDRESS, NETWORK, INTERFACE # ADDRESS NETWORK INTERFACE 0 10.20.0.1/31 10.20.0.0 ether4 1 10.100.0.2/32 10.100.0.2 BR0 [admin@R2] /routing/ospf/neighbor> /routing/ospf/neighbor/print Flags: V - virtual; D - dynamic 0 D instance=OSPF-INST-DEFAULT area=0.0.0.0 address=10.20.0.0 priority=128 router-id=10.100.0.1 dr=10.20.0.1 bdr=10.20.0.0 state="ExStart" state-changes=3 timeout=35s [admin@R2] /routing/ospf/neighbor> /routing/ospf/export # dec/04/2021 07:57:28 by RouterOS 7.1 # software id = # /routing ospf instance add name=OSPF-INST-DEFAULT /routing ospf area add instance=OSPF-INST-DEFAULT name=0.0.0.0 /routing ospf interface-template add area=0.0.0.0 networks=0.0.0.0/0
[admin@R2] /routing/ospf/neighbor> /routing/ospf/neighbor reset [find ]
no such item (4)
Read https://help.mikrotik.com/docs/display/ ... col+StatusOSPF on /31 does not work:
That I can do if wanted but will we get support from the mikrotik guys? :) would really love to get this one up and runningHave it running on mAP with mAPlite as cap in lab setup.Did anyone try to use capmans on v7.1? I am trying to get it working but with no joy. Have v7.1 on router
Maybe best to make separate post (provide link here) in order not to loose all info in this one.
Then others can also inspect in detail your config.
Nope.Capsman Support in wifiwave2?
/tool e-mail send to="someone@somedomain.tld" subject="Failover is UP" body="Main ISP failed..." tls=yes
Error sending e-mail <Failover is UP>: TLS handshake failed
Do 6.x RouterOS work fine with this? If yes, send an email to support@microtik.comThere is problem with sending e-mails from router in Netwatch tool (Up and Down scripts)
Error sending e-mail <Failover is UP>: TLS handshake failed
I don't know if it works on 6.x... I'm using RB5009.Do 6.x RouterOS work fine with this? If yes, send an email to support@microtik.com
From WikiNotice in the v7.1 "extra-packages" there is one for "LTE". I have never installed, and LTE generally works, does the "extra" package for LTE do anything or is needed for v7.1?
Required package only for SXT LTE (RBSXTLTE3-7), which contains drivers for the built-in LTE interface.
So did it work in any 7.1rcX? If not, it does not belong here - this thread is for release specific issues.I don't know if it works on 6.x... I'm using RB5009.Do 6.x RouterOS work fine with this?
With 6.x it was start-tls=yes, now the option is tls=starttlsThere is problem with sending e-mails from router in Netwatch tool (Up and Down scripts)
Sending from Terminal is OK
The same command in Netwatch, tab Up and Down says:Code: Select all/tool e-mail send to="someone@somedomain.tld" subject="Failover is UP" body="Main ISP failed..." tls=yes
Code: Select allError sending e-mail <Failover is UP>: TLS handshake failed
No, it will not.If I use "wifiwave2" on RB4011 2.4 GHz will still be available, right?
Here it works OK! I get 3 lines for resources (CPU, memory and disk) plus 33 lines for my interface graphs.Can confirm that http://10.10.10.225/graphs/ only gives one line with:
Traffic and system resource graphing
Users are allowed to hawk their third-party wares in the official forum?
from long-term to beta? are you crazy man? are you crazy?Hello
upgraded from latest LTS to 7.1
the BGP router doesnt advertise local connected routes neither default route.
any setting that I am overlooked?
Just a plain BGP session:
a) from CORE ROUTER (with the defaut route) - the CCR receives correctly default route
b) to customers, it doesnt propagate neither local connected routes, neither default route.
6.49.2 is also fine.Downgraded to 6.48.5 and everything works.
I am not able to let the 1036 propagate nor default route nor local connected routes.
I do have BGP working on my home router. I cannot test propagation of default route on this, but I can see that it receives a default route via BGP (multiple paths) and selects it based on local pref and distance.I am not able to let the 1036 propagate nor default route nor local connected routes.
The problem is, Mikrotik try to be enterprise or ISP aimed vendor, not home-toys producer. And waiting for years for 7.0 upcoming (yes, it rotates to 7.1 without 7.0 stable release at all!) and getting only version rename instead of stabilizing of current feature set seems to be not what serious guys are used to do.Sure there are some limitations of the new BGP implementation (no "redistribute connected", distribution via "bgp networks" now always has synchronize=yes) but for the purpose of routing my local networks to the rest of the network (which is still running v6) it works OK.
whatever.When you feel better at home at such a company, please go buy there and do not bother yourself with using MikroTik!
7.1rc7 was latest in testing. 7.1 has fixes confirmed in OSPF from the 7.1rc7 so its not a rename.So please comment if 7.x in "testing" branch is more stable that it was in "development", or we can consider testing to be new "not to expect to be stable soon"?
Git repo: /home/oxidized/.config/oxidized/devices.git
Git commit ID: 5d0e552803905a28fc4abf390d8abaf32dcc4a43
diff --git a/x.x.x.x b/x.x.x.x
index f5d732d..a92890c 100644
--- a/x.x.x.x
+++ b/x.x.x.x
@@ -104,10 +104,12 @@ set allow-guests=no
add comment="default share" directory=/pub name=pub
add comment="default share" directory=/pub name=pub
add comment="default share" directory=/pub name=pub
+add comment="default share" directory=/pub name=pub
/ip smb users
add name=guest
add name=guest
add name=guest
+add name=guest
I would like to request a separate smaller wifiwave2-package for cAP ac, hAP ac2, ... i.e. all devices with IPQ4018/IPQ4019 chipsets which could be possible:Version 7.1 has been released.
WIRELESS
----------------------
!) completely new alternative wireless package "wifiwave2" with 802.11ac Wave2, WPA3 and 802.11w management frame protection support (requires ARM CPU and 256MB RAM);
----------------------
Sure there are some limitations of the new BGP implementation (no "redistribute connected"
[admin@MikroTik] /routing/bgp/connection> set 0 output.redistribute=connected
Please consider https://wiki.mikrotik.com/wiki/Manual:I ... Offloading RB4011's RTL8367 Switch Chips can't HW offload with (R)STP or MSTP enabled..I've upgraded my RB4011iGS+ to 7.1 and hoped to get hw offload for the bridge I'm using. So far no problems with the upgrade but looking at the bridge ports all of them are marked with "Hardware Offload": "yes" and "Hw. Offload": "no".
Are there any preconditions or configuration steps to make that work? My bridge is set to MSTP. Is that a problem?
In the switch ports section there is a "L3 Hw Offloading" checkbox on each port (incl. switch cpu ports). Does it need to be set? For all ports of a switch? Also for CPU?
Thanks for the heads-up! I still need to make sense of the miriads of (in my head) conflicting information.@drasir, please consider not reading outdated documentation
https://help.mikrotik.com/docs/display/ ... Offloading
BFD is working for BGP in v6 not sure why you say its not working.Thanks mrz for clarifying even more OSPF fixes is there. I think our main problem was with large LS updates since the issue with the routers next to a rebooting one getting unstable is gone since rc7.Since it is not possible to guess what problem you are referring to, all I can say is that even rc7 compared to rc6 had OSPF fixes, and 7.1 compared to rc7 includes even more OSPF fixes.
Ill start upgrading the 17 routers I have running ROS7. Ill also test if the oddness with 2004s where we almost cant reach them after an upgrade and needs 2 reboots more to make them work as normal is still there.
I think it was a good decision to featurefreeze and stabilize ROS7.1 although we look forward to BFD etc but that wasent working in 6.x anyway.
/M
Documentation should write what is the minimum required version. So if 6.41.1 is the minimum, it will stay with that number until some change and a higher version is required.Well, the problem is that those wiki and help sites do not separate documentation per RouterOS version.
BFD is working for BGP in v6 not sure why you say its not working.
Yes this would be awesomeIt might be useful to have "crossfig" as a separate tool so that it can be run on an exported v6 config to see what happens during conversion.
(either some executable or a service on the mikrotik.com account where you can paste a v6 export and see the v7 version)
That will be helpful during the next phase of deployment where we would do remote upgrades of routers without physical access.
I can confirm this since early 7.1beta. My fix since then is to disable CAPsMAN at boot for 30 seconds so the router comes up before the CAPs connect. Maybe you want to give it a try:I'm able to generate a kernel panic on a CCR2004-1G-12S+2XS (capsman controller) when I enable caps-mode on a 951Ui-2HnD. If I leave this enabled, the CCR is rebooting in a loop. Cap certificate was just generated, capsman controller is reached via IP, not discovery interface. There's nothing in the logs other than the kernel crash message.
I added a 941-2nD before, using the discovery interface, that works without causing a crash on the controller.
/system scheduler
add name=STARTUP-script on-event="/system/script/run STARTUP-script" policy=\
ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon start-time=startup
add comment="Script to be run at system startup" dont-require-permissions=no name=STARTUP-script \
owner=admin policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon source="/c\
aps-man/manager/set enabled=no\
\n/log info \"STARTUP: disabled CAPsMAN\"\
\n\
\n:delay 30s\
\n/log info \"STARTUP: enabled CAPsMAN\"\
\n/caps-man/manager/set enabled=yes"
That is a minimal requirement, but it would be preferred when there is some "search field" (probably a dropdown) where you can select a version and then all documentation you see is relevant to that version. Especially now that some features (like routing) are completely overhauled.Documentation should write what is the minimum required version. So if 6.41.1 is the minimum, it will stay with that number until some change and a higher version is required.Well, the problem is that those wiki and help sites do not separate documentation per RouterOS version.
Could it be device dependent because I do not see this on a mAP device in lab setup ?I can confirm this since early 7.1beta. My fix since then is to disable CAPsMAN at boot for 30 seconds so the router comes up before the CAPs connect. Maybe you want to give it a try:I'm able to generate a kernel panic on a CCR2004-1G-12S+2XS (capsman controller) when I enable caps-mode on a 951Ui-2HnD. If I leave this enabled, the CCR is rebooting in a loop. Cap certificate was just generated, capsman controller is reached via IP, not discovery interface. There's nothing in the logs other than the kernel crash message.
I added a 941-2nD before, using the discovery interface, that works without causing a crash on the controller.
I think I´ve found the reason for the problem and it seems to be really a bug in RouterOS.Since the update from 6.49.1 to 7.1 via "update" in the package menu I have a strange behavior on some fiber connections. I saw the same behavior in one of the older 6.48.x releases and it was gone with the update to 6.48.5, if I remember correctly. :-/
The connection is dropped on a regular base ~60min. (there are NO scheduled tasks or something similar).
The connection is established between a CRS328-24P-4S+ and a CRS326-24S+2Q+ via two 10G fiber cables bonded with the LACP protocol.
I never saw this behavior with 6.49(x), it startet after the update to 7.1 (testing).
The cables are 35m long and connected with S-31DLC10D-C GBics. Tries to change the "Rate select" to low didn´t change anything.
Any ideas how to solve this?
hc_211.jpg
hc_210.jpg
Jap , it´s not available anymoreDid they remove this release from the download now?
MikroTik support #[SUP-67963] ThanksStable means it has no known serious issues affecting large groups of people, like crashes. It does not mean there are all features you want. We continue to work on new features in 7.2 branch.
v6 is still stable and still available, it is not being replaced.
x86 crashes with reboot when you use multi-queue-ethernet-defautStable means it has no known serious issues affecting large groups of people, like crashes. It does not mean there are all features you want. We continue to work on new features in 7.2 branch.
v6 is still stable and still available, it is not being replaced.
I can understand that it does not include all features promised for a new version or being developed in test/beta/rc versions, but should it not include all features that were working in a previous stable version and that are not announced to be deprecated?Stable means it has no known serious issues affecting large groups of people, like crashes. It does not mean there are all features you want.
You should only move to v7 if all the needed features are there. A decision was made, that we will not hold v7 release for much longer, because so many people can already use it, and it works great for 90% of users. People with specific needs for specific functions can then test 7.2 or next releases, but those who don't need them, can safely use 7.1 now.
What about the bug related to wireguard that has been reported (both here in the forrum and multiple support tickets) since 7.1rc5-7 (was fine on rc4) that was completely ignored?Stable means it has no known serious issues affecting large groups of people, like crashes. It does not mean there are all features you want. We continue to work on new features in 7.2 branch.
v6 is still stable and still available, it is not being replaced.
Great. Will you fix MTU >1500 on sfpplus port of RB4011 now?You should only move to v7 if all the needed features are there. A decision was made, that we will not hold v7 release for much longer, because so many people can already use it, and it works great for 90% of users. People with specific needs for specific functions can then test 7.2 or next releases, but those who don't need them, can safely use 7.1 now.
system package update check-for-updates
channel: stable
installed-version: 6.49.1
latest-version: 6.49.2
status: New version is available
LTE works fine in v7, please make a separate post or contact support via our portal
Totally agree, V7 need to be go forward as it has lots of new features, Normis but I don't have backup now, as updated to 7.1 and LTE stop working.
please read posts above, before asking againWhy is 7.1 posted under stable release tree? https://mikrotik.com/download/changelog ... lease-tree
I don't understand your question. This topic is about v7Yea, thats not a stable release on CRS326Code: Select allsystem package update check-for-updates channel: stable installed-version: 6.49.1 latest-version: 6.49.2 status: New version is available
I think the questions regarding 6.49.2 is because the upgrade to 7 is to be done not via stable on 6.49.1 but via upgrade.Yea, thats not a stable release on CRS326Code: Select allsystem package update check-for-updates channel: stable installed-version: 6.49.1 latest-version: 6.49.2 status: New version is available
MikroTik support #[SUP-67963] also with 7.1rc7.rif and 7.1.rif and screenshots. ThanksLTE works fine in v7, please make a separate post or contact support via our portal
Totally agree, V7 need to be go forward as it has lots of new features, Normis but I don't have backup now, as updated to 7.1 and LTE stop working. :)
What do you mean exactly? That ethernet interface name that is part of broadcast network is specified as a gateway? It didn't work reliably in v6 also. You can use it only on point to point links.this rule is not working and says invalid, but same rule works in v6.x
i use this rule is to give separate pool for internet access to hotspot users
If he had a V7-only device like RB5009, that might page maybe true. But agree looks likes in wrong place on website.please read posts above, before asking againWhy is 7.1 posted under stable release tree? https://mikrotik.com/download/changelog ... lease-tree
@parscon: Was static route in PPPOE client working before in previous versions of ver7 RC X ???Static route does not works in PPPOE Client , It just works for 10 second and gone ! . current solution just it works with default route Checked in PPPOE-Client Connection , Need fix ASAP !
Every time i think Mikrotik can't fuck there release proces up any more they prove me wrong.To avoid accidental move to v7 from v6, a new channel was added. Use UPGRADE channel for this major upgrade, only if you are sure you are ready for it.
I did not check with RC just it was working without anyproblem in latest 6.XX version . I see just table version released as this reason upgrade but ... . what i can say this stable version acutally is not stable version . and better wait for few month to upgrade for 7.XX . now i must downgrade 40 router ASAP ... . :(@parscon: Was static route in PPPOE client working before in previous versions of ver7 RC X ???Static route does not works in PPPOE Client , It just works for 10 second and gone ! . current solution just it works with default route Checked in PPPOE-Client Connection , Need fix ASAP !
yes they work!hi all, with this version recursive routes work? with 7.1rc4 not working but with 6.x yes
They do work. v7 introduced a new limitation: target-scope of your route must be greater than target-scope of the route through which it should be resolved.hi all, with this version recursive routes work? with 7.1rc4 not working but with 6.x yes
It is already built in. When you do an in-pace upgrade of a router running v6 the rules will be update to v7.In general, do you plan any BGP filter converter from the 6th version to the 7th? At least a separate software?
Heh, I am not sure if I need to take a philosophy course or go to Hogwarts School of Magic to understand that sentence let alone MTs intentions. Never understood scope anyway (at least nothing sticks in my brain).They do work. v7 introduced a new limitation: target-scope of your route must be greater than target-scope of the route through which it should be resolved.hi all, with this version recursive routes work? with 7.1rc4 not working but with 6.x yes
And the problem is?Now there's TWO stable trees listed
Well, on the other hand for "home" users who have a NAT router and/or WiFi access point, the software is largely without issues.Most people would not consider software with so many bugs "stable."