Community discussions

MikroTik App
 
igorr29
Frequent Visitor
Frequent Visitor
Posts: 82
Joined: Tue Jan 02, 2024 12:53 pm

Re: v7.17beta [testing] is released!

Sat Oct 05, 2024 12:55 pm

is SUPERCHANNEL actually working for anyone with ax boards?
why is it even there if it's not working?
winbox64_2Sq70RX0Ki.png
winbox64_3BWwv2XEbo.png
it *should* work:
winbox64_F4GxNNqQT7.png
You do not have the required permissions to view the files attached to this post.
 
User avatar
Coughy
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Tue Apr 23, 2024 2:53 am
Location: Brisbane Au

Re: v7.17beta [testing] is released!

Sat Oct 05, 2024 2:04 pm

check your logs if you have dude installed i just got a warning that IP 172.169.6.6 tried to log into my dude via winbox
now thats in amsterdam so the hackers are out and about
lucky the firewall did its job and denied that but WHY what is happening mikrotik i have never had syn flooding from ros before why now
and this new attempt to enter my mikrotik mmm
might have to uninstall dude if this keeps up
Screenshot 2024-10-05 210357.png

etRange: 172.160.0.0 - 172.191.255.255
CIDR: 172.160.0.0/11
NetName: RIPE
NetHandle: NET-172-160-0-0-1
Parent: NET172 (NET-172-0-0-0-0)
OrgName: RIPE Network Coordination Centre
OrgId: RIPE
Address: P.O. Box 10096
City: Amsterdam
You do not have the required permissions to view the files attached to this post.
 
riv
newbie
Posts: 30
Joined: Wed Jun 07, 2006 4:16 am

Re: v7.17beta [testing] is released!

Sat Oct 05, 2024 7:18 pm


need moons ,too
+1
 
User avatar
gabacho4
Member
Member
Posts: 399
Joined: Mon Dec 28, 2020 12:30 pm
Location: Earth

Re: v7.17beta [testing] is released!

Sat Oct 05, 2024 7:40 pm

Is there a specific reason why
multi-passphrase is not supported for the WPA3-PSK authentication type.

Will it be supported in future releases?
WPA3 will never support PPSK as currently implemented. A simple Google query for WPA3 and PPSK will get you all sorts of information from a variety of networking resources.
 
PackElend
Member Candidate
Member Candidate
Posts: 272
Joined: Tue Sep 29, 2020 6:05 pm

Re: v7.17beta [testing] is released!

Sat Oct 05, 2024 7:50 pm

Is there a specific reason why
multi-passphrase is not supported for the WPA3-PSK authentication type.

Will it be supported in future releases?
WPA3 will never support PPSK as currently implemented. A simple Google query for WPA3 and PPSK will get you all sorts of information from a variety of networking resources.
😭
So there any option to do the vlan separation based on PSK or similar?
Wondering how to deal with the headless devices which can be assigned to an VLAN easily now (with PPSK).
 
gigabyte091
Forum Guru
Forum Guru
Posts: 1490
Joined: Fri Dec 31, 2021 11:44 am
Location: Croatia

Re: v7.17beta [testing] is released!

Sat Oct 05, 2024 9:14 pm

You are doing VLAN separation. Every smart device must have some kind of app or a way to select SSID and input password. So just input password you specified for that VLAN and thats it
 
PackElend
Member Candidate
Member Candidate
Posts: 272
Joined: Tue Sep 29, 2020 6:05 pm

Re: v7.17beta [testing] is released!

Sat Oct 05, 2024 9:22 pm

You are doing VLAN separation. Every smart device must have some kind of app or a way to select SSID and input password. So just input password you specified for that VLAN and thats it
I want only broadcast two SSIDs guest and locals (locals has several VLANs and assignment is according to MAC, now PPSK).

Are we talking about the same setup?
 
gigabyte091
Forum Guru
Forum Guru
Posts: 1490
Joined: Fri Dec 31, 2021 11:44 am
Location: Croatia

Re: v7.17beta [testing] is released!

Sat Oct 05, 2024 9:28 pm

Why two ssids ? Just put guest on separate VLAN, assign them password and that's it.
 
PackElend
Member Candidate
Member Candidate
Posts: 272
Joined: Tue Sep 29, 2020 6:05 pm

Re: v7.17beta [testing] is released!

Sat Oct 05, 2024 9:36 pm

Why two ssids ? Just put guest on separate VLAN, assign them password and that's it.
Easier for the user, what they are used to.
GUEST and PRIVATE

There are several flats in the building, each flat has his own VLAN-I'd. Assignment is based on Hotspot login (using eworm's scripts), PPSK in the future.
 
gigabyte091
Forum Guru
Forum Guru
Posts: 1490
Joined: Fri Dec 31, 2021 11:44 am
Location: Croatia

Re: v7.17beta [testing] is released!

Sat Oct 05, 2024 9:40 pm

One thing that came to my mind is to create virtual AP just for guests, without PPSK, and give them one password.
 
PackElend
Member Candidate
Member Candidate
Posts: 272
Joined: Tue Sep 29, 2020 6:05 pm

Re: v7.17beta [testing] is released!

Sat Oct 05, 2024 9:41 pm

But how to deal with the PRIVATE ssid, which requires VLAN assignment based on device, password used
 
gigabyte091
Forum Guru
Forum Guru
Posts: 1490
Joined: Fri Dec 31, 2021 11:44 am
Location: Croatia

Re: v7.17beta [testing] is released!

Sat Oct 05, 2024 9:44 pm

For private SSID use PPSK. Works like a charm for now.
 
PackElend
Member Candidate
Member Candidate
Posts: 272
Joined: Tue Sep 29, 2020 6:05 pm

Re: v7.17beta [testing] is released!

Sat Oct 05, 2024 9:46 pm



WPA3 will never support PPSK as currently implemented. A simple Google query for WPA3 and PPSK will get you all sorts of information from a variety of networking resources.
😭
So there any option to do the vlan separation based on PSK or similar?
Wondering how to deal with the headless devices which can be assigned to an VLAN easily now (with PPSK).
PPSK gets me back to here, WPA3 and alternative way doing PPSK
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 4256
Joined: Sun May 01, 2016 7:12 pm
Location: California
Contact:

Re: v7.17beta [testing] is released!

Sat Oct 05, 2024 11:33 pm

multi-passphrase is not supported for the WPA3-PSK authentication type.
WPA3 will never support PPSK as currently implemented. A simple Google query for WPA3 and PPSK will get you all sorts of information from a variety of networking resources.
[...]
PPSK gets me back to here, WPA3 and alternative way doing PPSK
I believe you can do WPA3 and EAP using the user-manager package. You'd have to enable EAP in Wi-Fi, but you'd can keep WPA3. Since user manager let you set a VLAN (excluding wifi-qcom-ac), it be based on the "user" & "password" in EAP & those could map to in similar PPSK scheme (one user per vlan). As bonus, you'd have more control down to a specific user-level if desired, and without more SSIDs broadcasting.
 
PackElend
Member Candidate
Member Candidate
Posts: 272
Joined: Tue Sep 29, 2020 6:05 pm

Re: v7.17beta [testing] is released!

Sun Oct 06, 2024 12:22 am


WPA3 will never support PPSK as currently implemented. A simple Google query for WPA3 and PPSK will get you all sorts of information from a variety of networking resources.
[...]
PPSK gets me back to here, WPA3 and alternative way doing PPSK
I believe you can do WPA3 and EAP using the user-manager package.
would that a mix if WPA2 and WPA3?
Shouldn't be it WPA3-SAE?

Has anyone tried this approach?
I'm far from home for some time and cannot test that.
 
hapoo
Frequent Visitor
Frequent Visitor
Posts: 59
Joined: Wed Apr 24, 2019 1:35 am

Re: v7.17beta [testing] is released!

Sun Oct 06, 2024 5:05 pm

Bug introduced in ROS 7.16 with :resolve still persists.

If you have a static dns entry for example.com you run:
:resolve example.com server=1.1.1.1
The server is never queried and the static dns entry is returned instead.
 
User avatar
VadiKO
just joined
Posts: 8
Joined: Wed May 20, 2020 11:48 pm
Location: Ukraine

Re: v7.17beta [testing] is released!

Mon Oct 07, 2024 10:47 am

I have to report that the Wi-Fi disable issue is still not resolved... currently the stable version is still 7.14.3
We continue to discuss this in detail here - link
 
packetnerd
just joined
Posts: 1
Joined: Sat Oct 05, 2024 7:31 pm

Re: v7.17beta [testing] is released!

Mon Oct 07, 2024 5:51 pm

fischerdouglas compilation
Lets talk about Hardware Offload?

When will it be possible to use VRF without losing Fast-Path and Hardware Offload features?

+1 this request. Is this newly broken, or has it never worked?

Pretty please, Mikrotik, this is such an important feature.
 
merkkg
just joined
Posts: 15
Joined: Thu Jan 19, 2017 11:50 am

Re: v7.17beta [testing] is released!

Mon Oct 07, 2024 5:57 pm

fischerdouglas compilation
Lets talk about Hardware Offload?

When will it be possible to use VRF without losing Fast-Path and Hardware Offload features?

+1 this request. Is this newly broken, or has it never worked?

Pretty please, Mikrotik, this is such an important feature.
From mikrotik help

Only the main routing table gets offloaded. If VRF is used together with L3HW and packets arrive on a switch port with l3-hw-offloading=yes, packets can be incorrectly routed through the main routing table. To avoid this, disable L3HW on needed switch ports or use ACL rules to redirect specific traffic to the CPU.
 
User avatar
clambert
Member Candidate
Member Candidate
Posts: 160
Joined: Wed Jun 12, 2019 5:04 am

Re: v7.17beta [testing] is released!

Mon Oct 07, 2024 6:12 pm

From my perspective, VRF Hardware Offload in conjunction with MPLS (i.e. MPLS VPNv4) is the most important functionality that should be added.
 
User avatar
spippan
Member
Member
Posts: 459
Joined: Wed Nov 12, 2014 1:00 pm

Re: v7.17beta [testing] is released!

Mon Oct 07, 2024 6:31 pm

From my perspective, VRF Hardware Offload in conjunction with MPLS (i.e. MPLS VPNv4) is the most important functionality that should be added.
wonder if there are any 98DX or other marvell chips in use by MT are able to do this (did not read all whitepapers - maybe someone knows someone who might have some insight 🤷‍♂️ )
 
User avatar
woland
Member
Member
Posts: 310
Joined: Mon Aug 16, 2021 4:49 pm

Re: v7.17beta [testing] is released!

Mon Oct 07, 2024 6:35 pm

wonder if there are any 98DX or other marvell chips in use by MT are able to do this (did not read all whitepapers - maybe someone knows someone who might have some insight 🤷‍♂️ )
viewtopic.php?t=211511
Unfortunately, L3HW doesn't support VRF yet. The hardware (switch chip) supports it, but the feature has not yet been implemented in RouterOS. There are plans to add VRF L3HW, but I cannot share the ETA at the moment of writing.
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 2180
Joined: Mon Jan 14, 2008 1:53 pm
Location: Over the Rainbow
Contact:

Re: v7.17beta [testing] is released!

Tue Oct 08, 2024 8:54 am

From my perspective, VRF Hardware Offload in conjunction with MPLS (i.e. MPLS VPNv4) is the most important functionality that should be added.
wonder if there are any 98DX or other marvell chips in use by MT are able to do this (did not read all whitepapers - maybe someone knows someone who might have some insight 🤷‍♂️ )
They definitely are able to.
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 2180
Joined: Mon Jan 14, 2008 1:53 pm
Location: Over the Rainbow
Contact:

Re: v7.17beta [testing] is released!

Tue Oct 08, 2024 8:57 am

From my perspective, VRF Hardware Offload in conjunction with MPLS (i.e. MPLS VPNv4) is the most important functionality that should be added.
I agree, but Mikrotik cannot just add HW offloading. They need to add FastPath offloading for MPLS Push/Pop including VRF's (L3VPN/VPNv4/VPNv6)

The Marvell based platforms are a very small part of their entire portfolio, and FastPath will benefit a lot more devices than just L3HW. Both are needed to deliver the best outcome for Mikrotik's customers.


Not to mention the long overdue IPv6 FastPath module.
 
ivicask
Member
Member
Posts: 438
Joined: Tue Jul 07, 2015 2:40 pm
Location: Croatia, Zagreb

Re: v7.17beta [testing] is released!

Tue Oct 08, 2024 11:06 am

Logs full of connection lost for various devices
For example Samsung soundbar not moving inch, standing next to HAP AX3.
disconnected, connection lost, signal strength -24
disconnected, connection lost, signal strength -32
etc..

Also devices sometimes roam from 5 ghz to 2ghz again under for signal for no reason, or even flap around, 5ghz>2ghz>5ghz in like minute while not moving and under full signal (3m from router)

Disabled WPA3, disabled FT, etc, think i tried about everything.
Its same on 7.16 and 7.15...
Reverting to 7.14.3 fixes the problem.
 
User avatar
spippan
Member
Member
Posts: 459
Joined: Wed Nov 12, 2014 1:00 pm

Re: v7.17beta [testing] is released!

Tue Oct 08, 2024 12:37 pm

wonder if there are any 98DX or other marvell chips in use by MT are able to do this (did not read all whitepapers - maybe someone knows someone who might have some insight 🤷‍♂️ )
viewtopic.php?t=211511
Unfortunately, L3HW doesn't support VRF yet. The hardware (switch chip) supports it, but the feature has not yet been implemented in RouterOS. There are plans to add VRF L3HW, but I cannot share the ETA at the moment of writing.
thanks for the link
 
User avatar
clambert
Member Candidate
Member Candidate
Posts: 160
Joined: Wed Jun 12, 2019 5:04 am

Re: v7.17beta [testing] is released!

Tue Oct 08, 2024 2:20 pm

I agree, but Mikrotik cannot just add HW offloading. They need to add FastPath offloading for MPLS Push/Pop including VRF's (L3VPN/VPNv4/VPNv6)
The Marvell based platforms are a very small part of their entire portfolio, and FastPath will benefit a lot more devices than just L3HW. Both are needed to deliver the best outcome for Mikrotik's customers.
Not to mention the long overdue IPv6 FastPath module.
Totally agree. I'm confident they can implement that, considering the recent implementation of FastPath for VPLS.
 
User avatar
spippan
Member
Member
Posts: 459
Joined: Wed Nov 12, 2014 1:00 pm

Re: v7.17beta [testing] is released!

Tue Oct 08, 2024 3:00 pm

a roadmap would be nice (*wishful thinking*)
 
User avatar
fischerdouglas
Frequent Visitor
Frequent Visitor
Posts: 69
Joined: Thu Mar 07, 2019 6:38 pm
Location: Brazil
Contact:

Re: v7.17beta [testing] is released!

Tue Oct 08, 2024 3:10 pm

I agree, but Mikrotik cannot just add HW offloading. They need to add FastPath offloading for MPLS Push/Pop including VRF's (L3VPN/VPNv4/VPNv6)
The Marvell based platforms are a very small part of their entire portfolio, and FastPath will benefit a lot more devices than just L3HW. Both are needed to deliver the best outcome for Mikrotik's customers.
Not to mention the long overdue IPv6 FastPath module.
Totally agree. I'm confident they can implement that, considering the recent implementation of FastPath for VPLS.
I would guess that in order for RouterOS to interact with the chip to give hardware offload orders for features like L3VPN/VPNv4/VPNv6, they would need to do things like update the kernel they use and the Marvell SDK version.

I sincerely doubt they will have the will and courage to do that any time soon.
 
merkkg
just joined
Posts: 15
Joined: Thu Jan 19, 2017 11:50 am

Re: v7.17beta [testing] is released!

Tue Oct 08, 2024 3:27 pm



Totally agree. I'm confident they can implement that, considering the recent implementation of FastPath for VPLS.
I would guess that in order for RouterOS to interact with the chip to give hardware offload orders for features like L3VPN/VPNv4/VPNv6, they would need to do things like update the kernel they use and the Marvell SDK version.

I sincerely doubt they will have the will and courage to do that any time soon.
They should aim to keep up to date with kernel and sdk versions else we have situation like we did from ros6 to ros7 taking years as well as wifi6 taking
 
User avatar
Paternot
Forum Guru
Forum Guru
Posts: 1047
Joined: Thu Jun 02, 2016 4:01 am
Location: Niterói / Brazil

Re: v7.17beta [testing] is released!

Tue Oct 08, 2024 3:59 pm

I would guess that in order for RouterOS to interact with the chip to give hardware offload orders for features like L3VPN/VPNv4/VPNv6, they would need to do things like update the kernel they use and the Marvell SDK version.

I sincerely doubt they will have the will and courage to do that any time soon.
Well, they are using a fairly recent kernel - and the V7 series already had one kernel change. So, I think they learned their lesson with V6, and things are more decoupled this time.
 
merkkg
just joined
Posts: 15
Joined: Thu Jan 19, 2017 11:50 am

Re: v7.17beta [testing] is released!

Tue Oct 08, 2024 4:33 pm

I would guess that in order for RouterOS to interact with the chip to give hardware offload orders for features like L3VPN/VPNv4/VPNv6, they would need to do things like update the kernel they use and the Marvell SDK version.

I sincerely doubt they will have the will and courage to do that any time soon.
Well, they are using a fairly recent kernel - and the V7 series already had one kernel change. So, I think they learned their lesson with V6, and things are more decoupled this time.
How u checking kernel version?
 
elbob2002
Member Candidate
Member Candidate
Posts: 270
Joined: Tue May 15, 2018 8:15 pm
Location: Ireland

Re: v7.17beta [testing] is released!

Tue Oct 08, 2024 5:27 pm

How u checking kernel version?
/system/resource/usb

You should see something like:
0 1-0     Linux 5.6.3-64 uhci_hcd  UHCI Host Controller     12
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 21781
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: v7.17beta [testing] is released!

Tue Oct 08, 2024 6:28 pm

a roadmap would be nice (*wishful thinking*)
Easy Peasy just become a valued investor. ;-)
 
User avatar
eworm
Forum Guru
Forum Guru
Posts: 1090
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: v7.17beta [testing] is released!

Tue Oct 08, 2024 6:29 pm

Well, 5.6.3 is from 2020-04-08. IMHO that is far from recent.

https://git.kernel.org/pub/scm/linux/ke ... /?h=v5.6.3
 
User avatar
Paternot
Forum Guru
Forum Guru
Posts: 1047
Joined: Thu Jun 02, 2016 4:01 am
Location: Niterói / Brazil

Re: v7.17beta [testing] is released!

Tue Oct 08, 2024 7:13 pm

Well, 5.6.3 is from 2020-04-08. IMHO that is far from recent.
True - but is far from ancient. I said "fairly", I didn´t say "brand new". As long as Mikrotik keeps up with security patches - and backport them to this version - things will work.
At some point (I hope in a reasonably near future), it would be good to have a newer kernel. It must be balanced against what the hardware maker supports though. If Marvell, Qualcomm or <whatever> doesn't have SDK and drivers to a newer kernel... well, Mikrotik will have to keep the latest possible version, until hardware is deprecated.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7174
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: v7.17beta [testing] is released!

Tue Oct 08, 2024 7:17 pm

Kernel version have been discussed many times before and like it was mentioned before it is being patched, so you cannot say that it is 5.6.3 in the form as it came out in 2020. Kernel version is updated when it is absolutely necessary or the actual gains are worth the effort.
 
Network5
newbie
Posts: 30
Joined: Sat Mar 22, 2014 11:42 pm

Re: v7.17beta [testing] is released!

Tue Oct 08, 2024 8:17 pm

Speaking about MPLS / VPLS, did someone try to see if the last versions are still losing packets on CCR2216? As far as I know, it is still an unresolved issue.
 
infabo
Forum Guru
Forum Guru
Posts: 1447
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.17beta [testing] is released!

Tue Oct 08, 2024 9:49 pm

Kernel version have been discussed many times before and like it was mentioned before it is being patched, so you cannot say that it is 5.6.3 in the form as it came out in 2020. Kernel version is updated when it is absolutely necessary or the actual gains are worth the effort.
I am sure a XKCD comics exists for this.
 
User avatar
Paternot
Forum Guru
Forum Guru
Posts: 1047
Joined: Thu Jun 02, 2016 4:01 am
Location: Niterói / Brazil

Re: v7.17beta [testing] is released!

Tue Oct 08, 2024 9:52 pm

