v7.17beta [testing] is released!

erlinden · Fri Nov 08, 2024 5:03 pm

Both my wAP AX's where supplied with 7.15.x.

Fri Nov 08, 2024 6:27 pm

Both my wAP AX's where supplied with 7.15.x.

Previous poster omitted the fact I did an upgrade in between unpacking and noticing this "challenge"

erlinden · Fri Nov 08, 2024 6:51 pm

Wasn't this introduced in the 7.17 beta release? Only available through the beta channel, which has to be selected manually? But I might not understand you correctly...

Fri Nov 08, 2024 7:17 pm

Hence why I post here.
Device mode advanced should still result in routerboard settings to be disabled at first.
It wasn't.

merkkg · Fri Nov 08, 2024 7:21 pm

I believe he just upgraded to latest beta without checking what the impact would be and only learned of this change after.

This particular case is a user problem not system problem.

pe1chl · Fri Nov 08, 2024 7:23 pm

I think the intention was that with the new devicemode settings it would no longer be possible to change the "Boot device", not that an upgrade of the firmware would be blocked. Maybe auto-upgrade setting would need to be blocked, I'm not certain of that. But it isn't a good idea anymore to enable that, now firmware version is updated for every RouterOS release, even when there are no changes.
I have disabled "Auto upgrade" everywhere.

Fri Nov 08, 2024 7:57 pm

I believe he just upgraded to latest beta without checking what the impact would be and only learned of this change after.

This particular case is a user problem not system problem.

I know quite well what I'm doing and why I'm doing it.
Starting from ROS7 I think I haven't missed testing a single beta nor rc version.

Amm0 · Fri Nov 08, 2024 8:55 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/

And that part of the problem, we don't know what's driving the device-mode changes (i.e. the threat profile). Beyond platitudes like blocking "dangerous features". Some rational explanation of the concerns be good. The physical presence test changes the flexibility of your routers, and their value.

AFAIK device-mode is there "if a device is compromised"... someone cannot do X... But if this is just a response to OVH concerns... it was the lack of default firewall (i.e. HTTP open on any network added), so it's "dumb admins" with powerful routers that seem to more of OVH concerns.

While someone else DoH, especially at scale, is a really problem. It's the "if a device compromised" part where my concerns differ from Mikrotik+device-mode — since any RouterOS feature could be used to either sniff/redirect traffic or create a DoS on LAN side. So the notion of "dangerous features" depends on one's perspective.

Basically some blog post on the "WHY" of device-mode be good. This is why y'all create the security blog, to better communicate security issues... These change will have a measurable economic effect ("truck rolls"/TCO/etc) on some of your customers, so if there going to be a continued paternalistic enforcement of best practices (i.e. more device-mode changes in future version, etc.) just be honest and clear. Or, better, wait until you have a better ACL-based policy model so these deployment changes can be minimized - assuming the 7.17 changes are mere prophylactics, which is also an open question here.

1day · Sat Nov 09, 2024 1:16 am

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.

You misunderstand.
I already explained that the unit works fine on 7.16, installing 7.17 beta starts throwing errors immediately. That link is running at a crawl. It should be a 150Mbit symmetric optical link and I can't get more than 5MBit out of it as connections drop out as fast as they are created, clients are retrying continuously.
Btw reading some other errors I found at least one if not two which could be explained with the same issue.
Understand this:
The rules that logs those lines are not the lines that drop unwanted packets, they are lines that capture packets that were not processed that should have been. That means there are errors. as they show packets that should NOT have been dropped, and that should have been (in this case) forwarded. Packets that SHOULD be dropped are not normally logged and are dropped elsewhere.

In the log you can see a number of TCP 'connection' but these 'connections' do not and *CAN NOT* exist.

In one case, I can easily tell this, because the server sending them is sending only UDP, and *not* TCP!!
That port is not even open on TCP on the server that data was being sent by.
Why would it log a invalid state of a TCP session when no such thing exists, yet similar UDP ones do?

