v7.1beta6 [development] is released!

donluca · Wed Jul 14, 2021 7:58 pm

I would like to request a separate wifiwave2 package for IPQ4018/IPQ4019 devices with 16MB of ROM. With such a package a lot of more users could test this it, send feedbacks and bug reports which will result in an earlier available bugfree stable release.
+1

+1 here as well.

I still have the option to return my hAP AC2 (128MB RAM) and get an hAP AC3 (256MB RAM). If this means getting access to wifiwave2 in the future then I'll be definitely willing to spend a little bit more to get a more future-proof device.

nevolex · Fri Jul 16, 2021 12:20 am

I would like to request a separate wifiwave2 package for IPQ4018/IPQ4019 devices with 16MB of ROM. With such a package a lot of more users could test this it, send feedbacks and bug reports which will result in an earlier available bugfree stable release.
+1
+1 here as well.

I still have the option to return my hAP AC2 (128MB RAM) and get an hAP AC3 (256MB RAM). If this means getting access to wifiwave2 in the future then I'll be definitely willing to spend a little bit more to get a more future-proof device.

I think the only reason they have such a limited number of hardware to supported by this package at this moment, is proprietary nature of it (it's no mikrotik's but a qualcomm's driver), unless they will re write it from scratch they just cannot fit it in the rom.

This brings another question, however, why would most of their routers still have just 16MBs of storage, would that be 32MBs, there was not an issue to fit the driver in.

This being said with their ros 7 development delays, the wave2 driver is not the priority. They are doing a great job, but the company of their size supporting multiple ros versions for numerous hardware types a bit of a stretch

Kaldek · Fri Jul 16, 2021 4:54 am

Hey does anyone know if 7.1beta6 includes the FragAttack mitigations?

Fri Jul 16, 2021 12:26 pm

It contains the fixes for Frag Attacks: https://blog.mikrotik.com/security/fragattacks.html

frank333 · Fri Jul 16, 2021 12:28 pm

It contains the fixes for Frag Attacks: https://blog.mikrotik.com/security/fragattacks.html

@ Guntis
hi, can you give us a preview of the new release?

Fri Jul 16, 2021 2:36 pm

please just wait a little bit, we are preparing for release of the next beta soon

rpingar · Fri Jul 16, 2021 3:42 pm

please just wait a little bit, we are preparing for release of the next beta soon

please fix asap the crash about x86 winbox ip route describe in SUP-44860. I provided a router to test and a bgp session to test but since some days ago no one is responding.

thanks
Ros

SVD · Sun Jul 18, 2021 3:26 am

Does anybody have problems with ipv6? Firewall filters are totally broken. Just added this
/ipv6 firewall filter
add action=reject chain=forward reject-with=icmp-no-route
add action=reject chain=input reject-with=icmp-no-route
add action=reject chain=output reject-with=icmp-no-route

And still have acces to ipv6.google.com
also counters show mad values

doof · Sun Jul 18, 2021 8:55 am

First of all, thanks to Mikrotik for bringing MLAG to the CRS3xx switches!

I tried the new MLAG feature with two CRS326-24S+2Q+RM and a Server running Linux as the Bonding partner. Unfortunately the Multi-chassis link aggregation group is not reliable for me. While it works after the initial configuration it stops working after some minutes of load on the interfaces. Sometimes it works 2 minutes, sometimes 20 minutes, before it stops forwarding traffic. Disconnecting one cable of the Bonding or rebooting one of the switches nearly always leads to a situation, where no packages are forwarded over the Bonding. In order to make sure that I did not have a problem on the Linux side, I created a normal 802.3ad Bonding on one of the CRS326-24S+2Q+RM with two other ports. Unexpectedly this also did not work reliable. Sometimes the single device Bond was able to forward traffic after disconnecting one cable sometimes it stops forwarding any traffic already after disconnection just one cable. Super interesting are the cases where the Bonding survived a cable disconnect (as it should), but stopped forwarding traffic if the cable has been reconnected. Interesting is also that a port is often shown as active in the status window after the cable is already disconnected.
Disabling and re-enabling the Bonding on the Switch seams to fix the problems with not forwarding any traffic, most of the time, at least for the single device LAG.

Since the MLAG and also a conventional LAG was very unreliable on RouterOS v7.1beta6, I configured a 802.3ad Bonding on a CRS 17-1G-16S+ running RouterOS v6.48.3. I connect the same Linux Server without any configuration changes to the CRS317-1G-16S+ and the Bonding works exactly as expected. I can disconnect and reconnect cables all day long and I loose maximal two pings, as long as at least one connection stays up.

My conclusion is that there is something broken with 802.3ad Bonding in RouterOS v7.1beta6. I hope, Mikrotik can find and fix that problem soon.

I'm exited about all the new hardware offloaded features Mikrotik is bringing the CRS3xx switches!

I'm experiencing the exact same thing. 2x CRS326-24S-2G+RM. MLAGs and normal 802.3ad bonds work... sporadically. Downgrading to v6.48.3 makes normal 802.3ad bonds work fine, but there's no MLAG capability anymore.

please just wait a little bit, we are preparing for release of the next beta soon

Very much looking forward to this release -- MLAG support is a game-changer.

Railander · Wed Jul 21, 2021 8:14 am

if i may ask, what is the expected use case of offloading fasttracked connections?

4k connections seems way too few to me since everything else would be processed on the CPU (which considering the CPUs in these would be effectively dropping all other packets in any decently sized network), unless i'm missing something here.

mkx · Wed Jul 21, 2021 8:21 am

if i may ask, what is the expected use case of offloading fasttracked connections?

Wirespeed routing with firewall enabled?

I agree that 4k connections is small number even for a small business let alone for an ISP, but that doesn't mean the functionality should not be developed. It's just that one considering CRS3xx as main firewall needs to (re)consider the requirements to see if performance metric fits. It fits great for home use (combination of router/switch all-in-one device).

Railander · Wed Jul 21, 2021 11:07 am

I agree that 4k connections is small number even for a small business let alone for an ISP

well that is exactly why i am asking.
and i disagree with it being fit for home use since right now my home network is idle and sitting at 300 connections. start a torrent and its already about half the budget.
i guess if it's your grandma's home it should be okay, but then maybe a crs300 wouldn't be a good investment anyway...

pe1chl · Wed Jul 21, 2021 11:08 am

if i may ask, what is the expected use case of offloading fasttracked connections?

4k connections seems way too few to me since everything else would be processed on the CPU (which considering the CPUs in these would be effectively dropping all other packets in any decently sized network), unless i'm missing something here.

Well, of course it depends heavily on how cleverly the 4K connections are chosen from the total mix, how much CPU effort has to be spent on initially offloading a connection, and what the usage scenario is.
We have such routing switches at work, and they are routing between VLANs inside an office. 4K connections would be enough I think.
But when you use such a mechanism for your internet routing and have a lot of client systems, of course it is not very much.
As a sample I checked on our internet router just now, and we have 2779 IPv4 and 849 IPv6 connections. And of course that varies. Would not have much room for growth, that is for sure.
But, of course a lot of these connections will be single-exchange DNS lookups, and the software could be clever enough to not offload such things (as they probably only become slower anyway, as the effort to offload the connection to the hardware would likely be more than what is saved).
So it is more likely that it e.g. offloads only after some X amount of data has been transferred over the connection, or even when it is observed to have more than some minimal bitrate. That would not only make it more efficient but it also would limit the number of eligible connections to offload.

mkx · Wed Jul 21, 2021 12:19 pm

We have such routing switches at work, and they are routing between VLANs inside an office.

Do you enforce firewall filter for inter-VLAN connections? Without firewall enabled, those connections would be purely routed and for inter-VLAN routing the L3HW routing table is plenty large.

OTOH, when I was talking about "home use", I was thinking of place where torrent client is limited to a sane number (i.e. a few hundred) of concurrent connections for all torrents cumulative. That way there would be something like 2k connections over firewall alive at any time (my live torrent client has currently around 1k connections open).

pe1chl · Wed Jul 21, 2021 3:17 pm

We have such routing switches at work, and they are routing between VLANs inside an office.
Do you enforce firewall filter for inter-VLAN connections? Without firewall enabled, those connections would be purely routed and for inter-VLAN routing the L3HW routing table is plenty large.

Those routing switches are not from MikroTik... I do not know offhand what their limit is. It is just an example where the connection limit would be enough for me.

MarcSN · Thu Jul 22, 2021 3:20 pm

LTE stopped working for me. Where can I download beta4 or 5?

rextended · Thu Jul 22, 2021 3:24 pm

What device you use?

MarcSN · Thu Jul 22, 2021 4:42 pm

I'm using a WAP R ac

rextended · Thu Jul 22, 2021 4:46 pm

Thanks for reply.

Replace 6 with 4 or 5 on beta6 download link

clambert · Fri Jul 23, 2021 7:20 pm

Hi, according to what some users have commented, V7.1beta7 already exists. When will it be available for download?

w0lt · Fri Jul 23, 2021 7:53 pm

Hi, according to what some users have commented, V7.1beta7 already exists. When will it be available for download?

As I use PIM multicast, I hope that v7.1beta7 includes that in the WinBox menu.

santyx32 · Sun Jul 25, 2021 6:39 pm

After a year of using OpenWrt on my 16/128MB hAP ac2 I went back to ROS 7.1 beta 6 to check how has it evolved.

So far I'm really impressed with the CAKE implementation, it's much better than OpenWrt's after some fine tuning since ROS distributes IRQs across the 4 cores in a more efficient manner than OpenWrt + irqbalance daemon.

However WiFi is still meh compared to OpenWrt Wave2 + WPA3 functionality.

I hope someday Mikrotik switches to device specific builds so they can slim down their Wave2 package and optimize it for 128MB of RAM.

EDIT: after almost a day of uptime the router went into a kernel panic and rebooted itself, will try fq_codel to check if it also reboots.

mikegleasonjr · Mon Jul 26, 2021 7:01 pm

EDIT: after almost a day of uptime the router went into a kernel panic and rebooted itself, will try fq_codel to check if it also reboots.

I follow this thread and from what I read, codel panics too, but takes a little longer for some... looking forward to see how it goes on v7.1beta7

santyx32 · Mon Jul 26, 2021 8:11 pm

EDIT: after almost a day of uptime the router went into a kernel panic and rebooted itself, will try fq_codel to check if it also reboots.
I follow this thread and from what I read, codel panics too, but takes a little longer for some... looking forward to see how it goes on v7.1beta7

So far I haven't had a kernel panic with fq_codel yet but I'm still looking forward to beta 7.

santyx32 · Tue Jul 27, 2021 7:27 am

Had to return to OpenWrt, can't withstand unreliable WiFi from ROS and is too much time consuming to fine tune it. OpenWrt WiFi just works fast and reliable out of the box without having to tinker with it.

infabo · Tue Jul 27, 2021 12:10 pm

Had to return to OpenWrt, can't withstand unreliable WiFi from ROS and is too much time consuming to fine tune it. OpenWrt WiFi just works fast and reliable out of the box without having to tinker with it.

offtopic: I had Linksys WRT1200 and WRT3200 running for several years with OpenWrt. Wifi sucked soooo much - it was a pain. Even with its 4 external antennas I had so bad wifi coverage AND shitty throughput.

Switched to Chateau then. Did not expect anything from a device without external antennas and - from the datasheet - inferior wifi specs. But turned out: Mikrotik Wifi is a no-brainer for me. Coverage is sufficient and just works. No more wifi tinkering.

mikegleasonjr · Tue Jul 27, 2021 3:59 pm

Had to return to OpenWrt, can't withstand unreliable WiFi from ROS and is too much time consuming to fine tune it. OpenWrt WiFi just works fast and reliable out of the box without having to tinker with it.
offtopic: I had Linksys WRT1200 and WRT3200 running for several years with OpenWrt. Wifi sucked soooo much - it was a pain. Even with its 4 external antennas I had so bad wifi coverage AND shitty throughput.

Switched to Chateau then. Did not expect anything from a device without external antennas and - from the datasheet - inferior wifi specs. But turned out: Mikrotik Wifi is a no-brainer for me. Coverage is sufficient and just works. No more wifi tinkering.

I have 3 Cap AC on Openwrt now. So I have experience with both Router OS and OpenWRT.

Maybe in your use case you have enough coverage so that 1 access point is enough, and the band you use is always the same (always 2 ghz or always 5 ghz).

But my observations were:

- OpenWRT is clearly faster in pure throughput (1 wifi device doing an iperf3 test to a wired device). But going from 200mbps (RouterOS) to 400-500 mbps (OpenWRT) maybe does not matter for you. It doesn't really for me either since I mostly use Internet which is 100 mbps anyway.
- OpenWRT does roaming a lot better. First of all switching to/from 2 ghz and 5 ghz on the same access point works seamlessly. With RouterOS, I had to configure the 2ghz band to have 7db less than the 5ghz band for my devices to connect to the 5ghz band when reallt close to the access point. Then I was loosing range on the 2 ghz. Also when a device would connect to one band, it would be stuck on it for a very long time. For example, the device connects to the 5 ghz, I move, it stays on the 5ghz even if the 2ghz is clearly stronger. It takes a really bad 5 ghz signal or a very long time for the deviec to switch.
- Across all access points, OpenWRT does roaming. I can start an iperf3 test to a remote wired computer and move across all 3 access point seemlessly, switching from one access point to another or on one band to another very quickly without loosing the connection. And it does it pretty fast.
- OpenWRT configuration is faster out of the box, with RouterOS I had to define the non-overlapping channels, define the power of the 5ghz band, read a lot and tweak a lot of things, watch Mikrotik conferences on best practices, etc. I am glad I did, learned a lot, but in my use case at home, OpenWRT was clearly simpler.

So depending on the needs both can do the job, but when digging further I find OpenWRT better for me. Also super stable without one reboot since flashing and configuring.

My 2 cents

anthonws · Tue Jul 27, 2021 6:49 pm

Had to return to OpenWrt, can't withstand unreliable WiFi from ROS and is too much time consuming to fine tune it. OpenWrt WiFi just works fast and reliable out of the box without having to tinker with it.
offtopic: I had Linksys WRT1200 and WRT3200 running for several years with OpenWrt. Wifi sucked soooo much - it was a pain. Even with its 4 external antennas I had so bad wifi coverage AND shitty throughput.

Switched to Chateau then. Did not expect anything from a device without external antennas and - from the datasheet - inferior wifi specs. But turned out: Mikrotik Wifi is a no-brainer for me. Coverage is sufficient and just works. No more wifi tinkering.
I have 3 Cap AC on Openwrt now. So I have experience with both Router OS and OpenWRT.

Maybe in your use case you have enough coverage so that 1 access point is enough, and the band you use is always the same (always 2 ghz or always 5 ghz).

But my observations were:

- OpenWRT is clearly faster in pure throughput (1 wifi device doing an iperf3 test to a wired device). But going from 200mbps (RouterOS) to 400-500 mbps (OpenWRT) maybe does not matter for you. It doesn't really for me either since I mostly use Internet which is 100 mbps anyway.
- OpenWRT does roaming a lot better. First of all switching to/from 2 ghz and 5 ghz on the same access point works seamlessly. With RouterOS, I had to configure the 2ghz band to have 7db less than the 5ghz band for my devices to connect to the 5ghz band when reallt close to the access point. Then I was loosing range on the 2 ghz. Also when a device would connect to one band, it would be stuck on it for a very long time. For example, the device connects to the 5 ghz, I move, it stays on the 5ghz even if the 2ghz is clearly stronger. It takes a really bad 5 ghz signal or a very long time for the deviec to switch.
- Across all access points, OpenWRT does roaming. I can start an iperf3 test to a remote wired computer and move across all 3 access point seemlessly, switching from one access point to another or on one band to another very quickly without loosing the connection. And it does it pretty fast.
- OpenWRT configuration is faster out of the box, with RouterOS I had to define the non-overlapping channels, define the power of the 5ghz band, read a lot and tweak a lot of things, watch Mikrotik conferences on best practices, etc. I am glad I did, learned a lot, but in my use case at home, OpenWRT was clearly simpler.

So depending on the needs both can do the job, but when digging further I find OpenWRT better for me. Also super stable without one reboot since flashing and configuring.

My 2 cents

Wifi roaming is definitely something that I am not happy with the experience... I live in a 3 bedroom apartment (not big) and I have 3 APs. Each time I transition I lose connectivity... I've done my best at optimizing bands/channels, etc. to no avail (I might be dumb, I know... :P).

TBH I would love to try OpenWRT (used it alongside with DD-Wrt many years back in other make&model networking equipment), but right now I am "stuck" in that scenario where the level of work to transition to another vendor or even firmware, would be too much for me and my free time. We can say I am now vendor locked, and not totally satisfied with the basics (Wifi)...

But thanks for the info on OpenWrt!

infabo · Tue Jul 27, 2021 7:03 pm

@mikegleaso capac3 wifi chip may have better driver support than crappy Marvell 88W8964. It is trash. No MU-MIMO even the chip supports it. Despite 802.11ac a bunch of lame garbage. Sitting near 2m distance with macbookpro I got 60mbit/s with iperf3. Tweaking around with channels (I am alone on landside, no other used channels) and stuff I finally reached speeds like 180mbit/s with iperf3. Again, 5m meters distance. A real useless AP it was. But cake SQM worked quite fine. At least it did not kernel paniced ;)

