*) zerotier - upgraded to version 1.14.0;

Thanks for ZT update, have a good weekend all.

+1

There are also newer options in ZeroTier too that are not exposed... yet? i.e. be nice to control multipath and enable low-bandwidth mode

Has anyone checked if private moons support is really working?

need moons ,too

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

Will it be supported in future releases?

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.

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

Why two ssids ? Just put guest on separate VLAN, assign them password and that's it.

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).

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

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.

fischerdouglas compilation

Code: Select all

Lets talk about Hardware Offload?

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

fischerdouglas compilation

Code: Select all

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 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 🤷‍♂️ )

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.

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 )

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 🤷‍♂️ )

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.

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.

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.

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.

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.

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?

/system/resource/usb

0 1-0     Linux 5.6.3-64 uhci_hcd  UHCI Host Controller     12

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

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.

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;

: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 ...

fischerdouglas compilation

Code: Select all

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.

fischerdouglas compilation

Code: Select all

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.

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.

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.

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.

What is your proposal, to verify ownership of a device in a way, that a remote attacker can't do?

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?

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]

What will you be using traffic gen for, in this remote router? There is no need for theoretic, like I said

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!

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

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.

• 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.

• 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

• 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

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.

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.

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.

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??

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.

Creating support ticket is the most effective tool we have.

What is your proposal, to verify ownership of a device in a way, that a remote attacker can't do?

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.

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.

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.

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.

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.

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...

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

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?

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.

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.

*) switch - fixed L2MTU for 25Gbps ports;

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

This will simplify VLAN tables!thank you mikrotik.

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.

so we're far from a "real" DNS server. And, I'm sure others have their own DNS grips.

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.

container and run whatever you like.

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.

unbound is a recursive resolver. not an authorative dns. It has some limited features in that regard.

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...

container and run whatever you like.

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

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!

container and run whatever you like.

!) 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;

*) wifi - added extra info to CAPsMAN about message;

*) wifi - improved FT roaming with WPA3 for some Apple devices;

Code: Select all

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

*) 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);

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

So that means /partitions/activate (changing active partition) will after all remain available, and only /partitions/repartition will become locked?
That is good news!

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;

Makes sense. Bandwidth test tools create a bunch of traffic as well.

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?

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).

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!

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

*) log - added hostname support to remote logging action;

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

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?

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...

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.

Can you please share:

Code: Select all

/interface/wifi/export

Remove any private info.

Update: it works on my machine. Could it be a typo?

/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

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.

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);

*) 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);

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.

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

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.