The only conclusion I can make is either a bug in connection tracking, some sort of accidental connection ID swapping perhaps - fences and posts or bit shift errors perhaps? The only other explanations could be there is some packet mutation going on as the packets or frames move across the router. But that's unlikely as UDP and TCP are not similar enough to be confused should a few bits change, and though CRCs are not great hashes, most would still fail and would expect to see lots of corrupt packet errors. Lastly there may be memory corruption caused by corrupt pointers or memory write overflows. No idea as I've never looked at your code.
(BTW As an example, I've got a cheap Chinese switch that does just that, send it pings and it sends back ping data plus some more data it sent some time back. That upsets the sender a bit)

Now this issue is not just affecting the apparently 'existing, yet non-existing' connections but also other real connections are being dropped too, but those are being dropped silently and are not getting to the packet trap. They never get logged even if I turn on the logging of dropped packets or at least I have not managed to catch one yet. (It is tricky logging dropped packets as I get about 100 to 1000 hacking attempts a minute, the logs fly up the screen). It's rather tricky to separate out deliberate and non-deliberate in the logs, but you can suggest some mechanism if you wish. I've never been able to come up with log filters that are granular without some odd side effect.

Let me state again, something is wrong with connection tracking. I have no idea if it's hardware, an attribute of my config, an issue with config when linked with changes in the release or an actual firmware bug and I have no idea how to narrow it down any further. The contrack table changes far too fast to read or make sense of it. There are thousands of entries. I can say the lines that log misrouted packets until now almost never log anything unless I screw up the firewall config. Which is why I added them; To catch mistakes caused by edits to the firewall tables. Do you not have something similar on your test network?

This is not the first time I've tried to help out here by providing feedback and every time I get the same unhelpful response. I'm no noob and I've been using your kit for a very long time. I was a network tech in a previous life, but these days I am a staff engineer at a large global corporation and work in electronics and software, designing specialist high end test kit. My credentials have merit. It must be 20 years or at least 15 and I've been an advocate on your behalf at any opportunity. My endorsement and practical demos have been responsible for significant adoption on at least two occasions including, including military and airport customers. My own networks have used your kit since the early 2000's (I think it was 2004). I started using it for a community broadband project. You made flat panel antennas that I was attaching to modded wireless cards.
In addition your kit always goes into to my own LAN and my lab at work. But, sadly over the last couple years I have really started losing faith in the kit and the company. I got a similar response on another hardware issue that any other company would have taken seriously. Once again I am wondering why I even bother reporting things here as the response is always a brush off "customer at fault", ... then the bug gets fixed in some later release.

Right now I am in the process of reverting to the release and I will simply wait a few months until others report the same issue and it gets fixed quietly fixed.

I am not saying it is definitely a bug, maybe there is a latent error in my setup that is exposed by some code change or side effect of any automated config changes during the update. That is not the problem, it's still a bug if you were serious about product quality. Log it, track it, collect the evidence, and fix it or change the docs. I don't mind if it does not work, it's beta, warts and all I did not expect it to work, but hoped it may be less broken than it's predecessor. I make mistakes and I am happy to admit when I am wrong if it is a config error then fine. I will review the docs and see how I made a mistake.
But consider this. When you make the release what if you find others with the same or similar setup and they start seeing the same issue. What if they are new customers. The whole point of a beta is that you have friendly customers who you can trust to know what they are doing and will give up their time to help you test and fix error before other customers get visibility of them. Losing one new customer loses at least one more. With social media that can be a lot more. Whereas you have to try really, really hard to lose a beta tester but it seems you on that front you are doing quite well.
This has happened multiple times in the last 12 months, I was affected by the ARP issue, DNS issues, the IP multicast issue and issues with VLANs on bridges. I know complex software is never finished. And that cheap kit is cheap because it is tested less, or has less engineers developing it. So if it's rough at the edges, so long as it's secure and works I am fine with it. But I don't expect to feel I am wasting my time and that Mikrotik are unable to take their users seriously or respect the abilities of others without first at least asking a few questions and at least pretending to give a flying .... I will not be recommending Mikrotik any longer.

pe1chl · Sat Nov 09, 2024 11:03 am

Well, one thing is obvious: the issue you describe affects only you. Or else we would have seen many reports.
I can only suggest that you /export your configuration ("/export show-sensitive file=anyname") and netinstall the router without default config and import that export connected via MAC address (you may need to do some minor edits).
That excludes any discrepancy between what you see in the config and what actually happens in the router.

Nullcaller · Mon Nov 11, 2024 6:45 am

Presumably this is part of what is driving the ideological position of device-mode:
https://blog.ovhcloud.com/the-rise-of-p ... turn-evil/

Ah, this is why we can't have nice things. But I think, this is not entirely MikroTik's fault. Actually, not even mainly MikroTik's fault. Yes, it's their faulty code which is to blame. But it has been amended since.

What honestly should happen for this to be fixed, is there should be some sort of regulatory agencies analyzing the networking traffic and punishing those who mismanage their network devices into exposing their web management interface into the Internet.

We do this stuff for radio. Broadcast on some random frequency you don't have the license for, and people in black suits will turn up in a non-discrete van in your general vicinity, ready to have a very unpleasant conversation with you. Why can't we do it for DDoS attacks?

rm78 · Mon Nov 11, 2024 9:09 pm

Mikrotik should never have exposed the web interface to a WAN port. It should have been disabled by default.
A good improvement would be to have a choice when installing to select a set of firewall rules which resembles that of regular consumer devices.
More advanced users can always make the choice to open up things.

infabo · Mon Nov 11, 2024 9:15 pm

Default configuration does not allow accessing webfig from WAN.

Paternot · Mon Nov 11, 2024 10:54 pm

Default configuration does not allow accessing webfig from WAN.

Up to a point. The botnet on that article was composed by high end routers (CCR1036, CCR1072, CCR2004, CCR2116). Those have no firewall or protections whatsoever - since they are professional models.

rm78 · Mon Nov 11, 2024 10:58 pm

Default configuration does not allow accessing webfig from WAN.

It did with my rb5009 with the default configuration.

Paternot · Mon Nov 11, 2024 11:44 pm

It did with my rb5009 with the default configuration.

The RB5009s are already on the "prosumer" series. They come clean, without firewall or rules. Smaller devices (like hEX), come precofigured with firewall.

Amm0 · Tue Nov 12, 2024 12:17 am

Default configuration does not allow accessing webfig from WAN.
Up to a point. The botnet on that article was composed by high end routers (CCR1036, CCR1072, CCR2004, CCR2116). Those have no firewall or protections whatsoever - since they are professional models.

Yeah, that's makes the focus on device-mode so ridiculous - when devices use insecure protocols by default. There are home users that use "professional" routers, and professionals that use "home" routers.... The idea that security model depends on some marketing definitions of expected use cases is flawed.

infabo · Tue Nov 12, 2024 1:09 am

rm78 talks about "regular consumer devices". These kind of devices by Mikrotik have a default configuration (which can be reverted though). That is what I was referring to.

mantouboji · Tue Nov 12, 2024 8:58 am

As a new web view , the wireguard peer QRcode is still like this:

截图 2024-11-12 14-56-01.png

pe1chl · Tue Nov 12, 2024 10:54 am

Up to a point. The botnet on that article was composed by high end routers (CCR1036, CCR1072, CCR2004, CCR2116). Those have no firewall or protections whatsoever - since they are professional models.
Yeah, that's makes the focus on device-mode so ridiculous - when devices use insecure protocols by default. There are home users that use "professional" routers, and professionals that use "home" routers.... The idea that security model depends on some marketing definitions of expected use cases is flawed.

MikroTik should probably revise the policy on having default configuration?
While it can be understood that a CCR does not have a "forward" firewall (and "NAT"), for sure it should always have an "input" firewall.
So it does not hurt to have an example of that in the default config.

mkx · Tue Nov 12, 2024 12:28 pm

MikroTik should probably revise the policy on having default configuration?
While it can be understood that a CCR does not have a "forward" firewall (and "NAT"), for sure it should always have an "input" firewall.
So it does not hurt to have an example of that in the default config.

IMO *every* MT device should come with some sane default config (similar or same as it's currently shipped on SoHo devices) which has firewall enabled (active).
If "pro" device is then handled by a professional, then he (or she) should be capable of ditching entire configuration if that's necessary. Having a sane default config might even help some "professionals" to eventually have a good firewall (in some cases even "pros" end up with silly firewall config).

bratislav · Tue Nov 12, 2024 1:57 pm

As a new web view , the wireguard peer QRcode is still like this:
截图 2024-11-12 14-56-01.png

That is most likely a font (or encoding) issue... you may try and copy the text (QR code is actually a text) and paste it into Notepad and set the font to Consolas, regular and script to western...

wireguard.png

Jotne · Tue Nov 12, 2024 2:52 pm

Would it not be better to present the QR code as an image? Then font does not matter.

Paternot · Tue Nov 12, 2024 3:03 pm

Maybe it's a size and processing power thing? After all, it's the router that creates and stores this.

bratislav · Tue Nov 12, 2024 3:08 pm

Would it not be better to present the QR code as an image? Then font does not matter.

Not if you also want to display QR code in a terminal :)


    █▀▀▀▀▀█ ▄ █ █ █▀▀▀▀▀█
    █ ███ █ ▀ ▀▀▄ █ ███ █
    █ ▀▀▀ █ ███▀▀ █ ▀▀▀ █
    ▀▀▀▀▀▀▀ █ ▀ ▀ ▀▀▀▀▀▀▀
    ▀▀ █▄▄▀▀  ██▀ ███ ▀█▄
    █▄▄▀▄█▀  ▄ ▀▄ ▄▀▄█▀▄█
         ▀▀▀▄▄ █ ▀ ▀▀ ▄
    █▀▀▀▀▀█ ▀ ███ ▀█▀▀▀█
    █ ███ █ ▄▀█  ▀ ▄▄▄▄▄▄
    █ ▀▀▀ █ ▄█▀▄▀▄▀ ▀ ▀ ▀
    ▀▀▀▀▀▀▀ ▀   ▀ ▀▀ ▀ ▀

Although qrencode which I ssupect MikroTik uses also supports PNG,PNG32,EPS,SVG...

Acerorosso · Tue Nov 12, 2024 3:40 pm

Hi all, seems to me that a strange behaviour appeared on PPPoE Client on VLAN in 7.17beta4.

I have two CHR routers on X86 architecture connected via PPPoE Client on two different ISPs. Randomly, after upgrade to 7.17beta4, the PPPoE client disconnect after pressing "apply" to the PPPoE Interface even not changing anything (probably just because router restarts the connection).
After connecting phase the error is "Was unable to authenticate ourselves to the server". No reboot or other disable/able on the interface does nothing.
The previous version of the OS was stable from a couple of years in one case and 6 months on the other one with no issues at all, same lines, same accounts, same ISPs.
This behaviour goes on till when I update the password field and, sometimes, the connection goes up and then stays up till next renegotiation.

I'm quite sure this is a issue of 7.17beta4 because another RB5009 with 7.16.1 on same ISP connection goes up immediatly, same line, same credentials, same all....except for the RouterOS version...

Anybody had same issues ?
thanks,
Marco

kowal · Tue Nov 12, 2024 6:34 pm

I've one hap ac3 running v7.17beta4 with PPPoE client and I can't reproduce this ( anyway - what is the case for clicking "apply" without changing anything?)
It also may be architecture related problem but I don't have CHR or x86 running PPPoE client.

chojrak11 · Wed Nov 13, 2024 11:18 am

Hey Mikrotik, it's already been a month since beta4, and no new releases since, are you okay? :-)

ivicask · Wed Nov 13, 2024 11:40 am

Hey Mikrotik, it's already been a month since beta4, and no new releases since, are you okay? :-)

Well i hope they are fixing wireless problems, give them as much time needed..

satboxbg · Wed Nov 13, 2024 12:15 pm

I hope that MikroTik will also fix MLAG. In fact, all of us who have purchased the CRS520 and CRS510 are eagerly awaiting ROS 7.17 and stable MLAG.

ConiKost · Wed Nov 13, 2024 4:00 pm

Nice. Finally! MikroTik confirmed, that DHCPv6 stateful support (Clients can request IPv6 address with options like DHCP for IPv4) will be available in next beta.

nkourtzis · Wed Nov 13, 2024 4:07 pm

For the second time in a month the routing process of a CCR2004 running 7.17b4 gets into a deadlock. The strange thing is that rebooting, booting backup partition, resetting to defaults, netinstalling, notne of these helped. So maybe a hardware issue that is mishandled by the OS? I have raised a support request (SUP-168963) and I have just updated it with an rtrace. Mikrotik team, PLEASE treat this as urgent.

sirbryan · Wed Nov 13, 2024 4:30 pm

I hope that MikroTik will also fix MLAG. In fact, all of us who have purchased the CRS520 and CRS518 are eagerly awaiting ROS 7.17 and stable MLAG.

What about MLAG specifically doesn't work for you? I have it working with a 354 and 312 in "lab production" at my desk (runs my home and office) and in production two 317's in two different data center stacks. I think I remember only one time the 354 got into a funky state after I mistakenly enabled/disabled L3HW offload (which isn't supported and breaks things).

mantouboji · Wed Nov 13, 2024 6:02 pm

As a new web view , the wireguard peer QRcode is still like this:
截图 2024-11-12 14-56-01.png
That is most likely a font (or encoding) issue... you may try and copy the text (QR code is actually a text) and paste it into Notepad and set the font to Consolas, regular and script to western...
wireguard.png

Are you serious?

Yes, we do have 1000 methods to produce a normal QR code or other formats by use other tools , but, now we're talking about a basic function of RouterOS, isn't?

oreggin · Wed Nov 13, 2024 10:25 pm

Hey Mikrotik, it's already been a month since beta4, and no new releases since, are you okay? :-)

+1 :-)
zero reactions in ticketing also :(

cyrq · Wed Nov 13, 2024 10:40 pm

Considering the amount of flak they've gotten in this thread, I would be surprised to see any new public beta this year.

chojrak11 · Thu Nov 14, 2024 2:20 pm

Let's look at my mountaintop CCR2116 as an example. We can get there relatively easily from June to October.
Using a power adapter that was controlled by ping. If it for some reason lost ping to an IP (eks remote site) for some time, it would remove the power, wait a fixed time, and put the power back.

Yeah, that is called watchdog. A simple Google search gives the full portfolio of devices, e.g. https://www.netio-products.com/en/gloss ... p-watchdog

And stop spamming and annoying people about your psychic requests to change log format. I find the log to be perfectly fine. Never had issues working with them. It is possible to do wonders with Mikrotik logs if you use a tiny bit of brain power. For example it is easy to collect them to a central ELK log repository - https://archyslife.blogspot.com/2019/08 ... ch_16.html. Priority mapping would be a no-brainer if really required.

On the scale where 1 is the highest priority it should be assigned a priority 10 to the power of 100, which I think it is. We have really important issues to be solved.

Thu Nov 14, 2024 2:47 pm

What's new in 7.17beta5 (2024-Nov-13 12:51):

!) device-mode - after upgrade, mode "enterprise" is renamed to "advanced" and bandwidth-test, traffic-gen, partition (command "repartition"), routerboard and install-any-version features will be disabled;
!) webfig - redesigned HTML, styling and functionality (additional fixes);
*) bonding - hide mlag-id property on non-compatible devices;
*) bridge - added message for inactive port reason;
*) bridge - added priority setting to manually elect primary MLAG peer (CLI only);
*) bridge - fixed MVRP registrar and applicant port options;
*) bridge - prioritize MAC selection from Ethernet interfaces when using auto-mac feature;
*) bridge - re-synchronize MLAG system-id when bridge MAC changes;
*) bridge - update dynamic MSTI priority value when changing configuration;
*) certificate - do not download CRL if there is no enough free RAM;
*) certificate - do not show not relevant values for certificate template (CLI only);
*) certificate - removed unstructured address field support;
*) chr - added Chelsio VF driver for PCIID 5803;
*) console - added json.no-string-conversion to :serialize;
*) console - increased w60g scan-list size to 6;
*) console - show system-id in export for CHR;
*) container - fixed user and group ID range;
*) container - improved container shell;
*) defconf - do not add default password for CAP mode configuration on older Audience devices without a password;
*) detnet - remove dynamic DHCP client creation;
*) device-mode - added "allowed-versions" list which are allowed to be installed without "install-any-version" mode enabled;
*) device-mode - added routerboard, install-any-version and partitions features;
*) device-mode - limit device-mode update maximum allowed attempt count which can be reset only with reboot or button press;
*) device-mode - provide more precise device-mode update action printout;
*) dhcp-server - improved stability (introduced in v7.17beta4);
*) dhcp-server - use single RADIUS accounting session for IPv4 and IPv6 when dual stack is used (additional fixes);
*) dhcpv6-client - improved system stability when DHCPv6 client is enabled on non-existing interface;
*) dhcpv6-client - log message when response with invalid transaction-id received;
*) dhcpv6-server - added IPv6 address delegation support;
*) dhcpv6-server - improved system stability when removing actively used DHCPv6 server;
*) disk - add support for SWAP, currently allowed on any block device with "set x swap=yes" when container package is installed (CLI only);
*) disk - added "type=file" for file-based block devices, useful for using file as a swap, or when having file-based filesystem images (CLI only);
*) disk - added btrfs filesystems list (CLI only);
*) disk - auto mount iso and squashfs images;
*) disk - fixed managing and cleaning up mount points;
*) disk - fixed raid role auto selection for up to 64 drives;
*) disk - recognize virtual sd* interfaces;
*) disk - show usage as percentage (CLI only);
*) dns - added option to create named DNS servers that can be used as forward-to servers (additional fixes);
*) ethernet - improved linking after reboot for hAP ax lite devices ("/system routerboard upgrade" required);
*) ethernet - improved stability after reboot for Chateau PRO ax;
*) ethernet - improved system stability for CCR2004-1G-2XS-PCIe device;
*) firewall - added support for random external port allocation;
*) firewall - improved matching from deeply nested interface-lists;
*) ftp - added VRF support;
*) gps - LtAP mini, change default GPS antenna for new devices;
*) iot - added additional debug for LoRa logging;
*) iot - added support for USB Bluetooth dongles (LE 4.0+) which enables Bluetooth functionality;
*) iot - LoRa LNS improvement;
*) iot - modbus rework which improves Tx Rx switching behavior;
*) ipsec - ike2 improved process for policies;
*) lte - disabled ims service for Chateau 5G on operator "3 AT" network (PLMN ID 23205);
*) lte - drop operator selection support for R11e-4G modem as it is unreliable;
*) lte - fixed network registration for R11e-4G modem (introduced in v7.17beta2);
*) lte - fixed SMS sender parsing;
*) lte - improved R11eL-EC200A-EU modem firmware upgrade procedure;
*) lte - improvements to modem "firmware-upgrade" command (additional fixes);
*) lte - MBIM increased assignable APN profile count up to 8 then modem firmware allows it;
*) lte - modem firmware update (FOTA), added support to install provider specific version (additional fixes);
*) lte - set "sms-read=no" and "sms-protocol=auto" as default values;
*) modem - KNOT BG77 modem, improved handling of modem unexpected restarts;
*) netinstall - removed unused "Get key" button;
*) netwatch - fixed IP address variable for DNS probe;
*) ospf - improved stability on configuration update;
*) ovpn-client - added tls-crypt, tls-crypt-v2 support;
*) pimsm - improved system stability after interface disable;
*) poe-out - added low-voltage-too-low status;
*) poe-out - reset PoE-out configuration before reboot when using reset-configuration command;
*) poe-out - upgraded firmware for CRS354-48P-4S+2Q+ device (the update will cause brief power interruption to PoE-out interfaces);
*) port - more detailed print command output, include in "USED-BY" property channel number(s);
*) ppp - add routes in matching VRF;
*) ppp - added support for bridge-port-trusted configuration via ppp profile;
*) ppp - do not print local/remote pool related errors in log when configuration does not require pool usage;
*) ppp - fixed typos in log message;
*) ptp - added PTP support for CRS320-8P-8B-4S+ and CRS326-4C+20G+2Q+ devices;
*) ptp - fixed synchronization on QSFP28 interfaces;
*) romon - added dynamic switch rules on devices supporting it when enabling the service;
*) romon - added interface-list support;
*) route - fixed discourse attribute print;
*) route - fixed possible issue with inactive routes after reboot (introduced in v7.16);
*) routing-filter - fixed subtract and add for numerical values (+x, -x);
*) sfp - fixed 1Gbps supported rate for RB960 and RB962 devices;
*) sfp - improved SFP28, QSFP28 interface stability using DAC cable for CRS520 switch;
*) snmp - added wifi fields to MIKROTIK-MIB (additional fixes);
*) ssh - do not regenerate host key after update from RouterOS version older than 7.9;
*) ssh - fixed password authentication (introduced in v7.17beta2);
*) ssh - improved logging;
*) supout - added BGP advertisements section;
*) switch - fixed storm-rate accuracy on 98DX224S, 98DX226S, and 98DX3236 switch chips;
*) switch - improved system stability for RB5009 and CCR2004-16G-2S+ devices;
*) 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);
*) vpls - added support for bridge-pvid configuration;
*) webfig - allow download from file details;
*) webfig - reduce flickering when table is sorted by column with duplicate values (additional fixes);
*) wifi - add information to each interface, showing which CAPsMAN manages it or which CAP hosts it when applicable;
*) wifi - added station-roaming support (additional fixes);
*) wifi - fixed failure with "auto" peer update on the OWE interface;
*) wifi-qcom-ac - fix possible conflict between radio and USB initialization on hAP ac2;
*) wifi-qcom-ac - improved CPU load balancing and system stability;
*) winbox - added Enable/Disable buttons under "Tools/Graphing" menus;
*) winbox - allow to edit Ethernet MAC address;
*) winbox - refresh values under "Bridge/VLANs/MVRP Attributes" menu;
*) winbox - renamed wrong invalid interface flag to inactive;
*) x86 - Realtek r8169 updated driver;