I am sure a XKCD comics exists for this.
At this point, I`m convinced there is one XKCD for everything in life.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 4256
Joined: Sun May 01, 2016 7:12 pm
Location: California
Contact:

Re: v7.17beta [testing] is released!

Tue Oct 08, 2024 11:52 pm

What's new in 7.16 (2024-Sep-20 16:00):
*) console - added additional byte-array option to :convert command;
*) console - improved :serialize and :deserialize commands and added support for DSV (delimiter separated values) format;
What's new in 7.17beta2 (2024-Sep-27 10:07):
*) console - added to/from=num option for :convert command;
Thank you @Mikrotik for these!

For other folks, I wrote up [dense] examples of new ":convert" and ":serialize" methods – since the usage of the above new scripting function may not be clear from the RN:
CSV parsing ([de]serialize's =dsv)
binary/IOT/"hexstring" data parsing (convert's =byte-array =bit-array =hex =num)

With 7.17 specifically, ":convert from=num to=raw" adds converting from an ASCII code, into a letter (among other uses). Combined with "inkey" to collect a single character but returns a numeric ("num") ASCII code, so if you want to match on a letter, it's much shorter now.
:put "Press 'y' to continue, or any other key to abort"
:if ( [:convert from=num to=raw [/terminal/inkey]] != "y" ) do={ :error "script stopped by user" }
# more code after 'y' key ...
 
User avatar
msilcher
just joined
Posts: 7
Joined: Mon Mar 09, 2009 9:39 pm
Location: Argentina

Re: v7.17beta [testing] is released!

Wed Oct 09, 2024 3:26 pm

fischerdouglas compilation
Have you MikroTik guys considered splitting the DNS service as was done with the Wifi packages?
Separating different things of different interest into Packages?
Embedded in RouterOS DNS being just a regular AND SIMPLE DNS relay/recursive.
Focused on attending to the requirements of scenarios of home and basic device-modes.
An extra dns.npk designed to be a more complex DNS service, with all the more advanced features that already exist on actual DNS, and other ones that were not included because it complicates much of the basic.
It would reduce the probability of simple issues affecting a huge number of devices.
Would make it easier to do some demands that are a pain to deploy in the current scenario(like VRF on outgoing queries).
It would also prevent less experienced users from getting into trouble by messing with settings that don't need to exist in more basic scenarios.
In regards to have a "more advanced" DNS service in a separate package is not a bad idea at all, I like it!!
Actually there are a lot of features missing in the DNS service that could be addressed. Users who don't need additional features could stick to the integrated basic DNS service.
 
User avatar
spippan
Member
Member
Posts: 459
Joined: Wed Nov 12, 2014 1:00 pm

Re: v7.17beta [testing] is released!

Wed Oct 09, 2024 3:53 pm

fischerdouglas compilation
Have you MikroTik guys considered splitting the DNS service as was done with the Wifi packages?
Separating different things of different interest into Packages?
....
In regards to have a "more advanced" DNS service in a separate package is not a bad idea at all, I like it!!
Actually there are a lot of features missing in the DNS service that could be addressed. Users who don't need additional features could stick to the integrated basic DNS service.
would like to see that to. +1

additionally, splitting up services / make services more modular would be a great feature anyways. put smb, dlna, mpls, proxy and so on into separate packages like wireless, wifi-qcom(-ac) or rose.
this even helps saving storage footprint and modules which need to get loaded at bootup!
 
turan
just joined
Posts: 13
Joined: Wed Jul 26, 2023 8:28 pm

Re: v7.17beta [testing] is released!

Wed Oct 09, 2024 4:25 pm

there is an issue in hotspot html directory,
if i set "flash/hotspot" it becomes "flash/flash/hotspot" and so on.
keep adding flash/

Board: 750gr3
Last edited by turan on Sat Oct 12, 2024 3:17 pm, edited 1 time in total.
 
jpeppard
just joined
Posts: 7
Joined: Fri May 05, 2023 2:16 am

Re: v7.17beta [testing] is released!

Wed Oct 09, 2024 5:59 pm

Can anyone else confirm that the packet loss has increased in 7.17beta2 by comparision to 7.16. I noticed websites failing to load on 7.17beta2 and tested using https://speed.cloudflare.com/. I saw in "Packet Loss Measurements" between 1% to 10% lost packets and never 0% of lost packets. I downgraded to 7.16 and most are 0% of lost packets and the highest lost packets was 0.5% of lost packets.

To me its obvious that 7.17beta2 is loosing packets. I turned off all queues and same results.
Tested on my side, running CCR2004-16g-2S+ on 7.17beta2. No packet loss detected on multiple runs of cloudflare speed test.
 
noradtux
newbie
Posts: 39
Joined: Mon May 24, 2021 6:33 pm

Re: v7.17beta [testing] is released!

Wed Oct 09, 2024 7:04 pm

Logs full of connection lost for various devices
For example Samsung soundbar not moving inch, standing next to HAP AX3.
disconnected, connection lost, signal strength -24
disconnected, connection lost, signal strength -32
etc..

Also devices sometimes roam from 5 ghz to 2ghz again under for signal for no reason, or even flap around, 5ghz>2ghz>5ghz in like minute while not moving and under full signal (3m from router)

Disabled WPA3, disabled FT, etc, think i tried about everything.
Its same on 7.16 and 7.15...
Reverting to 7.14.3 fixes the problem.
Look if DHCP is working. I had devices disconnecting and reconnecting but had in fact an issue with DHCP snooping.
Last edited by noradtux on Fri Oct 11, 2024 8:23 am, edited 1 time in total.
 
nmt1900
Frequent Visitor
Frequent Visitor
Posts: 85
Joined: Wed Feb 01, 2017 12:36 am

Re: v7.17beta [testing] is released!

Wed Oct 09, 2024 7:36 pm

That might have some truth in it - some devices are so stupid that they "resolve" loss of their IP address configuration by disconnecting from wifi network.
 
Sit75
just joined
Posts: 12
Joined: Thu Mar 11, 2021 9:43 pm

Re: v7.17beta [testing] is released!

Wed Oct 09, 2024 8:36 pm

Can anyone else confirm that the packet loss has increased in 7.17beta2 by comparision to 7.16. I noticed websites failing to load on 7.17beta2 and tested using https://speed.cloudflare.com/. I saw in "Packet Loss Measurements" between 1% to 10% lost packets and never 0% of lost packets. I downgraded to 7.16 and most are 0% of lost packets and the highest lost packets was 0.5% of lost packets.

To me its obvious that 7.17beta2 is loosing packets. I turned off all queues and same results.
Tested on my side, running CCR2004-16g-2S+ on 7.17beta2. No packet loss detected on multiple runs of cloudflare speed test.
I can not confirm, no any visible packet loss (7.17beta2 cloudflare) on hAP ac^2 IPv6/IPv4 VDSL2 110/25 from Czechia.
 
ofca
Member Candidate
Member Candidate
Posts: 229
Joined: Fri Aug 20, 2004 7:18 pm

Re: v7.17beta [testing] is released!

Wed Oct 09, 2024 11:56 pm

What is your proposal, to verify ownership of a device in a way, that a remote attacker can't do?
An option in /system routerboard that will be available for 24 hours since upgrade/since first boot/since running a command confirmed with button press/since running a command confirmed with power cycle, that will return a random 16 character string, that will also be permanently written to the device. This random 16 character string may then be used to authorize restricted operations remotely. What's wrong with this? Why can't we have good things?
 
guipoletto
Member Candidate
Member Candidate
Posts: 201
Joined: Mon Sep 19, 2011 5:31 am

Re: v7.17beta [testing] is released!

Thu Oct 10, 2024 2:00 am

What is your proposal, to verify ownership of a device in a way, that a remote attacker can't do?
An option in /system routerboard that will be available for 24 hours since upgrade/since first boot/since running a command confirmed with button press/since running a command confirmed with power cycle, that will return a random 16 character string, that will also be permanently written to the device. This random 16 character string may then be used to authorize restricted operations remotely. What's wrong with this? Why can't we have good things?
Try keeping track of this across tousands of remotelly managed devices, it would be chaos. Random factory passwords are already bad enough!
 
User avatar
chechito
Forum Guru
Forum Guru
Posts: 3115
Joined: Sun Aug 24, 2014 3:14 am
Location: Bogota Colombia
Contact:

Re: v7.17beta [testing] is released!

Thu Oct 10, 2024 4:57 am


What about us that operate as WISP, ISP or consultants deploying devices and are soon ready to upgrade past 7.17+. Would we then need to schedule maintenance AND truck rolls to touch EACH device in order to properly change device-mode? Or we have to instruct the customers / end-users we need them to perform XYZ steps due to a security rollout? Otherwise, we decide to stay away from 7.17. Hard to stay away, especially when have future wireless enhancements -- AX is broken. [mANTBox 15 ax]
i operate hundreds of devices in multiple locations and several countries as an external consultant, some features that will be blocked in 7.17 i use it frecuently so i will have to stay on 7.16 because of this extreme measures
 
User avatar
chechito
Forum Guru
Forum Guru
Posts: 3115
Joined: Sun Aug 24, 2014 3:14 am
Location: Bogota Colombia
Contact:

Re: v7.17beta [testing] is released!

Thu Oct 10, 2024 5:02 am

What will you be using traffic gen for, in this remote router? There is no need for theoretic, like I said
i use traffic gen on a daily basis for performance testing and bandwidth validation i will have to stay on 7.16 because of this being disabled on 7.17, is very expensive to move personel to every site at off peak hours, paying hotel, etc, to do this upgrades and do the procedure to activate this features on production equipment
 
User avatar
nichky
Forum Guru
Forum Guru
Posts: 1387
Joined: Tue Jun 23, 2015 2:35 pm

Re: v7.17beta [testing] is released!

Thu Oct 10, 2024 5:07 am

does TE work on v7?
 
User avatar
coddy
just joined
Posts: 3
Joined: Mon Nov 11, 2013 7:13 am

Re: v7.17beta [testing] is released!

Thu Oct 10, 2024 10:33 am

@ofca, @mikrotik,

Another option would be to have a token that can be user settable for say 30 minutes after initial upgrade to v7.17 or first power on if already 7.17+. After that period of time you would need to set a flag and power cycle or reset the device to allow the token to be set again. Once the token is set to nvram the only way to change it would be set a flag and power cycle or reset. This covers someone downgrading and upgrading again to get the 30 minute window (if the user had allowed that already).

Having a user settable token is much easier for enterprises/businesses to handle as they can standardise it.

If you are concerned this could lead to poor token complexity you could have a command to generate a token, have a checksum in the token to ensure its a generated random token. Then only allow 'generated' tokens to be set. The admin would generate a token on one device and use that securely generated token across all devices. Simple as hashSha256('someRandomStringThatOnlyMTknows' | <32 byte random array>) and taking the last 8 bytes of the hash as the 'checksum', then take the combined (in any way you wish) 40 byte result mime encode and present to the user. A secure string that is highly probable to be MT generated and is random and secure with 256 bit strength.

This would allow enterprises to manage their upgrade to 7.17, set a highly secure key that when used would allow the admin to change options without power cycle or reset.

It allows for flexibility as to how the enterprise wants to manage the key(s). They could generate a key, set it and record it (encrypted) against the devices base MAC in a database somewhere on a per device basis.

They could generate a key to be used on a group of devices and record that in a password manager.

I appreciate the need for MT to secure these devices and it is great they are working on options to do it. I also fully agree that this needs to be manageable by IT teams, and especially the transition.

I hope MT takes onboard this approach, and turn this in to a win for everyone.
 
infabo
Forum Guru
Forum Guru
Posts: 1447
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.17beta [testing] is released!

Thu Oct 10, 2024 10:55 am

Mikrotik won't adopt this approach. The introduced the "downgrade" flag so an attacker can not downgrade to an insecure ROS version.

In the proposed case of token within 30minutes of initial upgrade to 7.17, the pitfalls are clear:

attacker gains access to device running < 7.17 somehow. Hits upgrade button; the token is presented to the attacker. Now the attacker can enable "downgrade" flag, enable e.g. "scheduler" or whatever device mode property that was previously disabled. Finally downgrade to previous ROS version. An admin without remote logging or remote uptime checks would notice that. It would only take some minutes for upgrade and downgrade again.

Or an attacker that does not want to "sneak into" but wants to make your life hard: Hits upgrade button, knows the token now and sets device-mode to "home". Now you have a "dumb" device instead of your previously full fledged router.

Would be a pretty effort to reset such a device to "advanced" mode again. It would not just involve netinstall, additionally some power cycle or button presses.

But I must admit: it is the best alternative approach suggestion so far. But it has this major pitfall.
 
sinisa
newbie
Posts: 34
Joined: Sun Apr 17, 2011 12:46 am

Re: v7.17beta [testing] is released!

Thu Oct 10, 2024 11:19 am

I must add that this device-mode change was not thought enough in advance, but pushed on us users in some sort of "let's see if anybody would complain" way. Luckily, it's only in beta, so it should be easy to go back and think things over.
You (Mikrotik) are asking us (users) about "Device Controller" that is not even on horizon (and that most don't care about because they have already got things under control), but did not bother to ask about "security" feature that WILL affect (in most negative way - by hitting their wallets) everyone already using MT devices unless they decide to never update past 7.16 (so bye-bye to "lifetime updates").
PLEASE make this completely optional, let us know that it exists and that we CAN lock-down the devices we WANT to, even remind us every time like with default passwords if you must, but don't force this on us!
 
nmt1900
Frequent Visitor
Frequent Visitor
Posts: 85
Joined: Wed Feb 01, 2017 12:36 am

Re: v7.17beta [testing] is released!

Thu Oct 10, 2024 11:30 am

Mikrotik will now either try (again) to make case that "nothing will change for devices that are already set up" - which is highly questionable (except when you do not use features to be locked out) or will be just ignoring this specific issue here.

Or will it go some other way (?)...
 
infabo
Forum Guru
Forum Guru
Posts: 1447
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.17beta [testing] is released!

Thu Oct 10, 2024 11:50 am

I see no other solution than to activate the new device mode defaults only for factory-new devices. Unless someone has a really secure alternative to that power-off/button-press thing that can confirm changes without physical access.

And one reminder: only a few are reading/following beta topics. This discussion will go through the roof - if really introduced in stable version.
 
User avatar
coddy
just joined
Posts: 3
Joined: Mon Nov 11, 2013 7:13 am

Re: v7.17beta [testing] is released!

Thu Oct 10, 2024 11:54 am

@infabo, I like how you think, but we need to find a suitable path forward. The pitfall, I guess falls into the "you can't trust a compromised device/pc/mac/toaster" category. You should netinstall such a device or 'recycle it' (rubbish bin).

(A possible workaround would be to only allow the 'devicekey' to be set in that 30 minute window via api/ssh/console/web but not a scheduled script. This would make it much harder for the attacker to maintain their foothold via a scheduled script - yes I can see ways around this too, but again its a compromised device to begin with trust = zero, but we can make them work harder for it, and since the 'door' is already open you probably have much bigger issues inside your network now than power cycling a device! Ransomware/wiper/multiple footholds bell ringing....).

If after upgrading you find you can't set the device key because it has already been set, that should set alarm bells ringing too. Again easy for an enterprise/ISP, they upgrade a device via api/ssh, wait for it to come back online, using api/ssh set the device key, failure to set results in a flagged device. Quarantine/bin.

The point of what I am proposing is to enable enterprises/ISPs to maintain their devices securely and remotely. Again, I am aiming for the win-win if possible. There are probably variations of what I am suggesting, but this fits into what most enterprises/ISPs could easily manage and keeps a very high degree of security by enforcing a strong random 'deviceKey'.

Please Mikrotik strongly consider this
 
ofca
Member Candidate
Member Candidate
Posts: 229
Joined: Fri Aug 20, 2004 7:18 pm

Re: v7.17beta [testing] is released!

Thu Oct 10, 2024 12:37 pm


An option in /system routerboard that will be available for 24 hours since upgrade/since first boot/since running a command confirmed with button press/since running a command confirmed with power cycle, that will return a random 16 character string, that will also be permanently written to the device. This random 16 character string may then be used to authorize restricted operations remotely. What's wrong with this? Why can't we have good things?
Try keeping track of this across tousands of remotelly managed devices, it would be chaos. Random factory passwords are already bad enough!
We already do. We manage over 7 thousand routers, have daily backups of configuration of each. Adding one more string to the database should take one man-hour with testing by my estimates +/- 30 min.
 
ofca
Member Candidate
Member Candidate
Posts: 229
Joined: Fri Aug 20, 2004 7:18 pm

Re: v7.17beta [testing] is released!

Thu Oct 10, 2024 12:44 pm

Mikrotik won't adopt this approach. The introduced the "downgrade" flag so an attacker can not downgrade to an insecure ROS version.
wait, what? So... if attacker gets access to sub 7.17 device they will upgrade to 7.17 to get the token, that will allow them to downgrade? :D
 
infabo
Forum Guru
Forum Guru
Posts: 1447
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.17beta [testing] is released!

Thu Oct 10, 2024 12:48 pm

That's one part I said. Read my full comment and/or don't quote an excerpt which makes no sense standalone quoted.
 
ofca
Member Candidate
Member Candidate
Posts: 229
Joined: Fri Aug 20, 2004 7:18 pm

Re: v7.17beta [testing] is released!

Thu Oct 10, 2024 1:10 pm

That's one part I said. Read my full comment and/or don't quote an excerpt which makes no sense standalone quoted.
You seem to be forgetting that reverting "dumb" device to "uber-smart" device is one button-push/power cycle away. This is merely a convenience for people controlling thousands of devices. "Normal" users could simply ignore it, and their routers would lockdown after n hours post-upgrade. Resetting this password could be implemented the same way.
 
ofca
Member Candidate
Member Candidate
Posts: 229
Joined: Fri Aug 20, 2004 7:18 pm

Re: v7.17beta [testing] is released!

Thu Oct 10, 2024 4:11 pm

Actually, now that I think about this a little more, instead of forcing an arbitrary device setting requiring reboots and button voodoo, perhaps what we all are looking for is some "superuser" (superadmin?) mode that requires the knowledge of an out-of-band password, like the one you can find on a sticker on the device? This way all routers could start in "home" mode, and enabling superadmin mode would allow setting which features are available to normal admins, and which require superadmin.

Ways to get the superadmin password:
- remotely in /system routerboard menu - using this option would require a button-push / power cycle confirmation, and then it would be possible to see the password only once, before reverting to previous locked state. Admin would make a note of it, or, in our case, our management system would make a note of it)
- one exemption to the above would be the upgrade to 7.17 from a version that didn't have the feature - it would be possible to see the password only once during first 24 hours after an upgrade.

Since this is only relevant to post 7.17 devices, the fact that some theoretical attacker could get hold of the password by upgrading to 7.17+ doesn't matter, since they could already downgrade to whatever vulnerable version they wish without doing pointless steps.
 
infabo
Forum Guru
Forum Guru
Posts: 1447
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.17beta [testing] is released!

Thu Oct 10, 2024 4:15 pm

You seem to be forgetting that reverting "dumb" device to "uber-smart" device is one button-push/power cycle away.
Well, what is then this whole discussion about when it is all just a "button-push/power cycle" away?

You can really piss someone's leg really hard by changing device mode to "dumb device" mode when physical access is not easy.
 
User avatar
genesispro
Member
Member
Posts: 304
Joined: Fri Mar 14, 2014 12:33 pm

Re: v7.17beta [testing] is released!

Thu Oct 10, 2024 7:05 pm

lte - added provider specific firmware update (FOTA) for Cosmote GR networks on Chateau 5G;

so can anyone explain in depth what is that? It could be interesting
 
foegra
just joined
Posts: 10
Joined: Wed Jan 31, 2024 6:53 pm

Re: v7.17beta [testing] is released!

Thu Oct 10, 2024 8:26 pm

I've been always using container running on USB on my Mikrotik device.
When tried switching from 7.17beta2 to 7.16 -> none of the containers would start.
I've noticed, while extracting - they were filling up internal memory, despite usb device path is set for pulling containers.

Does anyone know - how to go back to stable and still have containers running?
 
raffav
Member
Member
Posts: 345
Joined: Wed Oct 24, 2012 4:40 am

Re: v7.17beta [testing] is released!

Thu Oct 10, 2024 8:31 pm

You seem to be forgetting that reverting "dumb" device to "uber-smart" device is one button-push/power cycle away.
Well, what is then this whole discussion about when it is all just a "button-push/power cycle" away?

You can really piss someone's leg really hard by changing device mode to "dumb device" mode when physical access is not easy.

And what about if Mk create a tool in Mk account portal like the branding tool that generate a special package that you install on the device and reboot that will allow to enable the device to advance mode
They can create some sort of authentication that validate that is really you that trying to perform that change..
Or something like that...
 
FezzFest
Frequent Visitor
Frequent Visitor
Posts: 95
Joined: Wed Jun 03, 2015 12:03 am

Re: v7.17beta [testing] is released!

Fri Oct 11, 2024 12:20 am

Or, hear me out, what if they just allow people upgrading to v7.17 to keep existing functionality and simply introduce these new lockdown measures on new devices? That would still improve security while simultaneously not screwing over existing users in some way or another.
 
User avatar
coddy
just joined
Posts: 3
Joined: Mon Nov 11, 2013 7:13 am

Re: v7.17beta [testing] is released!

Fri Oct 11, 2024 4:18 am

ok, the main points of what I was proposing to ease this transition:

On first upgrade to 7.17, or initial power-on or netinstall with 7.17+
  • Display or have available (/system/routerboard/get device-token) a secure device token string for a limited period of time (30 minutes)
  • The admin can copy this token and record it against the device
  • During this 30 minutes the admin can CHANGE the device token (/system/routerboard/set device-token="newSecureToken")
  • During this 30 minutes the admin can SET secure device options as needed (downgrade, boot partitions, container use, etc) without being prompted to power-cycle/reset.
After 30 minutes/Second+ boot
  • The device token becomes inaccessible (/system/routerboard/get device-token returns null)
  • Changing secure device options, including the device-token would require adding the a device-token="..." to the command to enable it without requiring a power-cycle/reboot - this critically enables enterprises/ISPs/SMBs to continue to manage these and any future options without visiting/remotely power-cycling devices
  • The admin can also set the secure device options and device-token without using the device-token, but they will then be prompted to power-cycle or reset in the next 5 minutes
Rational
  • This would give a 'grace' window for setting options without having to go through the power-cycle/reset procedure
  • This would enable enterprises/ISPs/SMBs to record, and/or set their own device token in a way that works with their existing procedures
  • For instance, unique device token per device can be recorded in a database using a script to obtain them in the 30 minutes post upgrade
  • Or the admin can set a known device-token across a group of devices and have that recorded in a password manager
  • It also allows for the existing set and require a power-cycle/reset procedure
This will not satisfy everyone, if your device is already compromised, then netinstall it, or 'recycle' it.

I would hope that it covers the vast majority of needs out there, and allows for easy integration with existing workflows, would work with scripting.

It is constructive, flexible, and I hope, achieves the presumed goal of ESTABLISHING a secure base in-case of FUTURE compromise.
 
Pomo
just joined
Posts: 14
Joined: Sat Feb 06, 2016 10:09 pm

Re: v7.17beta [testing] is released!

Fri Oct 11, 2024 7:47 am

On restart hap ac3:
No routes injected from pppoe.
No routes injected from LTE.
Uploaded 7.16 files, downgrade button did nothing -> had a look, device mode probably.
Eventually, after rebooting for 5 times, got a default route from pppoe, downgraded via quickset.
 
User avatar
Coughy
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Tue Apr 23, 2024 2:53 am
Location: Brisbane Au

Re: v7.17beta [testing] is released!

Fri Oct 11, 2024 10:56 am

Please Team Mikrotik can we have a new tester firmware for the AX devices to some what work with AX CAPS in CAPsMAN
the reauthenticating errors and disconnects are getting annoying and shouldn't be there as we cant use the full functions on the devices.

PS yes i do have wpa3 disabled but why should i have to? and i have tried just about every trick test under the sun to get working from this forums but still no go
so has to be hardware / firmware / ROS

PPSS Yes i did a reset of the devices to default up dated all firmware all running current beta and a complete new config still issues GGGRRR
 
infabo
Forum Guru
Forum Guru
Posts: 1447
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.17beta [testing] is released!

Fri Oct 11, 2024 11:29 am

Maybe this is the time to "re-activate" the development channel.
 
noradtux
newbie
Posts: 39
Joined: Mon May 24, 2021 6:33 pm

Re: v7.17beta [testing] is released!

Fri Oct 11, 2024 8:04 pm

It's a beta. Issues are to be expected. If it doesn't work properly for you, just downgrade and maybe try the next beta.
 
infabo
Forum Guru
Forum Guru
Posts: 1447
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.17beta [testing] is released!

Fri Oct 11, 2024 8:31 pm

It's a beta. Issues are to be expected. If it doesn't work properly for you, just downgrade and maybe try the next beta.
In case it was targeted at me: I have not the guts to try this beta at all. I am done with betas. First and last time I tried was 7.15beta6 and I had to involuntary netinstall because device did not boot up.

Coughy volunteered as tester for new firmware containing possible wifi fixes. That's why I proposed to use the development channel for that case. Testing channel progress is probably too slow. So let's use development channel to go edge.
 
User avatar
fischerdouglas
Frequent Visitor
Frequent Visitor
Posts: 69
Joined: Thu Mar 07, 2019 6:38 pm
Location: Brazil
Contact:

Re: v7.17beta [testing] is released!

Fri Oct 11, 2024 10:57 pm

Kernel version have been discussed many times before and like it was mentioned before it is being patched, so you cannot say that it is 5.6.3 in the form as it came out in 2020. Kernel version is updated when it is absolutely necessary or the actual gains are worth the effort.
Can Mikrotik team say that Kernel version that is used has nothing to do with the inability to do hardware offload of VXLAN, MPLS L3VPN and L2VPN, and several other features?

If you say that it has nothing to do with it, I will not suggest anymore that should be updated.

But, SKDs of switchchips are offenly demanding that kind of updates.
 
User avatar
Coughy
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Tue Apr 23, 2024 2:53 am
Location: Brisbane Au

Re: v7.17beta [testing] is released!

Fri Oct 11, 2024 11:48 pm

It's a beta. Issues are to be expected. If it doesn't work properly for you, just downgrade and maybe try the next beta.
So you Don't read the forums??
there is literally everyone complaining about the AX series in everything Mikrotik
so we are all trying to get a fix and get the working hardware we all shelled out good money for to work as Mikrotik have marketed it to do
but so far nothing fix's the ax series Wi-Fi is behind the competitors And very unstable since its release
it has been Meany months now and still no fix this is why we try betas and try to get them more often
lets be honest here we don't need all the 1000000000 implementations they doing on the next beta
LETS JUST GET A SOILD PLATFORM and FIRMWARE to start with and all its features working as intended like the AX series then they can build up from there
then i wont have to come on here and ask every few weeks for a new beta as my devices will just WORK
cheers rant over
Please TEAM Mikrotik solid base to start then use betas to add and test

I would like to see the development channel back for this area to test
 
User avatar
Coughy
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Tue Apr 23, 2024 2:53 am
Location: Brisbane Au

Re: v7.17beta [testing] is released!

Sat Oct 12, 2024 10:00 am

On this development testing
Why cant we have the update broken down in to smaller manageable updates like the list is so long
to be honest I'm not interested or wont to no about 1/2 of it but some do
so why Mikrotik team cant we break the updates down in to like 3 or 4 sections and use the development update as like this
7.17 beta2 A with 1/3 of fix's with base ros
7.17 beta2 B with next 1/3 of fix's with base ros
7.17 beta C with last fix's with baser ros
7.17 beta2 as all combined
this way we can test and see if anything is fixed on a smaller beta
so this way i can test the areas i need to test and should get faster betas as im not waiting for all the tests to get finished which im not worried about really at the moment
and i can test the ones i wont to test and upgraded firmware's
please consider this option
so we as end user don't loose customers and or hardware becaues it is getting silly now
my hapax3 was released with 7.8 and it still isn't working as intended after NUMEROUS updates
So pls think about us the end user
 
noradtux
newbie
Posts: 39
Joined: Mon May 24, 2021 6:33 pm

Re: v7.17beta [testing] is released!

Sat Oct 12, 2024 11:38 am

It's a beta. Issues are to be expected. If it doesn't work properly for you, just downgrade and maybe try the next beta.
So you Don't read the forums??
No, I don't read "the forums", the signal to noise ration is too low in many cases. I read selected threads in this forum in search of information and maybe to contribute some information if I just found a way to solve or work around an issue. If you have issues with your stuff, open a support ticket. Once they start working on your bug they might even give you test-firmwares which address just your specific thing. It really works :) In my experience so far Mikrotik are a lot more responsive than what I am used from the likes of Cisco and Fortinet …

I guess everyone has it's own perspective. I for one do not have issues with AX on my Chateau, it is running quite fine. But again: If a beta fixes a bug for you, that's great. That means it will quite probably also be fixed in the next stable. If there are new issues (so far I see none for _my_ setup), please open a bug report so it can be fixed for next stable.
 
infabo
Forum Guru
Forum Guru
Posts: 1447
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.17beta [testing] is released!

Sat Oct 12, 2024 12:14 pm

Creating support ticket is the most effective tool we have.
 
buset1974
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Wed Sep 13, 2006 12:12 pm
Location: Jakarta

Re: v7.17beta [testing] is released!

Sat Oct 12, 2024 5:24 pm

Speaking about MPLS / VPLS, did someone try to see if the last versions are still losing packets on CCR2216? As far as I know, it is still an unresolved issue.
that kind of problem in MPLS/VPLS happen since v6 anyway
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 4256
Joined: Sun May 01, 2016 7:12 pm
Location: California
Contact:

Re: v7.17beta [testing] is released!

Sat Oct 12, 2024 6:52 pm

Creating support ticket is the most effective tool we have.
* with a supout.rif - even if you think the problem is obvious and easily tested...

In same PSA category... if someone does try 7.17... then find a problem and downgrades... I'd recommend always generating the supout.rif before downgrade, just in case it's needed. The RIF file no doubt help Mikrotik process a ticket better since it has config/logs. And useful without a ticket, since www.mikrotik.com has a "RIF file viewer" (if you setup a free account) — this let you downgrade and then "look" at the RIF yourself later... after the system is downgrade+service restored.
 
actck
just joined
Posts: 3
Joined: Sun Apr 16, 2017 10:13 am

Re: v7.17beta [testing] is released!

Sun Oct 13, 2024 7:12 am

Counter wrong. There is no RX activity on vlan4039 why it show about 1G? And why TX counter on vlan4039 is double ?
You do not have the required permissions to view the files attached to this post.
 
User avatar
dang21000
Frequent Visitor
Frequent Visitor
Posts: 54
Joined: Sat Feb 25, 2023 2:30 pm
Location: France

Re: v7.17beta [testing] is released!

Mon Oct 14, 2024 10:50 am

bridge - added interface-list support for VLAN : the best features!!!!

This will simplify VLAN tables!thank you mikrotik.
 
robertpenz
Member Candidate
Member Candidate
Posts: 104
Joined: Mon Oct 10, 2011 8:41 am

Re: v7.17beta [testing] is released!

Mon Oct 14, 2024 10:59 am

What is your proposal, to verify ownership of a device in a way, that a remote attacker can't do?
Put a QR Code on the router which we can scan and save in our management software before deploying the routers. If we need later in a remote location a feature activated which we did not previously, we can enable it and provide the code via CLI. It also helps if someone remote can provide the code without traffic interruption - it also allows collecting the codes over a longer period of time and activating the feature in maintaince window.

Otherwise, you need to set the device mode to full for all systems, as maybe you need it sometime in the future - it would be more secure to active only the mode you need at the time, but this requires a way to change it at runtime.
 
User avatar
dang21000
Frequent Visitor
Frequent Visitor
Posts: 54
Joined: Sat Feb 25, 2023 2:30 pm
Location: France

Re: v7.17beta [testing] is released!

Mon Oct 14, 2024 7:17 pm

Does the vlan interface list assignment in bridge can help the new behavior with qcomac driver that doesn't support vlan in data path..?
 
User avatar
dang21000
Frequent Visitor
Frequent Visitor
Posts: 54
Joined: Sat Feb 25, 2023 2:30 pm
Location: France

Re: v7.17beta [testing] is released!

Mon Oct 14, 2024 8:32 pm

Bug with device-mode and switch between partitions.
Like expected in doc (https://help.mikrotik.com/docs/display/ROS/Device-mode) advanced mode should have partition to yes.
[admmikrotik@ap70a] > /partitions/activate part0 
failure: not allowed by device-mode
[admmikrotik@ap70a] > /partitions/print          
Flags: A - ACTIVE; R - RUNNING
Columns: NAME, FALLBACK-TO, VERSION, SIZE
#    NAME   FALLBACK-TO  VERSION                                  SIZE 
0    part0  next         RouterOS v7.16.1 2024-10-10 14:03:32     64MiB
1 AR part1  next         RouterOS v7.17beta2 2024-09-27 07:07:42  64MiB
[admmikrotik@ap70a] > /partitions/activate part0 
failure: not allowed by device-mode
[admmikrotik@ap70a] > 
[admmikrotik@ap70a] > /system/device-mode/print  
       mode: advanced
  container: yes     
[admmikrotik@ap70a] > /system/routerboard/print 
       routerboard: yes                
        board-name: hAP ax^3           
             model: C53UiG+5HPaxD2HPaxD
     serial-number: x        
     firmware-type: ipq6000            
  factory-firmware: 7.6                
  current-firmware: 7.17beta2          
  upgrade-firmware: 7.17beta2 
So only way is that : "/system/device-mode/update partitions=yes" and after that all work fine.
[admmikrotik@ap70a] > /system/device-mode/print
        mode: advanced
   container: yes     
  partitions: yes     
[admmikrotik@ap70a] > /partitions/print
Flags: A - ACTIVE; R - RUNNING
Columns: NAME, FALLBACK-TO, VERSION, SIZE
#    NAME   FALLBACK-TO  VERSION                                  SIZE 
0    part0  next         RouterOS v7.16.1 2024-10-10 14:03:32     64MiB
1 AR part1  next         RouterOS v7.17beta2 2024-09-27 07:07:42  64MiB
[admmikrotik@ap70a] > /partitions/activate part0
[admmikrotik@ap70a] > /partitions/print         
Flags: A - ACTIVE; R - RUNNING
Columns: NAME, FALLBACK-TO, VERSION, SIZE
#    NAME   FALLBACK-TO  VERSION                                  SIZE 
0 A  part0  next         RouterOS v7.16.1 2024-10-10 14:03:32     64MiB
1  R part1  next         RouterOS v7.17beta2 2024-09-27 07:07:42  64MiB
[admmikrotik@ap70a] > /system/reboot 
 
infabo
Forum Guru
Forum Guru
Posts: 1447
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.17beta [testing] is released!

Mon Oct 14, 2024 8:42 pm

You read changelog and followed discussion?
!) device-mode - after upgrade, mode "advanced" is set by default and traffic-gen, changing active partitions, bootloader and downgrade features will be disabled;
And even in the docs you posted the link to, it clearly says partitions is one of the "disabled features" for advanced mode. Where is the bug?

"advanced (default) traffic-gen, container, partitions, bootloader"
https://help.mikrotik.com/docs/display/ ... bootloader
 
User avatar
dang21000
Frequent Visitor
Frequent Visitor
Posts: 54
Joined: Sat Feb 25, 2023 2:30 pm
Location: France

Re: v7.17beta [testing] is released!

Mon Oct 14, 2024 9:13 pm

You're right, i've not see this part in doc ; but read in the next section :
List of available properties (table) "container, fetch, scheduler, traffic-gen,
ipsec, pptp, smb, l2tp, proxy, sniffer, zerotier, bandwidth-test, email, hotspot, romon, socks, partitions, downgrade, bootloader. (yes | no; Default: yes, for advanced mode)"
Why disable it after upgrade IF they must be yes for advanced mode ...? don't understand ... mistake ?!


I'm scared about this future 7.17 upgrade... with more than 80 AP dev located on wall or ceiling (sometimes hidden).... this will be a great moment on pleasure with this newly disabled features now. And depending of each building, lot are not powered by real POE but standard PSU with injector.
 
toxicfusion
Member
Member
Posts: 324
Joined: Mon Jan 14, 2013 6:02 pm

Re: v7.17beta [testing] is released!

Mon Oct 14, 2024 9:38 pm

ok, the main points of what I was proposing to ease this transition:

On first upgrade to 7.17, or initial power-on or netinstall with 7.17+
  • Display or have available (/system/routerboard/get device-token) a secure device token string for a limited period of time (30 minutes)
  • The admin can copy this token and record it against the device
  • During this 30 minutes the admin can CHANGE the device token (/system/routerboard/set device-token="newSecureToken")
  • During this 30 minutes the admin can SET secure device options as needed (downgrade, boot partitions, container use, etc) without being prompted to power-cycle/reset.
After 30 minutes/Second+ boot
  • The device token becomes inaccessible (/system/routerboard/get device-token returns null)
  • Changing secure device options, including the device-token would require adding the a device-token="..." to the command to enable it without requiring a power-cycle/reboot - this critically enables enterprises/ISPs/SMBs to continue to manage these and any future options without visiting/remotely power-cycling devices
  • The admin can also set the secure device options and device-token without using the device-token, but they will then be prompted to power-cycle or reset in the next 5 minutes
Rational
  • This would give a 'grace' window for setting options without having to go through the power-cycle/reset procedure
  • This would enable enterprises/ISPs/SMBs to record, and/or set their own device token in a way that works with their existing procedures
  • For instance, unique device token per device can be recorded in a database using a script to obtain them in the 30 minutes post upgrade
  • Or the admin can set a known device-token across a group of devices and have that recorded in a password manager
  • It also allows for the existing set and require a power-cycle/reset procedure
This will not satisfy everyone, if your device is already compromised, then netinstall it, or 'recycle' it.

I would hope that it covers the vast majority of needs out there, and allows for easy integration with existing workflows, would work with scripting.

It is constructive, flexible, and I hope, achieves the presumed goal of ESTABLISHING a secure base in-case of FUTURE compromise.
I hope MikroTik takes this into consideration. This is much better solution for those with NUMEROUS devices that are not within "reach" for a button press. Especially for devices on customer locations as CPE. Or as core routers..... We cant simply truck roll and justify the upgrade past 7.17.
 
pbr3000
Frequent Visitor
Frequent Visitor
Posts: 75
Joined: Fri Jan 08, 2010 7:31 am

Re: v7.17beta [testing] is released!

Tue Oct 15, 2024 12:00 am

You're right, i've not see this part in doc ; but read in the next section :
List of available properties (table) "container, fetch, scheduler, traffic-gen,
ipsec, pptp, smb, l2tp, proxy, sniffer, zerotier, bandwidth-test, email, hotspot, romon, socks, partitions, downgrade, bootloader. (yes | no; Default: yes, for advanced mode)"
Why disable it after upgrade IF they must be yes for advanced mode ...? don't understand ... mistake ?!


I'm scared about this future 7.17 upgrade... with more than 80 AP dev located on wall or ceiling (sometimes hidden).... this will be a great moment on pleasure with this newly disabled features now. And depending of each building, lot are not powered by real POE but standard PSU with injector.
Welcome to the club. This is just the first beta, so I hope MT team changes its mind and choose a better solution for enterprise market.
We have thousands of equipment that will be affected mainly by partition disabled.
 
pbr3000
Frequent Visitor
Frequent Visitor
Posts: 75
Joined: Fri Jan 08, 2010 7:31 am

Re: v7.17beta [testing] is released!

Tue Oct 15, 2024 12:03 am

What is your proposal, to verify ownership of a device in a way, that a remote attacker can't do?
Put a QR Code on the router which we can scan and save in our management software before deploying the routers. If we need later in a remote location a feature activated which we did not previously, we can enable it and provide the code via CLI. It also helps if someone remote can provide the code without traffic interruption - it also allows collecting the codes over a longer period of time and activating the feature in maintaince window.

Otherwise, you need to set the device mode to full for all systems, as maybe you need it sometime in the future - it would be more secure to active only the mode you need at the time, but this requires a way to change it at runtime.
I think this solution is simple and effective for new equipment.
 
guipoletto
Member Candidate
Member Candidate
Posts: 201
Joined: Mon Sep 19, 2011 5:31 am

Re: v7.17beta [testing] is released!

Tue Oct 15, 2024 12:13 am



Put a QR Code on the router which we can scan and save in our management software before deploying the routers. If we need later in a remote location a feature activated which we did not previously, we can enable it and provide the code via CLI. It also helps if someone remote can provide the code without traffic interruption - it also allows collecting the codes over a longer period of time and activating the feature in maintaince window.

Otherwise, you need to set the device mode to full for all systems, as maybe you need it sometime in the future - it would be more secure to active only the mode you need at the time, but this requires a way to change it at runtime.
I think this solution is simple and effective for new equipment.
I think the QR idea is terrible

That would be an immutable string, that would remain valid for the life of the equipment
That's a big no-no.
In case an emplyee absconds with the company database, or you fire your consultatnt, passwords must be *changeable*

I guess Mikrotik should be more open as to what threat-model they are working from
There could probably be a place for a "RouterOS-FIPS-For-Ukraine" version, so long as it's not forced on existing, unwilling customers...
 
User avatar
sirbryan
Member
Member
Posts: 391
Joined: Fri May 29, 2020 6:40 pm
Location: Utah
Contact:

Re: v7.17beta [testing] is released!

Tue Oct 15, 2024 1:51 am

What is your proposal, to verify ownership of a device in a way, that a remote attacker can't do?
Put a QR Code on the router which we can scan and save in our management software before deploying the routers.
New deployments aren't as big of a problem as existing deployments, as I can readily enable the device-mode on the bench before putting the device in the field. But yes, if some features provide a measure of security, there are some things we might want to leave disabled until the feature is needed. If they are deployed at a site that is inconvenient (or impossible) to reach at the time, it does make it difficult to enable later without having physical access.... hmmm.

For me the most angst is locking down some features that I actively use on deployed devices, and forcing me to go onsite for all of those deployed devices.
 
User avatar
Paternot
Forum Guru
Forum Guru
Posts: 1047
Joined: Thu Jun 02, 2016 4:01 am
Location: Niterói / Brazil

Re: v7.17beta [testing] is released!

Tue Oct 15, 2024 3:53 am

I maintain that one simple way is to make one jump version.

Say, 7.16.3 (just made it up) will be a forced stop before going 7.17.1
At 7.16.3 the user would have the option to enable the desired settings - those, that on 7.17.x would need a press of button to enable. It would have no practical effect on this version - but it the option would be set - and without all the button problems.
Then the user upgrades to 7.17.1, and the device honor the settings. If the use4r chose to enable changing partitions, so be it. If the user did nothing, then the new setting is to forbid it.

There. Home devices are protected and hard to access ISP devices can be have the config changed in advance, without the whole mess of getting there.

Yes, I know. There would be a window of opportunity to someone infiltrate the router, before the magical 7.17.1 version. True - but this windows already exists. So...
 
User avatar
coddy
just joined
Posts: 3
Joined: Mon Nov 11, 2013 7:13 am

Re: v7.17beta [testing] is released!

Tue Oct 15, 2024 6:21 am

A jump version is simply a temporary solution, what happens when Mikrotik decide there is a 'new' device-mode setting that can be set? Another 'jump' version?

No, I believe the easiest way forward is as I've described:viewtopic.php?p=1103228#p1103228

It enables ISPs/SMBs/Enterprises to upgrade and set desired device mode. It keeps any window of opportunity small, and enables the device to be secured against any future compromises. It also enables ISPs/SMBs/Enterprises to maintain a secure separate device-token that can be used to set any future options.

It would work with existing devices, and new devices. A configuration script can set secure device-token, or record the randomly generated token during this window.

QR codes are more work than is necessary. They involve recording per device, or after the fact having some one visit the device, and does not cover existing devices.
 
pbr3000
Frequent Visitor
Frequent Visitor
Posts: 75
Joined: Fri Jan 08, 2010 7:31 am

Re: v7.17beta [testing] is released!

Tue Oct 15, 2024 7:17 am



I think this solution is simple and effective for new equipment.
I think the QR idea is terrible

That would be an immutable string, that would remain valid for the life of the equipment
That's a big no-no.
In case an emplyee absconds with the company database, or you fire your consultatnt, passwords must be *changeable*

I guess Mikrotik should be more open as to what threat-model they are working from
There could probably be a place for a "RouterOS-FIPS-For-Ukraine" version, so long as it's not forced on existing, unwilling customers...
Yes, you're right. There are many variables to consider. Thanks for clarifying this possible threat ;)
 
pbr3000
Frequent Visitor
Frequent Visitor
Posts: 75
Joined: Fri Jan 08, 2010 7:31 am

Re: v7.17beta [testing] is released!

Tue Oct 15, 2024 8:04 am

No, I believe the easiest way forward is as I've described:viewtopic.php?p=1103228#p1103228
After reading your post better I agree and hope MT changes its mind about this terrible press button / power cycle idea.
It's convenient for home and soho deployments and a nightmare for enterprise. This topic already reflects our legit fear from future chaotic mass upgrades.
 
m4rk3J
newbie
Posts: 35
Joined: Thu Jan 27, 2022 2:41 pm

Re: v7.17beta [testing] is released!

Tue Oct 15, 2024 1:33 pm

Is there a plan to add channel utilization status to the Wi-Fi interface tab? Thank you.
 
User avatar
Paternot
Forum Guru
Forum Guru
Posts: 1047
Joined: Thu Jun 02, 2016 4:01 am
Location: Niterói / Brazil

Re: v7.17beta [testing] is released!

Tue Oct 15, 2024 2:00 pm

A jump version is simply a temporary solution, what happens when Mikrotik decide there is a 'new' device-mode setting that can be set? Another 'jump' version?
Yes, a new jump version. There shouldn't be many things added to this device-mode, anyway.
You idea of QR code has several problems, one of them (already pointed out), is that it become a hardcoded password. All You need is one disgruntled employee, and what now? You can't revoke the QR code. You can't change it.
 
User avatar
coddy
just joined
Posts: 3
Joined: Mon Nov 11, 2013 7:13 am

Re: v7.17beta [testing] is released!

Tue Oct 15, 2024 3:12 pm

The problem with a jump version is it leaves the admin with a one time only choice, what options do I set? Now if you want to secure the device in case of possible future exploit you should choose the minimum options required. But what do you do if a year down the track you suddenly discover that a device needs to run a container to solve a new problem? Go to the device and set option and power cycle? Trying to avoid this as it is a bad option, as indicated by the large number of comments in this forum.

Alternatively, you could enable all options, because maybe one-day you will need them, even if not right now. Again this is counter productive to the purpose of the device mode options - to lock down the device in case of future exploit.

So, although not opposed to the idea of a simple jump version, it does leave the admin with sub-optimal choices that can only easily be made once, which will invariably lead them to decide to fully unlock the device.

This I why I think the proposal of a device token that is readable/set-able for a short window is better in the long term.

Agreed, in the absence of that, then a jump version is better than an automatically locked down device on upgrade (and certainly better than a QR code). But it will lead me, and many others to just fully unlock the device because I never can be sure when I might need one of those features in the future, especially for my remotely controlled devices.

If Mikrotik can program in a device-token as I've fully outlined in my other posts then admins can safely lock down the devices now, with the features they need now, knowing they can easily, remotely and securely unlock those features or any new features going forward.

I do believe that respects what Mikrotik are trying to achieve, a more secure device in case of future exploit, whilst leaving the admin with the ability to securely enable or disable features if and when necessary in the future.
 
User avatar
dang21000
Frequent Visitor
Frequent Visitor
Posts: 54
Joined: Sat Feb 25, 2023 2:30 pm
Location: France

Re: v7.17beta [testing] is released!

Tue Oct 15, 2024 4:24 pm

The main problem is not the new advanced/enterprise device mode.
But the change confirmation by button press/power lost.

Security reason ? remotely we can change/break everything else... but not that ?
 
pbr3000
Frequent Visitor
Frequent Visitor
Posts: 75
Joined: Fri Jan 08, 2010 7:31 am

Re: v7.17beta [testing] is released!

Tue Oct 15, 2024 4:54 pm

Yes @dang21000. I suggest you read the whole topic to understand the ideas presented to avoid this press button/power cycle thing.
 
User avatar
sirbryan
Member
Member
Posts: 391
Joined: Fri May 29, 2020 6:40 pm
Location: Utah
Contact:

Re: v7.17beta [testing] is released!

Tue Oct 15, 2024 5:22 pm

The problem with a jump version is it leaves the admin with a one time only choice, what options do I set? Now if you want to secure the device in case of possible future exploit you should choose the minimum options required. But what do you do if a year down the track you suddenly discover that a device needs to run a container to solve a new problem? Go to the device and set option and power cycle? Trying to avoid this as it is a bad option, as indicated by the large number of comments in this forum.
This is already the case for things like containers. You either unlock it before deploying it remotely, or have to touch it later. So for the existing device-mode options that you have to "physically unlock," this is a moot point.

The bigger issue at hand is locking down existing capabilities that many of us use on already-deployed devices. The ones we're really concerned about are not easily accessible (physically remote locations), or would take an inordinate amount of time (mass deployments in customers' homes or offices).
 
toxicfusion
Member
Member
Posts: 324
Joined: Mon Jan 14, 2013 6:02 pm

Re: v7.17beta [testing] is released!

Tue Oct 15, 2024 5:44 pm

This is all fault of MikroTik's leadership and decision making / vision. This "one product for everyone" agenda for ALL markets.

The device hardware is quite decent, RouterOS is swiss-army knife with full features. This allows multiple use-cases, from homelab - SOHO/SMB/Enterprise/WISP/ISP.....

This is what I've been saying. If MikroTik carved up a few product sets [CHR,CCR,CRS,etc] for the professional/Enterprise - we may not be in this situation with need of this device-lock. This is a kick in the head to those of us that picked MikroTik due to their flexibility and price to use in a business model. Deploying to customers as CPE's. Or us as professionals deploying to customers as a technology solution, or as our backbone. It is not cost effective to truck roll just to touch a device post-upgrade...

I mean... another vendor is getting heat right now for "forcing" SNMP defaults on devices instead of just keeping disabled. However, this other vendor actually listens to professionals. MikroTik -- are you listening and digesting the gravity of decisions? I think its time for a pivot.

I hope MikroTik will let us contrrol this device lock using the outlined suggestion of device token. RouterOS 7 is a hot mess express, also given this drive for RouterOS enterprise which is not at all synonymous - as they're "add-on" packages that do NOT belong on a router.

RouterOS 7 Focus point should be:
-Fixing current issues [Layer3 items, MLAG, AX, Capsman, IPv4, hardware offloading, VLANS]
- AX wireless
- AC qcom driver fixes
- Security enhancements

Winbox4 -- unsure if this was good timing or how many internal resources on this.
Where is MikroTik device controller?
Move ROSE to be actual RouterOS enterprise on enterprise level hardware, strip the storage network protocols. Leave or rename this to a different MikroTik operating system. MikroTik can probably sell different hardware.

MikroTik RouterOS Core [Routing, wireless packages, options like we had in ROS 6]
MikroTik RouterOS Enterprise [Everything]
MikroTik BoxOS [Enterprise ROSE packages for NAS type appliances - the Gavin Belson]

Then to keep with MikroTik's vision for no feature "lock downs" on THEIR hardware. The above OS's can still be installed onto XXX hardware via NetInstall or via package upload.
 
User avatar
Paternot
Forum Guru
Forum Guru
Posts: 1047
Joined: Thu Jun 02, 2016 4:01 am
Location: Niterói / Brazil

Re: v7.17beta [testing] is released!

Tue Oct 15, 2024 7:40 pm

Agreed, in the absence of that, then a jump version is better than an automatically locked down device on upgrade (and certainly better than a QR code). But it will lead me, and many others to just fully unlock the device because I never can be sure when I might need one of those features in the future, especially for my remotely controlled devices.
And that's fine. This whole thing is intended to lock down home devices, once installed and never upgraded. If You take a look at what is affected, all of them have one thing in common: they can be used to insert code to run, use a second partition as a "malware restore backup" and/or run a container with malware inside.

I really think the basic idea is quite good. What I'm not happy with is the planned migration. Even the implementation is good: needing physical access is the ultimate barrier, and a way to guarantee that a user just "turning it off and on again" will not enable something nasty to bypass the lock.
 
merkkg
just joined
Posts: 15
Joined: Thu Jan 19, 2017 11:50 am

Re: v7.17beta [testing] is released!

Tue Oct 15, 2024 8:20 pm

*) switch - fixed L2MTU for 25Gbps ports;
Any way to get more details on this?

its any device with 25G port or as long as using 25G SFP? visible to see when affected?
 
User avatar
spippan
Member
Member
Posts: 459
Joined: Wed Nov 12, 2014 1:00 pm

Re: v7.17beta [testing] is released!

Tue Oct 15, 2024 11:36 pm

bridge - added interface-list support for VLAN : the best features!!!!

This will simplify VLAN tables!thank you mikrotik.
is there any docs how we are ablte to use this feature? or best-practice?

EDIT: found it where it is used... (screenshot)
Screenshot from 2024-10-15 23-02-56.png
You do not have the required permissions to view the files attached to this post.
 
User avatar
Coughy
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Tue Apr 23, 2024 2:53 am
Location: Brisbane Au

Re: v7.17beta [testing] is released!

Wed Oct 16, 2024 2:17 am

This is all fault of MikroTik's leadership and decision making / vision. This "one product for everyone" agenda for ALL markets.

The device hardware is quite decent, RouterOS is swiss-army knife with full features. This allows multiple use-cases, from homelab - SOHO/SMB/Enterprise/WISP/ISP.....

This is what I've been saying. If MikroTik carved up a few product sets [CHR,CCR,CRS,etc] for the professional/Enterprise - we may not be in this situation with need of this device-lock. This is a kick in the head to those of us that picked MikroTik due to their flexibility and price to use in a business model. Deploying to customers as CPE's. Or us as professionals deploying to customers as a technology solution, or as our backbone. It is not cost effective to truck roll just to touch a device post-upgrade...

I mean... another vendor is getting heat right now for "forcing" SNMP defaults on devices instead of just keeping disabled. However, this other vendor actually listens to professionals. MikroTik -- are you listening and digesting the gravity of decisions? I think its time for a pivot.

I hope MikroTik will let us contrrol this device lock using the outlined suggestion of device token. RouterOS 7 is a hot mess express, also given this drive for RouterOS enterprise which is not at all synonymous - as they're "add-on" packages that do NOT belong on a router.

RouterOS 7 Focus point should be:
-Fixing current issues [Layer3 items, MLAG, AX, Capsman, IPv4, hardware offloading, VLANS]
- AX wireless
- AC qcom driver fixes
- Security enhancements

Winbox4 -- unsure if this was good timing or how many internal resources on this.
Where is MikroTik device controller?
Move ROSE to be actual RouterOS enterprise on enterprise level hardware, strip the storage network protocols. Leave or rename this to a different MikroTik operating system. MikroTik can probably sell different hardware.

MikroTik RouterOS Core [Routing, wireless packages, options like we had in ROS 6]
MikroTik RouterOS Enterprise [Everything]
MikroTik BoxOS [Enterprise ROSE packages for NAS type appliances - the Gavin Belson]

Then to keep with MikroTik's vision for no feature "lock downs" on THEIR hardware. The above OS's can still be installed onto XXX hardware via NetInstall or via package upload.
100% Agree with you here mate also it should be able to fix and tweak the parts of the operation to get the devices working correctly as they should not take months and months 27SEPT 3 weeks now to be precise since we as a community have seen anything (come on now mikrotik we need fixs more often not weeks apart we would like to use the devices )
lets get the device working properly first then fix/worry about all the add on's and such later get a good stable base then add on
that way we could get fix's faster as there not playing with the hole ros trying to move faster than the rest
because at the moment they are falling behind the rest as there moving to fast and not fixing the problems that everyday to today needs so people looking else where
they need dedicated engineers to the most important parts

I'm not ungrateful for the work that all is doing just i think that possibly that the work getting done could be done in a more constructive manner and more important items addressed first

-Fixing current issues [Layer3 items, MLAG, AX, Capsman, IPv4, hardware offloading, VLANS]
- AX wireless
- AC qcom driver fixes
- Security enhancements
 
ckleea
Frequent Visitor
Frequent Visitor
Posts: 69
Joined: Sun Apr 21, 2013 12:19 pm

Re: v7.17beta [testing] is released!

Wed Oct 16, 2024 7:31 am

I lost the mount position of the USB for containers and was unable to run. This happened many times before after the update which I thought it was fixed.

Is there way to recover the mount position and allow the containers to run again?
 
User avatar
tangent
Forum Guru
Forum Guru
Posts: 1655
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Re: v7.17beta [testing] is released!

Wed Oct 16, 2024 7:31 pm

This upgrade appears to be breaking IPv6 ND (a.k.a. NDP) to wired clients connected to RouterOS switches, when those switches sit between the client and the NDP source. Full saga here, but the tl;dr is that rolling back to 7.16.1 via netinstall fixed the symptom, and re-upgrading to 7.17beta2 broke it again.

EDIT: …and resetting the channel to stable to roll back to 7.16.1 via the regular software update (not netinstall) restored SLAAC to the client.

As a result of netinstalling this switch and the consequent need to rebuild its config from text backups, it is close to defconf now. The primary changes that I can see possibly affecting it are the bridge config:

/interface bridge add add-dhcp-option82=yes admin-mac=**ELIDED** auto-mac=no dhcp-snooping=yes igmp-snooping=yes igmp-version=3 mld-version=2 multicast-querier=yes name=bridge priority=0x1000

The path toward the NDP source is marked "Trusted" and has unknown multicast flooding enabled, which should allow the NDP messages to flow despite IGMP and DHCP snooping being enabled.
 
User avatar
osc86
Member Candidate
Member Candidate
Posts: 203
Joined: Wed Aug 09, 2017 1:15 pm

Re: v7.17beta [testing] is released!

Wed Oct 16, 2024 11:36 pm

try this (or add required ports manually):
/interface/bridge/mdb/add bridge=bridge group=FF02::2 ports=[/interface/bridge/port/find where bridge=bridge]
 
User avatar
wiktorbgu
just joined
Posts: 4
Joined: Sun Dec 26, 2021 11:59 am

Re: v7.17beta [testing] is released!

Thu Oct 17, 2024 9:58 am

My flash drive is mounted in different slots after each reboot.
As you can see, it turns on either in USB 3.0 mode or in USB 2.0 mode.
Model ax3.
You do not have the required permissions to view the files attached to this post.
 
holvoetn
Forum Guru
Forum Guru
Posts: 6618
Joined: Tue Apr 13, 2021 2:14 am
Location: Belgium

Re: v7.17beta [testing] is released!

Thu Oct 17, 2024 10:45 am

My flash drive is mounted in different slots after each reboot.
As you can see, it turns on either in USB 3.0 mode or in USB 2.0 mode.
Model ax3.
Long standing issue with certain USB stick brands.
So it's not yet completely resolved ... I hoped it was since I am not seeing this issue anymore on RB5009 (for now).

Next reboot may correct it.
Or try USB reset with small waiting time.
 
OlofL
Member Candidate
Member Candidate
Posts: 114
Joined: Mon Oct 12, 2015 2:37 pm

Re: v7.17beta [testing] is released!

Thu Oct 17, 2024 2:22 pm

is rfc 2136 forwarding possible?

When I run this nsupdate request:
nsupdate:
server 10.6.100.18
zone sub.network.test
update add hello.sub.network.test 300 A 1.3.3.7
send
Response: update failed: NOTIMP

I want to use mikrotik as forwarder only, and I want mikrotik to forward this request to my centralized internal DNS.
 
infabo
Forum Guru
Forum Guru
Posts: 1447
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.17beta [testing] is released!

Thu Oct 17, 2024 2:50 pm

Do you have a reference where or which DNS server already implements a forwarding of nsupdate requests? If there are none, why do you want Mikrotik to implement this? Why dont you send the nsupdate request directly to your "centralized" dns server?
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 4256
Joined: Sun May 01, 2016 7:12 pm
Location: California
Contact:

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 12:23 am

You can only send RFC-2136 updates via /tool/dns-update - not forward them. You also still cannot add a PTR type as a static (so while can forward mDNS, but cannot do more basic DNS-SD) - so we're far from a "real" DNS server. And, I'm sure others have their own DNS grips.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10519
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 10:39 am

so we're far from a "real" DNS server. And, I'm sure others have their own DNS grips.
MikroTik should offer "unbound" as an optional DNS resolver package (that replaces the internal one when installed), much like in v6 you could install an optional NTP client/server that would replace/upgrade the internal one.
 
bratislav
Frequent Visitor
Frequent Visitor
Posts: 69
Joined: Mon May 05, 2014 10:36 am

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 11:21 am

so we're far from a "real" DNS server. And, I'm sure others have their own DNS grips.
MikroTik should offer "unbound" as an optional DNS resolver package (that replaces the internal one when installed), much like in v6 you could install an optional NTP client/server that would replace/upgrade the internal one.
"unbound" is not "real" DNS server like BIND is for example... it is DNS caching validating recursor and if you need full DNS functionality you should use NSD in addition to be able to provide authoritative DNS services...
So IMHO Mikrotik should probably offer unbound by default for resolving, forwarding etc. and offer NSD as an upgrade for people who need to host their own DNS zones.
It seems to me that Mikrotik would be better of stop trying to develop everything in house and use some opensource software like unbound/nsd for common tasks especially if they are licensed under some non prohibitive license like BSD in case of unbound...
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7174
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 1:11 pm

container and run whatever you like.
 
mrshaba
just joined
Posts: 6
Joined: Thu Jul 04, 2019 11:49 am

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 1:55 pm

unrealistic solution for all non-ARM/X86 based device and also all devices (also ARM based) which have only 16MB of built in storage size and no USB where one could attach an external storage device (tried to get a second instance of a unbound container running on CRS309, no chance)
 
infabo
Forum Guru
Forum Guru
Posts: 1447
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 2:18 pm

unbound does not fit into 16mb flash by far. look at the unbound distroless docker images. The binary has at least 4mb+. given microtik has a lot of stuff developed in house (I am pretty sure they dont use any popular ssl library for example). It is all a matter of their limited storage they have opted. They limited themselves.
Last edited by infabo on Fri Oct 18, 2024 2:18 pm, edited 1 time in total.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10519
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 2:18 pm

container and run whatever you like.
Except then you have no configuration user interface.
Still, it would be nice when someone with container experience would make a container with unbound for RouterOS.
 
infabo
Forum Guru
Forum Guru
Posts: 1447
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 2:20 pm

unbound is a recursive resolver. not an authorative dns. It has some limited features in that regard. The consensus: use powerdns for that purpose.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10519
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 2:21 pm

unbound does not fit into 16mb flash by far. look at the unbound distroless docker images. The binary has at least 4mb+. given microtik has a lot of stuff developed in house (I am pretty sure they dont use any popular ssl library for example). It is all a matter of their limited storage they have opted. They limited themselves.
It may be possible to squeeze in a minimal unbound when the existing IP->DNS is removed, but frankly I am not that concerned about 16MB devices, I do not buy them to use as routers.
Even for the useful RB750Gr3 there is now an announced replacement with 128MB flash!
 
pe1chl
Forum Guru
Forum Guru
Posts: 10519
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 2:22 pm

unbound is a recursive resolver. not an authorative dns. It has some limited features in that regard.
The features are similar to what the current built-in MikroTik DNS resolver has, plus it can resolve from root servers.
(and it supports DNSSEC, and it has a test suite, and it has developers who know DNS, ...)
 
pe1chl
Forum Guru
Forum Guru
Posts: 10519
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 2:23 pm

It seems to me that Mikrotik would be better of stop trying to develop everything in house and use some opensource software like unbound/nsd for common tasks especially if they are licensed under some non prohibitive license like BSD in case of unbound...
+1
 
bratislav
Frequent Visitor
Frequent Visitor
Posts: 69
Joined: Mon May 05, 2014 10:36 am

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 2:28 pm

container and run whatever you like.
I usually do run DNS servers on a dedicated VMs and not on RouterOS, but wouldn't it be simpler for all, both Mikrotik and us users, that instead of wasting decades on trying to make proprietary software for something as common as DNS, and fail, you use something open source that is well maintained and reliable, after all you do use Linux. And maybe you could even give something back to open source community in form of patches if you happen to modify and improve something...
 
infabo
Forum Guru
Forum Guru
Posts: 1447
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 3:10 pm

Whole essence of ROS is proprietary development. But they contribute: https://github.com/torvalds/linux/commi ... 1bcb1a6574
 
pe1chl
Forum Guru
Forum Guru
Posts: 10519
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 3:12 pm

I fully agree! Every time a new feature is added, something else is broken, and we need another cycle to get that fixed.
And all that while ready solutions with the same functionality already exist. The only work that would have to be done is the configuration interface -> mapping to configuration file. That should be a common task in RouterOS.
And maybe to include all functions (like DNSSEC), more storage would be required than the current solution.
 
User avatar
Paternot
Forum Guru
Forum Guru
Posts: 1047
Joined: Thu Jun 02, 2016 4:01 am
Location: Niterói / Brazil

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 3:58 pm

Even for the useful RB750Gr3 there is now an announced replacement with 128MB flash!
That I didn't know! Where is it? Great news, finally we are leaving the 16MB behind!
 
pe1chl
Forum Guru
Forum Guru
Posts: 10519
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 5:02 pm

Even for the useful RB750Gr3 there is now an announced replacement with 128MB flash!
That I didn't know! Where is it? Great news, finally we are leaving the 16MB behind!
There is a video on the MikroTik YouTube channel: https://www.youtube.com/watch?v=Zrzq_zPWoQ4
But it is not yet on the products list... strange.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 4256
Joined: Sun May 01, 2016 7:12 pm
Location: California
Contact:

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 5:04 pm

container and run whatever you like.
... as long as someone is there to do the device-mode dance.

With the new "changing device-mode on upgrade" scheme here... I hope y'all are mulling how to deal with the device-lock provisioning side. I'd actually like to deploy containers as part of a default config, say a DNS server... but since the device-mode is not controllable via netinstall/flashflig/etc. it ain't possible.

I get security threats have changed, so get device-mode (just removing packages be better IMO). But there needs to be some automated way to set device-mode before deployment at least.
 
EdPa
MikroTik Support
MikroTik Support
Topic Author
Posts: 336
Joined: Fri Sep 15, 2017 10:05 am
Location: Riga
Contact:

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 5:24 pm

What's new in 7.17beta4 (2024-Oct-18 11:32):

!) device-mode - after upgrade, mode "enterprise" is renamed to "advanced" and bandwidth-test, traffic-gen, partition (command "repartition"), bootloader and downgrade features will be disabled;
!) webfig - redesigned HTML, styling and functionality (additional fixes);
*) arm64 - fixed for bare-metal servers to be able to access more than 2GB RAM;
*) arm64 - show CPU frequency on bare-metal installations;
*) bridge - correctly display PPP interfaces in VLAN menu;
*) bridge - fixed first host table response for SNMP;
*) bridge - fixed VLAN overlap check;
*) bridge - improved port handling;
*) certificate - fixed handling of capsman-cap certificates (introduced in v7.16);
*) console - added more argument definitions for mac-protocol property;
*) console - execute :return command without error;
*) crypto - improve crypto speeds (additional fixes);
*) crypto - use hardware accelerator for GCM cipher in TLS connection on Alpine CPUs;
*) defconf - changed wireless installation from "indoor" to "any";
*) defconf - disable 5GHz secondary channel on RB4011;
*) defconf - fixed new port name recognition;
*) device-mode - changed "partition" to allow activate and do not allow repartition (introduced in v7.17beta2);
*) device-mode - clarify message that pressing a button will reboot device;
*) device-mode - limit "/tool/ping-speed" and "/tool/flood-ping" under "traffic-gen" feature;
*) device-mode - show all features and active restrictions with "print" command;
*) dhcp-relay - added "local-address-as-src-ip" property;
*) dhcp-server - use interface ID for NAS-Port and added interface name to NAS-Port-ID attribute in RADIUS requests;
*) dhcp-server - use single RADIUS accounting session for IPv4 and IPv6 when dual stack is used;
*) dhcpv4-client - fixed crash when releasing disabled DHCP client;
*) dhcpv4-server - properly detect DHCP server address when underlying interface has multiple IP addresses configured;
*) dhcpv4-server/relay - added additional error messages for DHCP servers and relays;
*) discovery - added support for LLDP DCBX (additional fixes);
*) disk - added sshfs client to "/disk" menu (CLI only);
*) disk - improve slot naming and improvements for visualizing complex hardware topology;
*) disk - improve test to report zero byte iops;
*) disk - save raid superblock and raid bitmap superblock on member devices in 1.2 format/location;
*) disk - try all NFS versions (4.2,4.1,4.0,3,2) when mounting NFS in that order;
*) dns - added option to create named DNS servers that can be used as forward-to servers (CLI only) (additional fixes);
*) dns - do not look up local cache when executing ":resolve" command with specified "server" parameter (introduced in v7.16);
*) dns - refactored DNS service internal processes;
*) ethernet - log warning only about excessive broadcast (do not include multicast) and reduced log count;
*) file - do not needlessly scan large filesystems, could prevent unmounting;
*) graphing - fixed graphing rule removal (additional fixes);
*) health - changed PSU state from "no-ac" to "no-input";
*) igmp-proxy - refactored IGMP querier (additional fixes);
*) iot - fixed duplicate LoRa payloads in the traffic tab;
*) iot - limit mqtt publish message size to 32 KB;
*) iot - LoRa traffic tab RSSI now shows proper values for ARM architecture;
*) iot - mqtt improvement to support large payloads and gracefully discard payloads above size limit;
*) iot - removed some LoRa radio related parameters (e.g. RSSI-OFF and Tx-enabled) that were not meant to be changed (additional fixes);
*) ipv6 - added comment property to "/ipv6/nd/prefix" menu;
*) l3hw - improved system stability;
*) l3hw - rate limit error logging;
*) log - added hostname support to remote logging action;
*) log - added regex parameter for log filtering in rules;
*) lte - fixed "default-name" property in export when multiple LTE interfaces are used;
*) lte - fixed "lte monitor" signal reporting for RG520F-EU modem when connected to 5G SA network;
*) lte - fixed "operator" setting for EC200A-EU modem;
*) lte - fixed LTE band setting for SXT LTE 3-7;
*) lte - fixed roaming barring (allow-roaming=no) for EC200A-EU modem;
*) lte - set IPv6 address reporting format in modem init for AT modems and MBIM modems with AT channel;
*) mac-server - allow MAC-Telnet access through any bridged port when bridge interface is allowed;
*) mpls - added fast-path support for VPLS (additional fixes);
*) netwatch - added "ignore-initial-up" and "ignore-initial-down" properties (CLI only);
*) netwatch - fixed probe toggle when adding a comment;
*) ovpn-server - added "user-auth-method" property and allow mschap2 for RADIUS authentication;
*) ppp - added support for bridge-port-pvid configuration via ppp profile (additional fixes);
*) ppp - reuse link-local IPv6 address for static bindings when possible;
*) pppoe - added support for PPPoE server over 802.1Q VLANs (additional fixes);
*) ptp - added PTP support for CRS320-8P-8B-4S+ device;
*) ptp - make PTP process more stable and deterministic when applying configuration;
*) qos-hw - improved PFC behavior (additional fixes);
*) qos-hw - improved WRED and ECN behavior (additional fixes);
*) qos-hw - reworked PCP and DSCP mapping (now supports single, multiple and range values, previous configuration with minimal value mapping is converted to a single value);
*) rip - improved stability when changing metric;
*) route - fixed minor typo in failure message;
*) route - increased interface name length limit in log messages;
*) route - removed possibility for IPv6 routes to specify interface in the dst-address;
*) routerboot - fixed boot MAC for devices with Alpine CPU ("/system routerboard upgrade" required);
*) sfp - improved initialization for certain SFP modules on CRS309 and CRS317 devices ("/system routerboard upgrade" required);
*) smb - stability improvements for client/server (additional fixes);
*) snmp - added wifi fields to MIKROTIK-MIB;
*) ssh - added option to configure SSH ciphers (replaced allow-none-crypto parameter);
*) ssh - improved speed;
*) ssh - prefer GCM ciphers for arm64 and x86 devices when ciphers=auto;
*) storage - preserve permissions,owners,attributes when syncing under "/file/sync";
*) storage,rsync - fixed to work with clients passing "-a" option;
*) supout - added device-mode section;
*) switch - updated dynamic switch rules when using HW bridge with IGMP snooping (224.0.0.0/24 and ff02::/16 destination addresses are forwarded and copied to CPU) (additional fixes);
*) system - moved "/system/upgrade" to "/system/package/local-update";
*) vxlan - fixed issue causing to loose IPv6 VTEP address setting;
*) webfig - improved keyboard navigation (additional fixes);
*) webfig - reduce flickering when table is sorted by column with duplicate values (additional fixes);
*) wifi - added extra info to CAPsMAN about message;
*) wifi - fixed "disabled" property in certain cases;
*) wifi - fixed occasional failure to bring up management frame protection and channel switch capabilities;
*) wifi - improved FT roaming with WPA3 for some Apple devices;
*) wifi-qcom - updated regulatory info for Ukraine, Australia and United States;
*) winbox - renamed and moved "System/Auto Upgrade" to "System/Packages" menu;
*) winbox - show MLAG settings for CRS326-4C+20G+2Q+ device;
*) wireless - enable all chains by default for RB911 and RB922 series devices;
 
pe1chl
Forum Guru
Forum Guru
Posts: 10519
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 5:29 pm

!) device-mode - after upgrade, mode "enterprise" is renamed to "advanced" and bandwidth-test, traffic-gen, partition (command "repartition"), bootloader and downgrade features will be disabled;
So that means /partitions/activate (changing active partition) will after all remain available, and only /partitions/repartition will become locked?
That is good news!
 
infabo
Forum Guru
Forum Guru
Posts: 1447
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 6:02 pm

Yes, it means that.
*) device-mode - changed "partition" to allow activate and do not allow repartition (introduced in v7.17beta2);
 
crosswind
newbie
Posts: 46
Joined: Tue Feb 18, 2020 3:47 pm

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 6:05 pm

*) wifi - added extra info to CAPsMAN about message;
could you please elaborate? i cannot discern any meaning at all from this entry.

nice that the vxlan/vteps bug was fixed, ty.
 
crosswind
newbie
Posts: 46
Joined: Tue Feb 18, 2020 3:47 pm

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 6:20 pm

PIM-SM is still broken:
[admin@lab2.i.lfns.org.uk] > routing/pimsm/static-rp/add instance=lan-v6 address=2001:8b0:aab5:3::b
action timed out - try again, if error continues contact MikroTik support and send a supout file (13)
[admin@lab2.i.lfns.org.uk] > put [/system/resource/get version]
7.17beta4 (testing)
 
holvoetn
Forum Guru
Forum Guru
Posts: 6618
Joined: Tue Apr 13, 2021 2:14 am
Location: Belgium

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 6:40 pm

Upgraded RB5009, USB disk is gone after reboot.
No way to get it back, no USB reset, nada.
Unplugged USB stick, put it back in, doesn't come up again.

Only some small containers on it which are pretty easy to setup again but just wanted to let it know.
 
massinia
Member Candidate
Member Candidate
Posts: 184
Joined: Thu Jun 09, 2022 7:20 pm

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 6:44 pm

*) wifi - improved FT roaming with WPA3 for some Apple devices;
Thanks MikroTik 🎉
 
User avatar
tangent
Forum Guru
Forum Guru
Posts: 1655
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 6:45 pm

/interface/bridge/mdb/add bridge=bridge group=FF02::2 ports=[/interface/bridge/port/find where bridge=bridge]

I get "input does not match any value of port" from that command.

However, on inspecting the MDB, I do see an entry for that IPv6 multicast group on the CRS328's bridge and on the ports down which my other RouterOS devices are. I take that to mean the command would not have changed anything even if it had run without error.

I held off trying your (@osc86) suggestion in hopes that this second beta would fix this, but alas, no, despite this entry in the Changelog:

*) switch - updated dynamic switch rules when using HW bridge with IGMP snooping (224.0.0.0/24 and ff02::/16 destination addresses are forwarded and copied to CPU) (additional fixes);

There's still something for MT to fix here.

$ ifconfig en0
en0: flags=…
	inet6 fd88::…%en0 prefixlen 64 secured scopeid 0x4 

That's it, just one inet6 entry, not the three I'm used to seeing. (The others being fd80::… and the one for the local PD lease from my ISP.)
 
holvoetn
Forum Guru
Forum Guru
Posts: 6618
Joined: Tue Apr 13, 2021 2:14 am
Location: Belgium

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 6:47 pm

Upgraded RB5009, USB disk is gone after reboot.
No way to get it back, no USB reset, nada.
Unplugged USB stick, put it back in, doesn't come up again.

Only some small containers on it which are pretty easy to setup again but just wanted to let it know.
"Downgraded" to 7.16.1 -> disk back
Moving again to 7.17b4 -> disk remains

Really odd ...
 
User avatar
Paternot
Forum Guru
Forum Guru
Posts: 1047
Joined: Thu Jun 02, 2016 4:01 am
Location: Niterói / Brazil

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 7:04 pm

So that means /partitions/activate (changing active partition) will after all remain available, and only /partitions/repartition will become locked?
That is good news!
Yes, they are listening! Excellent news indeed. :D
"*) device-mode - changed "partition" to allow activate and do not allow repartition (introduced in v7.17beta2);"
 
blacksnow
Frequent Visitor
Frequent Visitor
Posts: 56
Joined: Wed Feb 15, 2023 4:46 pm

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 7:16 pm

In 7.17b4, the sorting on any column in webfig doesn't work on firefox. Not sure if it's just me.
 
crosswind
newbie
Posts: 46
Joined: Tue Feb 18, 2020 3:47 pm

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 7:20 pm

SUP-168334 also not fixed:
[admin@lab2.i.lfns.org.uk] > /ipv6/route print where dst-address=64:ff9b::/96
Flags: D - DYNAMIC; A - ACTIVE
Columns: DST-ADDRESS, GATEWAY, DISTANCE
   DST-ADDRESS   GATEWAY                       DISTANCE
DA 64:ff9b::/96  fe80::400:ff:fe00:509%ether1       115

[admin@lab2.i.lfns.org.uk] > /routing/route/print where dst-address=64:ff9b::/96
Flags: A - ACTIVE; i - ISIS
Columns: DST-ADDRESS, GATEWAY, AFI, DISTANCE, SCOPE, TARGET-SCOPE, IMMEDIATE-GW
   DST-ADDRESS   GATEWAY                       AFI  DISTANCE  SCOPE  TARGET-SCOPE  IMMEDIATE-GW                
Ai 64:ff9b::/96  fe80::400:ff:fe00:509%ether1  ip6       115     20            10  fe80::400:ff:fe00:509%ether1
not a serious issue but i was hoping we'd get a fix for 7.17.
 
User avatar
clambert
Member Candidate
Member Candidate
Posts: 160
Joined: Wed Jun 12, 2019 5:04 am

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 8:10 pm

*) dhcp-relay - added "local-address-as-src-ip" property;
Great news! Thanks Mikrotik!
 
FezzFest
Frequent Visitor
Frequent Visitor
Posts: 95
Joined: Wed Jun 03, 2015 12:03 am

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 8:54 pm

What's new in 7.17beta4 (2024-Oct-18 11:32):

!) device-mode - after upgrade, mode "enterprise" is renamed to "advanced" and bandwidth-test, traffic-gen, partition (command "repartition"), bootloader and downgrade features will be disabled;
WHAT THE FUCK?
Instead of listening to the critique bandwidth-test is now also disabled? Are you gonna leave any features intact? Maybe just brick the damn device w/ the software update to v7.17 so we have to physically go to all of our devices and NetInstall them! What a bunch of lunatics you've become.
 
infabo
Forum Guru
Forum Guru
Posts: 1447
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 9:10 pm

Makes sense. Bandwidth test tools create a bunch of traffic as well.
 
User avatar
BrateloSlava
Member Candidate
Member Candidate
Posts: 201
Joined: Mon Aug 09, 2021 10:33 am
Location: Ukraine, Kharkiv

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 9:19 pm

All this ( with device-mode ) is, of course great, and useful to improve security, etc. But still. What is the normal way to update remote devices now?

It is possible that all these new restrictions should be automatically set after netinstall. But switching from 7.16 to 7.17 for currently working remote devices is still seriously confusing for me.
 
FezzFest
Frequent Visitor
Frequent Visitor
Posts: 95
Joined: Wed Jun 03, 2015 12:03 am

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 9:30 pm

Makes sense. Bandwidth test tools create a bunch of traffic as well.
So does routing traffic through my fucking router. We have 2000+ devices and use bandwidth test constantly to debug throughput issues. You don't see Cisco or Arista implement virtual fucking child locks on their routers, they just assume people know what they're doing. MikroTik is trying to be holier than the pope and polish it's turd-like security posture for the rest of the world while screwing over their long-time customers. It's been 3 weeks since the release of v7.17beta2, they've been inundated with replies telling them this needs to be done differently and they ignore all that and introduce this? It's a disgrace.
 
Sit75
just joined
Posts: 12
Joined: Thu Mar 11, 2021 9:43 pm

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 9:35 pm

It would be good to either polish the Superchannel a bit or remove it. But it doesn't make sense now. :-)
You do not have the required permissions to view the files attached to this post.
 
User avatar
sirbryan
Member
Member
Posts: 391
Joined: Fri May 29, 2020 6:40 pm
Location: Utah
Contact:

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 9:36 pm

What's new in 7.17beta4 (2024-Oct-18 11:32):

!) device-mode - after upgrade, mode "enterprise" is renamed to "advanced" and bandwidth-test, traffic-gen, partition (command "repartition"), bootloader and downgrade features will be disabled;
Instead of listening to the critique bandwidth-test is now also disabled?
Yay on the "change active partition" being left alone. This bandwidth-test one I missed.

One of my selling points to customers about them purchasing a MikroTik router from me is that I can log in and run tests from it (ping, trace route, bandwidth) as if I was on-site. One of the tools I frequently use on ALL my MikroTik 60GHz radios and routers, especially those installed at customers' homes (500+), is the bandwidth-test (from the GUI) from site-to-site.

I get the need to dial some things down, but for already-deployed devices, there's got to be a compromise. This affects far more devices than the partition issues do (hundreds vs. dozens for me, anyway).
 
User avatar
Paternot
Forum Guru
Forum Guru
Posts: 1047
Joined: Thu Jun 02, 2016 4:01 am
Location: Niterói / Brazil

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 10:36 pm

I get the need to dial some things down, but for already-deployed devices, there's got to be a compromise. This affects far more devices than the partition issues do (hundreds vs. dozens for me, anyway).
To be fair, I think Mikrotik is listening. The recent change on partitioning shows this. They will probably go on tweaking this, using the beta as a RFC for the settings.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10519
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.17beta [testing] is released!

Fri Oct 18, 2024 11:29 pm

I hope at some point some scheme will be found where users upgrading to new versions can keep the features they already had, while newly installed devices need the device-mode setting to get access to those features.
(e.g. one of the many schemes proposed where one could set device-mode shortly after upgrade, or using the sticker password, or whatever method that may not be 100% secure but at least is better than nothing)
 
faxxe
newbie
Posts: 40
Joined: Wed Dec 12, 2018 1:46 pm

Re: v7.17beta [testing] is released!

Sat Oct 19, 2024 1:01 am

The approach sounds like success, surprising that a company has not yet recognized this.
Presumably the cheap hardware prevails
 
gigabyte091
Forum Guru
Forum Guru
Posts: 1490
Joined: Fri Dec 31, 2021 11:44 am
Location: Croatia

Re: v7.17beta [testing] is released!

Sat Oct 19, 2024 6:46 am

On PPSK there is still an incorrect password error when changing from one passphrase to another for the first time after forgetting old network.
 
User avatar
frank333
Member
Member
Posts: 333
Joined: Mon Dec 18, 2017 12:17 pm
Location: S.Marino Router model: RB3011UiAS-RM+RBM11G

Re: v7.17beta [testing] is released!

Sat Oct 19, 2024 1:17 pm

are you planning, an update to register eSIMs with a graphical interface? I tried AT commands but it's hell...
Schermata del 2024-10-19 12.16.33.jpeg
You do not have the required permissions to view the files attached to this post.
 
User avatar
Jotne
Forum Guru
Forum Guru
Posts: 3334
Joined: Sat Dec 24, 2016 11:17 am
Location: Magrathean

Re: v7.17beta [testing] is released!

Sat Oct 19, 2024 2:10 pm

Even for the useful RB750Gr3 there is now an announced replacement with 128MB flash!
That I didn't know! Where is it? Great news, finally we are leaving the 16MB behind!
And its arm as well, so zerotier etc should work.
 
User avatar
Jotne
Forum Guru
Forum Guru
Posts: 3334
Joined: Sat Dec 24, 2016 11:17 am
Location: Magrathean

Re: v7.17beta [testing] is released!

Sat Oct 19, 2024 2:11 pm

What's new in 7.17beta4 (2024-Oct-18 11:32):

*) log - added hostname support to remote logging action;
Do you have any more information on this?
 
hapoo
Frequent Visitor
Frequent Visitor
Posts: 59
Joined: Wed Apr 24, 2019 1:35 am

Re: v7.17beta [testing] is released!

Sat Oct 19, 2024 6:09 pm

Even for the useful RB750Gr3 there is now an announced replacement with 128MB flash!

Was there an announcement I missed? Where do you see this?
 
bmann
newbie
Posts: 29
Joined: Sat Jan 05, 2013 2:10 pm

Re: v7.17beta [testing] is released!

Sat Oct 19, 2024 6:23 pm

I like Mikrotik gear for it's flexibility and features. You can use it home, in SMB or as ISP and it is affordable.
Just not sure if the security is taken seriously as Mikrotik is not much transparent on it.

Anyway one problem that have with many home devices which were installed and forgotten. Then hacked and put to botnet:
https://therecord.media/more-than-90000 ... to-new-bug

I think that many ISPs are responsible to have proper configurations and patched systems, but many of them do not care too.

So I understand why Mikrotik wants to restrict device mode.
For new devices it is OK, but do not like the approach for actual big deployments. The proposals are here so I hope they will adjust the approach.
 
holvoetn
Forum Guru
Forum Guru
Posts: 6618
Joined: Tue Apr 13, 2021 2:14 am
Location: Belgium

Re: v7.17beta [testing] is released!

Sat Oct 19, 2024 6:33 pm

Even for the useful RB750Gr3 there is now an announced replacement with 128MB flash!

Was there an announcement I missed? Where do you see this?
viewtopic.php?t=211863
 
TomSF
Member Candidate
Member Candidate
Posts: 104
Joined: Tue Jun 27, 2017 2:12 am

Re: v7.17beta [testing] is released!

Sat Oct 19, 2024 7:06 pm

Beta 4 issues. I have a wireguard tunnel between two locations. Both locations automatically upgraded to B4 and then I could not access devices at location A from location B, and vice versa. I can Winbox into both routers though. In fact, I could not even ping devices at location B when Winboxed into location B. I downgraded location B to 7.16.1 but the problem remained. I then downgraded location A to 7.16.1 and the problems went away.

Addendum:
I upgraded location B to Beta4 again and no problems. I then upgraded location A to Beta4 again and no problems. I have no idea why things did not work initially.
Last edited by TomSF on Sun Oct 20, 2024 2:20 am, edited 3 times in total.
 
User avatar
clorichel
just joined
Posts: 7
Joined: Thu Aug 11, 2022 11:40 am

Re: v7.17beta [testing] is released!

Sat Oct 19, 2024 7:41 pm

the -s option wasn't working anymore on netinstall-cli version 7.16.1, while the latest 7.17beta4 somehow fixed it: thanks 🤗

please update your docs though: https://help.mikrotik.com/docs/spaces/R ... Netinstall mentions "text file in .RSC format" where it actually only works with .scr files
 
Sit75
just joined
Posts: 12
Joined: Thu Mar 11, 2021 9:43 pm

Re: v7.17beta [testing] is released!

Sat Oct 19, 2024 10:48 pm

Another bug or "feature". The WiFi .wnm parameter does not seem to be supported.
You do not have the required permissions to view the files attached to this post.
 
erlinden
Forum Guru
Forum Guru
Posts: 2584
Joined: Wed Jun 12, 2013 1:59 pm
Location: Netherlands

Re: v7.17beta [testing] is released!

Sat Oct 19, 2024 11:42 pm

Can you please share:
/interface/wifi/export
Remove any private info.

Update: it works on my machine. Could it be a typo?
 
joedoelv
just joined
Posts: 2
Joined: Mon Apr 06, 2020 2:03 pm

Re: v7.17beta [testing] is released!

Sun Oct 20, 2024 10:25 am

After updating my RB5009 to 7.17beta4 I've found that there is an issue with v4 DHCP server dealing with static leases.
Windows 11 24H2 failed to obtain IPv4 address (IPv6 is OK) after timeout.
With Wireshark, I've found that Windows is not receiving ACK from Mikrotik.
Checked debug logs on Mikrotik - and here was a message about "not authoritative, ignoring".
Found under address-pool parameter authoritative=after-2sec-delay (wasn't here before) - changed it to 'yes'
After that Mikrotik started to send NACK as soon as second/repeated DHCP REQUEST received.
Have to downgrade to 7.16.1 - no issue whatsoever.
P.S. If static lease is removed - dynamic one is working.
 
User avatar
Jotne
Forum Guru
Forum Guru
Posts: 3334
Joined: Sat Dec 24, 2016 11:17 am
Location: Magrathean

Re: v7.17beta [testing] is released!

Sun Oct 20, 2024 11:50 am

Even for the useful RB750Gr3 there is now an announced replacement with 128MB flash!

Was there an announcement I missed? Where do you see this?
Seems that you did not read this thread, it was posted just above latest beta4 info where we did get this info :)
viewtopic.php?p=1104012#p1104012
 
pe1chl
Forum Guru
Forum Guru
Posts: 10519
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.17beta [testing] is released!

Sun Oct 20, 2024 12:40 pm

I get the need to dial some things down, but for already-deployed devices, there's got to be a compromise. This affects far more devices than the partition issues do (hundreds vs. dozens for me, anyway).
To be fair, I think Mikrotik is listening. The recent change on partitioning shows this. They will probably go on tweaking this, using the beta as a RFC for the settings.
Apparently they have gotten a lot of flak for being part of DDoS botnets. And now in panic they try to disable all features that could generate a lot of traffic from the botnet members.
However, as I wrote before I think it is more effective to improve things that affect the home user who is not upgrading anyway...
Like "automatic upgrade" enabled by default on new devices, and upgrading/resetting firewall settings made easier.
It will be years before the millions of routers in the field ever see 7.17 installed, and while the above also does not fix it, at least it improves the situation on the way forward (I already suggested automatic upgrades long ago. Competitors usually have it).
 
User avatar
Paternot
Forum Guru
Forum Guru
Posts: 1047
Joined: Thu Jun 02, 2016 4:01 am
Location: Niterói / Brazil

Re: v7.17beta [testing] is released!

Sun Oct 20, 2024 4:22 pm

Apparently they have gotten a lot of flak for being part of DDoS botnets. And now in panic they try to disable all features that could generate a lot of traffic from the botnet members.
However, as I wrote before I think it is more effective to improve things that affect the home user who is not upgrading anyway...
Well, it's a hard nut to crack. If the user doesn't update, there isn't much we can do about it NOW, is there? Future versions could come with better defaults, more sensible options.

I agree with You: years will pass before the last "un-upgraded" unit is put out of its misery. At the same time, they are trying to do something now - even if only for the future. You know: "a thousand steps", "walk", "start" and all that.

And, again, we agree that the transition from "it was this way" and "now device-mode does it this way" is in serious need of attention. They did something for the partitioning - a good signal - but they still need to address the rest. There is simple no way to put this in production the way it is: everything will break.

New units are a whole different thing: I think we would need just minor tweaks on this device thing, nothing more.
 
infabo
Forum Guru
Forum Guru
Posts: 1447
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.17beta [testing] is released!

Sun Oct 20, 2024 5:04 pm

pe1chl, automatic updates mean for the vendor: more, more and much more testing. You cant push out another "stable release" when there are millions of devices out there potentially to turn into bricks.
In case of manual update action, as it is until today, the vendor can always play the deny game, commonly something like:

- why do you even upgrade a running system?
- why do you upgrade in production?
- why do you not first test upgrade in lab?
- why do you even hit upgrade button when no disaster recovery plan in place?
- etc

Once this is a automatic process, the vendor cant play the "your fault" card.

Easy as that.
 
nmt1900
Frequent Visitor
Frequent Visitor
Posts: 85
Joined: Wed Feb 01, 2017 12:36 am

Re: v7.17beta [testing] is released!

Sun Oct 20, 2024 5:53 pm

Mikrotik is not even able to provide proper release notes to new releases - big established vendors are able to provide release notes which include "known issues" section which provides workarounds to these issues as well.
(By not doing this) Mikrotik is able to just bury head in sand and pretend not knowing about these at all and there's no transparency about this. All software upgrades being free of charge has the consequence of us paying for this with our own work when managing these devices.

Introducing automatic upgrades and forcing them to be on as default would be suicidal for them.

One snippet related to this - Fortinet does provide this functionality but it is not forced to be on and as they are able to provide information about known issues I found that they had turned this feature off for new release as they found out a huge problem with other devices managed by Fortigates -> FortiOS 7.2.10 release notes

It is not realistic to expect RouterOS automatic upgrades to be "seamless" if at least similar level of release information and handling of known issues is not acheved.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10519
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.17beta [testing] is released!

Sun Oct 20, 2024 6:47 pm

pe1chl, automatic updates mean for the vendor: more, more and much more testing. You cant push out another "stable release" when there are millions of devices out there potentially to turn into bricks.
As I explained in the previous iterations of this topic: there should be a separate channel for urgent updates that really need to be installed to cover some serious issue. It would best be based on a long-term version that has been in use for some time, with the least required changes to cover the new vulnerability.
Devices that have not been configured to do otherwise (i.e. those that have been put in use by naive users that just open the box, connect it up, and perform the minimum required work to get the device operational) would auto-upgrade to that version when its version number is higher than the installed version.
Preferably, parts of the default configuration that have been changed in the release but were not changed in the unit will also be upgraded (e.g. the firewall for a default configuration).
Of course it can make existing devices fail. But so can leaving them on ancient versions forever!
When I see the routers that are distributed by ISPs here, they always have such a feature. And those brands do survive.
 
User avatar
BrateloSlava
Member Candidate
Member Candidate
Posts: 201
Joined: Mon Aug 09, 2021 10:33 am
Location: Ukraine, Kharkiv

Re: v7.17beta [testing] is released!

Sun Oct 20, 2024 7:50 pm

Honestly - do you know many home users who would ever update their router firmware at all? Any manufacturer. I haven't met any.

And about the “forced” automatic update. IMHO, this is possible only for devices that are configured somehow “step-by-step”, by a wizard, practically without manual involvement of the user. Next... Next... Next... And we got a ready configuration. There is no room for any variants, any ambiguous situations in such a configuration.

Also. There are just an inordinately large number of home users who continue to use devices for which support has long since expired. And you get the answer from them: “Well, it works somehow and it's fine”.

As a result - you get articles like this: Malware hunters at Lumen Technologies on Tuesday sounded an alarm after discovering a 40,000-strong botnet packed with end-of-life routers and IoT devices being used in cybercriminal activities.

Or this.The Rise of Packet Rate Attacks: When Core Routers Turn Evil
 
Sit75
just joined
Posts: 12
Joined: Thu Mar 11, 2021 9:43 pm

Re: v7.17beta [testing] is released!

Sun Oct 20, 2024 8:05 pm

Can you please share:
/interface/wifi/export
Remove any private info.

Update: it works on my machine. Could it be a typo?
Definitely not typo, because I have used GUI, not CLI. But CLI export seems .wnm is not supported somehow. HW hAP ac^2.
/interface wifi
set [ find default-name=wifi1 ] channel.band=2ghz-n .width=20/40mhz configuration.country=Czech .mode=ap \
    .multicast-enhance=enabled .qos-classifier=priority .ssid=xxx disabled=no mtu=1500 \
    security.authentication-types=wpa2-psk,wpa3-psk .ft=yes .ft-over-ds=yes .ft-preserve-vlanid=no .wps=disable \
    steering.neighbor-group=yyy .rrm=yes .wnm=yes
set [ find default-name=wifi2 ] channel.band=5ghz-ac .skip-dfs-channels=10min-cac .width=20/40/80mhz \
    configuration.country=Czech .mode=ap .multicast-enhance=enabled .qos-classifier=priority .ssid=xxx \
    disabled=no mtu=1500 security.authentication-types=wpa2-psk,wpa3-psk .ft=yes .ft-over-ds=yes \
    .ft-preserve-vlanid=no .wps=disable steering.neighbor-group=yyy .rrm=yes .wnm=yes
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 12895
Joined: Thu Mar 03, 2016 10:23 pm

Re: v7.17beta [testing] is released!

Sun Oct 20, 2024 8:20 pm

And about the “forced” automatic update. IMHO, this is possible only for devices that are configured somehow “step-by-step”, by a wizard, practically without manual involvement of the user.

I pretty much agree on this ... specially as quite a few breaches were due to inadequate firewall setup. And configuration is (almost) never changed by upgrading ROS. So to make changes in default setup effective on upgraded devices, the configuration either has to be completely stock (i.e. product of QuickSet) or the custom config should entirely be recorded as "delta" against default ... so that "underlying" default can be upgraded without affecting users' changes. And even this has a potential to break end configuration if users' configs still rely on particular variant of default config. Plus this would require a big change in how config changes are handled in ROS, a thing which is a heart of ROS.

I'm affraid that all MT can do is to make default config as bullet-proof as possible while allowing users to keep their config under control when upgrading. Those users, who actually do upgrade, are in better position to take care of security of their devices than those users who don't upgrade ever, upgrading ROS (manually) shows some determination after all. So IMO MT should make upgrade process more friendly to those who bother upgrading devices and less focused on those who don't upgrade ever. Yes, they should make life of owners of new devices "miserable" by requiring some sane initial setup (like setting up admin password before ever allowing any traffic in chain=forward) and I don't have much understanding to those who are whining about their "bulk initial config" tasks becoming harder ... they'll figure something out ... they might even want to pay some "trianed monkeys" to do it "half manually" if needed.
 
User avatar
spippan
Member
Member
Posts: 459
Joined: Wed Nov 12, 2014 1:00 pm

Re: v7.17beta [testing] is released!

Sun Oct 20, 2024 9:11 pm

What's new in 7.17beta4 (2024-Oct-18 11:32):


*) crypto - use hardware accelerator for GCM cipher in TLS connection on Alpine CPUs;

*) ssh - added option to configure SSH ciphers (replaced allow-none-crypto parameter);

so, could
*) crypto - use hardware accelerator for GCM cipher in TLS connection on Alpine CPUs;
...mean a pathway to use MACsec with hardware offload in the near future? (yeah i know, MACsec and TLS connection does not go along in the same sentence - but the option to use hw-offload for GCM ciphers ... just curious...)

*) ssh - added option to configure SSH ciphers (replaced allow-none-crypto parameter);
*(CLI only)
 
pe1chl
Forum Guru
Forum Guru
Posts: 10519
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.17beta [testing] is released!

Sun Oct 20, 2024 9:15 pm

Honestly - do you know many home users who would ever update their router firmware at all? Any manufacturer. I haven't met any.

And about the “forced” automatic update.
Nobody ever suggested “forced” automatic update.
What I suggest is "default" automatic update configured in devices as they come from the factory.
Experienced admins can disable it. But home users who would never update firmware now are guaranteed a "safe" version.

It could even streamline the initial installation of new devices: normally every new device first has to be upgraded to current stable firmware, THEN it has to be reset to defaults. Because out-of-the-box it will reset to the defaults of the factory installed firmware, and when the user does click the upgrade button they still are left with sub-optimal configuration (configuration is never upgraded).
 
User avatar
BrateloSlava
Member Candidate
Member Candidate
Posts: 201
Joined: Mon Aug 09, 2021 10:33 am
Location: Ukraine, Kharkiv

Re: v7.17beta [testing] is released!

Sun Oct 20, 2024 11:22 pm

What I suggest is "default" automatic update configured in devices as they come from the factory.

In principle, everything is great: the “new” device should, for example, first be connected by the WAN port to the switch or current router and the firmware should be updated. After that - configure it with the help of some wizard.
But - this does not solve the problem, how to “force” users to update in the future?
-------
And again - the unwillingness of the end user to properly “watch and maintain” the purchased device we blame as a problem on the manufacturer of the device.

Let's imagine a situation: you were brought home by a driver. Everyone got out, and the driver did not close the windows. And everyone went to bed. At night it rained heavily, water got into the car and something in the cabin got spoiled. You come to the car in the morning and notice the breakdown. Instead of scolding the driver, who operated the car incorrectly, you call the manufacturer of the car and start expressing your claims of improper quality.
 
User avatar
Paternot
Forum Guru
Forum Guru
Posts: 1047
Joined: Thu Jun 02, 2016 4:01 am
Location: Niterói / Brazil

Re: v7.17beta [testing] is released!

Sun Oct 20, 2024 11:52 pm

Let's imagine a situation: you were brought home by a driver. Everyone got out, and the driver did not close the windows. And everyone went to bed. At night it rained heavily, water got into the car and something in the cabin got spoiled. You come to the car in the morning and notice the breakdown. Instead of scolding the driver, who operated the car incorrectly, you call the manufacturer of the car and start expressing your claims of improper quality.
I think that about sums it up. We have a never ending number of aphorisms for this kind of thing:
"We can't fix stupid"
"It´s a PEBCAK"
"You can take a horse to the water, but You can't make it drink from it"
"Another Darwin Awards, I see"
And the list goes on. At some point we must concede that there's no solution for it.
 
User avatar
fischerdouglas
Frequent Visitor
Frequent Visitor
Posts: 69
Joined: Thu Mar 07, 2019 6:38 pm
Location: Brazil
Contact:

Re: v7.17beta [testing] is released!

Sun Oct 20, 2024 11:54 pm

I feel like that this talk will reach on things like ZTP, Branding, and TR069.
 
User avatar
fischerdouglas
Frequent Visitor
Frequent Visitor
Posts: 69
Joined: Thu Mar 07, 2019 6:38 pm
Location: Brazil
Contact:

Re: v7.17beta [testing] is released!

Sun Oct 20, 2024 11:57 pm

You guys fight to much!
I think that mayve a new flood of ideas colud help to remember that there is sooooo many things that Mikrotik guys needs to improve!
 
pe1chl
Forum Guru
Forum Guru
Posts: 10519
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.17beta [testing] is released!

Mon Oct 21, 2024 10:49 am

What I suggest is "default" automatic update configured in devices as they come from the factory.

In principle, everything is great: the “new” device should, for example, first be connected by the WAN port to the switch or current router and the firmware should be updated. After that - configure it with the help of some wizard.
But - this does not solve the problem, how to “force” users to update in the future?
Once again, I am NOT talking about "force". I am talking about "help".
There can be default configuration like a scheduled script that checks for new versions like once a day or once a week, at some nightly hour, and when a critical new version is available it downloads and installs it.
 
Guntis
MikroTik Support
MikroTik Support
Posts: 203
Joined: Fri Jul 20, 2018 1:40 pm

Re: v7.17beta [testing] is released!

Mon Oct 21, 2024 11:21 am

igorr29 - regarding Superchannel, it is a country profile that allows wider frequency selection, and must be used with caution to ensure regulatory compliance. What frequency can be selected is a combination of country profile you select and what frequencies the hardware supports, like with any other country profile. In this case, you selected a non-supported range - interfaces point of view. You can find what frequencies interface supports with "/interface/wifi/radio/print detail"

sit75 - what device are you using? Perhaps it is country locked? If it is not country locked device, please create a support ticket.
 
sharkys
newbie
Posts: 27
Joined: Sun Jun 22, 2014 2:01 am

Re: v7.17beta [testing] is released!

Mon Oct 21, 2024 3:26 pm



What your logs say ? If you are experiencing a problem please create supout.rif file and open a ticket with support so they can fix the bug.

I have few devices on 7.17beta and i experience no problems with dhcp server.
Found the issue, I had to change the interfaces for other relays (up/down) - when I had all set to bridge, it stopped working on 7.17 beta.

2024-10-01 08_15_39-Clipboard.png

I changed it as per relevant interfaces and works again fine.
Re logs, there were no erros just : "dhcp_main offering lease 10.0.0.XX for XX:XX:XX:XX:XX:XX without success"
Installed 7.17beta4 and again issue with DHCP Relay popup - now even changing it to Bridge or to relevant interface, did not help.
Rolled back to 7.16.1 and it's alright.

Anyone experienced any issues with DCHP Relays ? Didn't make yet any traffic dump to see what is really happening as I did upgrade midnight yesterday and had to revert. Any reasonable comments or suggestions appreciated. Thank you.
 
guipoletto
Member Candidate
Member Candidate
Posts: 201
Joined: Mon Sep 19, 2011 5:31 am

Re: v7.17beta [testing] is released!

Mon Oct 21, 2024 5:45 pm

Something that could work for more "secure" environments, instead of forcing a "no downgrade whatsoever" down our throats:

A bootloader package could be provided for interested admins, something like what's already done with the "branding" and "country lock" packages

This package would bump the "minimal supported version" for the platform, but would still allow for necessary downgrades when Mikrotik invariably pushes to "stable" some untested code that messes with production

As it stands, i can not ever risk pushing new versions to production (even those deemed "stable"), due to the massive unjustified overhead to "rollback" when some regression shows up.

Just limit rollback/downgrade to some reasonable baseline (such as whatever version was previously tested and working in that specific scenario)
 
Sit75
just joined
Posts: 12
Joined: Thu Mar 11, 2021 9:43 pm

Re: v7.17beta [testing] is released!

Mon Oct 21, 2024 10:15 pm

igorr29 - regarding Superchannel, it is a country profile that allows wider frequency selection, and must be used with caution to ensure regulatory compliance. What frequency can be selected is a combination of country profile you select and what frequencies the hardware supports, like with any other country profile. In this case, you selected a non-supported range - interfaces point of view. You can find what frequencies interface supports with "/interface/wifi/radio/print detail"

sit75 - what device are you using? Perhaps it is country locked? If it is not country locked device, please create a support ticket.
Dear Guntis, thanks for reply. There is definitely not any restriction, due to the simple fact Superchannel was possible to set on RouterOS 6 on hAP ac^2. I have raised the ticket SUP-169040 for Superchannel issue and SUP-169041 for wnm=yes issue mentioned above too. To complete overall "trinity" of issues, I have raised SUP-169042 for very probably memory leak related to fq-codel and queue implementation in RouterOS 7 branch.
 
hjoelr
newbie
Posts: 38
Joined: Mon Apr 28, 2008 11:29 pm

Re: v7.17beta [testing] is released!

Mon Oct 21, 2024 11:11 pm

Could we get address lists similar to interface lists where you first define a list and then add items to it? The ultimate goal is the ability to nest address lists. This could simplify my configurations immensely.
 
hjoelr
newbie
Posts: 38
Joined: Mon Apr 28, 2008 11:29 pm

Re: v7.17beta [testing] is released!

Mon Oct 21, 2024 11:14 pm

Another feature I really could use in Winbox is the ability to collapse related rules together in firewall>filter and firewall>mangle in particular.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10519
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.17beta [testing] is released!

Tue Oct 22, 2024 12:18 am

Could we get address lists similar to interface lists where you first define a list and then add items to it? The ultimate goal is the ability to nest address lists. This could simplify my configurations immensely.
That sure would have been better...and not only for address lists.
But it seems that in early RouterOS the design objective was to hide things like that from the user, and automagically create lists when you add items, for example.
In recent versions that was sometimes overturned, e.g. routing tables now have to be explicitly created.
Hopefully it will some time happen for address lists as well (and you can specify the type and e.g. if it has counters. just the capabilities of "ipset" in Linux).
 
User avatar
tangent
Forum Guru
Forum Guru
Posts: 1655
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Re: v7.17beta [testing] is released!

Tue Oct 22, 2024 7:41 am

I just had to revert another device from 7.17beta4 to 7.16.1 owing to these DHCP changes. This latest beta utterly wrecked an existing configuration:

  • Three independent devices stopped getting their lease renewals: an iPhone 14 running iOS 17.6.1, a cheap WiiM DAC, and an AlmaLinux VM bridged to the LAN, served from a QNAP NAS. It should go without saying that these things have nothing in common.
  • On attempting to debug it, "/ip/dhcp-server/export" hung for many seconds at a time and then errored out. (Sorry, didn't capture the exact text; I was in a bit of a panic.)

I do have DHCP snooping enabled on this LAN, but disabling it on all the devices the DHCP packets pass through did not help.

I ended up switching back to stable, resetting to defconf, and then restoring a binary backup. I'm relieved that worked, because netinstall would've been rather difficult to pull off without a working Internet gateway router. Apparently I need to make it a policy to download the current version's NPKs prior to the upgrade, just in case. 🙄

As far as I can tell, this breakage came in with beta4, not beta2. The DHCP leases aren't long enough that I would have failed to notice if all this broke prior to beta4.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10519
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.17beta [testing] is released!

Tue Oct 22, 2024 11:13 am

Depending on what type of router you use (16MB flash toy or one with sufficient flash) you can also configure partitioning so you can always switch back to the previous install without hassle...
 
ToTheFull
Member
Member
Posts: 402
Joined: Fri Mar 24, 2023 3:24 pm

Re: v7.17beta [testing] is released!

Tue Oct 22, 2024 11:25 am

i Just tried to add WPA3 via sec1 and apply to 3 of my wifi interfaces but it didn't work.
WPA3 wasn't applying, to note i don't use the main configuration tab, sec1 normally applies to everything I add it to soo long as evrything else is blanked and back spaced first. However I did notice that per device config tabs were pulled down maybe thats why. IE this vs that. Hope that makes sense.
You do not have the required permissions to view the files attached to this post.
 
User avatar
tangent
Forum Guru
Forum Guru
Posts: 1655
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Re: v7.17beta [testing] is released!

Tue Oct 22, 2024 12:01 pm

Depending on what type of router you use

hAP ax³ for the moment, 128 MB.

configure partitioning

Solid plan. Thanks for reminding me of the option.

I set the fallback sequence up for part0 → part1→ Etherboot. Sane?
 
erlinden
Forum Guru
Forum Guru
Posts: 2584
Joined: Wed Jun 12, 2013 1:59 pm
Location: Netherlands

Re: v7.17beta [testing] is released!

Tue Oct 22, 2024 12:34 pm

i Just tried to add WPA3 via sec1 and apply to 3 of my wifi interfaces but it didn't work.
What didn't work?
I tend to perform an export when in doubt if settings are correct:
/interface/wifi/export
Alternatively you can use a wifi scanner for getting insights wether i.e. WPA3 is available.
Fwiw, WPA3 is working next to WAP2 perfectly.
 
User avatar
Coughy
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Tue Apr 23, 2024 2:53 am
Location: Brisbane Au

Re: v7.17beta [testing] is released!

Tue Oct 22, 2024 12:46 pm

i Just tried to add WPA3 via sec1 and apply to 3 of my wifi interfaces but it didn't work.
What didn't work?
I tend to perform an export when in doubt if settings are correct:
/interface/wifi/export
Alternatively you can use a wifi scanner for getting insights wether i.e. WPA3 is available.
Fwiw, WPA3 is working next to WAP2 perfectly.
i wouldnt say perfectly
i have hapax3 , hapax2 , Capax devices running capsman and yes wpa3 and wpa2 are working but still getting reauthenticating and constant disconnections more with wpa3 enabled
still alot of work needs to be done on the ax devices
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 12530
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: v7.17beta [testing] is released!

Tue Oct 22, 2024 12:58 pm

 
ToTheFull
Member
Member
Posts: 402
Joined: Fri Mar 24, 2023 3:24 pm

Re: v7.17beta [testing] is released!

Tue Oct 22, 2024 1:00 pm

i Just tried to add WPA3 via sec1 and apply to 3 of my wifi interfaces but it didn't work.
What didn't work?
I tend to perform an export when in doubt if settings are correct:
/interface/wifi/export
Alternatively you can use a wifi scanner for getting insights wether i.e. WPA3 is available.
Fwiw, WPA3 is working next to WAP2 perfectly.
It's now working (WPA3 that is) but when I tried to add wpa3 via my sec1 config it wasn't applying properly for some reason.
I explained above what I did!

Back spaced evrything per device closed the tabs, chose sec1 from the top and applied for each interface,
 
erlinden
Forum Guru
Forum Guru
Posts: 2584
Joined: Wed Jun 12, 2013 1:59 pm
Location: Netherlands

Re: v7.17beta [testing] is released!

Tue Oct 22, 2024 1:44 pm

Anything can be overridden, could that have been the case? Can you share your config?
 
ToTheFull
Member
Member
Posts: 402
Joined: Fri Mar 24, 2023 3:24 pm

Re: v7.17beta [testing] is released!

Tue Oct 22, 2024 2:36 pm

Anything can be overridden, could that have been the case? Can you share your config?
Hope that helps!
# 2024-10-22 11:51:18 by RouterOS 7.17beta4
# software id = 
#
# model = C52iG-5HaxD2HaxD
# serial number =
/interface bridge
add admin-mac=18:FD auto-mac=no comment=defconf name=bridge
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wifi channel
add band=5ghz-ax comment=25mw disabled=no frequency=5745 name=155 \
    skip-dfs-channels=10min-cac width=20/40/80mhz
add band=5ghz-ax disabled=no frequency=5180 name=42 skip-dfs-channels=\
    10min-cac width=20/40/80mhz
add band=5ghz-ax disabled=no frequency=5500 name=106 skip-dfs-channels=\
    10min-cac width=20/40/80mhz
add band=2ghz-ax disabled=no frequency=2412 name=1 skip-dfs-channels=\
    10min-cac width=20mhz
add band=2ghz-ax disabled=no frequency=2437 name=6 skip-dfs-channels=\
    10min-cac width=20mhz
add band=2ghz-ax disabled=no frequency=2462 name=11 skip-dfs-channels=\
    10min-cac width=20mhz
/interface wifi
set [ find default-name=wifi1 ] channel=42 configuration.country=\
    "United Kingdom" .mode=ap .ssid=002 disabled=no \
    security.authentication-types=wpa2-psk,wpa3-psk .encryption=ccmp \
    .management-protection=allowed .wps=disable
add configuration.hide-ssid=yes .mode=ap .ssid=Radio disabled=no mac-address=\
    1A:FD master-interface=wifi1 name=wifi3 \
    security.authentication-types=wpa2-psk,wpa3-psk .encryption=ccmp .wps=\
    disable
/interface wifi security
add authentication-types=wpa2-psk,wpa3-psk disabled=no encryption=ccmp ft=yes \
    ft-over-ds=yes management-protection=allowed name=sec1 wps=disable
/interface wifi steering
add disabled=no name=steering1 neighbor-group=dynamic-001-84ef rrm=\
    yes wnm=yes
/interface wifi
# operated by CAP 48:A9, traffic processing on CAP
add channel=106 channel.frequency=5500 configuration.country="United Kingdom" \
    .mode=ap .ssid=001 disabled=no name=cap-wifi1 radio-mac=\
    48:A9 security=sec1 steering=steering1
# operated by CAP 48:A9, traffic processing on CAP
add channel=1 configuration.country="United Kingdom" .mode=ap .ssid=001 \
    disabled=no name=cap-wifi2 radio-mac=48:A9 security=sec1 \
    steering=steering1
set [ find default-name=wifi2 ] channel=11 configuration.country=\
    "United Kingdom" .mode=ap .ssid=001 disabled=no security=sec1 \
    steering=steering1
/ip pool
add name=dhcp ranges=192.168.0.100-192.168.0.200
/ip dhcp-server
add address-pool=dhcp interface=bridge lease-time=1d name=defconf
/ip smb users
set [ find default=yes ] disabled=yes
/queue type
add kind=fq-codel name=fq_codel
add kind=cake name=cake
/queue simple
add disabled=yes max-limit=250M/25M name=QOS queue=\
    pcq-upload-default/pcq-download-default target=ether1
add max-limit=250M/25M name=fq_codel queue=fq_codel/fq_codel target=ether1 \
    total-queue=fq_codel
add disabled=yes max-limit=250M/25M name=cake queue=cake/cake target=ether1
/interface bridge filter
add action=drop chain=forward in-interface=wifi3
add action=drop chain=forward out-interface=wifi3
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
add bridge=bridge comment=defconf interface=wifi1
add bridge=bridge comment=defconf interface=wifi2
add bridge=bridge interface=wifi3
/ip firewall connection tracking
set udp-timeout=10s
/ip neighbor discovery-settings
set discover-interface-list=LAN
/ipv6 settings
set disable-ipv6=yes
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/interface ovpn-server servers
add mac-address=FE:92 name=ovpn-server1
/interface wifi access-list
add action=reject disabled=no interface=cap-wifi2 mac-address=\
    1C:56 
add action=reject disabled=no interface=cap-wifi1 mac-address=\
    84:2A
add action=reject disabled=no interface=cap-wifi2 mac-address=\
    84:2A
add action=reject disabled=no interface=wifi1 mac-address=84:2A
add action=reject disabled=no interface=cap-wifi1 mac-address=\
    60:6B
add action=reject disabled=no interface=wifi2 mac-address=60:6B
add action=reject disabled=no interface=cap-wifi2 mac-address=\
    6C:A1
add action=reject disabled=no interface=wifi1 mac-address=6C:A1
add action=reject disabled=no interface=wifi2 mac-address=6C:A1
/interface wifi capsman
set enabled=yes
/ip address
add address=192.168.0.254/24 comment=defconf interface=bridge network=\
    192.168.0.0
/ip dhcp-client
add comment=defconf interface=ether1 use-peer-dns=no
/ip dhcp-server lease
add address=192.168.0.135 client-id=1:a0:80 mac-address=\
    A0:80 server=defconf
add address=192.168.0.8 client-id=1:dc:a6 mac-address=\
    DC:A6 server=defconf
add address=192.168.0.4 client-id=1:84:2a mac-address=\
    84:2A server=defconf
add address=192.168.0.104 client-id=\
    mac-address=\
    DC:A6 server=defconf
/ip dhcp-server network
add address=192.168.0.0/24 comment=defconf dns-server=192.168.0.254 gateway=\
    192.168.0.254
/ip dns
set allow-remote-requests=yes cache-size=250000KiB \
    doh-max-concurrent-queries=200 doh-max-server-connections=4 doh-timeout=\
    6s max-concurrent-queries=200 max-concurrent-tcp-sessions=40 \
    use-doh-server=https://cloudflare-dns.com/dns-query verify-doh-cert=yes
/ip dns adlist
add url="https://raw.githubusercontent.com/hagezi/dns-blocklists/main/hosts/pr\
    o.txt"
/ip dns static
add address=192.168.0.254 comment=defconf name=router.lan type=A
add address=1.1.1.1 name=cloudflare-dns.com type=A
add address=1.0.0.1 name=cloudflare-dns.com type=A
add address=9.9.9.9 disabled=yes name=dns.quad9.net type=A
add address=149.112.112.112 disabled=yes name=dns.quad9.net type=A
/ip firewall filter
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=\
    "defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
    in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
    ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
    ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related disabled=yes hw-offload=yes
add action=accept chain=forward comment=\
    "defconf: accept established,related, untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
    connection-state=new in-interface-list=WAN
add action=drop chain=input dst-port=53 in-interface=ether1 protocol=tcp
add action=drop chain=input dst-port=53 in-interface=ether1 protocol=udp
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    ipsec-policy=out,none out-interface-list=WAN
/ip ipsec profile
set [ find default=yes ] dpd-interval=2m dpd-maximum-failures=5
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh disabled=yes
/ip smb shares
set [ find default=yes ] directory=/pub
/ipv6 firewall address-list
add address=::/128 comment="defconf: unspecified address" list=bad_ipv6
add address=::1/128 comment="defconf: lo" list=bad_ipv6
add address=fec0::/10 comment="defconf: site-local" list=bad_ipv6
add address=::ffff:0.0.0.0/96 comment="defconf: ipv4-mapped" list=bad_ipv6
add address=::/96 comment="defconf: ipv4 compat" list=bad_ipv6
add address=100::/64 comment="defconf: discard only " list=bad_ipv6
add address=2001:db8::/32 comment="defconf: documentation" list=bad_ipv6
add address=2001:10::/28 comment="defconf: ORCHID" list=bad_ipv6
add address=3ffe::/16 comment="defconf: 6bone" list=bad_ipv6
/ipv6 firewall filter
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMPv6" protocol=\
    icmpv6
add action=accept chain=input comment="defconf: accept UDP traceroute" port=\
    33434-33534 protocol=udp
add action=accept chain=input comment=\
    "defconf: accept DHCPv6-Client prefix delegation." dst-port=546 protocol=\
    udp src-address=fe80::/10
add action=accept chain=input comment="defconf: accept IKE" dst-port=500,4500 \
    protocol=udp
add action=accept chain=input comment="defconf: accept ipsec AH" protocol=\
    ipsec-ah
add action=accept chain=input comment="defconf: accept ipsec ESP" protocol=\
    ipsec-esp
add action=accept chain=input comment=\
    "defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=input comment=\
    "defconf: drop everything else not coming from LAN" in-interface-list=\
    !LAN
add action=accept chain=forward comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf: drop packets with bad src ipv6" src-address-list=bad_ipv6
add action=drop chain=forward comment=\
    "defconf: drop packets with bad dst ipv6" dst-address-list=bad_ipv6
add action=drop chain=forward comment="defconf: rfc4890 drop hop-limit=1" \
    hop-limit=equal:1 protocol=icmpv6
add action=accept chain=forward comment="defconf: accept ICMPv6" protocol=\
    icmpv6
add action=accept chain=forward comment="defconf: accept HIP" protocol=139
add action=accept chain=forward comment="defconf: accept IKE" dst-port=\
    500,4500 protocol=udp
add action=accept chain=forward comment="defconf: accept ipsec AH" protocol=\
    ipsec-ah
add action=accept chain=forward comment="defconf: accept ipsec ESP" protocol=\
    ipsec-esp
add action=accept chain=forward comment=\
    "defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=forward comment=\
    "defconf: drop everything else not coming from LAN" in-interface-list=\
    !LAN
/system clock
set time-zone-name=Europe/London
/system leds settings
set all-leds-off=immediate
/system logging
add action=echo disabled=yes topics=dns
/system note
set show-at-login=no
/system package update
set channel=testing
/tool bandwidth-server
set authenticate=no enabled=no
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

 
Sit75
just joined
Posts: 12
Joined: Thu Mar 11, 2021 9:43 pm

Re: v7.17beta [testing] is released!

Tue Oct 22, 2024 9:35 pm

Anything can be overridden, could that have been the case? Can you share your config?
Hope that helps!
# 2024-10-22 11:51:18 by RouterOS 7.17beta4
# software id = 
#
# model = C52iG-5HaxD2HaxD
# serial number =
/interface bridge
add admin-mac=18:FD auto-mac=no comment=defconf name=bridge
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wifi channel
add band=5ghz-ax comment=25mw disabled=no frequency=5745 name=155 \
    skip-dfs-channels=10min-cac width=20/40/80mhz
add band=5ghz-ax disabled=no frequency=5180 name=42 skip-dfs-channels=\
    10min-cac width=20/40/80mhz
add band=5ghz-ax disabled=no frequency=5500 name=106 skip-dfs-channels=\
    10min-cac width=20/40/80mhz
add band=2ghz-ax disabled=no frequency=2412 name=1 skip-dfs-channels=\
    10min-cac width=20mhz
add band=2ghz-ax disabled=no frequency=2437 name=6 skip-dfs-channels=\
    10min-cac width=20mhz
add band=2ghz-ax disabled=no frequency=2462 name=11 skip-dfs-channels=\
    10min-cac width=20mhz
/interface wifi
set [ find default-name=wifi1 ] channel=42 configuration.country=\
    "United Kingdom" .mode=ap .ssid=002 disabled=no \
    security.authentication-types=wpa2-psk,wpa3-psk .encryption=ccmp \
    .management-protection=allowed .wps=disable
add configuration.hide-ssid=yes .mode=ap .ssid=Radio disabled=no mac-address=\
    1A:FD master-interface=wifi1 name=wifi3 \
    security.authentication-types=wpa2-psk,wpa3-psk .encryption=ccmp .wps=\
    disable
/interface wifi security
add authentication-types=wpa2-psk,wpa3-psk disabled=no encryption=ccmp ft=yes \
    ft-over-ds=yes management-protection=allowed name=sec1 wps=disable
/interface wifi steering
add disabled=no name=steering1 neighbor-group=dynamic-001-84ef rrm=\
    yes wnm=yes
/interface wifi
# operated by CAP 48:A9, traffic processing on CAP
add channel=106 channel.frequency=5500 configuration.country="United Kingdom" \
    .mode=ap .ssid=001 disabled=no name=cap-wifi1 radio-mac=\
    48:A9 security=sec1 steering=steering1
# operated by CAP 48:A9, traffic processing on CAP
add channel=1 configuration.country="United Kingdom" .mode=ap .ssid=001 \
    disabled=no name=cap-wifi2 radio-mac=48:A9 security=sec1 \
    steering=steering1
set [ find default-name=wifi2 ] channel=11 configuration.country=\
    "United Kingdom" .mode=ap .ssid=001 disabled=no security=sec1 \
    steering=steering1
/ip pool
add name=dhcp ranges=192.168.0.100-192.168.0.200
/ip dhcp-server
add address-pool=dhcp interface=bridge lease-time=1d name=defconf
/ip smb users
set [ find default=yes ] disabled=yes
/queue type
add kind=fq-codel name=fq_codel
add kind=cake name=cake
/queue simple
add disabled=yes max-limit=250M/25M name=QOS queue=\
    pcq-upload-default/pcq-download-default target=ether1
add max-limit=250M/25M name=fq_codel queue=fq_codel/fq_codel target=ether1 \
    total-queue=fq_codel
add disabled=yes max-limit=250M/25M name=cake queue=cake/cake target=ether1
/interface bridge filter
add action=drop chain=forward in-interface=wifi3
add action=drop chain=forward out-interface=wifi3
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
add bridge=bridge comment=defconf interface=wifi1
add bridge=bridge comment=defconf interface=wifi2
add bridge=bridge interface=wifi3
/ip firewall connection tracking
set udp-timeout=10s
/ip neighbor discovery-settings
set discover-interface-list=LAN
/ipv6 settings
set disable-ipv6=yes
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/interface ovpn-server servers
add mac-address=FE:92 name=ovpn-server1
/interface wifi access-list
add action=reject disabled=no interface=cap-wifi2 mac-address=\
    1C:56 
add action=reject disabled=no interface=cap-wifi1 mac-address=\
    84:2A
add action=reject disabled=no interface=cap-wifi2 mac-address=\
    84:2A
add action=reject disabled=no interface=wifi1 mac-address=84:2A
add action=reject disabled=no interface=cap-wifi1 mac-address=\
    60:6B
add action=reject disabled=no interface=wifi2 mac-address=60:6B
add action=reject disabled=no interface=cap-wifi2 mac-address=\
    6C:A1
add action=reject disabled=no interface=wifi1 mac-address=6C:A1
add action=reject disabled=no interface=wifi2 mac-address=6C:A1
/interface wifi capsman
set enabled=yes
/ip address
add address=192.168.0.254/24 comment=defconf interface=bridge network=\
    192.168.0.0
/ip dhcp-client
add comment=defconf interface=ether1 use-peer-dns=no
/ip dhcp-server lease
add address=192.168.0.135 client-id=1:a0:80 mac-address=\
    A0:80 server=defconf
add address=192.168.0.8 client-id=1:dc:a6 mac-address=\
    DC:A6 server=defconf
add address=192.168.0.4 client-id=1:84:2a mac-address=\
    84:2A server=defconf
add address=192.168.0.104 client-id=\
    mac-address=\
    DC:A6 server=defconf
/ip dhcp-server network
add address=192.168.0.0/24 comment=defconf dns-server=192.168.0.254 gateway=\
    192.168.0.254
/ip dns
set allow-remote-requests=yes cache-size=250000KiB \
    doh-max-concurrent-queries=200 doh-max-server-connections=4 doh-timeout=\
    6s max-concurrent-queries=200 max-concurrent-tcp-sessions=40 \
    use-doh-server=https://cloudflare-dns.com/dns-query verify-doh-cert=yes
/ip dns adlist
add url="https://raw.githubusercontent.com/hagezi/dns-blocklists/main/hosts/pr\
    o.txt"
/ip dns static
add address=192.168.0.254 comment=defconf name=router.lan type=A
add address=1.1.1.1 name=cloudflare-dns.com type=A
add address=1.0.0.1 name=cloudflare-dns.com type=A
add address=9.9.9.9 disabled=yes name=dns.quad9.net type=A
add address=149.112.112.112 disabled=yes name=dns.quad9.net type=A
/ip firewall filter
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=\
    "defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
    in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
    ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
    ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related disabled=yes hw-offload=yes
add action=accept chain=forward comment=\
    "defconf: accept established,related, untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
    connection-state=new in-interface-list=WAN
add action=drop chain=input dst-port=53 in-interface=ether1 protocol=tcp
add action=drop chain=input dst-port=53 in-interface=ether1 protocol=udp
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    ipsec-policy=out,none out-interface-list=WAN
/ip ipsec profile
set [ find default=yes ] dpd-interval=2m dpd-maximum-failures=5
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh disabled=yes
/ip smb shares
set [ find default=yes ] directory=/pub
/ipv6 firewall address-list
add address=::/128 comment="defconf: unspecified address" list=bad_ipv6
add address=::1/128 comment="defconf: lo" list=bad_ipv6
add address=fec0::/10 comment="defconf: site-local" list=bad_ipv6
add address=::ffff:0.0.0.0/96 comment="defconf: ipv4-mapped" list=bad_ipv6
add address=::/96 comment="defconf: ipv4 compat" list=bad_ipv6
add address=100::/64 comment="defconf: discard only " list=bad_ipv6
add address=2001:db8::/32 comment="defconf: documentation" list=bad_ipv6
add address=2001:10::/28 comment="defconf: ORCHID" list=bad_ipv6
add address=3ffe::/16 comment="defconf: 6bone" list=bad_ipv6
/ipv6 firewall filter
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMPv6" protocol=\
    icmpv6
add action=accept chain=input comment="defconf: accept UDP traceroute" port=\
    33434-33534 protocol=udp
add action=accept chain=input comment=\
    "defconf: accept DHCPv6-Client prefix delegation." dst-port=546 protocol=\
    udp src-address=fe80::/10
add action=accept chain=input comment="defconf: accept IKE" dst-port=500,4500 \
    protocol=udp
add action=accept chain=input comment="defconf: accept ipsec AH" protocol=\
    ipsec-ah
add action=accept chain=input comment="defconf: accept ipsec ESP" protocol=\
    ipsec-esp
add action=accept chain=input comment=\
    "defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=input comment=\
    "defconf: drop everything else not coming from LAN" in-interface-list=\
    !LAN
add action=accept chain=forward comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf: drop packets with bad src ipv6" src-address-list=bad_ipv6
add action=drop chain=forward comment=\
    "defconf: drop packets with bad dst ipv6" dst-address-list=bad_ipv6
add action=drop chain=forward comment="defconf: rfc4890 drop hop-limit=1" \
    hop-limit=equal:1 protocol=icmpv6
add action=accept chain=forward comment="defconf: accept ICMPv6" protocol=\
    icmpv6
add action=accept chain=forward comment="defconf: accept HIP" protocol=139
add action=accept chain=forward comment="defconf: accept IKE" dst-port=\
    500,4500 protocol=udp
add action=accept chain=forward comment="defconf: accept ipsec AH" protocol=\
    ipsec-ah
add action=accept chain=forward comment="defconf: accept ipsec ESP" protocol=\
    ipsec-esp
add action=accept chain=forward comment=\
    "defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=forward comment=\
    "defconf: drop everything else not coming from LAN" in-interface-list=\
    !LAN
/system clock
set time-zone-name=Europe/London
/system leds settings
set all-leds-off=immediate
/system logging
add action=echo disabled=yes topics=dns
/system note
set show-at-login=no
/system package update
set channel=testing
/tool bandwidth-server
set authenticate=no enabled=no
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

Remove .encryption=ccmp . It might help.
 
ToTheFull
Member
Member
Posts: 402
Joined: Fri Mar 24, 2023 3:24 pm

Re: v7.17beta [testing] is released!

Tue Oct 22, 2024 10:06 pm

What is your argument for removing the cipher which it is going to use anyway?
    Network type           : Infrastructure
    Radio type             : 802.11ax
    Authentication         : WPA3-Personal  (H2E)
    Cipher                 : CCMP
    Connection mode        : Profile
    Band                   : 5 GHz
    Channel                : 36
    Receive rate (Mbps)    : 1201
    Transmit rate (Mbps)   : 1201
    Signal                 : 88%
 
infabo
Forum Guru
Forum Guru
Posts: 1447
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.17beta [testing] is released!

Tue Oct 22, 2024 10:10 pm

Better try ".encryption=ccmp,gcmp" instead. ccmp is the default value.
 
ToTheFull
Member
Member
Posts: 402
Joined: Fri Mar 24, 2023 3:24 pm

Re: v7.17beta [testing] is released!

Tue Oct 22, 2024 10:14 pm

I'm not sure my card uses gcmp, The driver says it uses GCMP in enterprise mode only hmm.
    Authentication and cipher supported in infrastructure mode:
                                Open             None
                                Open             WEP-40bit
                                Open             WEP-104bit
                                Open             WEP
                                WPA-Enterprise   TKIP
                                WPA-Enterprise   CCMP
                                WPA-Personal     TKIP
                                WPA-Personal     CCMP
                                WPA2-Enterprise  TKIP
                                WPA2-Enterprise  CCMP
                                WPA2-Personal    TKIP
                                WPA2-Personal    CCMP
                                Open             Vendor defined
                                WPA3-Personal    CCMP
                                Vendor defined   Vendor defined
                                WPA3-Enterprise 192 Bits GCMP-256
                                OWE              CCMP
                                WPA3-Enterprise  CCMP
                                WPA3-Enterprise  TKIP
 
ToTheFull
Member
Member
Posts: 402
Joined: Fri Mar 24, 2023 3:24 pm

Re: v7.17beta [testing] is released!

Tue Oct 22, 2024 10:16 pm

Better try ".encryption=ccmp,gcmp" instead. ccmp is the default value.
I'll add it tomorrow for giggles but if I recall way back when both was used some of my gear would not connect!
 
Sit75
just joined
Posts: 12
Joined: Thu Mar 11, 2021 9:43 pm

Re: v7.17beta [testing] is released!

Wed Oct 23, 2024 12:11 am

Better try ".encryption=ccmp,gcmp" instead. ccmp is the default value.
No, remove it completely. I have bad experience with explicit verbose encryption type. WPA2 and WPA3 is enough. When there were explicit encryption type, some devices rejected to connect - that is my experience. I would avoid even explicit PMF. Devices can negotiate the best and the most secure protocol anyway.
 
User avatar
Coughy
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Tue Apr 23, 2024 2:53 am
Location: Brisbane Au

Re: v7.17beta [testing] is released!

Wed Oct 23, 2024 11:17 am

Ive tryied with and with out still same it has to be the firmware since 7.14 it is a mess and mikrotik cant fix it



Hope that helps!
# 2024-10-22 11:51:18 by RouterOS 7.17beta4
# software id = 
#
# model = C52iG-5HaxD2HaxD
# serial number =
/interface bridge
add admin-mac=18:FD auto-mac=no comment=defconf name=bridge
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wifi channel
add band=5ghz-ax comment=25mw disabled=no frequency=5745 name=155 \
    skip-dfs-channels=10min-cac width=20/40/80mhz
add band=5ghz-ax disabled=no frequency=5180 name=42 skip-dfs-channels=\
    10min-cac width=20/40/80mhz
add band=5ghz-ax disabled=no frequency=5500 name=106 skip-dfs-channels=\
    10min-cac width=20/40/80mhz
add band=2ghz-ax disabled=no frequency=2412 name=1 skip-dfs-channels=\
    10min-cac width=20mhz
add band=2ghz-ax disabled=no frequency=2437 name=6 skip-dfs-channels=\
    10min-cac width=20mhz
add band=2ghz-ax disabled=no frequency=2462 name=11 skip-dfs-channels=\
    10min-cac width=20mhz
/interface wifi
set [ find default-name=wifi1 ] channel=42 configuration.country=\
    "United Kingdom" .mode=ap .ssid=002 disabled=no \
    security.authentication-types=wpa2-psk,wpa3-psk .encryption=ccmp \
    .management-protection=allowed .wps=disable
add configuration.hide-ssid=yes .mode=ap .ssid=Radio disabled=no mac-address=\
    1A:FD master-interface=wifi1 name=wifi3 \
    security.authentication-types=wpa2-psk,wpa3-psk .encryption=ccmp .wps=\
    disable
/interface wifi security
add authentication-types=wpa2-psk,wpa3-psk disabled=no encryption=ccmp ft=yes \
    ft-over-ds=yes management-protection=allowed name=sec1 wps=disable
/interface wifi steering
add disabled=no name=steering1 neighbor-group=dynamic-001-84ef rrm=\
    yes wnm=yes
/interface wifi
# operated by CAP 48:A9, traffic processing on CAP
add channel=106 channel.frequency=5500 configuration.country="United Kingdom" \
    .mode=ap .ssid=001 disabled=no name=cap-wifi1 radio-mac=\
    48:A9 security=sec1 steering=steering1
# operated by CAP 48:A9, traffic processing on CAP
add channel=1 configuration.country="United Kingdom" .mode=ap .ssid=001 \
    disabled=no name=cap-wifi2 radio-mac=48:A9 security=sec1 \
    steering=steering1
set [ find default-name=wifi2 ] channel=11 configuration.country=\
    "United Kingdom" .mode=ap .ssid=001 disabled=no security=sec1 \
    steering=steering1
/ip pool
add name=dhcp ranges=192.168.0.100-192.168.0.200
/ip dhcp-server
add address-pool=dhcp interface=bridge lease-time=1d name=defconf
/ip smb users
set [ find default=yes ] disabled=yes
/queue type
add kind=fq-codel name=fq_codel
add kind=cake name=cake
/queue simple
add disabled=yes max-limit=250M/25M name=QOS queue=\
    pcq-upload-default/pcq-download-default target=ether1
add max-limit=250M/25M name=fq_codel queue=fq_codel/fq_codel target=ether1 \
    total-queue=fq_codel
add disabled=yes max-limit=250M/25M name=cake queue=cake/cake target=ether1
/interface bridge filter
add action=drop chain=forward in-interface=wifi3
add action=drop chain=forward out-interface=wifi3
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
add bridge=bridge comment=defconf interface=wifi1
add bridge=bridge comment=defconf interface=wifi2
add bridge=bridge interface=wifi3
/ip firewall connection tracking
set udp-timeout=10s
/ip neighbor discovery-settings
set discover-interface-list=LAN
/ipv6 settings
set disable-ipv6=yes
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/interface ovpn-server servers
add mac-address=FE:92 name=ovpn-server1
/interface wifi access-list
add action=reject disabled=no interface=cap-wifi2 mac-address=\
    1C:56 
add action=reject disabled=no interface=cap-wifi1 mac-address=\
    84:2A
add action=reject disabled=no interface=cap-wifi2 mac-address=\
    84:2A
add action=reject disabled=no interface=wifi1 mac-address=84:2A
add action=reject disabled=no interface=cap-wifi1 mac-address=\
    60:6B
add action=reject disabled=no interface=wifi2 mac-address=60:6B
add action=reject disabled=no interface=cap-wifi2 mac-address=\
    6C:A1
add action=reject disabled=no interface=wifi1 mac-address=6C:A1
add action=reject disabled=no interface=wifi2 mac-address=6C:A1
/interface wifi capsman
set enabled=yes
/ip address
add address=192.168.0.254/24 comment=defconf interface=bridge network=\
    192.168.0.0
/ip dhcp-client
add comment=defconf interface=ether1 use-peer-dns=no
/ip dhcp-server lease
add address=192.168.0.135 client-id=1:a0:80 mac-address=\
    A0:80 server=defconf
add address=192.168.0.8 client-id=1:dc:a6 mac-address=\
    DC:A6 server=defconf
add address=192.168.0.4 client-id=1:84:2a mac-address=\
    84:2A server=defconf
add address=192.168.0.104 client-id=\
    mac-address=\
    DC:A6 server=defconf
/ip dhcp-server network
add address=192.168.0.0/24 comment=defconf dns-server=192.168.0.254 gateway=\
    192.168.0.254
/ip dns
set allow-remote-requests=yes cache-size=250000KiB \
    doh-max-concurrent-queries=200 doh-max-server-connections=4 doh-timeout=\
    6s max-concurrent-queries=200 max-concurrent-tcp-sessions=40 \
    use-doh-server=https://cloudflare-dns.com/dns-query verify-doh-cert=yes
/ip dns adlist
add url="https://raw.githubusercontent.com/hagezi/dns-blocklists/main/hosts/pr\
    o.txt"
/ip dns static
add address=192.168.0.254 comment=defconf name=router.lan type=A
add address=1.1.1.1 name=cloudflare-dns.com type=A
add address=1.0.0.1 name=cloudflare-dns.com type=A
add address=9.9.9.9 disabled=yes name=dns.quad9.net type=A
add address=149.112.112.112 disabled=yes name=dns.quad9.net type=A
/ip firewall filter
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=\
    "defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
    in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
    ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
    ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related disabled=yes hw-offload=yes
add action=accept chain=forward comment=\
    "defconf: accept established,related, untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
    connection-state=new in-interface-list=WAN
add action=drop chain=input dst-port=53 in-interface=ether1 protocol=tcp
add action=drop chain=input dst-port=53 in-interface=ether1 protocol=udp
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    ipsec-policy=out,none out-interface-list=WAN
/ip ipsec profile
set [ find default=yes ] dpd-interval=2m dpd-maximum-failures=5
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh disabled=yes
/ip smb shares
set [ find default=yes ] directory=/pub
/ipv6 firewall address-list
add address=::/128 comment="defconf: unspecified address" list=bad_ipv6
add address=::1/128 comment="defconf: lo" list=bad_ipv6
add address=fec0::/10 comment="defconf: site-local" list=bad_ipv6
add address=::ffff:0.0.0.0/96 comment="defconf: ipv4-mapped" list=bad_ipv6
add address=::/96 comment="defconf: ipv4 compat" list=bad_ipv6
add address=100::/64 comment="defconf: discard only " list=bad_ipv6
add address=2001:db8::/32 comment="defconf: documentation" list=bad_ipv6
add address=2001:10::/28 comment="defconf: ORCHID" list=bad_ipv6
add address=3ffe::/16 comment="defconf: 6bone" list=bad_ipv6
/ipv6 firewall filter
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMPv6" protocol=\
    icmpv6
add action=accept chain=input comment="defconf: accept UDP traceroute" port=\
    33434-33534 protocol=udp
add action=accept chain=input comment=\
    "defconf: accept DHCPv6-Client prefix delegation." dst-port=546 protocol=\
    udp src-address=fe80::/10
add action=accept chain=input comment="defconf: accept IKE" dst-port=500,4500 \
    protocol=udp
add action=accept chain=input comment="defconf: accept ipsec AH" protocol=\
    ipsec-ah
add action=accept chain=input comment="defconf: accept ipsec ESP" protocol=\
    ipsec-esp
add action=accept chain=input comment=\
    "defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=input comment=\
    "defconf: drop everything else not coming from LAN" in-interface-list=\
    !LAN
add action=accept chain=forward comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf: drop packets with bad src ipv6" src-address-list=bad_ipv6
add action=drop chain=forward comment=\
    "defconf: drop packets with bad dst ipv6" dst-address-list=bad_ipv6
add action=drop chain=forward comment="defconf: rfc4890 drop hop-limit=1" \
    hop-limit=equal:1 protocol=icmpv6
add action=accept chain=forward comment="defconf: accept ICMPv6" protocol=\
    icmpv6
add action=accept chain=forward comment="defconf: accept HIP" protocol=139
add action=accept chain=forward comment="defconf: accept IKE" dst-port=\
    500,4500 protocol=udp
add action=accept chain=forward comment="defconf: accept ipsec AH" protocol=\
    ipsec-ah
add action=accept chain=forward comment="defconf: accept ipsec ESP" protocol=\
    ipsec-esp
add action=accept chain=forward comment=\
    "defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=forward comment=\
    "defconf: drop everything else not coming from LAN" in-interface-list=\
    !LAN
/system clock
set time-zone-name=Europe/London
/system leds settings
set all-leds-off=immediate
/system logging
add action=echo disabled=yes topics=dns
/system note
set show-at-login=no
/system package update
set channel=testing
/tool bandwidth-server
set authenticate=no enabled=no
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

Remove .encryption=ccmp . It might help.
 
naxus
just joined
Posts: 2
Joined: Tue Jan 12, 2021 2:33 pm

Re: v7.17beta [testing] is released!

Wed Oct 23, 2024 11:32 am

hapax2 - DHCP assigned every second for one device (RB260GS with DHCP and static IP fallback) - SUP-169225
 
infabo
Forum Guru
Forum Guru
Posts: 1447
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.17beta [testing] is released!

Wed Oct 23, 2024 11:52 am

Better try ".encryption=ccmp,gcmp" instead. ccmp is the default value.
No, remove it completely. I have bad experience with explicit verbose encryption type. WPA2 and WPA3 is enough. When there were explicit encryption type, some devices rejected to connect - that is my experience. I would avoid even explicit PMF. Devices can negotiate the best and the most secure protocol anyway.
Client can only use what AP promotes to support. So that's the base for negotiation. And if you disable WPA3-SAE on the AP, the client won't be able to "negotiate the most secure protocol anyway".
For the "bad experience" part: may indeed apply. There is also a warning in the docs: https://help.mikrotik.com/docs/spaces/R ... 20support.
I am in the "leave defaults" team usually. But it does not hurt to try it out and if does not help you can still unset explicit encryption value.
 
erlinden
Forum Guru
Forum Guru
Posts: 2584
Joined: Wed Jun 12, 2013 1:59 pm
Location: Netherlands

Re: v7.17beta [testing] is released!

Wed Oct 23, 2024 12:23 pm

Hope that helps!
It seems that there is difference between security. And SSID (on purpose?). I would always make one item (per SSID) in /interface/wifi/security and use that on all interfaces. Because when specifying security items on /interface/wifi explicitely, it will override the selected security item.

Can you elaborate how you want things to work?
 
pe1chl
Forum Guru
Forum Guru
Posts: 10519
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.17beta [testing] is released!

Wed Oct 23, 2024 12:45 pm

It seems that there is difference between security. And SSID (on purpose?). I would always make one item (per SSID) in /interface/wifi/security and use that on all interfaces. Because when specifying security items on /interface/wifi explicitely, it will override the selected security item.
When you are using winbox, that is a disaster waiting to happen!!!
Winbox has a big design error that makes it very difficult to use such hierarchically inherited parameters...
Whenever you have some template or similar at top level where you define e.g. security parameters, and you then use that at a lower level e.g. in an interface, it works.
But when you change any other parameter in that interface and save it, winbox will COPY the actual parameters from top level into the interface configuration, and from then on when you change the security item and expect all your interfaces to follow that change, it will fail.
(this happens in several areas in v7, e.g. also in BGP templates/connections)
 
infabo
Forum Guru
Forum Guru
Posts: 1447
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.17beta [testing] is released!

Wed Oct 23, 2024 12:48 pm

t will override the selected security item.
Some day I am going to file a feature request at Mikrotik support: "highlight overriden config values in export in different color". Or as a dedicated option in "print detail" or something. I've seen so many exports and always there are redundancies that make it hard a) to read and b) to follow.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10519
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.17beta [testing] is released!

Wed Oct 23, 2024 12:52 pm

t will override the selected security item.
Some day I am going to file a feature request at Mikrotik support: "highlight overriden config values in export in different color". Or as a dedicated option in "print detail" or something. I've seen so many exports and always there are redundancies that make it hard a) to read and b) to follow.
Inherited values should show in "greyed out" style until you change and save them, and should not be saved back into the config when they aren't changed.
Maybe the values should even be removed from local config when they are the same as the inherited value from above.
 
ToTheFull
Member
Member
Posts: 402
Joined: Fri Mar 24, 2023 3:24 pm

Re: v7.17beta [testing] is released!

Wed Oct 23, 2024 1:18 pm

Hope that helps!
It seems that there is difference between security. And SSID (on purpose?). I would always make one item (per SSID) in /interface/wifi/security and use that on all interfaces. Because when specifying security items on /interface/wifi explicitely, it will override the selected security item.

Can you elaborate how you want things to work?
Lets go back to the start, but first context!
I have 3 SSID'S across 2 devices with a hAP ax2 as controller and cAP ax as AP. SSID 01 runs 2.4G+5G on the cAP and 2.4G on the hAP which is my main wifi network which has FT/Steering with security being supplied by by sec1. Then I have SSID 02 5G which is my Living room wifi with FT disabled and SSID 03 (Radio) which is guest wifi 5G, both of these have the security set manually.

So I wanted to add WPA3 to SSID 01 for testing. I tried to apply WPA3 via sec1 to it but for some reason it wouldn't apply the setting, i tried several times and restarted the router a few times as well. In the end the only way the WPA3 setting would apply was by doing it via each wifi interface manually.

Does it all work now, yes all good, I was just trying to reason why!
 
erlinden
Forum Guru
Forum Guru
Posts: 2584
Joined: Wed Jun 12, 2013 1:59 pm
Location: Netherlands

Re: v7.17beta [testing] is released!

Wed Oct 23, 2024 1:23 pm

Does it all work now, yes all good, I was just trying to reason why!
Can't help you with that. Still, from a conceptual perspective I would use a /interface/wifi/security item per ssid. Personal preference...

But in the end...good to hear it works already.
 
ToTheFull
Member
Member
Posts: 402
Joined: Fri Mar 24, 2023 3:24 pm

Re: v7.17beta [testing] is released!

Wed Oct 23, 2024 1:30 pm

In other news today I removed the ccmp tick in sec1 and closed that section and it applied as expected, go figure... idk!
 
ToTheFull
Member
Member
Posts: 402
Joined: Fri Mar 24, 2023 3:24 pm

Re: v7.17beta [testing] is released!

Wed Oct 23, 2024 1:33 pm

Does it all work now, yes all good, I was just trying to reason why!
Can't help you with that. Still, from a conceptual perspective I would use a /interface/wifi/security item per ssid. Personal preference...

But in the end...good to hear it works already.
I used to do that but when you have to change everything 3 times and NOT make a mistake in the middle of it all, to me my way makes more sense to me. I guess we will have to beg-to-differ!
 
pe1chl
Forum Guru
Forum Guru
Posts: 10519
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.17beta [testing] is released!

Wed Oct 23, 2024 3:59 pm

So I wanted to add WPA3 to SSID 01 for testing. I tried to apply WPA3 via sec1 to it but for some reason it wouldn't apply the setting, i tried several times and restarted the router a few times as well. In the end the only way the WPA3 setting would apply was by doing it via each wifi interface manually.
I described the probably reason for that a couple of posts above. It is an error in winbox.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10519
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.17beta [testing] is released!

Wed Oct 23, 2024 4:00 pm

Please add the source IP to the message "ipsec,error payload missing: SA".
(the address where the packet was sent from that triggers the message)
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 4256
Joined: Sun May 01, 2016 7:12 pm
Location: California
Contact:

Re: v7.17beta [testing] is released!

Wed Oct 23, 2024 5:18 pm

I think there are issues in disks... I'm have "raid troubles" in 7.17beta4. Setup is just two identical sata drives, in raid1 config, on RB1100AHx4, with the raid1 volume as the mount (previously formatted ext4, not btfrs).

I went back to 7.16, and that did NOT get the disk back either. And same as 7.17, no combo of disabling & set raid-master=raid1 worked either. Since this is a test system, I decided to wipe the 2 sata drives, and recreate the raid - per the docs using btrfs formatting on raid. It was using ext4, so maybe that was an issue. Add a /containers on new raid1 to make sure, which work in 7.16.1.

Then went back to the 7.17beta4 — same issue: raid1 is not mounted. /containers not starting. And no "set"/"disable"/"enable" things in /disk worked either. Re-doing the RAID, again, does get it back. But clearly something goes wrong in 7.16.1 to 7.17beta4 with the ROSE+RAID. And it seems very repo-able.

Maybe I'm missing something — but docs are VERY skimpy on what to do to troubleshoot/fix RAID / "mounting issues". And in 7.16.1, I followed the manual to create a new RAID, and still got trouble in upgrading to 7.17beta.
 
ToTheFull
Member
Member
Posts: 402
Joined: Fri Mar 24, 2023 3:24 pm

Re: v7.17beta [testing] is released!

Wed Oct 23, 2024 5:55 pm

So I wanted to add WPA3 to SSID 01 for testing. I tried to apply WPA3 via sec1 to it but for some reason it wouldn't apply the setting, i tried several times and restarted the router a few times as well. In the end the only way the WPA3 setting would apply was by doing it via each wifi interface manually.
I described the probably reason for that a couple of posts above. It is an error in winbox.
Well at least 2 of us are on the same page, thats why i posted 'cus it didn't make any sense.
Thankyou
 
massinia
Member Candidate
Member Candidate
Posts: 184
Joined: Thu Jun 09, 2022 7:20 pm

Re: v7.17beta [testing] is released!

Wed Oct 23, 2024 9:19 pm

I have 3 SSID'S across 2 devices with a hAP ax2 as controller and cAP ax as AP. SSID 01 runs 2.4G+5G on the cAP and 2.4G on the hAP which is my main wifi network which has FT/Steering with security being supplied by by sec1. Then I have SSID 02 5G which is my Living room wifi with FT disabled and SSID 03 (Radio) which is guest wifi 5G, both of these have the security set manually.

So I wanted to add WPA3 to SSID 01 for testing.
Does it all work now, yes all good, I was just trying to reason why!
Were you able to get the FT/Steering to work with WPA3?
Some devices do not roam when WPA3 is enabled, while others (iPhone for example) only work well but only with beta4.
 
ToTheFull
Member
Member
Posts: 402
Joined: Fri Mar 24, 2023 3:24 pm

Re: v7.17beta [testing] is released!

Wed Oct 23, 2024 9:31 pm

I have 3 SSID'S across 2 devices with a hAP ax2 as controller and cAP ax as AP. SSID 01 runs 2.4G+5G on the cAP and 2.4G on the hAP which is my main wifi network which has FT/Steering with security being supplied by by sec1. Then I have SSID 02 5G which is my Living room wifi with FT disabled and SSID 03 (Radio) which is guest wifi 5G, both of these have the security set manually.

So I wanted to add WPA3 to SSID 01 for testing.
Does it all work now, yes all good, I was just trying to reason why!
Were you able to get the FT/Steering to work with WPA3?
Some devices do not roam when WPA3 is enabled, while others (iPhone for example) only work well but only with beta4.
just a quick reply, I can't give you a proper answer at this point because i have been messing with other settings as well. But I will get back to you in the next few days.

Edit: things are starting to play up so I have rolled back to my previous settings. WPA2 with CCMP Cipher set.
 
User avatar
Coughy
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Tue Apr 23, 2024 2:53 am
Location: Brisbane Au

Re: v7.17beta [testing] is released!

Thu Oct 24, 2024 10:47 am


It seems that there is difference between security. And SSID (on purpose?). I would always make one item (per SSID) in /interface/wifi/security and use that on all interfaces. Because when specifying security items on /interface/wifi explicitely, it will override the selected security item.

Can you elaborate how you want things to work?
Lets go back to the start, but first context!
I have 3 SSID'S across 2 devices with a hAP ax2 as controller and cAP ax as AP. SSID 01 runs 2.4G+5G on the cAP and 2.4G on the hAP which is my main wifi network which has FT/Steering with security being supplied by by sec1. Then I have SSID 02 5G which is my Living room wifi with FT disabled and SSID 03 (Radio) which is guest wifi 5G, both of these have the security set manually.

So I wanted to add WPA3 to SSID 01 for testing. I tried to apply WPA3 via sec1 to it but for some reason it wouldn't apply the setting, i tried several times and restarted the router a few times as well. In the end the only way the WPA3 setting would apply was by doing it via each wifi interface manually.

Does it all work now, yes all good, I was just trying to reason why!
Out of curiosity what winbox you using?
im still usung 3 dont like the winbox 4
 
ToTheFull
Member
Member
Posts: 402
Joined: Fri Mar 24, 2023 3:24 pm

Re: v7.17beta [testing] is released!

Thu Oct 24, 2024 10:53 am

Winbox 3 I keep trying to pry myself from it.....
 
merkkg
just joined
Posts: 15
Joined: Thu Jan 19, 2017 11:50 am

Re: v7.17beta [testing] is released!

Mon Oct 28, 2024 11:19 am

too quiet in here, we need another beta release
 
User avatar
eworm
Forum Guru
Forum Guru
Posts: 1090
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: v7.17beta [testing] is released!

Mon Oct 28, 2024 11:30 am

Hmm, looks like the SFTP client is broken... The backup script on my lab device failed. All other devices running 7.16 did succeed, so I am sure the server is ok.
This is still an issue with RouterOS 7.17beta4. Just opened support ticket SUP-169652.
 
Sit75
just joined
Posts: 12
Joined: Thu Mar 11, 2021 9:43 pm

Re: v7.17beta [testing] is released!

Mon Oct 28, 2024 7:50 pm

I am little bit confused, I have rised the ticket for unavailability to set "superchannel" on hAP ac^2 with "wifi-qcom-ac" driver. Fine, conclusion is - this feature in not supported, use old wireless drivers. Well, superchannel is newly supported in "wifi-qcom" branch, but not in "wifi-qcom-ac" branch. It means those branches are developed completely independently? It means for example that "wifi-qcom-ac - allow use of channel 144 under "Japan" regulatory domain" is solely for "wifi-qcom-ac" and not available in "wifi-qcom"? Makes it sense? Especially for features where definitely not a constrain size of memory?
 
teslasystems
just joined
Posts: 21
Joined: Sun Aug 09, 2015 3:00 pm

Re: v7.17beta [testing] is released!

Mon Oct 28, 2024 10:39 pm

Hmm, looks like the SFTP client is broken... The backup script on my lab device failed. All other devices running 7.16 did succeed, so I am sure the server is ok.
This is still an issue with RouterOS 7.17beta4. Just opened support ticket SUP-169652.
SFTP works fine on my router with 7.17beta2
 
merkkg
just joined
Posts: 15
Joined: Thu Jan 19, 2017 11:50 am

Re: v7.17beta [testing] is released!

Wed Oct 30, 2024 4:13 pm

7.17beta5 😀
 
User avatar
eworm
Forum Guru
Forum Guru
Posts: 1090
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: v7.17beta [testing] is released!

Wed Oct 30, 2024 4:52 pm

Hmm, looks like the SFTP client is broken... The backup script on my lab device failed. All other devices running 7.16 did succeed, so I am sure the server is ok.
This is still an issue with RouterOS 7.17beta4. Just opened support ticket SUP-169652.
The support reproduced this, a fix is pending.
 
User avatar
fischerdouglas
Frequent Visitor
Frequent Visitor
Posts: 69
Joined: Thu Mar 07, 2019 6:38 pm
Location: Brazil
Contact:

Re: v7.17beta [testing] is released!

Wed Oct 30, 2024 5:50 pm

https://help.mikrotik.com/docs already has references to 7.17beta5, but only beta4 is available in testing chain.

1- Those complainer that only complain and do not know how to differ a testing chain from a stable chain are a pain in the a**.
2- Mikrotik Guys are becoming afraid of the critics of those complainers and it make the process Weak.
 
merkkg
just joined
Posts: 15
Joined: Thu Jan 19, 2017 11:50 am

Re: v7.17beta [testing] is released!

Wed Oct 30, 2024 5:53 pm

Yeap I saw the references for 7.17b5 that's why got excited but I guess maybe tomorrow or Friday.
 
PackElend
Member Candidate
Member Candidate
Posts: 272
Joined: Tue Sep 29, 2020 6:05 pm

Re: v7.17beta [testing] is released!

Wed Oct 30, 2024 8:00 pm

7.17beta5 😀
Where to find it on the docs?
 
User avatar
chechito
Forum Guru
Forum Guru
Posts: 3115
Joined: Sun Aug 24, 2014 3:14 am
Location: Bogota Colombia
Contact:

Re: v7.17beta [testing] is released!

Wed Oct 30, 2024 8:34 pm

https://help.mikrotik.com/docs already has references to 7.17beta5, but only beta4 is available in testing chain.

1- Those complainer that only complain and do not know how to differ a testing chain from a stable chain are a pain in the a**.
2- Mikrotik Guys are becoming afraid of the critics of those complainers and it make the process Weak.
an that is bad?? your eagerness to criticize sometimes gets out of hand, i think is a good thing that documentation improves on following or even anticipate changes and new features, its not perfect, but,

where you see a motive to criticize i see a motive to congratulate
 
crosswind
newbie
Posts: 46
Joined: Tue Feb 18, 2020 3:47 pm

Re: v7.17beta [testing] is released!

Wed Oct 30, 2024 9:39 pm

rumour has it 7.17beta5 includes support for managed address configuration (IA_NA) in DHCPv6 server - very exciting!
 
User avatar
fischerdouglas
Frequent Visitor
Frequent Visitor
Posts: 69
Joined: Thu Mar 07, 2019 6:38 pm
Location: Brazil
Contact:

Re: v7.17beta [testing] is released!

Wed Oct 30, 2024 10:06 pm

an that is bad??
It's bad to the extent that all that complaining about changes in device-mode made Mikrotik Guys go back to hiding progress, and stop releasing testing with every possible release.

Do I think they're wrong?

Maybe a little...

But putting myself in their shoes, if every time they release a change a horde of zombies appears shouting (even though it's in testing), it's only natural that they start hiding their actions more.
 
merkkg
just joined
Posts: 15
Joined: Thu Jan 19, 2017 11:50 am

Re: v7.17beta [testing] is released!

Wed Oct 30, 2024 10:09 pm

7.17beta5 😀
Where to find it on the docs?
https://help.mikrotik.com/docs/pages/di ... ersions=29

but u can just go to https://help.mikrotik.com/docs and search for 7.17 in the search bar
Last edited by merkkg on Wed Oct 30, 2024 10:14 pm, edited 1 time in total.
 
User avatar
spippan
Member
Member
Posts: 459
Joined: Wed Nov 12, 2014 1:00 pm

Re: v7.17beta [testing] is released!

Wed Oct 30, 2024 10:12 pm

an that is bad??
But putting myself in their shoes, if every time they release a change a horde of zombies appears shouting (even though it's in testing), it's only natural that they start hiding their actions more.
that's the nature of this community i learnt over the years now. sad.
 
User avatar
spippan
Member
Member
Posts: 459
Joined: Wed Nov 12, 2014 1:00 pm

Re: v7.17beta [testing] is released!

Wed Oct 30, 2024 10:19 pm


so, could
*) crypto - use hardware accelerator for GCM cipher in TLS connection on Alpine CPUs;
...mean a pathway to use MACsec with hardware offload in the near future? (yeah i know, MACsec and TLS connection does not go along in the same sentence - but the option to use hw-offload for GCM ciphers ... just curious...)
...any chances? :|
 
itimo01
newbie
Posts: 25
Joined: Thu Jun 29, 2023 2:55 am
Location: Germany
Contact:

Re: v7.17beta [testing] is released!

Wed Oct 30, 2024 10:44 pm



But putting myself in their shoes, if every time they release a change a horde of zombies appears shouting (even though it's in testing), it's only natural that they start hiding their actions more.
that's the nature of this community i learnt over the years now. sad.
Like my tik trainer said, "don't listen to the forums" ^^

Coming from Unifi around 1 1/2 year ago, the forums there are more like "Unifi is the holy grail and whatever they say, we listen to"
The difference is quite interesting, and I do wonder how the mikrotik forum became so "toxic"
 
User avatar
sirbryan
Member
Member
Posts: 391
Joined: Fri May 29, 2020 6:40 pm
Location: Utah
Contact:

Re: v7.17beta [testing] is released!

Thu Oct 31, 2024 4:07 am


It's bad to the extent that all that complaining about changes in device-mode made Mikrotik Guys go back to hiding progress, and stop releasing testing with every possible release.
Every company on the planet that releases alphas and betas is doing so for user feedback. With MikroTik, unless you're a large buyer (i.e. distributor or VAR) or have some other means of influence, the forums and support tickets are the only way to get their attention.

I'm glad @normis, @antonb, @mrz, and others follow the forum, and sometimes their responses help us users understand where they're headed with particular features or decisions. It's obvious that their management team hadn't considered how often and frequent particular functionality was used, or they hadn't thought of those use cases (despite being documented and shared in the MikroTik realm for quite some time). I'm also glad they're adjusting their plans based on user feedback and look forward to testing 7.17 with those adjustments. But it's sad it took so much "yelling" (as it were) to get it considered. If they have a vetted/trusted alpha/beta-user program, the proverbial net hasn't been cast wide enough.

I'm just as vocal on Ubiquiti's forums when they make decisions reducing functionality of their hardware or software, or arbitrarily change settings in the name of security. I'm also critical of the design of some of their outdoor hardware (poor mounting options or lousy cable covers, for example). But, to their credit, Ubiquiti has shown up to shows like WISPAPALOOZA the last two years (including Robert Pera, with whom I got to talk for a few minutes last year), and they get an earful (good and bad) from many of the ISPs who buy (and advocate the use of) their products. This year I shared some frustrations with their product design again, and they took notes and affirmed that some changes related to what we've been asking for are coming down the pipe. (I also expressed appreciation for products that have helped me grow my business; not all feedback is bad or negative.) In short, with Ubqiuiti, I know for certain that my feedback is valued.

In all the years I've gone to ISP-related shows, I've yet to see MikroTik show up in any kind of official capacity, and am left talking with some of their distributors. (I have not been to MUM's anywhere, to be fair.) So, where else to go to voice feedback and general concern about hardware and/or decisions, except these forums, and more specifically, beta-related discussions?
 
itimo01
newbie
Posts: 25
Joined: Thu Jun 29, 2023 2:55 am
Location: Germany
Contact:

Re: v7.17beta [testing] is released!

Thu Oct 31, 2024 5:27 am

But it's sad it took so much "yelling" (as it were) to get it considered
I completely agree on that part.
And mikrotik should take constructive criticism and definitely take user requests into focus.
But to say there's been a lot of non-constructive criticism from what I've seen (I do have to add that I'm barely active) ^^

from many of the ISPs who buy
That's great that they listen to the ISPs. I heard that also on the "End-User" end they changed.
On campus networks which they also market their "unifi" line for, there were a lot of missing features with no change in sight (till recently)
Also, a lot of dead APs.
In all the years I've gone to ISP-related shows, I've yet to see MikroTik show up in any kind of official capacity
That's quite disappointing to hear.
 
User avatar
mantouboji
Frequent Visitor
Frequent Visitor
Posts: 58
Joined: Mon Aug 01, 2022 2:21 pm
Location: Shanghai

Re: v7.17beta [testing] is released!

Thu Oct 31, 2024 8:56 am

beta4 is so stable?
 
User avatar
strods
MikroTik Support
MikroTik Support
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v7.17beta [testing] is released!

Thu Oct 31, 2024 8:58 am

Do not worry, we are working on a new beta releases, new features and improvements - including device mode and others. We have never promised to release a new beta every few days. Nobody is hiding here from anyone - we are working!

Beta is beta - it is released so you can test fixes and new features, if you are a MikroTik enthusiast. Yes, things can get broken for you. That is the risk you are willing to take when you install beta.

The same goes here for device-mode - we are still working on it. Earlier betas were released so you can test also other fixes, not just device-mode. Do not focus just on one "change" here, others must be tested too.

We do welcome constructive criticism and feedback and improve our betas until release-candidates, and then the "final result" should be judged on the "stable" release. Beta is work in progress!
 
sinisa
newbie
Posts: 34
Joined: Sun Apr 17, 2011 12:46 am

Re: v7.17beta [testing] is released!

Thu Oct 31, 2024 11:11 am

beta4 is so stable?
Do not worry, we are working on a new beta releases, ...
Read: we are making it less stable :)

Sorry, could not resist
 
User avatar
strods
MikroTik Support
MikroTik Support
Posts: 1658
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v7.17beta [testing] is released!

Thu Oct 31, 2024 1:32 pm

Nothing to resist. That is the whole point of beta releases. Bunch of new stuff to test which can break something else. Otherwise, we would not release them at all like in the past and just prepare stable rc. Again - betas are released to test specific fixes, not the general system stability.
 
merkkg
just joined
Posts: 15
Joined: Thu Jan 19, 2017 11:50 am

Re: v7.17beta [testing] is released!

Thu Oct 31, 2024 2:24 pm

Nothing to resist. That is the whole point of beta releases. Bunch of new stuff to test which can break something else. Otherwise, we would not release them at all like in the past and just prepare stable rc. Again - betas are released to test specific fixes, not the general system stability.
I agree and I'm ready to test and happy to give feedback on MPLS HW Offloading and Multiple VRF tables L3HW Offloading not only main table. (only reason I cant use L3HW Offloading)
 
ThrowMeAwayDaddy
just joined
Posts: 5
Joined: Fri Apr 12, 2024 2:11 am

Re: v7.17beta [testing] is released!

Thu Oct 31, 2024 5:49 pm

I'm noticing a strange performance regression using ingress policing on the current beta release. Tests were done using the WAN interface (sfp28-1) of the CCR2216 I have in testing.
It's almost as if there's some sort of math / calc scaling bug for policing. This is born out born out by the following results, where we start the policer at 6000Mbps and gradually work up from there.

Note: Under each set value is the actual value speed taken from a 10 pass Speedtest average.

Set Value: 6000Mbps
Actual: 897.52Mbps

Set Value: 6200Mbps
Actual: 929.84Mbps

Set Value: 6300Mbps
Actual: 948.05Mbps

Set Value: 6400Mbps
Actual: 1032.80Mbps

Set Value: 6500Mbps
Actual: 1086.70Mbps

Setting the ingress policer on an interface to 6000Mbps yields an actual throughput of less than 900Mbps. At lower speeds, moving the policer up 100Mbps at a time only increases throughput by 20-50Mbps. Eventually though, the speed starts to jump by much larger amounts:

Set Value: 8460Mbps
Actual: 6878.45 Mbps

Set Value: 8480Mbps
Actual: 7148.92Mbps

Set Value: 8500Mbps
Actual: 7394.56Mbps

Set Value: 8520Mbps
Actual: 7762.31Mbps

Set Value: 8540Mbps
Actual: 8067.23Mbps

Above we can see that 20Mbps jumps in the policer set speed are increasing the actual throughput by north of 100Mbps, an inversion from the first test results done at lower speeds.

To add additional context, I was concerned the issues might have been caused by the Speedtest servers I was using, so I replicated the results using iPerf to a server on the LAN and by applying the policer on the client side. I then removed and applied the policer on the server side and tested again. The results have remained nearly identical.

Is anyone else experiencing this? I'm happy to share more information.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10519
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.17beta [testing] is released!

Thu Oct 31, 2024 8:04 pm

Did you ever test that working on older releases?
 
User avatar
fischerdouglas
Frequent Visitor
Frequent Visitor
Posts: 69
Joined: Thu Mar 07, 2019 6:38 pm
Location: Brazil
Contact:

Re: v7.17beta [testing] is released!

Thu Oct 31, 2024 11:22 pm

fischerdouglas multiple posts compilation
What about Hardware offload of L3VPN MPLS?
Or even Hardware offload of a quite simple thing like VRFs?




Let's talk about hardware offload?
Not just kernel bypass (fast-path) but hardware offload itself...

Let's talk about the issues the comes with the actual methodology of hardware offload.
For example, if the packets are in hardware offload, no IPFIX/Netflow, and no firewall rules(even raw) are possible.



A recurrent complain is that RouterOS is becoming more Enterprise then Telco.

Is kind of true. But it is unavoidable...
What is avoidable is that those extra features interferes on progress of the core of the solution...

Have you (Mikrotik Guys) considered to put all those extra resources in Extra packages? Containers?




And what about doing all the process of control-plane being on containers?
Similar to what junos Evo and IOS-XR is doing?

It would allow better control of resources, priority, reservation.





Well... Something I said hurt somebody.
Some(maybe several) of my replies were deleted.
Attitude of incompetent and cowardly people!

I do not remember exactly what I said.
But it were related to the fact Mikrotik Guys need to split the support of hardware offload support on their development.
The limitations faced today are imposed by old models of switchchip(Atheros and Mediatek).
Marvel Prestera and Marvel Link street(Maybe eve sobre of RTL chips) certainly do support more than what is being used by Mikrotik now days!
Certainly multi VRF, L3VPN(PE), VXLAN, stateless firewall, and even a bit of Stateful firewall.

And I'm not just talking about CCR2216 here...
CRS 317/326, even 305, could be used to do PE of underlayed/overlayed networks.
To be clear, this is the difference between corporative networks to Telco Networks.

I'm talking about changing to nftables and support eBPF/XDP.
And it will probably not be supported by the old devices.
To workaround that, Mikrotik guys will need to split the development for old pieces from development for new hardware.,
Last edited by chechito on Sun Nov 03, 2024 1:02 am, edited 2 times in total.
Reason: consolidation in a single post
 
User avatar
loloski
Member
Member
Posts: 415
Joined: Mon Mar 15, 2021 9:10 pm

Re: v7.17beta [testing] is released!

Fri Nov 01, 2024 5:11 am

The future with MT is bleak anything with Service Provider solution my company accept that facts now, we are now going back to Juniper as much as possible and put mikrotik on some areas as we see it fit or put them in the shelves for eternity who knows one of these days they are going to land some code and harness the full potential of the hardware
 
merkkg
just joined
Posts: 15
Joined: Thu Jan 19, 2017 11:50 am

Re: v7.17beta [testing] is released!

Fri Nov 01, 2024 12:41 pm

The future with MT is bleak anything with Service Provider solution my company accept that facts now, we are now going back to Juniper as much as possible and put mikrotik on some areas as we see it fit or put them in the shelves for eternity who knows one of these days they are going to land some code and harness the full potential of the hardware
I disagree, sure they need to work to resolve some key issues that affecting big portion of people but I wouldn't go as far as to say it looks bleak...
 
buset1974
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Wed Sep 13, 2006 12:12 pm
Location: Jakarta

Re: v7.17beta [testing] is released!

Fri Nov 01, 2024 2:07 pm

The future with MT is bleak anything with Service Provider solution my company accept that facts now, we are now going back to Juniper as much as possible and put mikrotik on some areas as we see it fit or put them in the shelves for eternity who knows one of these days they are going to land some code and harness the full potential of the hardware
I agree, for x86 solution some of my partner prefer using vyos.
 
User avatar
loloski
Member
Member
Posts: 415
Joined: Mon Mar 15, 2021 9:10 pm

Re: v7.17beta [testing] is released!

Fri Nov 01, 2024 2:44 pm

Yep you can disagree with me anytime but it's happening, we can no longer wait for mikrotik to mature its routing and switching portfolio our company is now restructuring the team willing to let go some MT engineer not willing to be re-assigned or adapt other platform, MT not wanting to spend development on SP space cause havoc and push us to the other direction.

We learned the hard lesson and I think there's no turning back
 
merkkg
just joined
Posts: 15
Joined: Thu Jan 19, 2017 11:50 am

Re: v7.17beta [testing] is released!

Fri Nov 01, 2024 3:15 pm

Yep you can disagree with me anytime but it's happening, we can no longer wait for mikrotik to mature its routing and switching portfolio our company is now restructuring the team willing to let go some MT engineer not willing to be re-assigned or adapt other platform, MT not wanting to spend development on SP space cause havoc and push us to the other direction.

We learned the hard lesson and I think there's no turning back
I understand and respect your point of view and I can only hope that things improve before my point of view follows same as yours.
 
toxicfusion
Member
Member
Posts: 324
Joined: Mon Jan 14, 2013 6:02 pm

Re: v7.17beta [testing] is released!

Fri Nov 01, 2024 5:14 pm

Yep you can disagree with me anytime but it's happening, we can no longer wait for mikrotik to mature its routing and switching portfolio our company is now restructuring the team willing to let go some MT engineer not willing to be re-assigned or adapt other platform, MT not wanting to spend development on SP space cause havoc and push us to the other direction.

We learned the hard lesson and I think there's no turning back
We are also in the same position as you. Looking to completely move away. Even with the other hardware vendor options being more expensive; long term will be less expensive....

We are passionate about MikroTik and been using for over 10-years. However, this is where we draw the line. They're playing games and not serious. They're playing with toys and think its "cool" to push "enterprise" naming for storage protocols that do NOT belong on a router as an example.
 
Johann1525
just joined
Posts: 2
Joined: Fri Oct 27, 2023 12:00 am

Re: v7.17beta [testing] is released!

Fri Nov 01, 2024 6:41 pm

Hi,
i'm relatively new here in the Forum. I did more reading than writing tho.
My opinion on the general direction Mikrotik is going is similar to the previous posts here. I think there is a great need for products which are affordable for the small business or markets which are currently becoming more difficult. I myself work for a Town hall in Germany and we are always very restricted budget-wise. So i want to adapt the Mikrotik ecosystem. I do have some Sites which are already connected via RouterOS devices. And in general i'm very happy with them. Especially because they just do what they should without a great hassle. That is also why i use mikrotiks for my private projects since a long time because of the freedom in configuration and features.
But how should i sell my colleagues and boss a Solution which is completely randomly deciding to focus on NAS Features when things like HW-accel or proper HA are nothing near ready? Even the documentation is sometimes, lets say, difficult. I do not even want to start about the log formats.
And hey. even implementing something like snort as a package would be more fitting into a router than NFS or even dlna.

There is a Point why we do not like the FritzBox approach! And if you want to go that route. Please start integrating asterisk so i do know when to recommend your products to some home user Friends, who do not want to pay a cent, instead of considering it as a soulution for the business.

The summary is. Please Mikrotik keep your spirit at your pace. I do not care about early adopting some wifi standard or any other features. But try to stay on the good path you started.

My English is not native so sorry if it sounds like a rant. Just my opinion. :)
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 4256
Joined: Sun May 01, 2016 7:12 pm
Location: California
Contact:

Re: v7.17beta [testing] is released!

Fri Nov 01, 2024 7:33 pm

Well, I just looked at the webfig. Does look nice, & like the collapsing of the left-side.

But this one affects us.
*) webfig - status page is deprecated, old status page config will work, but can't be updated or created;
The webfig "status page" was the only way to create some customer-friendly dashboard. I use these status pages (and custom "QuickSet-safe" defconf) to enable deployment by less-sophisticated installers/customers. So I'm not sure why remove stuff that was actually working. While the whole "status page" system could be improved – it was the only way I've found to present some simple "dashboard" to see if the routers was working, without having to navigate a half-dozen RouterOS menus to find out same info....

And the "can't be updated" part really does not help... since often the ".id" of the status page elements does need to change sometimes. And given netinstall for the 16MB is common... so "keeping the old status page" is not so easily done.

Additionally, I notice there is a "Get Apps" in the new webfig, but that gets you an HTTP 404 from mikrotik.com/getapps:
WebFigGetApps404Error.png
You do not have the required permissions to view the files attached to this post.
 
crosswind
newbie
Posts: 46
Joined: Tue Feb 18, 2020 3:47 pm

Re: v7.17beta [testing] is released!

Sat Nov 02, 2024 7:47 am

Let's talk about the issues the comes with the actual methodology of hardware offload.
For example, if the packets are in hardware offload, no IPFIX/Netflow, and no firewall rules(even raw) are possible.
ROS supports two different "methodologies" of hardware offload. if you use basic L3HW, you cannot offload iptables rules, but you can do filtering in the switch chip, which is largely equivalent to raw rules.

if you want to offload proper iptables rules, you can disable L3HW and enable FastTrack HW offload instead, which still provides offload of L3 connections after the initial setup.

it's true MikroTik doesn't have a full stateful firewall in hardware, but it's not like firewall and L3HW are entirely incompatible.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7174
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: v7.17beta [testing] is released!

Sat Nov 02, 2024 11:05 am

But how should i sell my colleagues and boss a Solution which is completely randomly deciding to focus on NAS Features when things like HW-accel or proper HA are nothing near ready?
If you read this forum then you will notice statements that more than one developer is working on ROS. Adding NAS features does not mean that work on HW acceleration is stopped.
Just look at the changelog of each release and see how many things are being worked on at a time.
 
Johann1525
just joined
Posts: 2
Joined: Fri Oct 27, 2023 12:00 am

Re: v7.17beta [testing] is released!

Sat Nov 02, 2024 12:28 pm

But how should i sell my colleagues and boss a Solution which is completely randomly deciding to focus on NAS Features when things like HW-accel or proper HA are nothing near ready?
If you read this forum then you will notice statements that more than one developer is working on ROS. Adding NAS features does not mean that work on HW acceleration is stopped.
Just look at the changelog of each release and see how many things are being worked on at a time.
You are right. I just felt there was kind of a trend going on the last couple releases. But maybe i'm wrong. :)
 
User avatar
mantouboji
Frequent Visitor
Frequent Visitor
Posts: 58
Joined: Mon Aug 01, 2022 2:21 pm
Location: Shanghai

Re: v7.17beta [testing] is released!

Sun Nov 03, 2024 1:07 pm

For a wireguard interface. if we disable and then re-enable it . the IPv6 link-local address fe80::xxxx. will lost and then OSPFv3 can't work , must reboot the router.
 
User avatar
Brain2000
newbie
Posts: 27
Joined: Thu Sep 26, 2024 6:20 am

Re: v7.17beta [testing] is released!

Mon Nov 04, 2024 12:37 am

OK, I found three bugs so far. One is a visual glitch, one is a showstopper, and one has a workaround.

1) When a "Station Bridge" connection is made, the GUI shows that it is Running while the CLI does not (see the CLI screenshot below and note the Station Bridge does not have an R next to it, yet the GUI counterpart shows it as "Running").

2) "Station Bridge" type connections will no longer pass traffic even though they connect. This is a connection where one side is an "AP" and the other side is a "Station Bridge". I also tried "Station Pseudobridge", and it also does not work. This is the showstopper.
(At first, after I would edit anything in the station bridge interface they would no longer reconnect, but that was because the passphrase was getting corrupted when Applying any changes. Which happens to also be the next issue.)

3) From the GUI, if you go into a wifi interface that is set up as PSK, and simply click "Apply", the passphrase will be corrupted and you'll have to go back and retype it.
Under the hood it sets the passphrase to \E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2 no matter what it was prior.
This issue has an easy workaround, don't save anything from the GUI.

bug1.png
bug1_2.png
2)
You do not have the required permissions to view the files attached to this post.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 4256
Joined: Sun May 01, 2016 7:12 pm
Location: California
Contact:

Re: v7.17beta [testing] is released!

Mon Nov 04, 2024 1:23 am

3) From the GUI, if you go into a wifi interface that is set up as PSK, and simply click "Apply", the passphrase will be corrupted and you'll have to go back and retype it.
Under the hood it sets the passphrase to \E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2 no matter what it was prior.
LOL. It's writing the UTF-8 unicode for • (a bullet, option+8 on Mac)
:put "\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2"
••••••••
which requires `ssh`, since Winbox4 Terminal will NOT render the UTF-8, which was a previously complaint pages ago here...
Last edited by Amm0 on Mon Nov 04, 2024 1:30 am, edited 3 times in total.
 
User avatar
Brain2000
newbie
Posts: 27
Joined: Thu Sep 26, 2024 6:20 am

Re: v7.17beta [testing] is released!

Mon Nov 04, 2024 1:27 am

Also, downgrading was a bit of a surprise. It would let me click "Downgrade" but nothing would happen and it would delete my downgrade files in the Files folder.
The logs showed that downgrading was not enabled. If it's not enabled, it should probably tell me so I can correct it BEFORE it fails to downgrade.
Also, having to press the button to disable downgrading.... I get it for security reasons, but I think the beta channel should, by default, allow downgrading when moving to this new version. Where the stable channel would not.

This is what the log said after the router rebooted for a downgrade:
downgrade.png
You do not have the required permissions to view the files attached to this post.
 
User avatar
Brain2000
newbie
Posts: 27
Joined: Thu Sep 26, 2024 6:20 am

Re: v7.17beta [testing] is released!

Mon Nov 04, 2024 1:29 am

3) From the GUI, if you go into a wifi interface that is set up as PSK, and simply click "Apply", the passphrase will be corrupted and you'll have to go back and retype it.
Under the hood it sets the passphrase to \E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2 no matter what it was prior.
LOL. It's writing the UTF-8 unicode for • (a bullet, option+8 on Mac)
:put "\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2"
••••••••
I thought it had something to do with the new UTF-8 support... thank you for clarifying that. I don't think WIFI passwords even support UTF-8, so we might want to nix that.
[Edit: actually wifi passwords support anything encoded into a byte array, so UTF-8 would technically be just fine. But the SSID may or may not show up correctly on various clients]
[Edit2: I wonder if the poop emoji would work.... ]
 
User avatar
fischerdouglas
Frequent Visitor
Frequent Visitor
Posts: 69
Joined: Thu Mar 07, 2019 6:38 pm
Location: Brazil
Contact:

Re: v7.17beta [testing] is released!

Mon Nov 04, 2024 2:21 am

Once again deleted messages.
Puke!
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 26881
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia
Contact:

Re: v7.17beta [testing] is released!

Mon Nov 04, 2024 8:38 am

Please keep topic to release notes! You are free to make a new topic and continue offtopic in there, but this topic must not be messed up by other discussions except changes in the version.
 
User avatar
Coughy
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Tue Apr 23, 2024 2:53 am
Location: Brisbane Au

Re: v7.17beta [testing] is released!

Mon Nov 04, 2024 9:46 am

Also, downgrading was a bit of a surprise. It would let me click "Downgrade" but nothing would happen and it would delete my downgrade files in the Files folder.
The logs showed that downgrading was not enabled. If it's not enabled, it should probably tell me so I can correct it BEFORE it fails to downgrade.
Also, having to press the button to disable downgrading.... I get it for security reasons, but I think the beta channel should, by default, allow downgrading when moving to this new version. Where the stable channel would not.

This is what the log said after the router rebooted for a downgrade:
downgrade.png
what ros where you trying to downgrade to??
i have had same issue it is the new advanced section i had to downgrade to the stable 7.16 from the packages menu then i could downgrade more with the files
i think you need to downgrade and then remove power and repower before it boots to make it downgrade i think that was it
 
User avatar
grusu
Member Candidate
Member Candidate
Posts: 140
Joined: Tue Aug 13, 2013 7:35 am
Location: Bucharest, Romania

Re: v7.17beta [testing] is released!

Mon Nov 04, 2024 10:03 am

Run:
system/device-mode/print
to see if downgrade is enabled.
 
infabo
Forum Guru
Forum Guru
Posts: 1447
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.17beta [testing] is released!

Mon Nov 04, 2024 10:43 am

3) From the GUI, if you go into a wifi interface that is set up as PSK, and simply click "Apply", the passphrase will be corrupted and you'll have to go back and retype it.
Under the hood it sets the passphrase to \E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2 no matter what it was prior.
This issue has an easy workaround, don't save anything from the GUI.
Maye be a Winbox 4 bug and not related to this specific ROS version. But as I always said for years: I don't trust Winbox.
 
User avatar
fischerdouglas
Frequent Visitor
Frequent Visitor
Posts: 69
Joined: Thu Mar 07, 2019 6:38 pm
Location: Brazil
Contact:

Re: v7.17beta [testing] is released!

Mon Nov 04, 2024 11:14 am

Please keep topic to release notes! You are free to make a new topic and continue offtopic in there, but this topic must not be messed up by other discussions except changes in the version.
OK!

When we will see in release notes changes that will show that IPv4 / IPv6 / etc are all the same routes, just exhibited with filters in winbox and CLI?

When we will se in release notes the difference between RIB and FIB and what goes and what do not goes to switchchip being well documented and informed to operators?
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 26881
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia
Contact:

Re: v7.17beta [testing] is released!

Mon Nov 04, 2024 11:43 am

You are still writing in the wrong topic!
 
1day
just joined
Posts: 2
Joined: Wed Aug 07, 2024 10:29 pm

Re: v7.17beta [testing] is released!

Mon Nov 04, 2024 2:21 pm

Due to the number of fixes I updated from latest release 16.x to 17beta4. I am now seeing a lot (like thousands) of 'invalid' dropped packets on the firewall.
I was seeing this very rarely on 16.
afaik I am running default timeouts. I increased the 10s ones to 15s to see if that would make any difference but it did not.

Have there been any changes to connection tracking?
How to trace the reason for the tracking of an existing connection being lost?
Other settings to check?
Should I try and return to 16?

I have logs on all drop actions and only see these and others that are expected (i.e. portscans, bogons, unwanted telemetry, etc)
 
pe1chl
Forum Guru
Forum Guru
Posts: 10519
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.17beta [testing] is released!

Mon Nov 04, 2024 2:29 pm

Due to the number of fixes I updated from latest release 16.x to 17beta4. I am now seeing a lot (like thousands) of 'invalid' dropped packets on the firewall.
It helps to show a couple of example log lines. There are some different reasons why these appear.
 
1day
just joined
Posts: 2
Joined: Wed Aug 07, 2024 10:29 pm

Re: v7.17beta [testing] is released!

Mon Nov 04, 2024 4:46 pm

Due to the number of fixes I updated from latest release 16.x to 17beta4. I am now seeing a lot (like thousands) of 'invalid' dropped packets on the firewall.
It helps to show a couple of example log lines. There are some different reasons why these appear.
Here are some examples though I can see these are in error.
2024-11-04 13:10:22 firewall,info **Fwd:ERR:TCP forward: in:BR11-lan out:isp<->VLAN666<->f/w, connection-state:invalid src-mac 24:5e:be:67:c8:5f, proto TCP (ACK), 192.168.30.60:45009->207.243.203.2:10006, len 168 
2024-11-04 13:10:23 firewall,info **Fwd:ERR:TCP forward: in:BR11-lan out:isp<->VLAN666<->f/w, connection-state:invalid src-mac 24:5e:be:67:c8:5f, proto TCP (ACK), 192.168.30.60:45997->73.203.163.244:5000, len 168 
2024-11-04 13:10:23 firewall,info **Fwd:ERR:TCP forward: in:BR11-lan out:isp<->VLAN666<->f/w, connection-state:invalid src-mac 24:5e:be:67:c8:5f, proto TCP (ACK,FIN,PSH), 192.168.30.60:36529->75.109.55.175:6681, len 148 
2024-11-04 13:10:27 firewall,info **Fwd:ERR:TCP forward: in:BR11-lan out:isp<->VLAN666<->f/w, connection-state:invalid src-mac 24:5e:be:67:c8:5f, proto TCP (ACK), 192.168.30.60:53731->74.87.73.194:4401, len 180 
2024-11-04 13:10:28 firewall,info **Fwd:ERR:TCP forward: in:BR24-wifi-d out:isp<->VLAN666<->f/w, connection-state:invalid src-mac 08:12:a5:63:e0:3d, proto TCP (ACK,FIN,PSH), 192.168.36.70:57720->18.165.232.238:443, len 76 
2024-11-04 13:10:32 firewall,info **Fwd:ERR:TCP forward: in:BR11-lan out:isp<->VLAN666<->f/w, connection-state:invalid src-mac 24:5e:be:67:c8:5f, proto TCP (ACK), 192.168.30.60:43165->70.185.23.111:7001, len 168 
2024-11-04 13:10:32 firewall,info **Fwd:ERR:TCP forward: in:BR11-lan out:isp<->VLAN666<->f/w, connection-state:invalid src-mac 24:5e:be:67:c8:5f, proto TCP (ACK), 192.168.30.60:57031->97.71.152.205:6881, len 168 
2024-11-04 13:10:52 firewall,info **Fwd:ERR:TCP forward: in:BR11-lan out:isp<->VLAN666<->f/w, connection-state:invalid src-mac 24:5e:be:67:c8:5f, proto TCP (ACK,FIN,PSH), 192.168.30.60:34187->216.16.76.241:3540, len 225 
2024-11-04 13:11:13 firewall,info **Fwd:ERR:TCP forward: in:BR22-wifi-p out:isp<->VLAN666<->f/w, connection-state:invalid src-mac 80:39:8c:a9:3e:94, proto TCP (ACK,PSH), 192.168.32.19:49132->104.16.8.45:443, len 608 
2024-11-04 13:11:13 firewall,info **Fwd:ERR:TCP forward: in:BR22-wifi-p out:isp<->VLAN666<->f/w, connection-state:invalid src-mac 80:39:8c:a9:3e:94, proto TCP (ACK,PSH), 192.168.32.19:49148->104.16.8.45:443, len 608 
2024-11-04 13:11:13 firewall,info **Fwd:ERR:TCP forward: in:BR22-wifi-p out:isp<->VLAN666<->f/w, connection-state:invalid src-mac 80:39:8c:a9:3e:94, proto TCP (ACK,PSH), 192.168.32.19:49132->104.16.8.45:443, len 76 
2024-11-04 13:11:13 firewall,info **Fwd:ERR:TCP forward: in:BR22-wifi-p out:isp<->VLAN666<->f/w, connection-state:invalid src-mac 80:39:8c:a9:3e:94, proto TCP (ACK,PSH), 192.168.32.19:49148->104.16.8.45:443, len 76 
2024-11-04 13:11:13 firewall,info **Fwd:ERR:TCP forward: in:BR22-wifi-p out:isp<->VLAN666<->f/w, connection-state:invalid src-mac 80:39:8c:a9:3e:94, proto TCP (ACK,PSH), 192.168.32.19:49132->104.16.8.45:443, len 76 
2024-11-04 13:11:13 firewall,info **Fwd:ERR:TCP forward: in:BR22-wifi-p out:isp<->VLAN666<->f/w, connection-state:invalid src-mac 80:39:8c:a9:3e:94, proto TCP (ACK,PSH), 192.168.32.19:49148->104.16.8.45:443, len 76 
I've run TCP dump on the server 192.168.30.60 (who's IP is mentioned as a source) and that server is not sending that traffic. So this is some sort of data leak causing phantom packets probably related to real traffic but with the details munged, hence why I don't find those mentioned connection in the connections list.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10519
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.17beta [testing] is released!

Mon Nov 04, 2024 5:21 pm

This kind if "invalid" packets is caused by the connection tracking entry in the router already removed, and the system (or the remote) still sending related traffic. It can even cause leaking of internal addresses because in that case the corresponding NAT action isn't performed either.
It is a known problem. The solution is either:
- do not log actions of the "match invalid" firewall line
- drop packets with state invalid, protocol tcp, flag ACK, without logging, or reject them with "TCP Reset", then drop remaining invalid packets with log.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7174
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: v7.17beta [testing] is released!

Mon Nov 04, 2024 5:36 pm

And additionally what pe1chl mentioned it is strange that you see this only after upgrade, such behaviour existed for years.
 
Sheriff1972
newbie
Posts: 29
Joined: Fri Feb 16, 2018 7:48 pm

Re: v7.17beta [testing] is released!

Mon Nov 04, 2024 7:23 pm

[/quote]

I had same problems as you, disabling WPA3 solved the problem. WiFi is now really rock solid. I hope Mikrotik solve this in the future.
[/quote]

Disabling WPA3 also improved my AX experience hugely! (HAP AX3)
 
User avatar
Brain2000
newbie
Posts: 27
Joined: Thu Sep 26, 2024 6:20 am

Re: v7.17beta [testing] is released!

Tue Nov 05, 2024 3:10 am

3) From the GUI, if you go into a wifi interface that is set up as PSK, and simply click "Apply", the passphrase will be corrupted and you'll have to go back and retype it.
Under the hood it sets the passphrase to \E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2\E2\80\A2 no matter what it was prior.
This issue has an easy workaround, don't save anything from the GUI.
Maye be a Winbox 4 bug and not related to this specific ROS version. But as I always said for years: I don't trust Winbox.
This was the www interface.
 
ds37577
just joined
Posts: 10
Joined: Tue Nov 05, 2024 2:16 am

Re: v7.17beta [testing] is released!

Wed Nov 06, 2024 12:17 am

Just FYI, I upgraded from 7.16 to 17.17beta4 on my LtAP with Quectel EC25-AF modem. It boots up, activates the LTE interface and then crashes. Since that happens at boot, it was just crashlooping before I could really get in an do anything. Reset to defaults, which let me in and wouldn't crashloop because LTE didn't come up. Re-configured LTE and ... crashloop again. Had to roll back to 7.16.

I only have one of these else I'd try to gather more info, but just FYI in case it helps anyone.
 
rm78
just joined
Posts: 9
Joined: Sun Feb 25, 2024 11:04 am

Re: v7.17beta [testing] is released!

Wed Nov 06, 2024 8:23 pm

I had same problems as you, disabling WPA3 solved the problem. WiFi is now really rock solid. I hope Mikrotik solve this in the future.
[/quote]

Disabling WPA3 also improved my AX experience hugely! (HAP AX3)
[/quote]

Same experience here. Just about all of the WiFi issues I had disappeared after I disabled WPA3. Mikrotik should really step up their WiFi game.
 
PhilB
just joined
Posts: 19
Joined: Tue Jun 05, 2012 10:00 pm

Re: v7.17beta [testing] is released!

Wed Nov 06, 2024 10:15 pm

(NB: Quotes below are paraphrasing, not literal quotes, obviously)

Sorry, but people upgrading on a unit with a factory version <7.17 (or whatever build this feature eventually ships in) need to /at least/ have an opt-out from mandatory device-mode (I would sooner device-mode was opt-in for these devices).

You have made an ideological decision about hardening the O/S to prevent abuses in a way that you admit you have no evidence for, and just expect your customers to eat a truck roll to every remote device to re-enable btest.

Make this feature apply to devices with factory >7.17, fine, make that improvement, as you see it, to improve the security posture going forward. Over time, all devices still in active use will have the feature.

We're going to need the ability to manage this using netinstall, by the way, before this becomes a stable feature. Surely you understand this. There is no reason to rush this out before the tooling is available to properly manage it, when you have no evidence that this is a extant, much less significant threat.

"end user devices do not need btest!"

in your opinion and even if that was universally true*, end user devices in their house/office actually are not the problem. We can ask those end users to push buttons, if we really needed to, even though you are now mandating a full outage just to enable diagnostics in a situation where maybe only a (perceived) service impairment exists.
"What if hackers (that we have no evidence actually exist) exploit any bypass to enable nefarious features before you upgrade to 7.17? what then?!!??!"
ok, well, you have already said that all 'already enabled features' will be preserved on upgrade. So you have already built a bypass for /most/ of these dangerous features that these theoretical** hackers could exploit, they just have to turn on these desired nefarious features before carrying out the upgrade. Just not one that allows us to preserve btest client on devices already in the field, something we want available on every device we have deployed (in our case, mostly RB4011, RB5009, CCR*).


Zooming out:

The problem is not *only* the inconvenience of having to make end users push buttons and reboot their routers just to enable btest to/from their device, but also the many tens of thousands of mikrotik devices that are deployed without someone nearby to push buttons, that are not just sat on a cupboard in a home. It is not clear to me why you seem to think you only sell direct to consumers. You are disabling btest *and* btest-server on every single device. Even if we accept the premise that this is to save consumers from themselves, how many consumers who need "protecting" have a CCR2004+ in their home?

Don't make your service provider customers - the people who I wager are responsible for actually driving a sizeable chunk of mikrotik devices into the homes and offices of end users, rather than consumers selecting these routers for themselves - eat thousands of man hours collectively on fixing existing deployed devices to make them behave as they did when they were deployed.

Deliberately and materially changing the way an existing device works in any way that requires physical intervention is just a cardinal sin for a network vendor, IMO. If a service provider has to send a team out to push buttons, they might choose to just change the device entirely to another vendor whilst they're there.

Please, seriously, reconsider this implementation to instead make it opt-in for devices with older factory releases, and also please stick a pin in it entirely until it can be fully customised with netinstall. There is - by your own admission - no need to rush this.

* (it is not, at all - we and I am sure the vast majority of service providers use btest routinely during diagnosis, as every mikrotik we supply to an end customer is /managed/.)
** (remember how quick you were to scold your customers and their "theoretical" situations they have illustrated where device-mode harms them. You are taking a decision to implement something that you think will improve against theoretical attacks, and implementing it in a way that will cause actual harm to your paying customers.)
 
PhilB
just joined
Posts: 19
Joined: Tue Jun 05, 2012 10:00 pm

Re: v7.17beta [testing] is released!

Wed Nov 06, 2024 11:21 pm

Also, if the btest function can be used to just packet random IPs (why else would it need restricting?) instead of just talking to btest servers, maybe /that/ is actually what needs fixing?
 
guipoletto
Member Candidate
Member Candidate
Posts: 201
Joined: Mon Sep 19, 2011 5:31 am

Re: v7.17beta [testing] is released!

Thu Nov 07, 2024 5:57 am

Also, if the btest function can be used to just packet random IPs (why else would it need restricting?) instead of just talking to btest servers, maybe /that/ is actually what needs fixing?
Btest-Server being off by default (service, on port2000) is good practice, and long overdue

Btest-Client got swept in this overzealous purge, but it's not really the focus .
Btest-Client will only start sending packets after handshaking/authenticating with the remote device.
it's pretty gentlemanly as far as load testing tools go

Traffic-Generator, in the other hand, is a RAW packet synthesizer
it will spew whatever you tell it to, towards any programmed destination, indiscriminately, at wire-speed

The uses for this one are a lot more niche, like RFC testing a dedicated circuit
for 99% of the cases, and 99.95% of the population, "Btest" is what they think/want as a "speed-testing" tool

they former should be left alone
the latter, can justifiably be locked behind some scary warnings, and button-press gymnastics
 
lubomirs
just joined
Posts: 5
Joined: Tue Feb 05, 2019 4:07 pm

Re: v7.17beta [testing] is released!

Thu Nov 07, 2024 10:46 am

I had same problems as you, disabling WPA3 solved the problem. WiFi is now really rock solid. I hope Mikrotik solve this in the future.
Disabling WPA3 also improved my AX experience hugely! (HAP AX3)
[/quote]
Same experience here. Just about all of the WiFi issues I had disappeared after I disabled WPA3. Mikrotik should really step up their WiFi game.
[/quote]

I updated my hw to use wpa3 and now should I disable it?
Probably a mistake that I updated again to hw mikrotik. . . .
 
User avatar
woland
Member
Member
Posts: 310
Joined: Mon Aug 16, 2021 4:49 pm

Re: v7.17beta [testing] is released!

Thu Nov 07, 2024 12:07 pm

I updated my hw to use wpa3 and now should I disable it?
Probably a mistake that I updated again to hw mikrotik. . . .
You are not alone:
viewtopic.php?t=198736

Quite annoying: there was no improvement up to 7.17Beta4 or any meaningful reaction from MT....
 
erlinden
Forum Guru
Forum Guru
Posts: 2584
Joined: Wed Jun 12, 2013 1:59 pm
Location: Netherlands

Re: v7.17beta [testing] is released!

Thu Nov 07, 2024 12:22 pm

Besides lots of improvements (though not working for you), MikroTik is constantly requensting their users to provide information. So I don't agree with you, @woland.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10519
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.17beta [testing] is released!

Thu Nov 07, 2024 12:23 pm

Incompatibilities between WiFi access points and clients are something that every manufacturer is fighting with...
The users ask for new features, better performance, more security, etc etc but expect that all their equipment, no matter if it is a brand new smartphone or a simple IoT device with an ESP8266 WiFi chip, to work at high speed, roam perfectly, prefer 5 or 6 GHz, etc.
It sometimes looks like a whack-a-mole game where each change improves something that was requested or reported, but breaks the connection to some different class of device.
I do not envy the developers that have to create updates and can maybe test them with 10 or 20 test devices that they have in their office, then get a load of complaints when they release it...
 
jszakmeister
just joined
Posts: 1
Joined: Tue May 14, 2024 2:11 pm

Re: v7.17beta [testing] is released!

Thu Nov 07, 2024 1:52 pm

This morning with 7.17beta4, I went to look at IP -> Firewall -> Connections in the advanced web interface and noticed that sorting is not functioning on the table. All the entries remain in the same order, despite clicking on different column headings, trying to reverse it, etc. I also always struggle with interfaces like this because it's not generally one thing I want to sort on, but several. Like Protocol, src address, and then dst address. You can't go that by selecting a single column. That's probably an issue for a different day though. :-)
 
pe1chl
Forum Guru
Forum Guru
Posts: 10519
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.17beta [testing] is released!

Thu Nov 07, 2024 1:56 pm

When you have advanced requirements you may want to consider winbox v3.
 
ormandj
just joined
Posts: 18
Joined: Tue Jun 15, 2021 12:25 am

Re: v7.17beta [testing] is released!

Thu Nov 07, 2024 2:16 pm

Incompatibilities between WiFi access points and clients are something that every manufacturer is fighting with...
The users ask for new features, better performance, more security, etc etc but expect that all their equipment, no matter if it is a brand new smartphone or a simple IoT device with an ESP8266 WiFi chip, to work at high speed, roam perfectly, prefer 5 or 6 GHz, etc.
It sometimes looks like a whack-a-mole game where each change improves something that was requested or reported, but breaks the connection to some different class of device.
I do not envy the developers that have to create updates and can maybe test them with 10 or 20 test devices that they have in their office, then get a load of complaints when they release it...
It is no doubt a difficult problem, but there is a serious issue with MT wireless when a $100 router/AP combo from any store can outperform their enterprise wireless solution in compatibility with clients, range, and throughout.

I’ve had to go back to multiple installations with cAP AXs or even family and friends I installed hAP AX2/3s for, and switch them to other vendors due to all the issues they had with the MT solutions, even after disabling WPA3, intentional channel selection based on RF analysis, etc. Same channels and generic configuration works without issue on the consumer brands.

On topic this beta is proving to be more of the same for me. I was really hoping improvements to wireless would continue with the newer driver in the previous release but it does not seem so. I’m not even sure what to report to MT since it affects so many different clients it seems like testing with anything would make it apparent. Switching to Ruckus APs with the same MT routing/switching gear makes all the problems go away. What’s wild is the same is true with trying ASUS and other cheap consumer options, as well. Certainly intel card bearing laptops are an common issue with the MT wireless products, but not with other brand wireless solutions.
 
PhilB
just joined
Posts: 19
Joined: Tue Jun 05, 2012 10:00 pm

Re: v7.17beta [testing] is released!

Thu Nov 07, 2024 2:39 pm

Btest-Server being off by default (service, on port2000) is good practice, and long overdue
Pretty sure the BTest Server isn't enabled by default in the stock mikrotik configuration. I don't know that it ever has been?
Traffic-Generator, in the other hand, is a RAW packet synthesizer
it will spew whatever you tell it to, towards any programmed destination, indiscriminately, at wire-speed
Yeah I don't think that a fraction as many providers are going to miss traffic generator, however I'd still argue that these restrictions should be opt-in for existing devices in the field.

"we don't think people need this" is not a good reason to subject customers with many remote devices into a load of busy-work because of Mikrotik's ideological position on this.

I just don't understand why the btest functions have been classified as the same as traffic generator (maybe they use some traffic generator function on the back end? still, these specific functions should be treated differently)
 
itimo01
newbie
Posts: 25
Joined: Thu Jun 29, 2023 2:55 am
Location: Germany
Contact:

Re: v7.17beta [testing] is released!

Thu Nov 07, 2024 2:40 pm

 
ToTheFull
Member
Member
Posts: 402
Joined: Fri Mar 24, 2023 3:24 pm

Re: v7.17beta [testing] is released!

Thu Nov 07, 2024 2:44 pm

I'm getting this on more and more devices any thoughts please.
possible SYN flooding on tcp port 53
Seems to be from my lan to dns for some reason.
 
User avatar
woland
Member
Member
Posts: 310
Joined: Mon Aug 16, 2021 4:49 pm

Re: v7.17beta [testing] is released!

Thu Nov 07, 2024 2:51 pm

@erlinden:
Besides lots of improvements (though not working for you), MikroTik is constantly requesting their users to provide information.
Yes, that´s true we have seen lot´s of improvements, except WPA3 is still unusable with many very common chipsets. There is a list we have created in the thread from my previous post and many users created tickets about this issue.
I haven´t seen anything reassuring regarding WPA3 issues.
WPA3 is there since 2018! There are similarly priced solutions from other vendors which work flawlessly with WPA3 & AX or even BE.

@pe1ch & @itimo01l: I agree: it must be a difficult thing to be compatible with every vendor, but others have managed to get WPA3 running many years ago and if they break it (which happens more often than we would like it), they consider it a priority to make it work again.

Meanwhile MT had a working implementation, has broken it and than just lets it be since 7.14.3.
This is not how MT will win over customers.
 
PhilB
just joined
Posts: 19
Joined: Tue Jun 05, 2012 10:00 pm

Re: v7.17beta [testing] is released!

Thu Nov 07, 2024 5:44 pm

Presumably this is part of what is driving the ideological position of device-mode:
https://blog.ovhcloud.com/the-rise-of-p ... turn-evil/

But this has to surely be caused by traffic generator, not btest/speedtest functionality itself, correct?

Given the distribution of versions mentioned in the article (and only really v6 seems to be mentioned in the article at all), these devices probably will never be upgraded to run 7.17+, so hammering the customers who DO upgrade with controls designed to cure problems caused by fools who do not know what they are doing (and do not notice their router emanating $x Mpps of garbage) does not seem to be much of a solution, so in practice, OVH (and other victims) are unfortunately going to have to rely on the host ASes dealing with their problem devices/downstream customers.
 
holvoetn
Forum Guru
Forum Guru
Posts: 6618
Joined: Tue Apr 13, 2021 2:14 am
Location: Belgium

Re: v7.17beta [testing] is released!

Fri Nov 08, 2024 3:04 pm

Just unpacked a new wAP AX.
First thing I did (after setting new user and passwd) was upgrade to testing 7.17b4 (it's a home device for experimenting first).
Then I wanted to upgrade routerboard settings to auto-upgrade and I can not. Blocked by device settings.

I know how to solve this but this means you ALWAYS have to have someone knowledgeable around before you can change some things if such devices are sent remotely.

And now the joke:
according to help pages routerboard settings should be DISABLED by default when selecting mode=advanced.
Not so.
After power off/on I can change routerboard settings without any further interaction.

This is plain crazy ...
 
User avatar
Paternot
Forum Guru
Forum Guru
Posts: 1047
Joined: Thu Jun 02, 2016 4:01 am
Location: Niterói / Brazil

Re: v7.17beta [testing] is released!

Fri Nov 08, 2024 4:57 pm

Just unpacked a new wAP AX.
according to help pages routerboard settings should be DISABLED by default when selecting mode=advanced.
Not so.
This is plain crazy ...
But this is for the stable releases only (as of writing 7.16.1), no? The behavior changes exactly with the 7.17 series - currently in beta. Don't get me wrong: I think Mikrotik is shooting itself on both feet, with this planned change of units already on the field.

I have no problems with this being the default 7.17 and beyond - so long as old behavior it's not changed when upgrading from lower versions. At least there must be a way for us to make this transition on the field units that doesn't need physical access.

Who is online

Users browsing this forum: No registered users and 9 guests