Cablenut9 · Tue Jul 27, 2021 7:06 pm

Tweaking around with channels (I am alone on landside, no other used channels) and stuff I finally reached speeds like 180mbit/s with iperf3. Again, 5m meters distance. A real useless AP it was.

This is pure BS, as I can get a solid 450 Mbps with my old Linux laptop at the same distance. Then again, there's no interference where I am and this is the best case scenario.

infabo · Wed Jul 28, 2021 4:25 pm

Are you talking about WRT1200/3200 too? If yes - then maybe in 2021. I shut down my linksys devices in 2020. I maybe miss OpenWrt - but definitely not these two devices.

Cablenut9 · Wed Jul 28, 2021 4:30 pm

Are you talking about WRT1200/3200 too?

No, only the cAP ac and hAP ac3.

infabo · Wed Jul 28, 2021 4:32 pm

yeah, found the openwrt device topic for cap ac support. people are quite freaking out because of boosted wifi throughput compared with routeros. well, ipq4018 is maybe a wide supported chip and therfore has good opensource drivers available.

looks like a major defeat for mikrotik. some guy makes cap-ac compatible with openwrt - and wifi performance outperforms factory firmware. well played.

santyx32 · Wed Jul 28, 2021 7:39 pm

looks like a major defeat for mikrotik. some guy makes cap-ac compatible with openwrt - and wifi performance outperforms factory firmware. well played.