infabo · Thu Nov 14, 2024 3:04 pm

Considering the amount of flak they've gotten in this thread, I would be surprised to see any new public beta this year.

Did not age well.

*) disk - add support for SWAP, currently allowed on any block device with "set x swap=yes" when container package is installed (CLI only);

😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍

cyrq · Thu Nov 14, 2024 3:13 pm

Considering the amount of flak they've gotten in this thread, I would be surprised to see any new public beta this year.
Did not age well.

It was a bait. You can thank me later 😉

satboxbg · Thu Nov 14, 2024 3:15 pm

I hope that MikroTik will also fix MLAG. In fact, all of us who have purchased the CRS520 and CRS518 are eagerly awaiting ROS 7.17 and stable MLAG.
What about MLAG specifically doesn't work for you? I have it working with a 354 and 312 in "lab production" at my desk (runs my home and office) and in production two 317's in two different data center stacks. I think I remember only one time the 354 got into a funky state after I mistakenly enabled/disabled L3HW offload (which isn't supported and breaks things).

I'm not sure if this topic is entirely relevant here, but I would like to clarify what I mean when I say I hope MLAG will be fixed.

4xCRS520-in-MLAG-to-MLAG.png

In the diagram, I’ve shown how the switches are connected, managed through a VLAN interface. SW2 and SW3 are configured in MLAG with each other, as are SW4 and SW5 (L3 hardware offloading is disabled). When any of the secondary peers restarts, everything is fine; there’s not even an interruption between SW1 and SW6, and all switch management addresses remain accessible. However, in more than 50% of cases, when one of the primary peers (SW2 or SW4) is restarted, L3 connectivity to the management VLAN of one of SW1, SW2, SW4, or SW6 is lost, requiring an additional reboot.

More on the topic is written here.

viewtopic.php?t=195955
viewtopic.php?t=191621
viewtopic.php?t=196776

The same topology, but built with CRS326-24S+ switches and ROS 7.6, works without these issues. This is why I want to point out that the CRS520-4XS-16XQ-RM cannot be downgraded to 7.6 because the minimum version for this switch is 7.15.1.

Thu Nov 14, 2024 3:23 pm

satboxbg
please make a separate topic. we only discuss changes between latest and previous beta in this topic.

satboxbg · Thu Nov 14, 2024 3:42 pm

satboxbg
please make a separate topic. we only discuss changes between latest and previous beta in this topic.

Thank you for the note, normis, and I apologize.

I'm glad to hear there’s an improvement in the bridge functionality in 7.17beta5, which I eagerly anticipate.

*) bonding - hide mlag-id property on non-compatible devices;
*) bridge - added message for inactive port reason;
*) bridge - added priority setting to manually elect primary MLAG peer (CLI only);
*) bridge - fixed MVRP registrar and applicant port options;
*) bridge - prioritize MAC selection from Ethernet interfaces when using auto-mac feature;
*) bridge - re-synchronize MLAG system-id when bridge MAC changes;
*) bridge - update dynamic MSTI priority value when changing configuration;

Congratulations on the hard work.

erlinden · Thu Nov 14, 2024 4:30 pm

Was able to upgrade through the App of both my RB4011 and cAP AX. The (two) wAP AX's do not upgrade (hangs on "Download in progress", nothing else happens). Nothing in the logging. Will try with Winbox tonight (currently off site). Anyone else having the same issue?

For who is interested, upgrading from cli does work:

/system package update check-for-updates
/system package update install

Thu Nov 14, 2024 4:49 pm

I just upgraded following devices without any hitch (home/lab setup):
RB5009
AX2
wAP AX
AX Lite
Hex Refresh

clambert · Thu Nov 14, 2024 5:04 pm

*) vpls - added support for bridge-pvid configuration;

Great news! Thanks Mikrotik Team!

Sit75 · Thu Nov 14, 2024 7:13 pm

For radio guys: I am from Czechia and enclosed link show exact allowed conditions for 5GHz frequency spectrum - https://ctu.gov.cz/sites/default/files/ ... 1enfin.pdf It is clearly visible, that you limited frequency and power more strict than allowed by our regulator office. For example, if I have hAP ac^2 with 2.5dBi (isotropic) antenna - we have allowed 1W e.i.r.p. (30 dBm) - but you allow set only 26 + 2.5 = 28.5 dBm (0,71W) and I can not set more. In addition we have more allowed spectrum than in ETSI EN 301 893.

That is the reason, I have requested for "superchannel" for wifi-qcomm-ac. But reply for my ticket was - sorry - superchannel is not supported in wifi-qualcomm-ac, only in wifi-qualcomm. Checkmate.

mkx · Thu Nov 14, 2024 7:22 pm

Hmmm ... what does /interface/wifi/radio/reg-info country=Czech show on your device? On my audience (running 7.15.3) it says

  ranges: 2402-2482/20
          5170-5250/23/indoor
          5250-5330/23/indoor/dfs
          5490-5710/30/dfs

Which more or less corresponds with limits from "your" document). BTW numbers in above table are EIRP, actual Tx power is reduced by antenna gain. BTW2 if chipset capability is lower, then that's limitation which can't be circumvented.

leonardogyn · Thu Nov 14, 2024 7:38 pm

*) ovpn-client - added tls-crypt, tls-crypt-v2 support;

.
This is huge ... THANKS Mikrotik Dev Team <3

ToTheFull · Thu Nov 14, 2024 7:47 pm

Thanks, testing quad9 now!

CTassisF · Thu Nov 14, 2024 8:12 pm

*) dhcpv6-server - added IPv6 address delegation support;

I'm trying this new address delegation support but no clients would get IPv6 from DHCPv6.

Here's my config:

[cesar@RB5009] > /ipv6/dhcp-server/export 
/ipv6 dhcp-server
add address-pool="" interface=bridge lease-time=1d name=dhcpv6 prefix-pool=pppoe

[cesar@RB5009] > /ipv6/nd/export            
/ipv6 nd
set [ find default=yes ] advertise-dns=no interface=bridge managed-address-configuration=yes

The IPv6 pool is a /64. IPv6 from RA works just fine, but DHCPv6 doesn't even with managed-address-configuration=yes.

Other RouterOS' in the same network with /ipv6/dhcp-client/add request=address are stuck in status=searching....

Am I missing something?

mkx · Thu Nov 14, 2024 8:22 pm

Just guessing: you have to set address-pool to some existing pool for DHCPv6 server to hand out addresses (seems like it uses prefix-pool only to hand out prefixes). And quite likely you have to provide a pool with same prefix length as is used on interface (and probably router's address on that interface should belong to same prefix as address-pool). Which means you can't simply set address-pool to pppoe, you probably have to create a pool with longer prefix (a part of large pool).

kcarhc · Thu Nov 14, 2024 9:16 pm

I think I have identified an issue causing DNS crashes in all versions of 7.16.x and 7.17betaX.

Simply enabling the following code reproduces the problem:

/ip dns static
add address-list=DNS_DMN-BYPASS disabled=yes forward-to=8.8.8.8 regexp="(\\.|^)[a-zA-Z0-9]+\\.[a-z][a-z]+\$" type=FWD
add address-list=DNS_DMN-BYPASS disabled=yes forward-to=8.8.8.8 regexp="(\\.|^)[a-zA-Z0-9][-a-zA-Z0-9]+\\.[a-z][a-z]+\$" type=FWD

After rebooting, you’ll notice that the dns dynamic-servers list is empty, indicating an abnormal DNS state.
However, once you disable these two lines and restart RouterOS, the dns dynamic-servers function returns to normal.

I have confirmed this issue in tests on 7.17beta5.

please check ticket SUP-167541

ToTheFull · Thu Nov 14, 2024 9:28 pm

Oh well I guess not!
DoH server response not OK: 502: no downstream server available

And now the good, for the first time EVER! an iphone went from my cAP ax upstairs to the gym in an out building roaming to my hAP ax2 2.4g.... came back in and re-connected back where it came from with no drama. I'll say again, this has never happened. 33:25 -70 to -78

BrateloSlava · Thu Nov 14, 2024 9:46 pm

Please, update the documentation on how to use the new options for device-mode.

Thu Nov 14, 2024 10:15 pm

You must use address-pool instead of prefix-pool and address pool specified prefix-length must be /128. Other than that you have gotten the idea correctly - IPv6/ND must be used to advertise managed-network for end devices.

*) dhcpv6-server - added IPv6 address delegation support;

I'm trying this new address delegation support but no clients would get IPv6 from DHCPv6.

Here's my config:
Code: Select all
[cesar@RB5009] > /ipv6/dhcp-server/export 
/ipv6 dhcp-server
add address-pool="" interface=bridge lease-time=1d name=dhcpv6 prefix-pool=pppoe

[cesar@RB5009] > /ipv6/nd/export            
/ipv6 nd
set [ find default=yes ] advertise-dns=no interface=bridge managed-address-configuration=yes
The IPv6 pool is a /64. IPv6 from RA works just fine, but DHCPv6 doesn't even with managed-address-configuration=yes.

Other RouterOS' in the same network with /ipv6/dhcp-client/add request=address are stuck in status=searching....

Am I missing something?

baragoon · Fri Nov 15, 2024 12:11 am

I see that logging of container actions was changed (but can't find anything related in the changelog), now every container start logged to the system log =\
I have a container which is started every 5 minutes by the scheduler, did the work and stops, now my log is spammed with this:

 2024-11-14 20:55:38 container,info,debug container cd2ee075-7e28-4973-ab16-05e6d32fb75f started
 2024-11-14 20:55:39 container,info,debug container cd2ee075-7e28-4973-ab16-05e6d32fb75f exited, status: 0
 2024-11-14 21:00:38 container,info,debug container cd2ee075-7e28-4973-ab16-05e6d32fb75f started
 2024-11-14 21:00:39 container,info,debug container cd2ee075-7e28-4973-ab16-05e6d32fb75f exited, status: 0
 2024-11-14 21:05:38 container,info,debug container cd2ee075-7e28-4973-ab16-05e6d32fb75f started
 2024-11-14 21:05:39 container,info,debug container cd2ee075-7e28-4973-ab16-05e6d32fb75f exited, status: 0
 2024-11-14 21:10:38 container,info,debug container cd2ee075-7e28-4973-ab16-05e6d32fb75f started
 2024-11-14 21:10:39 container,info,debug container cd2ee075-7e28-4973-ab16-05e6d32fb75f exited, status: 0
 2024-11-14 21:15:38 container,info,debug container cd2ee075-7e28-4973-ab16-05e6d32fb75f started
 2024-11-14 21:15:39 container,info,debug container cd2ee075-7e28-4973-ab16-05e6d32fb75f exited, status: 0
 2024-11-14 21:20:38 container,info,debug container cd2ee075-7e28-4973-ab16-05e6d32fb75f started
 2024-11-14 21:20:39 container,info,debug container cd2ee075-7e28-4973-ab16-05e6d32fb75f exited, status: 0
 2024-11-14 21:25:38 container,info,debug container cd2ee075-7e28-4973-ab16-05e6d32fb75f started
 2024-11-14 21:25:39 container,info,debug container cd2ee075-7e28-4973-ab16-05e6d32fb75f exited, status: 0
 2024-11-14 21:30:38 container,info,debug container cd2ee075-7e28-4973-ab16-05e6d32fb75f started
 2024-11-14 21:30:39 container,info,debug container cd2ee075-7e28-4973-ab16-05e6d32fb75f exited, status: 0
 2024-11-14 21:35:38 container,info,debug container cd2ee075-7e28-4973-ab16-05e6d32fb75f started
 2024-11-14 21:35:39 container,info,debug container cd2ee075-7e28-4973-ab16-05e6d32fb75f exited, status: 0
 2024-11-14 21:40:38 container,info,debug container cd2ee075-7e28-4973-ab16-05e6d32fb75f started
 2024-11-14 21:40:39 container,info,debug container cd2ee075-7e28-4973-ab16-05e6d32fb75f exited, status: 0
 2024-11-14 21:45:38 container,info,debug container cd2ee075-7e28-4973-ab16-05e6d32fb75f started
 2024-11-14 21:45:39 container,info,debug container cd2ee075-7e28-4973-ab16-05e6d32fb75f exited, status: 0
 2024-11-14 21:50:38 container,info,debug container cd2ee075-7e28-4973-ab16-05e6d32fb75f started
 2024-11-14 21:50:39 container,info,debug container cd2ee075-7e28-4973-ab16-05e6d32fb75f exited, status: 0
 2024-11-14 21:55:38 container,info,debug container cd2ee075-7e28-4973-ab16-05e6d32fb75f started
 2024-11-14 21:55:39 container,info,debug container cd2ee075-7e28-4973-ab16-05e6d32fb75f exited, status: 0

How to disable exactly these type of messages?

I understand that I can disable logging entirely for the container, but I need to keep container stdout messages, just disable start/stop actions.

P.S. disabling logging for the specific container didn't help, It's still spam start/stop to the system log =\
P.P.S forked SUP-171389

ConiKost · Fri Nov 15, 2024 12:28 am

You must use address-pool instead of prefix-pool and address pool specified prefix-length must be /128. Other than that you have gotten the idea correctly - IPv6/ND must be used to advertise managed-network for end devices.

So basically something like that? If I would like to hand out, for example, fd23:dead:beef:babe:0000 up to fd23:dead:beef:babe:ffff for clients?

/ipv6/pool/add name=mypool prefix=fd23::dead:beef:babe:0/112 prefix-length=128

Sit75 · Fri Nov 15, 2024 1:03 am

Hmmm ... what does /interface/wifi/radio/reg-info country=Czech show on your device? On my audience (running 7.15.3) it says
Code: Select all
  ranges: 2402-2482/20
          5170-5250/23/indoor
          5250-5330/23/indoor/dfs
          5490-5710/30/dfs
Which more or less corresponds with limits from "your" document). BTW numbers in above table are EIRP, actual Tx power is reduced by antenna gain. BTW2 if chipset capability is lower, then that's limitation which can't be circumvented.

Those values are correct and same for me, but there are 3 issues: 1) In case of 5490-5710 I have only maximal power 26 dBm with 2.5 dBi antenna. 2) I can not set up manually or automatically any of frequencies beyond 5600 with 20 MHz channel or beyond 5580 with 20/40 MHz channel or beyond 5560 with 20/40/80 MHz channel. If I try - there is only message "no available channels". 3) And in addition why is there 160 MHz channel, but in reality I can not set up? Everything with wifi-qcomm-ac.

[admin@MikroTik] > interface/wifi/radio/reg-info country=Czech
number: 1
  ranges: 2402-2482/20dBm/40MHz            
          5170-5250/23dBm/160MHz/indoor    
          5250-5330/23dBm/160MHz/indoor/dfs
          5490-5710/30dBm/160MHz/dfs

naxus · Fri Nov 15, 2024 1:49 am

Anybody else has issue with connection to internet after upgrade? (I'm using pppoe and there are some changes for PPP) - SUP-171366

thekrzos · Fri Nov 15, 2024 2:58 am

Why bandwidth-test is now blocked by default?

JohnTRIVOLTA · Fri Nov 15, 2024 7:06 am

Anybody else has issue with connection to internet after upgrade? (I'm using pppoe and there are some changes for PPP) - SUP-171366

Yes, i have same problem with pppoe ISP connection on the one of remote routerboard. It looks like it's fine, but there's no internet. After downgrade to stable channel everything work fine again.

grusu · Fri Nov 15, 2024 7:55 am

Anybody else has issue with connection to internet after upgrade? (I'm using pppoe and there are some changes for PPP) - SUP-171366

Same for me on my home router. Downgrade to beta4 and seems stable now.

blingblouw2 · Fri Nov 15, 2024 8:56 am

This device mode is a PITA

We supplied all of our end clients routerboards (hapac2, ax2, etc), the VERY first thing we do if someone complains about speed is we login to their router and do a btest to our core, we're losing such a valuable tool - boo

Fri Nov 15, 2024 9:14 am

Anyone who is experiencing these problems with "No Internet" after upgrade to beta5, please generate supout file while running beta5 and send this files to support@mikrotik.com.

Fri Nov 15, 2024 9:30 am

blingblouw2 you can just enable bandwidth test. ask the user to push the button to confirm. it's a one time operation, you don't have to do it every time.

loloski · Fri Nov 15, 2024 9:41 am

@normis I don't think that's practical on operation standpoint I also can feel their pain, can we revert or go back to 7.16 and moved on and don't touch that device-mode thing!, you guys are shooting yourself on the foot there are lot of people don't like where this is heading, just my 0.02$

mkx · Fri Nov 15, 2024 11:48 am

Those values are correct and same for me, but there are 3 issues: 1) In case of 5490-5710 I have only maximal power 26 dBm with 2.5 dBi antenna. 2) I can not set up manually or automatically any of frequencies beyond 5600 with 20 MHz channel or beyond 5580 with 20/40 MHz channel or beyond 5560 with 20/40/80 MHz channel. If I try - there is only message "no available channels". 3) And in addition why is there 160 MHz channel, but in reality I can not set up? Everything with wifi-qcomm-ac.

1.)
If you check specifications for hAP ac2, you'll see that chipset can only transmit at 26dBm in 5GHz band. As I already mentioned, higher limits, settings, etc. can't change that.

2.)
According to wifi channel table for 5GHz band it should be possible to set something above 5600MHz. But in Europe, frequencies starting from 5650MHz (that's channel 132 with center frequency 5640MHz) come with limitation of indoor use only. While I don't see any configuration parameter available in wifi-qcom-ac , this might still affect channel availability somehow. I can't try (I have one hAP ac2, but without any wireless/wifi driver as I'm using it as router and tight flash storage makes problems if wifi driver is installed). In legacy wireless driver there was property installation with possible settings any, indoor and outdoor ... and if it was set to outdoor, it would refuse to use channels specified for indoor use only by regulations.
You may want to "delegate" this problem to MT support (e.g. by opening a ticket by sending e-mail to support@mikrotik.com)

3.)
I guess it's because wifi-qcom-driver supports 160MHz channels on different hardware (e.g. Audience on the "upper 5GHz" radio)

sharkys · Fri Nov 15, 2024 12:05 pm

7.17beta5 seems to brick RB960PGS - I had to do recovery via Netinstal. I even tried to flash 7.17beta5 via Netinstal and unfortunately the same story - device leds are off except of Blue for POE and RED to POE enabled ports, no ping, no visibility for WinBOX, simply dead. Haven't tried to reset config but if 7.16.1 is running well and 7.17beta4 was okay except of DHCP issue, I don't see reason for reset.

Is there some way to diagnose this, eg. makes suppout sense here after reset via Netinstal ?

2024-11-15 11_06_54-admin@10.0.0.1 (RouterMK) hEX PoE WinBox.png

pekr · Fri Nov 15, 2024 12:07 pm

blingblouw2 you can just enable bandwidth test. ask the user to push the button to confirm. it's a one time operation, you don't have to do it every time.

Is this answer even real, or your computer got hacked? So you think that ppl will do so for 1000+ potential clients, and more so, if the router is e.g. on /under the roof? How on earth disabling stuff like btest protects just anyone? Are there any documented cases of a feature missuse?

ToTheFull · Fri Nov 15, 2024 12:26 pm

Is quad9 DoH ever going to work properly on Mikrotik ?
This works fine when I use Cloudflare DoH, but I get the following for Quad9 DoH, the reason I want to use Quad9 is It's faster!
I Have all the certs etc...

 2024-11-14 19:17:03 dns,warning DoH server response not OK: 502: no downstream server available
 2024-11-14 23:17:19 dns,error DoH server connection error: remote disconnected while in HTTP exchange
 2024-11-15 06:46:36 dns,error DoH server connection error: remote disconnected while in HTTP exchange
 2024-11-15 06:57:10 dns,error DoH server connection error: remote disconnected while in HTTP exchange
 2024-11-15 07:44:29 dns,error DoH server connection error: remote disconnected while in HTTP exchange
 2024-11-15 07:44:29 dns,error DoH server connection error: remote disconnected while in HTTP exchange [ignori
ng repeated messages]
 2024-11-15 08:12:11 dns,error DoH server connection error: remote disconnected while in HTTP exchange
 2024-11-15 08:25:39 dns,error DoH server connection error: while reading - Connection reset by peer
 2024-11-15 08:39:23 dns,error DoH server connection error: remote disconnected while in HTTP exchange

nmt1900 · Fri Nov 15, 2024 12:36 pm

blingblouw2 you can just enable bandwidth test. ask the user to push the button to confirm. it's a one time operation, you don't have to do it every time.
Is this answer even real, or your computer got hacked? So you think that ppl will do so for 1000+ potential clients, and more so, if the router is e.g. on /under the roof? How on earth disabling stuff like btest protects just anyone? Are there any documented cases of a feature missuse?

Exactly - I think that all this fuss related to (previously mentioned) OVHCloud blogpost is probably related to traffic-gen and not bandwidth-test feature. Bandwidth test can generate actual traffic only after establishing session with other Mikrotik device.

If my memory serves me right then in United States they have some sort of federal requirement to do periodic automated bandwidth measurements to CPE's - and bandwith test can actually be used for this if configured correctly. Bandwidth test cannot send billions of packets willy-nilly to "non-predetermined" locations...

erlinden · Fri Nov 15, 2024 1:26 pm

Is quad9 DoH ever going to work properly on Mikrotik ?

Can't reproduce this behavior.
Can you share your /ip dns export?

Fri Nov 15, 2024 1:35 pm

How on earth disabling stuff like btest protects just anyone? Are there any documented cases of a feature missuse?

no need to get agressive. yes, of course there is documented cases of misuse, even in this forum there are people who are asking why they have unrecognized accounts and unrecognized scripts in their devices, that are calling traffic generator, configuring proxy etc. even forum users make mistakes and let in people they did not intend to let in.

pe1chl · Fri Nov 15, 2024 2:16 pm

even in this forum there are people who are asking why they have unrecognized accounts and unrecognized scripts in their devices, that are calling traffic generator, configuring proxy etc. even forum users make mistakes and let in people they did not intend to let in.

I still wonder how many of the large number of users who have a not-optimal configuration are actually upgrading RouterOS, given the fact that this does not occur automatically. They may "forever" remain on <7.17 and only new buyers who get 7.17 from the factory get the improved safety.
I think more would have been gained with a default-enabled auto-upgrade mechanism that can install critical updates, because that helps those people that simply never do any maintenance by themselves. "If it works, don't touch it!". Understandable.
It also would be good when the updater recognizes that the firewall config is a past default, and upgrades it to the current default.

ToTheFull · Fri Nov 15, 2024 2:18 pm

Is quad9 DoH ever going to work properly on Mikrotik ?
Can't reproduce this behavior.
Can you share your /ip dns export?

I would like to blame my isp but this doesn't happen on Cloudflared, or not very often anyway!

/ip/dns/export
# 2024-11-15 12:12:26 by RouterOS 7.17beta5
# software id = FA8N-TIE6
#
# model = C52iG-5HaxD2HaxD
# serial number = 
/ip dns
set allow-remote-requests=yes cache-max-ttl=1d cache-size=250000KiB doh-max-concurrent-queries=200 doh-max-server-connections=2 \
    doh-timeout=4s max-concurrent-queries=200 max-concurrent-tcp-sessions=40 use-doh-server=https://dns.quad9.net/dns-query \
    verify-doh-cert=yes
/ip dns adlist
add url=https://raw.githubusercontent.com/hagezi/dns-blocklists/main/hosts/pro.txt

/ip dns static
add address=192.168.0.254 comment=defconf name=router.lan type=A
add address=9.9.9.9 name=dns.quad9.net type=A
add address=149.112.112.112 name=dns.quad9.net type=A
add address=1.1.1.1 disabled=yes name=cloudflare-dns.com type=A
add address=1.0.0.1 disabled=yes name=cloudflare-dns.com type=A
[@MikroTik] > /ip/dns/static print                                                                                   
Flags: X - DISABLED
Columns: NAME, TYPE, ADDRESS, TTL
#   NAME                TYPE  ADDRESS          TTL
;;; defconf
0   router.lan          A     192.168.0.254    1d 
1   dns.quad9.net       A     9.9.9.9          1d 
2   dns.quad9.net       A     149.112.112.112  1d 
3 X cloudflare-dns.com  A     1.1.1.1          1d 
4 X cloudflare-dns.com  A     1.0.0.1          1d

erlinden · Fri Nov 15, 2024 2:57 pm

How does your router know the IP adress of dns.quad9.net?

/ip dns
set allow-remote-requests=yes cache-size=409600KiB servers=9.9.9.9 use-doh-server=https://dns.quad9.net/dns-query verify-doh-cert=yes