The real problem is that Mikrotik launched IPQ401X devices with only 128MB of RAM to then realize propietary Qualcomm drivers require 256MB of RAM for correct operation, their old in house drivers can work fine on low RAM devices but they're no longer capable of keeping up with increasing broadband speeds and customer demands for newer technologies like WPA3.

Maybe they can go the OpenWrt way and patch the propietary driver to keep the buffers small and remove unnecessary carrier grade features such as BGP on low RAM WiFi enabled devices, but I highly doubt they will ever do it since selling new models / upgraded hardware revisions generates more revenue for Mikrotik as a company.

EDIT: I forgot to say that OpenWrt small buffers patch also limits each radio to a maximum of 32 concurrent devices (64 in total if you use the two radios as in cAP AC) so keep this in mind for large deployments.

r00t · Wed Jul 28, 2021 11:48 pm

Even with smaller buffers it would be miles ahead from original Mikrotik driver, at least for most users. OpenWrt devs already done all the work on figuring out how to do the patching, all this info is there and available... if Mikrotik wants it. If ROS packages weren't signed, there would probably be modified package available by now... but all we can do is to wait and see what happens.

TomSF · Fri Jul 30, 2021 1:08 am

Does anybody have problems with ipv6? Firewall filters are totally broken. Just added this
/ipv6 firewall filter
add action=reject chain=forward reject-with=icmp-no-route
add action=reject chain=input reject-with=icmp-no-route
add action=reject chain=output reject-with=icmp-no-route