Mostly default settings, no DNS entries in the log so far.

Amm0 · Fri Nov 15, 2024 3:04 pm

How on earth disabling stuff like btest protects just anyone? Are there any documented cases of a feature missuse?
no need to get agressive. yes, of course there is documented cases of misuse, even in this forum there are people who are asking why they have unrecognized accounts and unrecognized scripts in their devices, that are calling traffic generator, configuring proxy etc. even forum users make mistakes and let in people they did not intend to let in.

The reaction is that this will cost customers time and money. It's like y'all are saying we don't care about professional users. Other Linux-based network OSes give customers root access, and can directly install packages without a physical presence to do even worse.

And the issue, in terms of security, the problem is: "unrecognized accounts and unrecognized scripts in their devices". So if there is similar attack that use /tool/fetch or ping or whatever instead.... are those going to going require a physical presence to re-enable in 7.18+? Requiring more costly site visits and more changes in your customer's provisioning processes. These all eat into the value of RouterOS.

Mikrotik seems to want to focus home users. So this trend is concerning, since disabling features is not root cause and shows a haphazard approach to security.

ToTheFull · Fri Nov 15, 2024 3:17 pm

How does your router know the IP adress of dns.quad9.net?
Code: Select all
/ip dns
set allow-remote-requests=yes cache-size=409600KiB servers=9.9.9.9 use-doh-server=https://dns.quad9.net/dns-query verify-doh-cert=yes
Mostly default settings, no DNS entries in the log so far.

They are set static ?

/ip/dns/static print                                                                                   
Flags: X - DISABLED
Columns: NAME, TYPE, ADDRESS, TTL
#   NAME                TYPE  ADDRESS          TTL
;;; defconf
0   router.lan          A     192.168.0.254    1d 
1   dns.quad9.net       A     9.9.9.9          1d 
2   dns.quad9.net       A     149.112.112.112  1d 
3 X cloudflare-dns.com  A     1.1.1.1          1d 
4 X cloudflare-dns.com  A     1.0.0.1          1d

mozerd · Fri Nov 15, 2024 3:39 pm

Mikrotik seems to want to focus home users. So this trend is concerning, since disabling features is not root cause and shows a haphazard approach to security.

Its my opinion the the Tik market is focused on small ISP, entrepreneurs, SMB's and the Home users who are enthusiast's ...

TIK can never be a Enterprise solution consideration because Tik does not provide direct support ... to keep prices down many compromises must be made in hardware, software and peripherals ... IMO, what one gets for the money in purchasing Tik is a very good product ... the shortcoming that many complain about is just very poor planning on "their" part and overestimating the capabilities that Tik provide or should provide ... Nice to have [must have] generally means that cost must rise ...

Amm0 · Fri Nov 15, 2024 3:54 pm

Mikrotik seems to want to focus home users. So this trend is concerning, since disabling features is not root cause and shows a haphazard approach to security.
Its my opinion the the Tik market is focused on small ISP, entrepreneurs, SMB's and the Home users who are enthusiast's ...

In those markets you don't assume your customers are idiots, which is what device-mode assumes. And UBNT or any other new Linux-based network distro - used in those markets - folks can install packages. And I cannot imagine many in those categories see value in truck rolls to re-enable remotely doing a bandwidth test.

nmt1900 · Fri Nov 15, 2024 4:00 pm

I think more would have been gained with a default-enabled auto-upgrade mechanism that can install critical updates, because that helps those people that simply never do any maintenance by themselves. "If it works, don't touch it!". Understandable.
It also would be good when the updater recognizes that the firewall config is a past default, and upgrades it to the current default.

There is no distinction between "critical" and "non-critical" updates and there's no way to activate this feature (if it would become in existance eventually) on already existing devices. Somewhat "unknown" level of QC would lead to additional maintenance costs when issues caused by new bugs will spread like wildfire through automatic updates. It is not viable to do this at current state of things...

pe1chl · Fri Nov 15, 2024 4:36 pm

Yes of course it should only update to versions that have been "stable" for a long time, and without modifying them.
At the moment, a "beta" is promoted to "stable" and that is when everyone starts installing it and the bugs appear all over the place.
So such a "critical" update should always be only a x.xx.2 or higher subrelease, which has been in "stable" for at least a couple of months.
Unfortunately it is likely that when a critical vulnerability would appear, the current "stable" release is quickly patched and marked as "critical", without field testing.
(much like Windows Update lately)

eworm · Fri Nov 15, 2024 4:57 pm

2   dns.quad9.net       A     149.112.112.112  1d

Where did you find that address? Perhaps your device queries the wrong address?

ToTheFull · Fri Nov 15, 2024 5:11 pm

Code: Select all
2   dns.quad9.net       A     149.112.112.112  1d 
Where did you find that address? Perhaps your device queries the wrong address?

https://quad9.net/service/service-addre ... d-features

eworm · Fri Nov 15, 2024 5:28 pm

Well, yes... But querying DNS this combination does not exist. So possibly the hosts at 149.112.112.112 are not configured to accept requests for dns.quad9.net? You should disable that static entry, or use a different url:

https://9.9.9.9/dns-query
https://149.112.112.112/dns-query

Even then I am not sure the latter is intended to work.

ToTheFull · Fri Nov 15, 2024 5:47 pm

Well, yes... But querying DNS this combination does not exist. So possibly the hosts at 149.112.112.112 are not configured to accept requests for dns.quad9.net? You should disable that static entry, or use a different url:

https://9.9.9.9/dns-query
https://149.112.112.112/dns-query

Even then I am not sure the latter is intended to work.

i'm more confused than when i started...
I get send and rec when using tool/sniffer/quick port=443 ip-address=9.9.9.9,149.112.112.112 from both.
I'll dissable the 149 and see what gives!
I'm just used to using pi-hole, ie example

# Commandline args for cloudflared, using Cloudflare DNS
CLOUDFLARED_OPTS=--port 5053 --upstream https://1.1.1.1/dns-query --upstream https://1.0.0.1/dns-query --address 0.0.0.0

massinia · Fri Nov 15, 2024 6:30 pm

I also updated from 7.16 to 7.17beta5

- PPPoE client works so fortunately no "No Internet"
- FT-WPA3 finally works very well, it doesn't work only with old smartphones that connect in WPA3 but don't support fast roaming.

ft_wpa3.png

What does "D" mean in Current Channel?

Thanks

channel.png

ToTheFull · Fri Nov 15, 2024 6:57 pm

Well, yes... But querying DNS this combination does not exist. So possibly the hosts at 149.112.112.112 are not configured to accept requests for dns.quad9.net? You should disable that static entry, or use a different url:

https://9.9.9.9/dns-query
https://149.112.112.112/dns-query

Even then I am not sure the latter is intended to work.
i'm more confused than when i started...
I get send and rec when using tool/sniffer/quick port=443 ip-address=9.9.9.9,149.112.112.112 from both.
I'll dissable the 149 and see what gives!
I'm just used to using pi-hole, ie example
Code: Select all
# Commandline args for cloudflared, using Cloudflare DNS
CLOUDFLARED_OPTS=--port 5053 --upstream https://1.1.1.1/dns-query --upstream https://1.0.0.1/dns-query --address 0.0.0.0

This argument is flawed bacause quad9 set with 9.9.9.9 is still doing this
DoH server connection error: remote disconnected while in HTTP exchange

mkx · Fri Nov 15, 2024 7:07 pm

What does "D" mean in Current Channel?

I'd say it means DFS.

massinia · Fri Nov 15, 2024 7:13 pm

What does "D" mean in Current Channel?
I'd say it means DFS.

You're right, I hadn't thought of that!
Thanks

infabo · Fri Nov 15, 2024 7:54 pm

/ip dns
set allow-remote-requests=yes cache-max-ttl=1d cache-size=250000KiB doh-max-concurrent-queries=200 doh-max-server-connections=2 \
doh-timeout=4s max-concurrent-queries=200 max-concurrent-tcp-sessions=40 use-doh-server=https://dns.quad9.net/dns-query \
verify-doh-cert=yes
[/code]

All these additional properties may be the cause for your issues. Unset and leave the defaults. Start from there again.

FurfangosFrigyes · Fri Nov 15, 2024 9:00 pm

In those markets you don't assume your customers are idiots, which is what device-mode assumes.
Device mode is direct consequence of exactly this assumption.

You have two different clients. The first is the home or small business user who has one or a few devices and has no idea that there is anything to update on the devices at all and the device is dying of obsolescence with the firmware that was on the device when it has been bought, and the other is the professional business user. You have lost or is slowly losing the professional users and stuck in the home segment.

FezzFest · Fri Nov 15, 2024 10:36 pm

blingblouw2 you can just enable bandwidth test. ask the user to push the button to confirm. it's a one time operation, you don't have to do it every time.

MikroTik is still sponsoring a team of engineers with snowmobiles and helicopters to push buttons on routers on remote mountaintop sites, right?
It's pretty hilarious, "We're trying to improve security! How? By making sure users will never update past ROS 7.16!"

erlinden · Fri Nov 15, 2024 11:03 pm

Is quad9 DoH ever going to work properly on Mikrotik ?

Has been running pretty stable for some time (think at least 6 hours), but then all of a sudden:

DoH server connection error: remote disconnected while in HTTP exchange
DoH server response not OK: 403: dns query not allowed
DoH server response not OK: 403: dns query not allowed [ignoring repeated messages]

Have the feeling that it is not MikroTik related.

fischerdouglas · Fri Nov 15, 2024 11:37 pm

About this fight around device-mode and the famous "power-off or push button".

Possible solution to that: TPM, Key-Pair file in boot, or similar.

It's clear that MikroTik guys are trying to do something good.
Certainly, related to security and avoid use of MikroTik devices as a denial-of-service attack vector.

I guess probably they were "kindly" forced by some government to do something about that.
And they are doing it! And I reinforce: THIS IS A GOOD THING.

This "physical access to the device" is the only way they found to verify that those "possible malicious actions" are not malicious.

But what if it were possible to get a remote signal saying "Yes, this is trustworthy" from someone that the device could cryptographically validate?

P.S.:
This leads-me to other unicorn that exists on MikroTik's world:
"The MikroTik Devices Controller"
haha.jpg

That push could come via API/Secure-API/Rest-API/TR-069, bringing an "It's safe to do what the other guy is saying." in a cryptographic signed message that only a "trustable guy" could do.

For that, the ideal would be some kind hardware based cryptography key. I guess TPM would be ideal for that.
But I had never heard any mention of this type of hardware in any Mikrotik hardware. If it exists, it would be great.
So I think this is a solution that will only be implemented and available 10 years from now.

An alternative to the hardware key would be to put the cryptography keys on a boot partition(or similar). Not a perfect alternative, but maybe reasonable.
Something to be studied.

But in the hypothesis been accepted, comes another discussion:
Who will generate those certificates? And how would those certificates be inserted there?
(It reminds-me of some very old discussions on the linux mail list. haha)

Dreaming a bit here in my own world where everything is possible:
“/ip/cloud” already has something to deal with key-pairs, maybe new release that would have a feature like:
“The special reboot cycle that will write the file on the boot partition will only occur on releases newer than X.Y.Z, and it will only occur if the device can connect “/ip/cloud” and “flagged: no”.
By now it’s just an idea!

infabo · Sat Nov 16, 2024 12:11 am

There is a "spotted in the wild" series on Mikrotik youtube channel. People send images of Mikrotik devices found anywhere. Sometimes on obscure places (hard, hard to reach physically). Still they insist on the button push confirmation thing.

There must be an alternative approach.

fischerdouglas · Sat Nov 16, 2024 12:35 am

Still they insist on the button push confirmation thing.

I wonder what the "conversation" was like, and how important that someone must be to generate such an hard action.

Larsa · Sat Nov 16, 2024 12:57 am

… Sometimes on obscure places (hard, hard to reach physically). Still they insist on the button push confirmation thing.

There must be an alternative approach.

No worries, we rent out specially trained button-pushers worldwide.

IMG_2529.jpeg

sirbryan · Sat Nov 16, 2024 1:32 am

blingblouw2 you can just enable bandwidth test. ask the user to push the button to confirm. it's a one time operation, you don't have to do it every time.

You act like it's no big deal, but I have hundreds MikroTik devices to which I run bandwidth tests as part of regular troubleshooting. These are all well out of customer reach. (Many times customers have a non-MikroTik router, and I'm testing to the radio or a PowerBox Pro on their roof.)

These changes require physical access
Truck rolls are expensive (customers are not touching the equipment)
Application of the change is service disrupting, stuff that we would normally do overnight
We don't climb roofs and towers at night for safety reasons, forcing the work to be done during the day
Daytime maintenance is best done on weekends, to be the least disruptive

You are (essentially) saying that, in order to keep using bandwidth-test as a troubleshooting tool, we have to coordinate a time to visit each house and business, climb to their outdoor-mounted gear, have someone type in a device-mode permission via the CLI, push the reset button in time, disrupting their service, then pack it up and go to the next one. And after we've spent all week doing that, spend the weekends doing the same process with the rest of the gear at our tower sites, taking dozens (if not hundreds) of customers down in the process.

I'm a one-man WISP. To hit all customer-inaccessible CPE devices would take me two to three weeks (10-15 8-hour business days), and 5 weekends (at best). This is assuming I have no other work to do, and wouldn't give me any time to install new customers or upgrade existing ones.

Let's say I don't need it on customer equipment, or I don't upgrade any outdoor gear past 7.16. I still have 20+ sites I have to go to in order to touch the routers/switches, plus dozens of devices in two data centers.

Why not just force bandwidth-test to use authentication, and not work at all unless it has some kind of strong (i.e. long) password?

(Photos attached of a CCR2116 installed in a cabinet that is only accessible 6 months out of the year at a site that overlooks three valleys. We tried to get up there this past Monday, but the truck got stuck.)

IMG_5306.jpeg

IMG_0125.jpeg

IMG_1284.jpeg

IMG_7535.jpeg

Amm0 · Sat Nov 16, 2024 2:43 am

In those markets you don't assume your customers are idiots, which is what device-mode assumes.
Device mode is direct consequence of exactly this assumption.

LOL. Perhaps. But device-mode needs more "sophistication" than just physical presence test. I got similar problem as @sirbryan, why I persist... i.e. there are real costs to a power-reset.

Larsa · Sat Nov 16, 2024 3:10 am

No worries ya all!

Should MT decide to keep device mode in its current glorious form, just remember—we’re always here for you! 😄

Button-pushers.com

IMG_2527.jpeg

mantouboji · Sat Nov 16, 2024 5:59 am

7.17beta5 crashed once on AX3, out of memory?

  MMM      MMM  III  KKK  KKK  RRR  RRR   OOOOOO      TTT     III  KKK  KKK

  MikroTik RouterOS 7.17beta5 (c) 1999-2024       https://www.mikrotik.com/


Press F1 for help

2024-11-15 14:32:38 system,clock,critical,info ntp change time Nov/15/2024 14:29:41 => Nov/15/2024 14:32:38
2024-11-15 14:32:41 system,error,critical router was rebooted without proper shutdown, probably kernel failure
2024-11-15 14:32:42 system,error,critical kernel failure in previous boot
2024-11-15 14:32:42 system,error,critical out of memory condition was detected
2024-11-16 04:26:33 system,clock,critical,info ntp change time Nov/15/2024 14:37:12 => Nov/16/2024 04:26:33

infabo · Sat Nov 16, 2024 8:42 am

Given the wide variety of environments where Mikrotik equipment is deployed, it's quite bold to sit in the comfort of the Mikrotik headquarters in Riga, maintained at a pleasant 20°C, and suggest in a straightforward manner:

blingblouw2 you can just enable bandwidth test. ask the user to push the button to confirm. it's a one time operation, you don't have to do it every time.

It might be worth considering a more differentiated approach. New device mode defaults could be applied only to devices known to have been part of these DDoS botnets. This likely concerns devices that are already accessible, such as those located in data centers.

Has a wAP ac, installed somewhere on a remote mountain hut with a 5 Mbps internet connection, ever been part of an attack? I highly doubt it.

Therefore, it might be worth exploring whether a selective approach could be taken. Reducing unnecessary disruptions.

Sat Nov 16, 2024 9:36 am

As already mentioned before
Traffic- gen: I can understand why that's blocked by default.
Bandwidth test / speedtest: You always need a target device responding before it does anything. So why block this as well ?

Sat Nov 16, 2024 10:54 am

You always need a target device responding before it does anything.

For TCP, you may be right, but UDP is spoofable unless it takes specific measures to guard against it. (Three-way handshakes, cryptographic authentication, etc.) If not, it’s a potential attack bandwidth amplifier.

pekr · Sat Nov 16, 2024 10:59 am

How on earth disabling stuff like btest protects just anyone? Are there any documented cases of a feature missuse?
no need to get agressive. yes, of course there is documented cases of misuse, even in this forum there are people who are asking why they have unrecognized accounts and unrecognized scripts in their devices, that are calling traffic generator, configuring proxy etc. even forum users make mistakes and let in people they did not intend to let in.

I don't think I am agressive at all, maybe assertive, as I am over-sensitive to what I regard a wrong, not well thought out solution. Normis, it is actually your suggestion of pushing a button being bold, not reflecting reality ppl are pointing at.

We've already sold our ISP network, and I can tell you, that one of primary uses of Mikrotiks was to perform off-site client bandwidth test. What I think is, that with MT's decision, you might harm your ISP business.

You also mention a traffic generator, but as for btest, we were always testing against concrete MT node, for which, you need to know login information? When we've got some excessive traffic (e.g. firewall non protected DNS usage from Internet), we solved it case by case.

Someone has already suggested some key / cryptographic solution instead. What about some public / private key scenario like with WG, agains MT cloud to confirm feature unlock? IP/Cloud section already has a Back-2-home section. Add just another tab there.

Simply put - any physical button push solution is an old school nonsense. It is like claiming, that in today's world, there are no suitable cryptograpic solutions. Those pure banks, allowing us to protect our accounts by multifactor authentication :-) You've also got a 3 mobile applictions, just add FMA (2FA) there. Even my Synology NAS can do it to protect my admin access.

wrkq · Sat Nov 16, 2024 11:13 am

Also "as already mentioned before", the double-lemonjuice-salt-in-the-wound part is the general implication that later upgrades post 7.17 would as well put additional features (existing or brand-new) behind the device-mode lock and require repeat of the button pusher visit.
"Yes hello mrs. customer would you happen to have two screwdrivers and a ladder? I need you to open the control cabinet for your solar and look for the little white box that says Mikrotik on it..."

PhilB · Sat Nov 16, 2024 11:17 am

It might be worth considering a more differentiated approach. New device mode defaults could be applied only to devices known to have been part of these DDoS botnets. This likely concerns devices that are already accessible, such as those located in data centers.

Devices in the field need to have a mechanism to just keep working the way they are regardless of model. No explanation has been forthcoming about how bricking features on existing devices will significantly reduce the harm caused by improperly administered MTs already in the wild because no evidence exists that those devices causing the most harm volumetrically will actually be upgraded to any new version MT releases. This change will only impact people actually installing updates.

People who are confused about their already hacked router (re: MT staff comments upthread about customer forum posts) should be resetting it, not hoping for MT slapping a bandaid on by just disabling trafficgen leaving someone inside their device with the continued ability to redirect their (or their customers) DNS or traffic. Or is reconfiguring DNS and firewall rules also going to need a button press soon?

Bring device-mode to devices with factory > x, fine. Industry can change their build process to re-enable features as part of initial build. Was there any news on managing device-mode in netinstall yet?

I get MTs point that any software bypass - no matter how sophisticated - can be used by an attackerto maintain their access to trafficgen on upgrade. But that presumes that this is an effective control for the existing problem with improperly administered devices in the wild apparently mostly running 6.x, which I don’t think it is.

Johann1525 · Sat Nov 16, 2024 12:13 pm

I think MTs task here is to give the owner the best tools and defaults for security and the best help with best practices and documentation. If someone is still running a MT in a insecure manner the owner should be responsible. If you are a datacenter owner or ISP and detect malicious traffic you should talk to your customer anyway. Its like running an SMTP Server. If i do bad things i get on a blocklist.

And for the home user the current default config does not let in management traffic from the internet as far as i know. Passwords are randomized by default. So if setup like intended there should not be any problem.

Maybe we should try to make this world a better place by protecting our freedom and independence. Trust each other to be responsible. Because if you MT wanted to make it even more secure you should lock out the customer entirely and configure it from your end. Do not even sell the device. Trust no one and force the customer into some rental service ;) => bad future

However. I can see the button press maybe for new devices. I agree that it is not very feasible for ones which are already in service.
In the end it is a problem of trust. And the only way to get trust (especially with a device) is currently to meet personally. It does not matter if you exchange key pairs or press a button. So i would let the old devices be and try to make the process of establishing trust with the new device as good as possible.

ToTheFull · Sat Nov 16, 2024 12:21 pm

Is quad9 DoH ever going to work properly on Mikrotik ?
Has been running pretty stable for some time (think at least 6 hours), but then all of a sudden:

DoH server connection error: remote disconnected while in HTTP exchange
DoH server response not OK: 403: dns query not allowed
DoH server response not OK: 403: dns query not allowed [ignoring repeated messages]
Have the feeling that it is not MikroTik related.

Yeah thats what happens, it's frustrating. But at least I'm not going crazy. Thanks for taking the time to humour me!

wiktorbgu · Sat Nov 16, 2024 6:35 pm

7.17beta5 seems to brick RB960PGS - I had to do recovery via Netinstal. I even tried to flash 7.17beta5 via Netinstal and unfortunately the same story - device leds are off except of Blue for POE and RED to POE enabled ports, no ping, no visibility for WinBOX, simply dead. Haven't tried to reset config but if 7.16.1 is running well and 7.17beta4 was okay except of DHCP issue, I don't see reason for reset.

7.17beta5 seems to brick C53UiG+5HPaxD2HPaxD
Same thing with my ax3. All indicators go out and there is no link on any port and no wifi. I installed the latest beta via netinstall, then chose to restore my backup via winbox and the problem repeated. As a result, I rolled back to the 4th beta version.

BrateloSlava · Sat Nov 16, 2024 7:49 pm

@wiktorbgu
I didn't have any problems with the update.

Screenshot_AX3.png

Current devices with 7.17beta5:

AX3
hEX
cAP ac
wAP ac

jookraw · Sat Nov 16, 2024 8:29 pm

My hAP ax3 also bricked when updating to beta 5. Just like with @wiktorbgu.
Resetting config it does work, but that is not acceptable, I should not need to reconfigure my device from zero. restoring the backup make the device brick again.
At the moment I'm back to 7.17b4

oreggin · Sat Nov 16, 2024 9:28 pm

Device-Mode: My personal opinion is that this is a bad approach. (not only MikroTik) customers are a special species :-) Who don't want to bother with SW upgrades and security to harden its network environment, they don't bother with this kind of tries. What they would do in that moment when they hit a barrier?

google
search "how to put mikrotik device into advanced device-mode"

They sets device-mode to advanced and forget their device as long as it works.

What would must do an ISP when it hits this barrier on thousands of endpoints countrywild?

buy sedative tablets
trying to reach all of the endpoints on phone (impossible)
if endpoint is reachable try to modify the device-mode settings with button push or power cycle (hard)

We are a (W)ISP with thousands of endpoints and millions of users. The users and their admins sometimes doing unimaginable things which leaves my mouth opened when I get to know about that :-)

We using partition function, on first install we repartition the device with two partitions and install and configure it then copy everything onto the second partition when part0 gets somehow corrupted device can boot from part1. But this is only one example which could cause headache when you are serious about this function. In this form it is only causes extra expense and work to:

ISPs
conscientious administrators
conscientious endusers

And causing some minutes of google searching and button pushing for those who doesn't bother this and they open their device to the bad guys. I would like to suggest that we think about this again.

ps.: I don't usually write such long comments ;-)

RafGan · Sun Nov 17, 2024 12:53 am

7.17beta5 seems to brick RB960PGS - I had to do recovery via Netinstal. I even tried to flash 7.17beta5 via Netinstal and unfortunately the same story - device leds are off except of Blue for POE and RED to POE enabled ports, no ping, no visibility for WinBOX, simply dead. Haven't tried to reset config but if 7.16.1 is running well and 7.17beta4 was okay except of DHCP issue, I don't see reason for reset.
7.17beta5 seems to brick C53UiG+5HPaxD2HPaxD
Same thing with my ax3. All indicators go out and there is no link on any port and no wifi. I installed the latest beta via netinstall, then chose to restore my backup via winbox and the problem repeated. As a result, I rolled back to the 4th beta version.

Yeah, this same, no Ethernet, no wifi, no double beep. Reset to defaults and work. Restore config bricked again. Revert back to stable.

sinisa · Sun Nov 17, 2024 12:59 am