And still have acces to ipv6.google.com
also counters show mad values

I too just discovered that firewall filters are totally broken. Only 4 of my 54 filters have non-zero counters, one of which is a jump to an icmp chain for further filtering. The jump filter as of this post has -3057636768 631 697 packets (yes it is a negative number!) and all filters in the icmp chain have zero counters, including a default drop at the end of the chain. Time to downgrade.

zainarbani · Sun Aug 01, 2021 8:29 am

Adapting from 3.3 to new 5.6 kernel behaviour isn't an easy task.
Massive backporting also adding new features on their back-end & front-end.

v7 already installable so far, new features also added which is nice start.
We can assume the initial phase was done. So, lets just wait for it.

But also, Hi Team,
it is possible to make usermanager package open source ?

pe1chl · Sun Aug 01, 2021 1:34 pm

it is possible to make usermanager package open source ?

It is not possible to make ANY package open source, because it is not possible to compile a package for RouterOS unless you are in possession of the signing key.
Ok technically you could release the source, but it would not be possible for others to do something useful with it.

I think a worthwile addition to RouterOS would be some possibility to run user-supplied binaries on the router without access to the filesystem (i.e. in a chroot jail) and with limited privileges (run as normal user).
A kind of lightweight replacement for MetaROUTER which does not run an entire OS but only a network server process.
Then, you could run something like usermanager on your router after having compiled it yourself and putting it in a folder on the flash.