It seems that we have here a "Mikrotik vs Mikrotik users/buyers" situation...
And I agree with other buyers. We DON'T WANT ANY OF THE FUNCTIONALITY TO BE TAKEN AWAY.
I bought Mikrotik routers because I knew I could manage them, no matter where they "live".
Many of them are in hardly accessible places, many have to work 24/7/366, and many of them have no easy way to cut power (I have made sure that they stay alive however long power outage might be, some of them even days). Only way is that I send someone on a road trip and have devices restarted on Sunday @3am... and I DON'T WANT TO DO THAT just because someone at MT thinks that this messing with "device mode" is a good thing.
Of course, I can leave everything on 7.16 level forever and never upgrade, but that is not really my idea of properly managed network...
And start looking for something to replace MT's... it seems that there is a plenty of "Chinese" devices with enough gigabit ports, strong enough ARM CPU's and able to run Linux which I am perfectly capable of administering to achieve my routing needs (but I'd rather not do that, I love everything else about Mikrotik except for this "device mode" nonsense).
</rant>

chojrak11 · Sun Nov 17, 2024 1:08 am

Upgraded without issues my hAP ax^3.

I don't know what you have done in beta4 or more probably in beta5, but the wireless is much improved. It's stable as hell and I've got 647 Mbps in speedtest (5GHz, no supperchannel, WPA-3). That is, it was able to use all my 600 Mbps connection and it seems it could do more.

In previous versions it was much worse. So, thank you and keep up the good work!

Amm0 · Sun Nov 17, 2024 2:09 am

*) webfig - status page is deprecated, old status page config will work, but can't be updated or created;

A previously created webfig status page does NOT work, despite the release note.... I upgraded a wAPacR with status page showing LTE stuff, running 7.16.1 to 7.17beta5 — no status page is shown.

Tried on RB1100AHx4 by downgrading from 7.17beta5 to 7.16.1 — to test the status page. RAID mounted, but didn't show any files - not sure why....but a 2nd reboot (apply firmware) did get the files. But then containers still didn't start and showed nothing in log . Dunno why those would break in downgrade....

I added a status page under 7.16.1 and upgrade back to 7.17beta5. Disk and containers did come back once at 7.17 again. But like wAPacR, the status page was GONE in the "improved" webfig on RB1100 too... So the "old status page config will work" commentary was not my experience. I use the "status page" to provide a "customer friendly" dashboard – so I know that they do need to change over time. So even if status pages was correctly "preserved" that won't help for too long (i.e. the .id of the status page element may need change). While the status page far from ideal... but now I got nothing for a customer friendly view.

And that's going to be on top of not being able to test speeds remotely. I got sold a Swiss Army knife, but now getting a very stylish butter knife.

Amm0 · Sun Nov 17, 2024 2:39 am

*) iot - added additional debug for LoRa logging;
[...]
*) iot - added new LoRa traffic FCnt packet counter parameter;

On a positive note :). I have a KNOT with LoRa (+ 3rd party temp sensor) running 7.17beta5, connected to mosquitto and an old erlang lorawan-server container on RB1100 to run entire LoRaWAN ecosystem entirely on RouterOS. This has [surprisingly] worked flawless in 7.17 (other than the various broken RAID issues I've reported) ... while previously in 7.16 with the same setup, the KNOT occasionally seems to lose LoRa messages over time (which could be a lot of things too). So despite the long list of IOT and LoRa changes in 7.17... those did NOT break anything. And FCnt is pretty useful to check for lost messages. The KNOT is actually one of my test devices for a few months, and it has not had any issue with beta/rc from 7.15+ - why y'all don't hear about that one as much as the wAP and RB1100 ;).

Still it's one step forward, two steps back here....

teslasystems · Sun Nov 17, 2024 6:49 am

MikroTik is still sponsoring a team of engineers with snowmobiles and helicopters to push buttons on routers on remote mountaintop sites, right?

many of them have no easy way to cut power (I have made sure that they stay alive however long power outage might be, some of them even days). Only way is that I send someone on a road trip and have devices restarted on Sunday @3am...

and others

Are you guys serious? People who have their devices "on mountains" or other similar locations, ALWAYS install some kind of additional device that allows to power-cycle their hardware by remote request or automatically by timer or if some condition is met. Of course if they are adequate and don't want to "sponsor helicopter teams" or "send someone on a trip".

wiktorbgu · Sun Nov 17, 2024 2:35 pm

I was trying to figure out why the new version was bricks on my ax3. I decided to load my backup to CHR 7.17b5 on VmWare. Yes, I know it's not right, but this is the experience of investigating the problem.
As a result, I got a cyclic reboot.
I attach a screenshot.
I suppose my ax3 has the same effect.

infabo · Sun Nov 17, 2024 4:54 pm

Dear MikroTik,

I’d like to suggest focusing on enhancing the "flagged status" feature rather than restricting the default feature set of RouterOS. A better approach might be to analyze system configurations for abnormalities. Many forum threads highlight cases where users have been hacked and locked out of their systems—often showing the same warning signs. These cases could serve as excellent references.

The "flagged status" is already a strong foundation. As it stands:

If the system has this flagged status, the current configuration works, but it is not possible to perform the following actions: bandwidth-test, traffic-generator, sniffer.

Why isn’t this enough?

I think improving the analytics to better detect unauthorized or compromised systems would be a far more effective solution.

Looking forward to hearing your thoughts!

nmt1900 · Sun Nov 17, 2024 5:12 pm

There's one other detail in being hacked/locked out as well. Intruder can disable button/jumper reset before changing the password and that can really make device a paperweight for the owner. Therefore flagged status should take care of re-enabling jumper/button reset as well.

Sun Nov 17, 2024 7:07 pm

There's one other detail in being hacked/locked out as well. Intruder can disable button/jumper reset before changing the password and that can really make device a paperweight for the owner. Therefore flagged status should take care of re-enabling jumper/button reset as well.

good point !!!

oreggin · Mon Nov 18, 2024 6:01 pm

There's one other detail in being hacked/locked out as well. Intruder can disable button/jumper reset before changing the password and that can really make device a paperweight for the owner. Therefore flagged status should take care of re-enabling jumper/button reset as well.

What? :-O
If anybody disable the button/jumper reset method and login credentials is unknown then that device is bricked forever? Can't support revive it either?

infabo · Mon Nov 18, 2024 7:28 pm

netboot aka netinstall is initiated by reset button press.

rzirzi · Tue Nov 19, 2024 6:19 am

It seems that we have here a "Mikrotik vs Mikrotik users/buyers" situation...
And I agree with other buyers. We DON'T WANT ANY OF THE FUNCTIONALITY TO BE TAKEN AWAY.
I bought Mikrotik routers because I knew I could manage them, no matter where they "live".
Many of them are in hardly accessible places, many have to work 24/7/366, and many of them have no easy way to cut power (I have made sure that they stay alive however long power outage might be, some of them even days). Only way is that I send someone on a road trip and have devices restarted on Sunday @3am... and I DON'T WANT TO DO THAT just because someone at MT thinks that this messing with "device mode" is a good thing.
Of course, I can leave everything on 7.16 level forever and never upgrade, but that is not really my idea of properly managed network...
And start looking for something to replace MT's... it seems that there is a plenty of "Chinese" devices with enough gigabit ports, strong enough ARM CPU's and able to run Linux which I am perfectly capable of administering to achieve my routing needs (but I'd rather not do that, I love everything else about Mikrotik except for this "device mode" nonsense).
</rant>

agree 100% !!!

evellin · Tue Nov 19, 2024 9:55 am

Hi,

I'm working for an ISP and we use a lot of Mikrotik devices on customer sites. BTest is a very important feature for us for validating and supporting. Please don't disable it in advanced mode. I can understand that you want to make product for home users with some security but in this case please create a different brand than Mikrotik home users. Disabling things like btest is just like giving us more difficulties to make our work. We don't need that.

Regards,
Jerome.

txfz · Tue Nov 19, 2024 10:08 am

> *) container - improved container shell;

Any details?

ToTheFull · Tue Nov 19, 2024 11:59 am

Hi,

I'm working for an ISP and we use a lot of Mikrotik devices on customer sites. BTest is a very important feature for us for validating and supporting. Please don't disable it in advanced mode. I can understand that you want to make product for home users with some security but in this case please create a different brand than Mikrotik home users. Disabling things like btest is just like giving us more difficulties to make our work. We don't need that.

Regards,
Jerome.

On the flip side of the Coin, I buy Mikrotik Gear to keep ISP's OUT!
Strange world we live in.

nichky · Tue Nov 19, 2024 1:46 pm

about device-mode - install-any-version.
how to get that?

infabo · Tue Nov 19, 2024 1:48 pm

By the push of a button or power-cycle :D

leoktv · Tue Nov 19, 2024 3:26 pm

about device-mode - install-any-version.
how to get that?

https://help.mikrotik.com/docs/spaces/R ... evice-mode

evellin · Tue Nov 19, 2024 6:08 pm

Hi,

I'm working for an ISP and we use a lot of Mikrotik devices on customer sites. BTest is a very important feature for us for validating and supporting. Please don't disable it in advanced mode. I can understand that you want to make product for home users with some security but in this case please create a different brand than Mikrotik home users. Disabling things like btest is just like giving us more difficulties to make our work. We don't need that.

Regards,
Jerome.
On the flip side of the Coin, I buy Mikrotik Gear to keep ISP's OUT!
Strange world we live in.

lol

guipoletto · Tue Nov 19, 2024 6:55 pm

On the flip side of the Coin, I buy Mikrotik Gear to keep ISP's OUT!
Strange world we live in.

I wish half my customers were proficient enough to plug their own network cables

configuring and managing their intranet, reading the changelogs before updating , and engaging in the beta thread? --unheard of--

nmt1900 · Tue Nov 19, 2024 7:22 pm

Hi,

I'm working for an ISP and we use a lot of Mikrotik devices on customer sites. BTest is a very important feature for us for validating and supporting. Please don't disable it in advanced mode. I can understand that you want to make product for home users with some security but in this case please create a different brand than Mikrotik home users. Disabling things like btest is just like giving us more difficulties to make our work. We don't need that.

Btest is not likely be able to be abused when device is compromised because it needs other endpoint to connecto to. Traffic-gen should be the one to be disabled...

Tue Nov 19, 2024 7:36 pm

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:

7.17beta5 appears to have fixed this symptom.

I've successfully upgraded a hAP ax³, a CRS328-24P, and an RB4011 (wired-only) to beta5.

infabo · Tue Nov 19, 2024 8:14 pm

when compromised at least one device on at least 2 different networks (meaning 2+ devices), you can establish a btest between these devices.

guipoletto · Tue Nov 19, 2024 8:32 pm

when compromised at least one device on at least 2 different networks (meaning 2+ devices), you can establish a btest between these devices.

If we redteam all possible scenarios of misuse, then mikrotik will have to rename, and become air-gapped-tik

There has to be a ballance between a deployable, diagnosable, mantainable/remotelly manageable piece of equimnent, and the possible avenues for abuse of such tools
i still believe that 7.17b5 is still heavy-handedly restricting legitimate and necessary tools and functionality

Paternot · Tue Nov 19, 2024 9:17 pm

when compromised at least one device on at least 2 different networks (meaning 2+ devices), you can establish a btest between these devices.

Ain't we gasping at straws here? I mean, it's true - but You are still limited to the processing capabilities of the (supposed) compromised Miktorik ate the attacked network. Really, really niche - and quite convoluted.

oreggin · Tue Nov 19, 2024 9:58 pm

Hi,

I'm working for an ISP and we use a lot of Mikrotik devices on customer sites. BTest is a very important feature for us for validating and supporting. Please don't disable it in advanced mode. I can understand that you want to make product for home users with some security but in this case please create a different brand than Mikrotik home users. Disabling things like btest is just like giving us more difficulties to make our work. We don't need that.
Btest is not likely be able to be abused when device is compromised because it needs other endpoint to connecto to. Traffic-gen should be the one to be disabled...

Functions shouldn't be disabled in this way. A worldwide opened DNS/NTP server is more dangerous than btest or trafficgen! Should MTik disable these functions too? I think no.

Just a tip, maybe somehow these dangerous(?) functions needs multifactor authorization? A regular home user wont use trafficgen. btest has authentication. DNS/NTP server, hmmm, I ain't a beginner but once I had left an innocent router with publicly accessible DNS server, and it was actively used in amplification attack, but I realized my mistake and fixed it fast.

Regards,
oreggin

guipoletto · Tue Nov 19, 2024 10:29 pm

but once I had left an innocent router with publicly accessible DNS server, and it was actively used in amplification attack, but I realized my mistake and fixed it fast.

In that case, we should definitelly hide this dangerous functionality behind device-mode
/s

or maybe fix DNS VRF-support, still broken in 7.17
or maye still, bind to interface-list, so we can direct the local DNS server to listen only on selected interfaces

oreggin · Tue Nov 19, 2024 11:08 pm

but once I had left an innocent router with publicly accessible DNS server, and it was actively used in amplification attack, but I realized my mistake and fixed it fast.
In that case, we should definitelly hide this dangerous functionality behind device-mode
/s

or maybe fix DNS VRF-support, still broken in 7.17
or maye still, bind to interface-list, so we can direct the local DNS server to listen only on selected interfaces

DNS was just an example. It is a basic functionality of internet. In HTTPS/TLS world NTP too. You can't just simply disable them without harm.
In device mode section, DNS and NTP are not mentioned, btest and traffic-gen does. We should handle this two category separated.

wiktorbgu · Tue Nov 19, 2024 11:36 pm

Let's imagine what Mikrotik is trying to implement this for.

1. If the device is hacked, will the attacker update the software to limit himself?
No.

2. If the device is not updated, will the Mikrotik solution help in the fight against hacking of these devices?
No.

3. If someone updates the device, he will be warned in the update that the ability to disable potentially dangerous options has been added to establish increased security. Will this break the device?
No. Because the user himself takes measures to protect his device.

Accordingly, I suggest not to forcibly disable the capabilities of devices, but only indicate this in the update, as it was when switching to new Wi-Fi drivers.

oreggin · Tue Nov 19, 2024 11:49 pm

As far as I understand MTik tries to mitigate unauhorized atterkers to using MTik devices for attacks.

the user himself takes measures to protect his device.

In a perfect world, yes, In a real world, unfortunately not in every single case.

oreggin · Wed Nov 20, 2024 9:35 am

As far as I understand, MTik is trying to discourage unauthorized attackers from using MTk devices for attacks.

the user himself takes measures to protect his device.

In a perfect world, yes, In a real world, unfortunately not in every single case.

raphaps · Wed Nov 20, 2024 9:45 am

The ISP serving one of my business clients has an entire network in bridge mode. As a result, if I enable the ISP's interface discovery in the neighbors' settings, I can see several of their clients who have Mikrotik routers, many of them with versions older than 6.45, and some even without passwords, where it was possible to log in using just the admin user. So, I agree with the Mikrotik team about finding a solution for the situation, but being radical doesn’t seem like the best approach. They should listen carefully to their clients so that they can come up with a solution that doesn't harm those who are trying to work properly.

pe1chl · Wed Nov 20, 2024 2:21 pm

Why is BGP not getting any love?
There are several known problems in BGP yet no release notes about improvements...

Wed Nov 20, 2024 4:41 pm

What's new in 7.17beta6 (2024-Nov-20 09:58):

!) device-mode - after upgrade, mode "enterprise" is renamed to "advanced" and traffic-gen, partition (command "repartition"), routerboard and install-any-version features will be disabled (additional fixes);
!) webfig - redesigned HTML, styling and functionality (additional fixes);
*) bridge - fixed bridge packet transmit if dhcp-snooping is enabled (introduced in v7.17beta5);
*) disk - added mount-read-only and mount-filesystem options to allow read-only mounts and prevent mounting device at all (CLI only);
*) firewall - improved matching from deeply nested interface-lists (additional fixes);
*) ipv6 - added support for manual link-local address configuration;
*) lte - improved recovery after unexpected modem reboot for Chateau's 5G and 5G R16 series devices;
*) port - display a warning when using invalid log-file with the "remote-access" feature;
*) ptp - fixed DSCP values for IPv4 packets;
*) ptp - fixed synchronization on QSFP28 interfaces (additional fixes);
*) qos-hw - allow to disable/enable profiles, disabled or removed profile gets replaced with the default (additional fixes);
*) routerboot - improved stability for IPQ8072 and IPQ6010 when flash-boot is used ("/system routerboard upgrade" required);
*) smb - stability improvements for client/server (additional fixes);
*) supout - do not create autosupout.rif for second time after system reboot;
*) tftp - improved stability;
*) winbox - improved stability;