zainarbani · Sun Aug 01, 2021 5:44 pm

I think a worthwile addition to RouterOS would be some possibility to run user-supplied binaries on the router without access to the filesystem

Allright, besides of signed binary mandatory
What's the matter with access to the FS?
I mean if user want, they can easily replace the entire OS right?
I dont think it will create a hole for a hacker or something like that.

however, why bother with usermanager when REST api finally added

pe1chl · Sun Aug 01, 2021 8:45 pm

What's the matter with access to the FS?
I mean if user want, they can easily replace the entire OS right?
I dont think it will create a hole for a hacker or something like that.

Well, I think MikroTik would not like to open a hole for users (even when no hacker) to access the entire FS and gain shell access etc.
Earlier holes that allowed that were always fixed as soon as they became known to them.

When RouterOS allows a binary to run in a separate folder in the flash, with chroot to that folder, the binary can still access files in that same folder so it should be possible to maintain e.g. a database for usermanager but prevent access to other files.
To run the binary as a restricted user further improves that security.
The only thing that has to be arranged is some way to open network sockets either from the binary or from a configuration similar to MetaROUTER.
Then users can install binaries for purposes like usermanager without having to rely on MikroTik creating and distributing them, and without opening the "signed packages only" restriction we currently have.

r00t · Mon Aug 02, 2021 2:39 pm

I really really hope this chrooted feature will happen in v7.1. There's plenty of security features available in the kernel to make sure it's secure so it can't be abused, so this shouldn't be a problem.
And it would allow us to finally get some of the most wanted tools running on a ROS that Mikrotik doesn't want to give us.
Good examples are UDPXY (there's 5 years old thread here), NMAP (another thread about missing portscanner in ROS), MQTT, ...

pe1chl · Mon Aug 02, 2021 4:13 pm

Yes I agree! And I keep posting it in every topic where this limitation is discussed and this solution would solve it, hoping that finally some MikroTik employee will pick it up and start considering it.
After all, MetaROUTER was implemented at some time. So they are not completely blind to this wish. But MetaROUTER is not supported on new devices and it is likely difficult to implement, whereas running user processes should be easier to implement on new architectures.

santyx32 · Wed Aug 04, 2021 11:59 pm

A quick iPerf3 LAN - 5GHz WLAN benchmark of my hAP AC2 running OpenWrt RC4 with irqbalance.

Host: Linux laptop connected through Cat 5e
Client: Xiaomi X3 Pro

Channel: 52 (DFS) @ 80MHz

This is far better than anything else the stock RouterOS can offer when it comes to WiFi performance.

I guess the wifiwave2 driver on the hAP AC3 can outperform these results due to some propietary QCA optimizations which are not publicly disclosed, however this unit won't benefit from those improved drivers anyways.

nannou9 · Thu Aug 05, 2021 8:39 am

Hopefully the wait for next beta will be worth it and it fixes Wifiwave2 issues where my wifi sometimes goes down every few minutes on my audience.
I have reported this multiple times with logs and config export already.
@Normis I also asked for comment few times from MikroTik on this, no answer so far while the bug exists in last 3 beta releases.

Thu Aug 05, 2021 10:07 am

Have you created a support ticket about it?

nannou9 · Thu Aug 05, 2021 5:07 pm

Have you created a support ticket about it?

I though this thread is good enough to report a bug/issue.
But as you are asking for it it sounds like it isn’t.
I will raise support ticket separately.
Thanks.
But this is then slightly weird. Are you telling me that all the problems reported in this forums are ignored if no support ticket is raised?
Then why do we have this forum and why then MikroTik support tickets are not available for people to view/track like many it projects are for example using jira.
It would definitely limit the amount of reports you get.

pe1chl · Thu Aug 05, 2021 5:17 pm

But this is then slightly weird. Are you telling me that all the problems reported in this forums are ignored if no support ticket is raised?
Then why do we have this forum and why then MikroTik support tickets are not available for people to view/track like many it projects are for example using jira.

It sure is weird! Why are there "is released" topics that are open for comment and where often remarks are made to "stay on the topic of issues with that release" when MikroTik is not at all following the replies on these topics.
One would expect someone reads the replies and creates internal support tickets for reported issues as necessary, especially when others in the topic confirm the issue.

infabo · Thu Aug 05, 2021 7:13 pm

They do. At least Normis tells us.

viewtopic.php?f=1&t=175201&p=869593#p869593

dksoft · Mon Aug 09, 2021 3:45 pm

Re: CCR1009 reboots at startup using 7.1b6

Hi,

does anybody have an idea, why my CCR1009 does reboot just after start? It shows "loading services", double beeps and then reboots. Over and over.
If I remove the SFP+ which is the only connection, the router comes up and if I replug the SFP+ after 10 seconds, everything works fine.
I also tried SFP and RJ45, the result is just the same.

Thanks
dksoft

PS: Yes, I already sent autosupout.rif to support and created a ticket but never heard back.

dksoft · Mon Aug 09, 2021 3:52 pm

Re: WireGuard interface shuts down when bandwith test runs on 7.1b6

Hi,

I created a WireGuard tunnel between a CHR (7.1b6) and CCR1009 (7.1b6). Simple configuration, all IP addresses allowed, no fast path/track.
CHR server is 192.168.178.1, the CCR1009 client is 192.168.178.2.

Ping works fine, but if I do a TCP Bandwith test (the Router OS embedded one) from client to CHR server at 192.168.178.1, the WireGuard interface shuts down.
Both ends show that the tunnel is still running but ping/bandwith test no longer work. Also dis-/enabling the tunnel interfaces on both ends does not bring it back to live.

Only rebooting the client brings up the tunnel again. Rebooting the server does not have an effect.

Any ideas, what might go wrong here?

Thanks,
dksoft

mjbnz · Tue Aug 10, 2021 6:46 am

the new filter rule syntax in 7.1beta7 is much much better, but does need to have tab/? completion implemented. the documentation at https://help.mikrotik.com/docs/pages/vi ... d=74678285 is fairly complete, and not hard to follow. The resulting syntax from /routing/filter/rule/print is very easy to read and comprehend.

An example:

[admin@BETA7-TEST] > /routing/filter/rule/print
Flags: X - disabled, I - inactive 
 0   chain=bgp_in rule="set bgp-local-pref 100" 

 1   chain=bgp_in rule="if (bgp-input-local-as == 4242424201) {set bgp-local-pref -10}" 

 2   chain=bgp_in rule="accept" 

 3   chain=bgp_out rule="if (dst in 192.168.0.0/16) {accept}" 

 4   chain=bgp_out rule="if (dst in 10.0.0.0/8) {accept}" 

 5   chain=bgp_out rule="reject" 
[admin@BETA7-TEST] >

One issue so far is that I cannot use the if (bgp-as-path [regex]) predicate - it seems to crash the BGP process.

edit: bgp connections can now have output.filter-chain= added which uses a rule chain, without needing to use /routing/filter/select-rule. That's still there though, and you can apply that to a connection using output.filter-select= .

So far, a really good bit of progress.

pe1chl · Tue Aug 10, 2021 11:33 am

I notice that in the /ipv6 firewall mangle rules there still is no "set priority" action, as there is in /ip firewall mangle.
(to set the priority of packets to a fixed value, according to DSCP, or from ingress)

I think it was promised that this would be implemented in v7, but frankly I would like to see it in v6 as well.
What makes it so hard to complete the ipv6 feature set? There are lots of small things still missing from IPv6.

huntermic · Thu Aug 12, 2021 5:19 pm

please just wait a little bit, we are preparing for release of the next beta soon

How soon is soon?
Almost a month has passed since this message from normis

rextended · Thu Aug 12, 2021 5:21 pm

please just wait a little bit, we are preparing for release of the next beta soon
How soon is soon?
Almost a month has passed since this message from normis

23 Aug 2021

pe1chl · Thu Aug 12, 2021 5:27 pm

please just wait a little bit, we are preparing for release of the next beta soon
How soon is soon?
Almost a month has passed since this message from normis

Hey come on, not so impatient! It has been SEVEN YEARS since this message from normis:

viewtopic.php?f=2&t=87388#p438725

hessamsaheli · Thu Aug 12, 2021 5:31 pm

On this update
Dial on Demand l2tp connections doesn't work

poldim · Thu Aug 12, 2021 6:28 pm

Is there a special upgrade procedure for the LTE modem after upgrading to v7.1beta6?

It seems on the factory shipped firmware (6.45.9) and testing firmware (6.49beta54), LTE works fine as configured out of the box. However, I am upgrading to development firmware (7.1beta6) and this seems to break LTE connection to the network.

When I upgrade to 7.1beta6, LTE just says that “a newer version of modem firmware is available” but since I cannot connect to the network it can’t download any update. Downgrading back to 6.49beta54 allows the LTE to work instantly.

Cablenut9 · Thu Aug 12, 2021 7:36 pm

On this update
Dial on Demand l2tp connections doesn't work

I have the same problem, just use Wireguard until it's fixed.

pe1chl · Thu Aug 12, 2021 7:49 pm

On this update
Dial on Demand l2tp connections doesn't work
I have the same problem, just use Wireguard until it's fixed.

I always wonder how "Dial on Demand L2TP" is ever supposed to work... I don't need it, but I think "well, an L2TP client only gets an IP address and peer IP when it is connected, how is the router supposed to know that certain traffic is to be routed to that L2TP connection unless it already is established (catch-22)".
But probably there is a reasonable usage scenario for it...

Thu Aug 12, 2021 8:01 pm

how is the router supposed to know that certain traffic is to be routed to that L2TP connection unless it already is established

You can specify L2TP interface itself as a gateway in a static route (including default one).

mjbnz · Fri Aug 13, 2021 3:18 am

Is there a special upgrade procedure for the LTE modem after upgrading to v7.1beta6?

It seems on the factory shipped firmware (6.45.9) and testing firmware (6.49beta54), LTE works fine as configured out of the box. However, I am upgrading to development firmware (7.1beta6) and this seems to break LTE connection to the network.

When I upgrade to 7.1beta6, LTE just says that “a newer version of modem firmware is available” but since I cannot connect to the network it can’t download any update. Downgrading back to 6.49beta54 allows the LTE to work instantly.

Common report - LTE support in beta6 is busted - either upgrade from 6.49beta54 to 7.1beta5 , or wait for 7.1beta7.

mafiosa · Sun Aug 15, 2021 9:10 pm

Is next beta/RC being released on 23rd August?

Cablenut9 · Sun Aug 15, 2021 9:38 pm

Is next beta/RC being released on 23rd August?

That's what the rumor mill says!

McShadow · Mon Aug 16, 2021 2:54 pm

I don't know if it is just a bug in my setup but when I want to do an operator scan via lte1 the LTE Scanner always shows "Running".

LTEScan.PNG

I tried:
- Interfaces > lte1 > Scan... > Stop
- Restart interface / device
- /interface lte scan lte1 duration=1s

But it keeps showing the status "Running" and the scan does not work properly. Sometimes I see several operators but more often I don't see any.

This appeared with a Chateau LTE12 running on v7.1beta6.

Did someone recognize the same behaviour?

Best regards,
McShadow

rextended · Mon Aug 16, 2021 3:52 pm

This appeared with a Chateau LTE12 running on v7.1beta6.

The only valid software for Chateau LTE12 is 7.0.3, why you install the beta called 7.1beta6?

McShadow · Mon Aug 16, 2021 4:01 pm

This appeared with a Chateau LTE12 running on v7.1beta6.
The only valid software for Chateau LTE12 is 7.0.3, why you install the beta called 7.1beta6?

Thanks for the reply. I will check it out. Installed it for test purposes and wanted to tell you about that bug.

rextended · Mon Aug 16, 2021 4:08 pm

If I can suggest something, next time check if you can go back before upgrade to non-removeable beta...
Download link for 7.0.3 is removed.

sindy · Mon Aug 16, 2021 4:26 pm

Download link for 7.0.3 is removed.

The clickable link is indeed not available at the https://mikrotik.com/download page as there's always only the latest version in each branch. However, the files themselves haven't been removed. You have to enter the complete url manually - see https://download.mikrotik.com/routeros/ ... a3-arm.npk etc.

rextended · Mon Aug 16, 2021 4:53 pm

I wrote 7.0.3, not 7.0beta3
The RouterOS 7.0.3 (stable) for ARM is an factory software dedicated version for Chateau LTE12 only.
@Normis posted a "private download" link, but it has been removed.

r00t · Mon Aug 16, 2021 10:22 pm

I don't understand why is Mikrotik playing games with this Chateau 7.0.x download link. If you want to go back to original ROS version, you need it.
So just put it on official download page, what's so complicated about that?!
Mikrotik is actually shipping device with this version for quite a while, but they are too embarrassed(?) to put in on download page?

nescafe2002 · Mon Aug 16, 2021 10:55 pm

They do not post the firmware publicly because it will brick non-chateau devices. Both times they posted a link, with warning, at least one user tried installing it on another model.

santyx32 · Tue Aug 17, 2021 5:12 am

ROS 7.1 moving to testing channel on August 23th?

Jotne · Tue Aug 17, 2021 9:03 am

Why do speculate? Only MT knows the release schedule. Stop spreading rumor.
If some has a link to hard facts, do post...

pe1chl · Tue Aug 17, 2021 11:29 am

ROS 7.1 moving to testing channel on August 23th?

Before that can happen, at least the conversion of configuration has to work reasonably well, and that has not been tested yet.
I think we need further beta versions that people can upload to their 6.48.3 install had see that it keeps functioning as before.
Observations of problems (MikroTik cannot possibly test all configurations) have to be reported and fixed, probably requiring another beta or two.

Moving it to testing now will result in a massacre, no matter how big the warning at the top of the release notes is to not just do a blind update of a router when you cannot afford hours of downtime and do not have local access.

JoshDi · Tue Aug 17, 2021 5:13 pm

Can anyone report/comment if OSPF is working with v7.1beta6 with wire guard? It has not worked in beta5 and earlier. Thank you!

aussetg · Tue Aug 17, 2021 6:56 pm

Can anyone report/comment if OSPF is working with v7.1beta6 with wire guard? It has not worked in beta5 and earlier. Thank you!

Yes it works for me (OSPFv2).

(With PTP type /30 Wireguard links)

But it worked on beta5 for me too so...

FezzFest · Mon Aug 23, 2021 12:28 pm

[admin@MikroTik] > /system package update check-for-updates 
            channel: development
  installed-version: 6.47.10
     latest-version: 7.1rc1
             status: New version is available

Looks like v7.1rc1 has been released (but the changelog is currently missing).

emils · Mon Aug 23, 2021 12:32 pm

New version 7.1rc1 has been released in development RouterOS channel:

viewtopic.php?f=1&t=177800