Wed Nov 20, 2024 4:58 pm

P.S: we have listened to the community and have walked back the device mode defaults. Btest is now allowed on the advanced mode template which is the same template that will be used after upgrade from previous versions if you did not change it manually. Also, to those who missed the previous betas, downgrade is also allowed to certain versions.

blacksnow · Wed Nov 20, 2024 5:05 pm

Great job, keep up the solid work. Looks like an RC release is nearby!

massinia · Wed Nov 20, 2024 5:07 pm

Thanks MikroTik ☺️

evellin · Wed Nov 20, 2024 5:21 pm

Thank you for Btest :)

ToTheFull · Wed Nov 20, 2024 6:11 pm

Thanks

baragoon · Wed Nov 20, 2024 6:24 pm

@EdPa, @normis thank you

ToTheFull · Wed Nov 20, 2024 6:43 pm

Will it change anything that is already set? For example install-any-version

It didn't unchange mine!
I still have it set as before update

system/device-mode/print                    
                 mode: advanced
              flagged: no      
     flagging-enabled: yes     
            scheduler: yes     
                socks: yes     
                fetch: yes     
                 pptp: yes     
                 l2tp: yes     
       bandwidth-test: yes     
          traffic-gen: no      
              sniffer: yes     
                ipsec: yes     
                romon: yes     
                proxy: yes     
              hotspot: yes     
                  smb: yes     
                email: yes     
             zerotier: yes     
            container: no      
  install-any-version: yes     
           partitions: no      
          routerboard: no      
        attempt-count: 0

sirbryan · Wed Nov 20, 2024 6:51 pm

Thank you for listening.

wiktorbgu · Wed Nov 20, 2024 8:02 pm

My ax3 survived this update. But this time I was prepared for a crash like in the previous beta.

guipoletto · Wed Nov 20, 2024 8:39 pm

Updating from a 7.16.1 base ( with empty config "/sys reset-configuration defaults=no" ) --> 7.17beta6
i have this auto-generated interface:

/interface ovpn-server server
add mac-address=FE:C6:E8:ED:5F:C3 name=ovpn-server1

btest works (yay!)
downgrade from .npk works (yay!)
activating secondary (pre existing) partition works (yay!)
changing fallback order works! (including to etherboot! Yay!)

anything in the /system/routerboard menu is completelly blocked

we sometimes have to edit:
A- boot-delay , to prevent race-conditions with monitored equipment during boot
B- change setup-key from "any" to "delete"
C- boot-device, specifically for remote-netinstall ("try ethernet once, then nand")

all of those seem innofensive, ,and enabling full-access just to permit remote-recovery seems counter-productive?

i think a more granular approach, such as was done with /partitions (only block repartition action) would disencourage people enabling /routerboot for 99% of the use-cases
allow change cpu-speed from "auto" up to the datasheet max
allow change to boot-delay, boot-device (specifically bewteen "nand-then-ethernet", "flashboot-once-then-nand" and "try-ethernet-once")
allow re-enabling "reset-button", but not disabling it
allow toggle silent-boot
allow toggle auto-upgrade

blacksnow · Wed Nov 20, 2024 8:47 pm

i think a more granular approach, such as was done with /partitions (only block repartition action) would disencourage people enabling /routerboot for 99% of the use-cases
allow change cpu-speed from "auto" up to the datasheet max
allow change to boot-delay, boot-device (specifically bewteen "nand-then-ethernet", "flashboot-once-then-nand" and "try-ethernet-once")
allow re-enabling "reset-button", but not disabling it
allow toggle silent-boot
allow toggle auto-upgrade

I agree granular control here would be nice and the optimal solution, but then again for any units in the field, you can set these options before upgrading to a version where it gets locked down (also currently you can downgrade to v7.13+ where things aren't as locked down so you can make changes if you make mistakes).

One additional gripe is, can things be greyed out in Webfig when the underlying option is not enabled so it's clear that the functionality is disabled.

guipoletto · Wed Nov 20, 2024 9:11 pm

the thing is, putting the useful and inoffensive stuff (such as cpu-frequency, without overclock) behind the same security-group as some other "more dangerous" settings (boot to ethernet-only, disable reset)
will incentivize people to "unblock" this, defeating the purpose of the setting

Amm0 · Wed Nov 20, 2024 9:41 pm

the thing is, putting the useful and inoffensive stuff (such as cpu-frequency, without overclock) behind the same security-group as some other "more dangerous" settings (boot to ethernet-only, disable reset)
will incentivize people to "unblock" this, defeating the purpose of the setting

It's a numbers game. I cannot believe more than ~<5% of users change the CPU/etc settings. And even among that ~<5%, some either might re-enable it and/or know something about a firewall (esp if one is mod'ing CPU on a router)...

While more granular device-mode be good... the real/underlying issue is the user policy granularity & lack of MFA/certs/etc, not the specificity of device-mode...

deadmaus911 · Wed Nov 20, 2024 9:52 pm

Hi all!
How do I configure new forwarders in my DNS server settings?

erlinden · Wed Nov 20, 2024 10:00 pm

How do I configure new forwarders in my DNS server settings?

Please check the documentation:
https://help.mikrotik.com/docs/spaces/R ... 748767/DNS

pekr · Wed Nov 20, 2024 10:13 pm

Thanks for freeing the btest! Now let's move to RC.

Johann1525 · Thu Nov 21, 2024 12:18 am

P.S: we have listened to the community and have walked back the device mode defaults. Btest is now allowed on the advanced mode template which is the same template that will be used after upgrade from previous versions if you did not change it manually. Also, to those who missed the previous betas, downgrade is also allowed to certain versions.

Very good! Thank you very much. :) +1
I'm sure there will come up some good ideas for security in the future. Keep up the good work.

sinisa · Thu Nov 21, 2024 1:10 pm

P.S: we have listened to the community and have walked back the device mode defaults. Btest is now allowed on the advanced mode template which is the same template that will be used after upgrade from previous versions if you did not change it manually. Also, to those who missed the previous betas, downgrade is also allowed to certain versions.

Well, I'd still prefer earlier "full access", but it seems that I'll have to live with this... Downgrade and BW-test is the minimum that I want always enabled. I don't use other disabled things, so I'm fine, but I still see no point in disabling things in already deployed equipment.

infabo · Thu Nov 21, 2024 2:43 pm

How do I configure new forwarders in my DNS server settings?
Please check the documentation:
https://help.mikrotik.com/docs/spaces/R ... 748767/DNS

Direct-Link to section: https://help.mikrotik.com/docs/spaces/R ... terOS7.17)

leoktv · Thu Nov 21, 2024 5:45 pm

P.S: we have listened to the community and have walked back the device mode defaults. Btest is now allowed on the advanced mode template which is the same template that will be used after upgrade from previous versions if you did not change it manually. Also, to those who missed the previous betas, downgrade is also allowed to certain versions.

I have a question regarding the lockdown of routerboard part as you often need to update the bootloader and set auto upgrade. this is now locked!!!
all this settings should be able to change with tr-069 from local networks as a minimum

grusu · Thu Nov 21, 2024 6:53 pm

Hi,

smb client not working in version 7.17beta6.

akschu · Fri Nov 22, 2024 1:30 am

There is a DHCP bug in 7.17beta6 (and all earlier versions tested):

If you create a radius backed DHCP server and pass Framed-Route = 10.44.44.4/31, then when the dhcp lease is created the router correctly adds the route:

> /ip route/print where dst-address=10.44.44.4/31
Flags: D - DYNAMIC; A - ACTIVE; d - DHCP
Columns: DST-ADDRESS, GATEWAY, DISTANCE
    DST-ADDRESS    GATEWAY       DISTANCE
DAd 10.44.44.4/31  10.44.44.100         1

However, the route never again is removed until reboot. I can disable the dhcp server or let the lease expire but the route remains and because it’s dynamic, there is no way to remove it.

This is unusable, I need routes to be cleaned up otherwise I can’t assign them in radius.

Fri Nov 22, 2024 4:17 pm

There is a DHCP bug in 7.17beta6 (and all earlier versions tested):

If you create a radius backed DHCP server and pass Framed-Route = 10.44.44.4/31, then when the dhcp lease is created the router correctly adds the route:
Code: Select all
> /ip route/print where dst-address=10.44.44.4/31
Flags: D - DYNAMIC; A - ACTIVE; d - DHCP
Columns: DST-ADDRESS, GATEWAY, DISTANCE
    DST-ADDRESS    GATEWAY       DISTANCE
DAd 10.44.44.4/31  10.44.44.100         1
However, the route never again is removed until reboot. I can disable the dhcp server or let the lease expire but the route remains and because it’s dynamic, there is no way to remove it.

This is unusable, I need routes to be cleaned up otherwise I can’t assign them in radius.

I reported the same problem to Mikrotik after they initially added Framed-Route support for DHCP early in the RouterOS v6 lifecycle. It was resolved and we were using this in production for almost 10 years.

It's disappointing to see that this behaviour has regressed.

Your best bet to get this resolved is to log a support ticket via the Web Portal, or by emailing support@mikrotik.com

Fri Nov 22, 2024 6:14 pm

Version 7.17rc1 has been released.
viewtopic.php?t=212754