v7.17rc [testing] is released!

Tue Jan 07, 2025 4:59 pm

The issue with User-Manager and oversize UDP packet that I mentioned in post #236 viewtopic.php?t=212754#p1115736 is still present in 7.17.rc6.

Is anything mentioned about it in the release notes for that version ? I don't see it. Therefor it's logical the issue is still there.
It should be solved but it hasn't been mentioned as being fixed (yet).

CGGXANNX · Tue Jan 07, 2025 5:11 pm

Yeah, you are correct. But in the past, they have sometimes fixed things silently :).

Also, looking at the changelog, the only change mentioned that might be related is:

*) user-manager - improved stability;

pe1chl · Tue Jan 07, 2025 5:13 pm

Did you by chance upgrade the Unifi application to version 9.x? I see others reporting RADIUS problems for that version, unclear what the problem is.

Tue Jan 07, 2025 5:23 pm

You mentioned that the second fragment never appears on the device directly connected to RB5009 Ethernet port. It could be something related to RB5009 Ethernet or switch. Can you quickly test if disabling bridge HW offloading makes any difference (I assume you are using bridge)? Can you share supout.rif file and pcap files from the RB5009 to support?

CGGXANNX · Tue Jan 07, 2025 10:01 pm

Did you by chance upgrade the Unifi application to version 9.x? I see others reporting RADIUS problems for that version, unclear what the problem is.

No, I haven't upgraded to version 9 yet, still running 8.6.9. And it's unrelated to UniFi or the UniFi APs, because the tests showed the issue even when sending packets to normal Linux and Windows machines. And my next post will, I think, show that it's not even caused by User Manager, but something else inside RouterOS that has changed in 7.17.

CGGXANNX · Tue Jan 07, 2025 11:14 pm

You mentioned that the second fragment never appears on the device directly connected to RB5009 Ethernet port. It could be something related to RB5009 Ethernet or switch. Can you quickly test if disabling bridge HW offloading makes any difference (I assume you are using bridge)? Can you share supout.rif file and pcap files from the RB5009 to support?

I have disabled hardware offload on the bridge's ethernet ports on the RB5009 and the behavior was the same. But I have since made many more tests, and have found out that the problem is related to the size of the second fragment. Please note that the following test outcomes have been repeated with both hardware offload turned on and off, and with both tagged and untagged VLANs (my config doesn't use the native VLAN of the bridge interface):

I wanted to test whether the problem is solely caused by User Manager, or whether RouterOS 7.17 is unable to properly fragment UDP packets. At first, I tried Traffic Generator, but it doesn't seem to automatically fragment UDP packets. Luckily, there is another tool in RouterOS that allows sending UPD packets with arbitrary sizes, and that's the Traceroute tool in UDP mode (instead of ICMP). However, the Packer Size field doesn't allow any value larger than 1500. So, the next logical step is to reduce the MTU on the (VLAN) interfaces. At first, I reduced the MTU down to 1480, but the packets seem to be broken up at the 1476-byte mark anyway, so there is no difference between MTU 1480 and MTU 1476 for the following findings.

With the MTU set to 1480 (or 1476), I used Traceroute to send UPD packets to a Windows machine running Wireshark. Windows doesn't support UDP traceroute but that's not important because I only wanted to capture the incoming packets. By setting the traceroute Packet Size to 1482, I got the same fragmentation where the 2nd fragment has the same 40-byte frame size:

traceroute-1482-ros.png

And the exact same issue as the one with User Manager happened. After a while the Packet Sniffer showed a bunch of ICMP packets. On the Windows machine, Wireshark showed that the 40-byte frames never arrived, only the 1490-byte ones. And Windows sent the ICMP Fragment reassembly time exceeded responses.

traceroute-1482-win.png

But at this moment, with the MTU set to 1480, the same RADIUS authentication tests with eapol_test suceeded! Obviously, with smaller MTU the 2nd fragment got bigger. So I tried to increase the size of the traceroute packet to 1492:

traceroute-1492-ros.png

Packet sniffer showed the ethernet frame size of the 2nd fragment to be 50 bytes. This time there is no ICMP packets. And on the windows machine, all packets have arrived! But the 2nd fragments have a frame size of 56 bytes. With trailer inserted at the end.

traceroute-1492-win.png

Next, I tried to increase the traceroute packet size from 1482. At 1483 bytes, a 41-byte 2nd fragment was produced, but also disappeared and never arrived. At 1484 bytes however, just two bytes larger than 1482, the fragmentation worked, and the Windows machine could reassemble all the UDP packets:

traceroute-1484-ros.png

We can also see that the 2nd fragments are listed as having a 42-byte framesize on ROS, but were sent as 56-byte frames with 14-byte trailer:

traceroute-1484-win.png

When I changed the traceroute target to one UniFi AP, which runs Linux, the traceroute worked with packet size 1484 (because the AP understands UDP traceroute and can respond), but also failed with ICMP fragmentation timeout when the packet size was reduced to 1482 bytes.

traceroute-1484-ap.png

traceroute-1482-ap.png

It looks like RouterOS is unable to append a 15- or 16-byte trailer, so that the ethernet frame sent can reach the minimum allowed size? Am I unlucky that my certificate size somehow causes User Manager to produce UDP packets that cause fragmentation with the 40-byte second fragment (at MTU 1500)? Maybe I should try to add some junks into the different fields of the certificate to make it larger 🙃?

CGGXANNX · Tue Jan 07, 2025 11:50 pm

I just made some test with a hAP ac² running 7.16.2 using the normal bridge (no VLAN). With MTU set to 1480 and packer size 1482, sending UDP traceroute to an UniFi AP (at another location but with the same model and firmware) and there were no problems at all with the 40-byte fragment.

traceroute-1482-ap-7.16.2.png

CGGXANNX · Wed Jan 08, 2025 5:04 am

I went ahead and upgraded the hAP ac² to 7.17rc6. And now the bug is reproducible there too. With no configuration changes (MTU was 1480 same as with the 7.16.2 tests) the router can no longer send the 1482-byte traceroute to the same AP as from the post above.

traceroute-1482-hapac2.png

But 1484 worked:

traceroute-1484-hapac2.png

Which means it's definitely a bug introduced by 7.17, and is not restricted to the RB5009, and also regardless of VLAN configuration. The hAP ac² only has the standard bridge from defconf.

I just noticed that the command line allows entering packet size > 1500 bytes. Which means running the traceroute test with MTU 1500 is possible too. Here is the result which shows the problem when there are 6 extra bytes that need to be transferred:

traceroute-mtu1500-hapac2.png

All tests with packet size 1501-1507 failed. It worked for sizes <= 1500 and >= 1508.

pe1chl · Wed Jan 08, 2025 11:24 am

I have always wondered why the IP fragmentation code in network stacks splits a too-large packet into a maximal size packet and a small remainder... IMHO that only increases the risk that further fragmentation is required further down the path when another smaller MTU is encountered.
Back when I maintained IP network software I modified the fragmentation so that it splits the packet into fragments of about equal size, so a 1500 byte packet that has to go over a 1480 MTU link would not be split into 1480 and 20 but instead into 752 and 748 (the first fragment(s) have to be a multiple of 8 bytes in size).
That worked just fine and it is more efficient e.g. when further down the path the MTU is 1400 bytes. The two fragments can pass without further splitting, unlike in the commonly used method.
It would also have avoided the bug currently at hand, but of course that is not relevant.

Wed Jan 08, 2025 11:33 am

@CGGXANNX thanks for the details so far.

Can you test if disabling bridge dhcp-snooping fixes the issue?

You did not post your configuration export and I failed to reproduce the problem in our labs, but once I tried different bridge settings, the dhcp-snooping=yes caused the same behavior as you described, so I assume you have it enabled as well.

CGGXANNX · Wed Jan 08, 2025 11:53 am

Yes, I have DHCP Snooping enabled on both routers (because both support it with hardware offload still possible), IGMP snooping is not enabled. I just disabled DHCP Snooping on the RB5009 and now both the traceroute and the RADIUS authentication for WPA3 Enterprise are working. So the bug is definitely related to that feature 👍.

infabo · Wed Jan 08, 2025 12:12 pm

Don't get me wrong, I really appreciate the detailed debugging effort. I am 100% sure it helped to identify and reproduce the issue. Especially it made EdPa look into it.

But one remark; these statements were misleading:

I just made some test with a hAP ac² running 7.16.2 using the normal bridge (no VLAN).

The hAP ac² only has the standard bridge from defconf.

It implied that bridge settings were not modified from defconf.

But I am glad EdPa did not give up and identified the issue. Good job!

CGGXANNX · Wed Jan 08, 2025 12:28 pm

Sorry for the wordings. What I meant was that it was using the "bridge" interface (with the "defconf" comment still over it) and not an additional VLAN interface over it like on the RB5009, or a bridge that has been created from scratch like in the cases of a blank configuration. Of course, other settings have been changed, like, from the screenshots, the IP address range.

SXMU · Thu Jan 09, 2025 11:16 am

Hello! I need help from support - after upgrading from ros7.16.2 to 7.17rc6 i have loop reboot on my x86 machine. Just tried to change PC to other with same disk - still same problem. How can i solve this problem without reinstalling system(i dont want to loose my license)? Disk is Transcend DOM SATA 2GB
Photo of screen stuck:

mkx · Thu Jan 09, 2025 11:24 am

You could try to change some memory settings in BIOS regarding mapping memory of PCI peripherial devices ...
Another thing to try is to increase memory size on PC, the number says it needs a bit less than 4M of contiguous space (not sure if that's possible with your hardware).

But the error does seem weird to me, AFAIK 7.16.2 and 7.17rc are running same version of linux kernel and should thus behave very similarly in this aspect.

You may want to contact MT support via official support channels (e.g. e-mail to support@mikrotik.com), this forum is not one of them and there's no guarantee that some MT support staffer will notice your post.

fischerdouglas · Thu Jan 09, 2025 3:26 pm

With the MTU set to 1480 (or 1476), I used Traceroute to send UPD packets to a Windows machine running Wireshark. Windows doesn't support UDP traceroute but that's not important because I only wanted to capture the incoming packets. By setting the traceroute Packet Size to 1482, I got the same fragmentation where the 2nd fragment has the same 40-byte frame size:

And the exact same issue as the one with User Manager happened. After a while the Packet Sniffer showed a bunch of ICMP packets. On the Windows machine, Wireshark showed that the 40-byte frames never arrived, only the 1490-byte ones. And Windows sent the ICMP Fragment reassembly time exceeded responses.

But at this moment, with the MTU set to 1480, the same RADIUS authentication tests with eapol_test suceeded! Obviously, with smaller MTU the 2nd fragment got bigger. So I tried to increase the size of the traceroute packet to 1492:

Packet sniffer showed the ethernet frame size of the 2nd fragment to be 50 bytes. This time there is no ICMP packets. And on the windows machine, all packets have arrived! But the 2nd fragments have a frame size of 56 bytes. With trailer inserted at the end.

Next, I tried to increase the traceroute packet size from 1482. At 1483 bytes, a 41-byte 2nd fragment was produced, but also disappeared and never arrived. At 1484 bytes however, just two bytes larger than 1482, the fragmentation worked, and the Windows machine could reassemble all the UDP packets:

We can also see that the 2nd fragments are listed as having a 42-byte frame size on ROS, but were sent as 56-byte frames with 14-byte trailer:

When I changed the traceroute target to one UniFi AP, which runs Linux, the traceroute worked with packet size 1484 (because the AP understands UDP traceroute and can respond), but also failed with ICMP fragmentation timeout when the packet size was reduced to 1482 bytes.

It looks like RouterOS is unable to append a 15- or 16-byte trailer, so that the ethernet frame sent can reach the minimum allowed size? Am I unlucky that my certificate size somehow causes User Manager to produce UDP packets that cause fragmentation with the 40-byte second fragment (at MTU 1500)? Maybe I should try to add some junks into the different fields of the certificate to make it larger 🙃?

Please allow me to make 2 troubleshooting suggestions that may help to make clear where the cause of the issue is.
Clarification: I have no idea where the cause of the problem really lies. This is just a suggestion for how to approach the issue.

1) Try lowering the MTU to a VERY LOW value, such as 1300 bytes.
If this is the type of problem I imagine, this may force the UDP fragment headers to be well-formed. This is just a test/hypothesis.

2) Try to do the same test using IPv6 for Radius queries.
This changes many variables, from the IPv4-IPv6 protocol stack to the type of off-load hardware, to the MTU issue, which is better resolved in IPv6 than in IPv4.

These tests are not intended to definitively solve the problem, but rather to help build a truth-table of problem conditions and make it easier for the MikroTik team to find the cause of the problem.

CGGXANNX · Thu Jan 09, 2025 4:19 pm

Thanks, @fischerdouglas. From post #310 viewtopic.php?p=1118339#p1118102 above it looks like @EdPa from MikroTik was able to reproduce the bug with DHCP Snooping enabled. It's probably related to this change item:

*) bridge - fixed bridge packet transmit if dhcp-snooping is enabled (introduced in v7.17beta5);

Hopefully they will be able to fix it before the final version. For the moment I am temporarily disabling DHCP-Snooping on the router running User Manager as work-around.

CGGXANNX · Fri Jan 10, 2025 7:35 am

An interesting side effects of disabling DHCP-Snooping is that Fasttrack seems to be working again on my router. Since over 1.5 year my RB5009 has been running in an all-VLAN configuration. All 9 ports are in the main bridge with VLANs used for everything. The WAN port (sfp-sfpplus1) is part of the bridge and is an access port of a dummy VLAN (id 1000), with pppoe-out1 running over that VLAN. All ports have the H flag. @raimondsp from MikroTik wrote about such setups and said that it wastes a few CPU cycles, but not much:

viewtopic.php?p=1059009#p1058995

Everything works (except 1 thing) and the router is fast enough (maxed out my GPON line without problem at > 2.3Gbps download) and I like having all the ports connected to the switch chip managed by the bridge that maps directly to the switch chip, so I have been keeping that configuration for the past year and more.

What no longer worked since switching from sfp-sfpplus1-out-of-bridge to sfp-sfpplus1-in-bridge-as-access-port is that all the fasttrack counters no longer increased above 0. The counters in the dummy dynamic rules (with the special dummy rule to show fasttrack counters comment) all stayed at 0. Same for the fasttrack counters at the bottom of the IP -> Settings dialog. But the IPv4 Fasttrack Active checkbox on that Dialog is still checked. Also, most of the connections in the IP -> Firewall -> Connections table have the F-flag, with fasttrack in the status bar when viewing the details. But on the Statistic tabs of those connections, Orig./Repl. Fasttrack Bytes and Orig./Repl. Fasttrack Packets are always 0. So, I assumed that the special configuration caused some requirements for fasttrack to fail and fasttrack has become effectively useless. It didn't bother me because performance is still above my needs and the majority of my traffics are IPv6 anyway.

But after turning off DCHP-Snooping in the past couple of days, suddenly the fasttrack counters started showing positive numbers, at tens of GBytes now. And the fasttrack counters on the statistics tab of the individual connections now also have positive values. It looks like turning off DHCP-Snooping also triggered something that causes the fasttrack requirement to be fulfilled. I am not reporting this as a bug, only as an interesting anecdote 😊.

Fri Jan 10, 2025 11:37 am

Regarding fasttrack, it is expected behavior. Dhcp-snooping disables bridge fast-path which in turn affects the ability to fasttrack connections going over that bridge. See https://help.mikrotik.com/docs/spaces/R ... quirements

The issue with fragmented packet drop when dhcp-snooping is enabled will be fixed in the next rc release.

Fri Jan 10, 2025 11:42 am

Should be clearly mentioned in the dhcp-snooping option description and FastPath requirements:

Now it is not mentioned:

dhcp-snooping (yes | no; Default: no) Enables or disables DHCP Snooping on the bridge.

IPv4 FastTrack is active if the following conditions are met:

no mesh, metarouter interface configuration;
sniffer, torch, and traffic generator are not running;
"/tool mac-scan" is not actively used;
"/tool ip-scan" is not actively used;
FastPath and Route cache are enabled under IP/Settings (route cache condition does not apply to RouterOS v7 or newer);
bridge FastPath is enabled if a connection is going over the bridge interface;

rzirzi · Fri Jan 10, 2025 12:05 pm

With ROS 7.17rc6 i can't connect L2TP with PSK to MikroTik router CCR2116-12G-4S+.
I can connect to other MT routers with that verion, but NOT to CCR2116 with VLAN interfaces(see attached screenschot).
VLAN1- is WAN, VLAN3- LAN. CCR2116 is connected to CRS305 with SFF interfaces.

LOG from CCR2116:
respond new phase 1 (Identity Protection): 83.xxx.xxx.xxx[500]<=>37.47.xxx.xxx[8730]
ISAKMP-SA established 83.xxx.xxx.xxx[4500]-37.xxx.xxx.xxx[16146] spi:cc6366dae0274db6:4ef419c203705487
first L2TP UDP packet received from 37.xxx.xxx.xxx
first L2TP UDP packet received from 37.xxx.xxx.xxx
<37.xxx.xxx.xxx>: authentication failed: peer didn't respond to CHAP challenge
purging ISAKMP-SA 83.xxx.xxx.xxx[4500]<=>37.xxx.xxx.xxx[16146] spi=cc6366dae0274db6:4ef419c203705487.
ISAKMP-SA deleted 83.xxx.xxx.xxx[4500]-37.xxx.xxx.xxx[16146] spi:cc6366dae0274db6:4ef419c203705487 rekey:1

Please help. L2TP VPN is very important for me.

pe1chl · Fri Jan 10, 2025 12:11 pm

It could be considered a lesson "do not enable each and every feature just because it looks cool"...
DHCP snooping can be useful in large networks with access for guests and other BYOD equipment, but on a home network it really isn't worth the (potential) trouble.

Fri Jan 10, 2025 12:17 pm

It could be considered as a ">>monkey test<< lesson" -> "do enable each and every feature because it looks cool"...

infabo · Fri Jan 10, 2025 12:27 pm

I learned the "monkey test lesson" by enabling IGMP-snooping and multicast querier some months ago. It introduced extreme latency on my whole network I could not explain - just to finally determining these 2 bridge settings as the issue.

CGGXANNX · Fri Jan 10, 2025 12:36 pm

Regarding fasttrack, it is expected behavior. Dhcp-snooping disables bridge fast-path which in turn affects the ability to fasttrack connections going over that bridge. See https://help.mikrotik.com/docs/spaces/R ... quirements

Thanks. That's interesting because on the hAP ac² DHCP-Snooping (because it's supported with hardware offload when VLAN is not in used on that router) has been enabled over the same timespan (since 2023) and fasttrack has always been working on that router. I guess it depends on the switch chip.

Oh, and on the RB5009 it also worked with DHCP-Snooping enabled when sfp-sfpplus1 was outside of the bridge. The counter only stopped increasing after the move to the 9-port-bridge configuration.

pe1chl · Fri Jan 10, 2025 12:43 pm

I learned the "monkey test lesson" by enabling IGMP-snooping and multicast querier some months ago. It introduced extreme latency on my whole network I could not explain - just to finally determining these 2 bridge settings as the issue.

I configured IGMP snooping on our work network (switches and a CCR) in an effort to cut the multicast traffic, only to learn that the vast majority of multicast traffic is sent in the IP range that does not use IGMP snooping :-)
After it caused an issue, I removed it all. Probably only useful in networks that e.g. use video distribution using multicast.

For the DHCP issue, I use the RouterOS "dhcp alert" feature to send an alert message when a rogue DHCP server is detected.
I also use "add ARP for leases" and "ARP mode reply-only" to cut down on broadcast traffic and opportunities to spoof.

Fri Jan 10, 2025 12:47 pm

@CGGXANNX does your hap ac2 LAN/WAN interfaces are on same bridge, is the config same as RB5009? Depending on your setup (where WAN is not configured on bridge) fasttrack could be working in one direction, but not in the other. But it is getting out of scope, let's keep this discussion related to 7.17, please.

CGGXANNX · Fri Jan 10, 2025 12:52 pm

It could be considered a lesson "do not enable each and every feature just because it looks cool"...
DHCP snooping can be useful in large networks with access for guests and other BYOD equipment, but on a home network it really isn't worth the (potential) trouble.

Well, I only enabled the "features" when the hardware says that it supports them, and both switch chips "support" DHCP-Snooping. I've never enabled IGMP Snooping on the hAP ac² because it's not compatible with hardware offload.

But on the RB5009 since the beginning I have been unable to turn on the IGMP Snooping feature, and not only because of the VLANs. Turning it on and IPv6 RA/ND stop working. Although 7.17 is supposed to have a workaround for IPv6 multicast related to RA/ND, and did initially appear to work too. However, after about one week my devices in the LAN stopped getting prefix announcements after resuming from standby (it worked for a week), so IGMP Snooping is now disabled again. And it's a feature that I actually need (IPTV usage). For now, I have to run the TV streams over UPDXY (running in container).

@CGGXANNX does your hap ac2 LAN/WAN interfaces are on same bridge, is the config same as RB5009? Depending on your setup (where WAN is not configured on bridge) fasttrack could be working in one direction, but not in the other. But it is getting out of scope, let's keep this discussion related to 7.17, please.

The WAN is on ether1 and outside of the bridge (because I don't want to setup VLAN the hAP ac², that can't use Bridge VLAN Filtering with hardware offload). Thank you for the information.

mkx · Fri Jan 10, 2025 3:10 pm

... so IGMP Snooping is now disabled again. And it's a feature that I actually need (IPTV usage).

It depends. My ISP offers IPTV over tagged VLAN ... so I pass that VLAN only to required ports (connecting TV boxes). Even without IGMP snooping, only those few ports get active streams. Indeed all active streams (e.g. 3 streams in case when there are 3 active TV boxes) instead of only the required one ... but I don't care that much. The point is that in such environment, even without IGMP snooping normal devices don't get pestered with unneeded multicast streams.

pe1chl · Fri Jan 10, 2025 3:20 pm

But on the RB5009 since the beginning I have been unable to turn on the IGMP Snooping feature, and not only because of the VLANs. Turning it on and IPv6 RA/ND stop working.

I had such an issue for quite some time on one of my devices, a hAP ac2 used as a second AP in bridge mode, and at some point I discovered by accident that on that device "Use IP firewall" had been (sort of mistakingly) enabled, and the IPv6 firewall did not forward multicast frames.
That setting is quite hidden and it is "global for all bridges" while in most configurations today there is only one bridge.
It would be nice when IP firewalling on bridges was more controllable, i.e. it could be enabled per bridge or even per bridge VLAN, and possibly even custom chains to be used for the firewalling could be specified.

OOJSPI · Fri Jan 10, 2025 3:52 pm

WiFi password is unhidden by default in the latest version (when viewed with Firefox), even though box to hide it is ticked by default.

Fri Jan 10, 2025 5:05 pm

What's new in 7.17rc7 (2025-Jan-10 10:37):

!) webfig - redesigned HTML, styling and functionality (additional fixes);
*) bridge - fixed fragmented packet transmit when dhcp-snooping is enabled (introduced in v7.17beta6);
*) ptp - fixed packet tx/rx when enabling PTP on 1/2.5/100Gbps links for 98CX8410, 98DX8525, 98DX4310 switches (introduced in v7.16);
*) system - improved system stability for CRS520-4XS-16XQ (introduced in v7.17beta2);

un9edsda · Fri Jan 10, 2025 5:15 pm

Regarding fasttrack, it is expected behavior. Dhcp-snooping disables bridge fast-path which in turn affects the ability to fasttrack connections going over that bridge. See https://help.mikrotik.com/docs/spaces/R ... quirements

@EdPa is it despite that according to Bridge Hardware Offloading part of the documentation the devices with 88E6393X switch chip (such as the RB5009 models) support hardware offloading while using the "Bridge IGMP Snooping" and "Bridge DHCP Snooping" features of RouterOS?

massinia · Fri Jan 10, 2025 5:22 pm

@EdPa is there any chance that SUP-172111 will be fixed before the stable release?
hAP ac2 reboots itseft with SMB transfers also with 7.17rc7 (more info).
Thanks

osc86 · Fri Jan 10, 2025 7:49 pm

This fast* stuff getting disabled if condition x,y,z is met is slowly getting out of control. I wish there would be a warning inside Winbox, that clearly shows why fasttrack is currently disabled. Same applies to fastpath. Not to mention, that winbox still shows a fake ticked checkbox for these features, even though it is disabled / not working. Really confusing sometimes.

Paternot · Fri Jan 10, 2025 10:14 pm

Just to say: this rc is taking its time - and I love it!

Take 6 months if needed - but wait until its as (reported) "bug free" as possible !

S8T8 · Fri Jan 10, 2025 10:15 pm

Due to "keep this discussion related to 7.17" and the fact that this post will be locked soon, a moderator could please open new topic and move all the messages related to DHCP / IGMP Snooping?
Would be nice to have a clear statement from @MT Staff like sometimes @raimondsp does, what is affected, when should be used (router / switch / ap) etc.

dang21000 · Sat Jan 11, 2025 12:17 am

Just upgraded the lab to rc7 (2x 5009, + 4x ax3 + 1x crs310)... and still working :)

CGGXANNX · Sat Jan 11, 2025 2:26 am

*) bridge - fixed fragmented packet transmit when dhcp-snooping is enabled (introduced in v7.17beta6);

Thank you! I've tested and RADIUS (User Manager) is working again with my APs with DHCP-Snooping enabled. I also did the manual test with the different packet sizes on both routers and can no longer reproduce the issue.

It depends. My ISP offers IPTV over tagged VLAN ... so I pass that VLAN only to required ports (connecting TV boxes)...

With my ISP you normally have to pay a subscription for IPTV and get a TV-Box. But if you don't subscribe and pay nothing, the IPTV multicast streams with all the channels are still available on the ethernet connection that PPPoE uses, not in a separate VLAN, free of charge, you just don't get the physical TV-Box. People in my country just share the playlist file with the UDP multicast URLs of all the channels and I use that to watch the multicast streams on my Phone/Tablet/PC devices with VLC or MPC 😊 for free. Only the TV devices really require UDPXY. But with IGMP Snooping still not really working in 7.17rc, UDPXY is for now needed for the other devices too (but it introduces delay).

Due to "keep this discussion related to 7.17" and the fact that this post will be locked soon, a moderator could please open new topic and move all the messages related to DHCP / IGMP Snooping?
Would be nice to have a clear statement from @MT Staff like sometimes @raimondsp does, what is affected, when should be used (router / switch / ap) etc.

Yes, I second this. Because it just crossed my mind that, according to @EdPa fasttrack is unavailable due to fast path not being active on the bridge, and fast path is not active because of DHCP-Snooping, and it works when the WAN port is moved out of the bridge for traffics between WAN and LAN, because fasttrack does not need the bridge fast path functionality in that case, BUT! I my case WAN is over PPPoE, which means if I understand correctly, is CPU based and traffics between PPPoE and normal bridge/vlan is not contained within the bridge, and normally doesn't involve fast path at all.

So, if fasttrack is possible between PPPoE on ethernet port outside of bridge and the bridge, it should be possible between PPPoE on VLAN on bridge and the bridge too, because bridge fast path is not used in both cases?

I had such an issue for quite some time on one of my devices, a hAP ac2 used as a second AP in bridge mode, and at some point I discovered by accident that on that device "Use IP firewall" had been (sort of mistakingly) enabled, and the IPv6 firewall did not forward multicast frames.

On my routers I think the "Use IP Firewall" settings has never been active. I just checked again to make sure. Also, I regularly export the routers' config (and diff the changes between the exports), and a search showed that the setting has not been enabled in the archived config export files.

Amm0 · Sat Jan 11, 2025 2:43 am

With my ISP you normally have to pay a subscription for IPTV and get a TV-Box. But if you don't subscribe and pay nothing, the IPTV multicast streams with all the channels are still available on the ethernet connection that PPPoE uses, not in a separate VLAN, free of charge, you just don't get the physical TV-Box. People in my country just share the playlist file with the UDP multicast URLs of all the channels and I use that to watch the multicast streams on my Phone/Tablet/PC devices with VLC or MPC 😊 for free. Only the TV devices really require UDPXY. But with IGMP Snooping still not really working in 7.17rc, UDPXY is for now needed for the other devices too (but it introduces delay).

You may just need to add the firewall RTSP helper (via /ip/firewall/service-port/enable rtsp), if the multicast IPTV streams are on the WAN side & the IPTV is using RTSP. If the service is not using RTSP, well, than enabling helper is not going help. But the IPTV source may need the PPPoE IP address, not the local LAN address, in the SDP message used by RTSP - which is what the firewall service-port/helper will do. (And, given "7.17 focus" point... might be best to start a new thread with more details on the IPTV setup, sample playlist file, ROS config, etc....)

CGGXANNX · Sat Jan 11, 2025 2:50 am

You may just need to add the firewall RTSP helper (via /ip/firewall/service-port/enable rtsp), if the multicast IPTV streams are on the WAN side & the IPTV is using RTSP. If the service is not using RTSP, well, than enabling helper is not going help. But the IPTV source may need the PPPoE IP address, not the local LAN address, in the SDP message used by RTSP - which is what the firewall service-port/helper will do.

The URLs are all udp:// and not rtsp://. I am able to watch them on my devices too, with a normal IGMP Proxy setup. It's just that without IGMP Snooping, the packets of the streams are simultaneously sent to all the ports of the same VLAN, producing unnecessary traffics. UDPXY solves this but with delay.

rzirzi · Sat Jan 11, 2025 6:23 am

Now I'm sure, that L2TP VPN with IPSEC is boken on ROS 7.17X. After many tests, config changes, downgrade to ROS 7.17rc3 - nothing helped. After downgrade to ROS 7.16.2 (on CCR2116) - it works like a charm!!! (L2TP with IPSEC).
MikroTik team - please repair that problem, SUP-176062

oreggin · Sat Jan 11, 2025 9:07 am

RoSv7.17RC3. SSTP doesn't work with ciphers=aes256-gcm-sha384. If I change back to ciphers=aes256-sha it works again.
Other relevant configs:

verify-server-certificate=yes verify-server-address-from-certificate=no authentication=mschap2 pfs=required tls-version=only-1.2 add-sni=no

Edit: SSTP works with ciphers=aes256-gcm-sha384 on v7.16.x

[oreggin@rtr1.xxxxxx] > interface/sstp-client/monitor 1
               status: connected
               uptime: 1m31s
             encoding: AES256-GCM
                  mtu: 1378
        local-address: 10.1.1.16
       remote-address: 10.1.1.10
   local-ipv6-address: fe80::29ab:d5a4:0:1a
  remote-ipv6-address: fe80::66d5:fa33:f0:6f6c

Valerio5000 · Sun Jan 12, 2025 12:22 pm

@EdPa is there any chance that SUP-172111 will be fixed before the stable release?
hAP ac2 reboots itseft with SMB transfers also with 7.17rc7 (more info).
Thanks

After a month they closed my ticket saying that AC2 with the wifi-qcom-ac driver does not have the hardware to support even a transfer via SMB, the only solution is to use the legacy wifi driver.

Valerio5000 · Sun Jan 12, 2025 12:24 pm

I'm noticing a strange thing, AC2 with 7.17 Rc7 can't ping any external IP like the classic 8.8.8.8 or 1.1.1.1. The internal IPs work but the external ones are no way. I haven't touched anything at the firewall level in the last few months. I'm talking about "tools>ping"

massinia · Sun Jan 12, 2025 12:28 pm

@EdPa is there any chance that SUP-172111 will be fixed before the stable release?
hAP ac2 reboots itseft with SMB transfers also with 7.17rc7 (more info).
Thanks
After a month they closed my ticket saying that AC2 with the wifi-qcom-ac driver does not have the hardware to support even a transfer via SMB, the only solution is to use the legacy wifi driver.

I use the legacy wifi driver but at this point I expect the same response from MikroTik.

With 7.16.2 it works fine... incredible.

massinia · Sun Jan 12, 2025 12:31 pm

I'm noticing a strange thing, AC2 with 7.17 Rc7 can't ping any external IP like the classic 8.8.8.8 or 1.1.1.1. The internal IPs work but the external ones are no way. I haven't touched anything at the firewall level in the last few months. I'm talking about "tools>ping"

ping.png

It works for me, you should open a new thread with your configuration

Atmis · Sun Jan 12, 2025 6:00 pm

i

Before 7.15, there were stability issues with some SFP ONU sticks and CRS305. (Suddenly, TX Power was showing -40.0dBm with FS.com GPON-ONU-34-20 BI).
Issue was fixed in 7.15 (* sfp - improved "sfp-tx-power" value monitoring in certain cases;)
I have updated my CRS305 to 7.17RC2 (firmware upgrade too) and the issue is back (4 crashes in few days, after months of stability).
I have reopened the original ticket on support side.

Issue is still present with 7.17rc7, while 7.16 is rock stable for months on my clone installation. Clearly a regression here (SUP-141528).

PS : Why the forum is showing a total post of 1 for me, when I have posted at least 5 messages already ? 😊

merkkg · Mon Jan 13, 2025 9:12 am

Can we get v7.17 out the door and move to v7.18 beta so we can see what's new..... this version dragging now.

I do appreciate stability and rigorous testing but I also want movement and new features as there are stuff I'm waiting for which may or may not be in next version.

mkx · Mon Jan 13, 2025 9:21 am

Can we get v7.17 out the door and move to v7.18 beta so we can see what's new..... this version dragging now.

I do appreciate stability and rigorous testing but I also want movement and new features as there are stuff I'm waiting for which may or may not be in next version.

A counter proposal: can we make one version actually stable and suitable for long-term use (even if it's not officially declared as such)? I'm sick of using beta-quality software on my devices since a few years ago. 7.17 seems to be heading in right direction and a few more weeks won't make lots of change.

Larsa · Mon Jan 13, 2025 9:28 am

Completely agree. I don't see the point of rushing things for the sake of it!

merkkg · Mon Jan 13, 2025 9:34 am

well it seems we have 2 groups of people... 1 that needs specific features which is only possible in new versions and other group that has all they need and just want stability.... there is no right answer here...

Mon Jan 13, 2025 9:42 am

A bird in hand is better than two in the bush.

Larsa · Mon Jan 13, 2025 9:45 am

@merkkg - If you’ve got an important business case, you can ask support for a special custom patch to test in the meantime. If you’re just eager for new features, it’s probably better to wait for a stable version.

merkkg · Mon Jan 13, 2025 9:49 am

@merkkg - If you’ve got an important business case, you can ask support for a special custom patch to test in the meantime. If you’re just “eager” for new features, it’s probably better to wait for a stable version.

I'm looking for a very specific feature, but as there is no roadmap I have no clue when it will come... for all I know it will come in v7.25.... or v7.40

Mon Jan 13, 2025 9:56 am

So start a new topic, ask a question and then push Mikrotik Team to implement the funcionality you want.

CGGXANNX · Mon Jan 13, 2025 10:41 am

Maybe they can release a 7.16.3 version with the following changes backported, and mark it as "extra stable before device mode change" version?

*) arm64 - fixed for bare-metal servers to be able to access more than 2GB RAM;
*) chr/arm64 - fixed kernel crypto use without crypto extensions for RPi CM4;
*) dhcpv6-client - improved system stability when DHCPv6 client is enabled on non-existing interface;
*) ethernet - improved interface stability for RB4011 devices;
*) ethernet - improved stability after reboot for Chateau PRO ax;
*) ethernet - improved system stability for CCR2004-1G-2XS-PCIe device;
*) fetch - fixed certificate check when provided hostname is IP address;
*) fetch - fixed large file (over 4GB) fetch in HTTP/HTTPS mode;
*) log - fixed e-mail logging (introduced in v7.16);
*) macvlan - improved error when trying to create new interface on already busy parent interface;
*) macvlan - updated driver;
*) ptp - fixed packet tx/rx when enabling PTP on 1/2.5/100Gbps links for 98CX8410, 98DX8525, 98DX4310 switches (introduced in v7.16);
*) routerboot - fixed boot MAC for devices with Alpine CPU ("/system routerboard upgrade" required);
*) routerboot - fixed boot MAC for MIPSBE CRS3xx and CRS5xx switches ("/system routerboard upgrade" required);
*) sfp - fixed 1Gbps supported rate for RB960 and RB962 devices;
*) sfp - fixed linking with 1Gbps optical modules with "combo-mode=sfp" configuration for CRS312 device;
*) switch - fixed a potential issue with packet corruption caused by incorrect switch initialization on CRS3xx/5xx devices;
*) switch - fixed L2MTU for 25Gbps ports;
*) switch - fixed RSPAN error message when using mirror-target=cpu;
*) switch - fixed rule disable in certain cases for 98DX224S, 98DX226S, and 98DX3236 switch chips;
*) switch - fixed storm-rate accuracy on 98DX224S, 98DX226S, and 98DX3236 switch chips;
*) x86 - Realtek r8169 updated driver;
*) zerotier - added debug logging;
*) zerotier - do not show default settings in export;
*) zerotier - upgraded to version 1.14.0;

Some probably small fixes (nothing that requires the big modifications made to bridge, dhcpv6 server, lte, wifi, or device mode) + device/platform specific fixes + some upgrade with external dependencies (driver/module upgrade). I personally would have not upgraded to 7.17rc if I didn't encounter the dhcpv6-client bug that was fixed by item #3.

pe1chl · Mon Jan 13, 2025 11:45 am

well it seems we have 2 groups of people... 1 that needs specific features which is only possible in new versions and other group that has all they need and just want stability.... there is no right answer here...

Then there is people caught in the middle. We upgraded all our routers to 7.16(.x) and since then we have BGP issues.
In 7.17 there is no fix in BGP whatsoever, so we will of course skip that version (not worth the device-mode trouble).
But I would like it when it gets released and the 7.18beta versions start appearing with again hope for BGP fixes.

This night our internet connection failed but the backup via LTE (auto switched using BGP), which worked perfectly at least until 7.12 or 7.15, don't remember exactly, again failed to take over. That is because prefixes at lower preference are not in the table.
The users suffer from that and I don't like that.

un9edsda · Mon Jan 13, 2025 11:50 am

Can we get v7.17 out the door and move to v7.18 beta so we can see what's new..... this version dragging now.

I do appreciate stability and rigorous testing but I also want movement and new features as there are stuff I'm waiting for which may or may not be in next version.

One new feature which is expected to be in 7.18, is /31 address support according to the Routing Protocol Overview part of the documentation.

Mon Jan 13, 2025 11:56 am

RoSv7.17RC3. SSTP doesn't work with ciphers=aes256-gcm-sha384. If I change back to ciphers=aes256-sha it works again.
Other relevant configs:
Code: Select all
verify-server-certificate=yes verify-server-address-from-certificate=no authentication=mschap2 pfs=required tls-version=only-1.2 add-sni=no
Edit: SSTP works with ciphers=aes256-gcm-sha384 on v7.16.x
Code: Select all
[oreggin@rtr1.xxxxxx] > interface/sstp-client/monitor 1
               status: connected
               uptime: 1m31s
             encoding: AES256-GCM
                  mtu: 1378
        local-address: 10.1.1.16
       remote-address: 10.1.1.10
   local-ipv6-address: fe80::29ab:d5a4:0:1a
  remote-ipv6-address: fe80::66d5:fa33:f0:6f6c

Could you please send us your supout rif file. Seems something missing here, as this works for us.

pe1chl · Mon Jan 13, 2025 11:58 am

@oskarsk is there anyone working on the BGP issues at the moment?

fischerdouglas · Mon Jan 13, 2025 1:18 pm

Based solely on the weak statistics from my vague memory, every time an RC greater than 5 appears on the sly on a Friday with few changes, and without any mention of the bugs declared in the RC thread on the Forum, it is almost certain that a Stable will appear ignoring the mentioned bugs.

Just to say: this rc is taking its time - and I love it!

Take 6 months if needed - but wait until its as (reported) "bug free" as possible !

What's new in 7.17rc7 (2025-Jan-10 10:37):

!) webfig - redesigned HTML, styling and functionality (additional fixes);
*) bridge - fixed fragmented packet transmit when dhcp-snooping is enabled (introduced in v7.17beta6);
*) ptp - fixed packet tx/rx when enabling PTP on 1/2.5/100Gbps links for 98CX8410, 98DX8525, 98DX4310 switches (introduced in v7.16);
*) system - improved system stability for CRS520-4XS-16XQ (introduced in v7.17beta2);

oreggin · Mon Jan 13, 2025 1:44 pm

RoSv7.17RC3. SSTP doesn't work with ciphers=aes256-gcm-sha384. If I change back to ciphers=aes256-sha it works again.
Other relevant configs:
Code: Select all
verify-server-certificate=yes verify-server-address-from-certificate=no authentication=mschap2 pfs=required tls-version=only-1.2 add-sni=no
Edit: SSTP works with ciphers=aes256-gcm-sha384 on v7.16.x
Code: Select all
[oreggin@rtr1.xxxxxx] > interface/sstp-client/monitor 1
               status: connected
               uptime: 1m31s
             encoding: AES256-GCM
                  mtu: 1378
        local-address: 10.1.1.16
       remote-address: 10.1.1.10
   local-ipv6-address: fe80::29ab:d5a4:0:1a
  remote-ipv6-address: fe80::66d5:fa33:f0:6f6c
Could you please send us your supout rif file. Seems something missing here, as this works for us.

Sure, I sent (SUP-176227).
Thanks!

ruijzhan · Mon Jan 13, 2025 2:16 pm

When I tried upgrading my RB450Gx4 router to the latest 7.17rc version, it restarted but remained on 7.16. The first log entry stated: "Upgrade failed, free 9 kB of kernel disk space." My router has over 400MB of free disk space, and despite searching extensively online, I couldn’t find anyone else encountering this error on RouterOS.

oreggin · Mon Jan 13, 2025 3:17 pm

When I tried upgrading my RB450Gx4 router to the latest 7.17rc version, it restarted but remained on 7.16. The first log entry stated: "Upgrade failed, free 9 kB of kernel disk space." My router has over 400MB of free disk space, and despite searching extensively online, I couldn’t find anyone else encountering this error on RouterOS.

If you would like to upgrade to 7.17, maybe you should make a full backup and try netinstall. It should repartition the flash on the router for proper partition sizes.

infabo · Mon Jan 13, 2025 3:29 pm

@ruijzhan how does your partitioning look like? Better to discuss this further in a dedicated topic or contact Mikrotik support.

Jotne · Mon Jan 13, 2025 3:51 pm

Based solely on the weak statistics from my vague memory, every time an RC greater than 5 appears on the sly on a Friday with few changes, and without any mention of the bugs declared in the RC thread on the Forum, it is almost certain that a Stable will appear ignoring the mentioned bugs.

Based on facts. Here is the latest RC version before release with number of changes and day of week when it was released.
Not that many RC has passed version 5 :)

version	count	day_of_week
7.9rc5	3	Fri
7.8rc3	1	Mon
7.7rc5	4	Wed
7.6rc3	2	Fri
7.5rc2	1	Thu
7.4rc2	8	Thu
7.3rc2	3	Thu
7.2rc7	1	Wed
7.17rc7	4	Fri
7.16rc5	5	Fri
7.15rc5	4	Tue
7.14rc4	2	Wed
7.13rc4	6	Tue
7.12rc6	1	Mon
7.11rc4	4	Sun
7.10rc6	4	Tue
7.1rc6	18	Thu
6.49rc2	14	Tue

bbs2web · Mon Jan 13, 2025 3:58 pm

We have a problem with DHCP snooping dropping packets on 7.17rc1 that was only reported now, I see a change log entry for 7.17rc7 which talks about DHCP snooping fragmenting packets which doesn't exactly match our use case.

PS: Everything works when we turn DHCP snooping off but turning it back on again caused the console session to crash, the session couldn't continue and the switch eventually rebooted.

Will upgrade to 7.17rc7 after 5:30pm today (in under 2 hours) and will test again.

Switches: CRS354-48G-4S+2Q+

Port personality is QinQ:

/interface bridge
add admin-mac=E1:E1:E1:E1:E1:E1 auto-mac=no dhcp-snooping=yes name=bridge priority=0x5000 vlan-filtering=yes
/interface bridge port
<snip>
add bridge=bridge edge=yes interface=ether35 pvid=10 restricted-role=yes tag-stacking=yes trusted=yes

PS: Previously on 7.16.x the port would still transmit DHCP relay packets even though trusted=no

ruijzhan · Mon Jan 13, 2025 4:28 pm

@ruijzhan how does your partitioning look like? Better to discuss this further in a dedicated topic or contact Mikrotik support.

Hello, please see the output below:

[admin@RB450Gx4] > /partitions/print
Flags: A - ACTIVE; R - RUNNING
Columns: NAME, FALLBACK-TO, VERSION, SIZE
# NAME FALLBACK-TO VERSION SIZE
0 AR part0 next RouterOS v7.16.2 2024-11-26 12:09:40 512MiB

pe1chl · Mon Jan 13, 2025 4:38 pm

/interface bridge
add admin-mac=E1:E1:E1:E1:E1:E1

Your admin-MAC is invalid!
The lower bit of the first byte must be zero.

oreggin · Mon Jan 13, 2025 5:01 pm

Code: Select all
/interface bridge
add admin-mac=E1:E1:E1:E1:E1:E1
Your admin-MAC is invalid!
The lower bit of the first byte must be zero.

Good catch! This is a multicast MAC address. The first octet of the MAC address must be even. Odds are Multicast MACs.
https://en.wikipedia.org/wiki/MAC_address

bbs2web · Mon Jan 13, 2025 5:33 pm

Herewith confirmation that the problem persists with 7.17rc7

DHCP Snooping eats DHCP relay packets although the port is marked as trusted. Upgraded to 7.17rc7, then upgraded RouterBOOT and rebooted a 2nd time before testing.

PS: The E1:E1...E1 mac address was me scrubbing the info on the public post.

ruijzhan · Mon Jan 13, 2025 5:54 pm

@ruijzhan how does your partitioning look like? Better to discuss this further in a dedicated topic or contact Mikrotik support.

I tried a netinstall it worked. thank you

buset1974 · Mon Jan 13, 2025 6:27 pm

waiting for this
viewtopic.php?t=213301

This is a important BGP bugs, it s not a new feature, its a bug, i dont think we need to wait new major version to fix this.

pe1chl · Mon Jan 13, 2025 7:44 pm

Well, there are even bugs in the basic BGP function, confirmed by others and some by MikroTik too:
- when a BGP session closes, at random some other (or all) session closes and has to be re-opened
- when a BGP session is established, no routes are exchanged until the keepalive timer elapses for the first time
- when there are multiple sessions between the same peers (e.g. over a GRE tunnel and a L2TP tunnel), at random the prefixes are not installed in the routing table for one of the sessions
These bugs were all introduced in the 7.16 version or shortly before. It used to work OK.
But the expected fix in 7.17 does not seem to happen...

fischerdouglas · Mon Jan 13, 2025 8:01 pm

Based on facts. Here is the latest RC version before release with number of changes and day of week when it was released.
Not that many RC has passed version 5 :)

Yep! You are right...
Probably my metrics are not good.

But my spider-sense tells-me that we will see a 7.17 stable born in forceps, without correcting issues mentioned by user in this thread, very soon.
Probably affected by the SNR on device-mode-thing.

fedorovic · Tue Jan 14, 2025 12:08 am

Superchannel can't be set.
On RB4011 (wifi-qcom-ac), Superchannel isn't possible to set: "failed to set country".

Tue Jan 14, 2025 6:41 am

rzirzi, oreggin - Thank you for your reports. We have discovered that Alpine CPU ARM64 devices does not work with GCM AES encryption. We are working on a fix.

rzirzi · Tue Jan 14, 2025 9:03 am

rzirzi, oreggin - Thank you for your reports. We have discovered that Alpine CPU ARM64 devices does not work with GCM AES encryption. We are working on a fix.

Thank You. It's very good information, that You have found the problem and are working on it! :)

bbs2web · Tue Jan 14, 2025 9:59 am

Just re-iterating that 7.17rc7 has a problem on at least CRS354-48G-4S+2Q+, whereby DHCP relay packets are dropped although the bridge port is marked as trusted.

The port is a QinQ VLAN stacking port, not sure if this plays a role in the behaviour.

/interface bridge
add admin-mac=DC:2C:6E:D2:AF:4B auto-mac=no dhcp-snooping=yes name=bridge priority=0x5000 vlan-filtering=yes
/interface bridge port
<snip>
add bridge=bridge edge=yes interface=ether35 pvid=10 restricted-role=yes tag-stacking=yes trusted=yes

PS: I had previously scrubbed the MAC as E1:E1:E1:E1:E1:E1

NB: Have logged this as SUP-176308, where the supout.rif file was provided

massinia · Tue Jan 14, 2025 1:36 pm

@EdPa is there any chance that SUP-172111 will be fixed before the stable release?
hAP ac2 reboots itseft with SMB transfers also with 7.17rc7 (more info).
Thanks

Unfortunately I confirm that it is due to a hardware limit (low RAM) of the hAP ac2 and not a problem of ROS 7.17.
SMB works perfectly by disabling adlist and containers that could use a lot of RAM.
Thanks to MikroTik support for the help and patience.

oreggin · Tue Jan 14, 2025 2:57 pm

rzirzi, oreggin - Thank you for your reports. We have discovered that Alpine CPU ARM64 devices does not work with GCM AES encryption. We are working on a fix.

Thanks strods! However in RB4011 there is an AL21400 32bit SoC. I hope it will be fixed too ;-)

Ullinator · Tue Jan 14, 2025 4:08 pm

I did just a few minutes ago the update from 7.17rc2 to rc3 and again (see SUP-172313) the names for the internal disks were changed.
Now with every reboot the names between disk1 and disk2 switches….
sata1 and sata2 flip their names with every reboot…..
You can see it in the screenshots.

Before reboot:
before reboot.jpg
...and after reboot:
after reboot.jpg

Still not fixed, even with the RC7 the exact same behaviour.
In my ticket (SUP-172313) unfortunatly since Dec. 11 no update....I hope it will be fixed before it´s marked as "stable" :-/

Tue Jan 14, 2025 4:23 pm

@bbs2web, thanks for letting us know.

We have reproduced the issue and working on a fix. However, the root cause is not specifically related to ROS 7.17, so a fix will likely not be included in this version.

armandfumal · Wed Jan 15, 2025 12:27 am

even 7.17.rc7....
still not working....

7.17.rc3

still not working.
Profile designer is make json file on disk but no more usable by winbox to assign to user group ou web interface, the profile is not listed after creation.

7.17rc2

Making skin with Skin Designer, save it, jason file present in the disk skin directory, but in user group cannot see it.
Even if I try to edit in skin designer, i cannot read it because not present in drop box...
seems system not load existing skin...

nichky · Wed Jan 15, 2025 12:37 am

we need VRF in to netwatch

pe1chl · Wed Jan 15, 2025 11:51 am

@EdPa is there any chance that SUP-172111 will be fixed before the stable release?
hAP ac2 reboots itseft with SMB transfers also with 7.17rc7 (more info).
Thanks
Unfortunately I confirm that it is due to a hardware limit (low RAM) of the hAP ac2 and not a problem of ROS 7.17.
SMB works perfectly by disabling adlist and containers that could use a lot of RAM.
Thanks to MikroTik support for the help and patience.

Well, frankly the hAP ac2 is a low-end device. You are just expecting too much from it.
There even was a time period where it could barely run RouterOS v7 (and be updated), because of the extreme shortage of flash space.
That has been cured (for now), but still I think you should see this as a low-end home router and access point, not as the central piece of your datacenter-like IP infrastructure.
When you have bought that and got excited about RouterOS possibilities, consider buying a more powerful device (maybe RB5009) for that, and continue to use it as a WiFi AP. Or maybe a hAP ax3 when you really want to combine router and AP.

pe1chl · Wed Jan 15, 2025 12:06 pm

I would like to have logging of state changes of routes with "check-gateway".
I.e. when the state of these routes changes (up to down or down to up) a message is logged with at least the dst-address, gateway, and routing-table.

Wed Jan 15, 2025 3:51 pm

What's new in 7.17rc8 (2025-Jan-15 08:19):

!) webfig - redesigned HTML, styling and functionality (additional fixes);
*) system - fixed crypto for Alpine CPUs (introduced in v7.17beta1);

fischerdouglas · Wed Jan 15, 2025 4:04 pm

we need VRF in to netwatch

It has already existed for a while!

Properties
Sub-menu: /tool/netwatch

host (Default:"")
The IP address of the server to be probed. Formats:

- ipv4

- ipv4@vrf

- ipv6

- ipv6@vrf

- ipv6-linklocal%interface

- domain name (for type=dns)

You should take a look at confluence of MikroTik and do a search...
https://help.mikrotik.com/docs/spaces/R ... Properties

fischerdouglas · Wed Jan 15, 2025 5:04 pm

What's new in 7.17rc8 (2025-Jan-15 08:19):

!) webfig - redesigned HTML, styling and functionality (additional fixes);
*) system - fixed crypto for Alpine CPUs (introduced in v7.17beta1);

Once again, I will repeat:
I'm smelling a "If we say it is stable, it is stable! The reported issues do not matter!"

I hope I'm wrong.

wispmikrotik · Wed Jan 15, 2025 5:47 pm

Hi,

Mikrotik when will we see the stable v7.17 version? We need certain changes/improvements in ipsec applied in v7.17.

Regards,

Wed Jan 15, 2025 6:08 pm

To which issue/s introduced in v7.17 do you refer to?

What's new in 7.17rc8 (2025-Jan-15 08:19):

!) webfig - redesigned HTML, styling and functionality (additional fixes);
*) system - fixed crypto for Alpine CPUs (introduced in v7.17beta1);
Once again, I will repeat:
I'm smelling a "If we say it is stable, it is stable! The reported issues do not matter!"

I hope I'm wrong.

sirbryan · Thu Jan 16, 2025 7:33 am

But I would like it when it gets released and the 7.18beta versions start appearing with again hope for BGP fixes.

This night our internet connection failed but the backup via LTE (auto switched using BGP), which worked perfectly at least until 7.12 or 7.15, don't remember exactly, again failed to take over. That is because prefixes at lower preference are not in the table.
The users suffer from that and I don't like that.

I backed my most problematic router off from 7.16.2 to 7.15.3 and the BGP problems seem to have stopped. I saw some appear on other routers due to a bouncing session due to faulty BFD, and so I anticipate moving them all to 7.15.3 (BGP cores and reflectors).

rzirzi · Thu Jan 16, 2025 9:18 am

What's new in 7.17rc8 (2025-Jan-15 08:19):

!) webfig - redesigned HTML, styling and functionality (additional fixes);
*) system - fixed crypto for Alpine CPUs (introduced in v7.17beta1);

I confirm, that problem with L2TP on CCR2116 has been resolved. Now it works! :) - thank You MikroTik team!

pe1chl · Thu Jan 16, 2025 11:28 am

I backed my most problematic router off from 7.16.2 to 7.15.3 and the BGP problems seem to have stopped. I saw some appear on other routers due to a bouncing session due to faulty BFD, and so I anticipate moving them all to 7.15.3 (BGP cores and reflectors).

Thanks for confirming that! I was quite sure that it worked OK very shortly before upgrading to 7.16 but I did not remember at
what version. I had to upgrade our RB5009UPr+S+IN routers due to PoE issues, but I think that was an update pushed to the
PoE controllers and a downgrade may leave that in place. Fortunately I have a spare so I can try that.

Still I think it is a shame that there is total silence from MikroTik about the BGP issues, both on this topic and from support.
(I have an open ticket)

Valerio5000 · Thu Jan 16, 2025 11:44 am

Unfortunately I confirm that it is due to a hardware limit (low RAM) of the hAP ac2 and not a problem of ROS 7.17.
SMB works perfectly by disabling adlist and containers that could use a lot of RAM.
Thanks to MikroTik support for the help and patience.
Well, frankly the hAP ac2 is a low-end device. You are just expecting too much from it.
There even was a time period where it could barely run RouterOS v7 (and be updated), because of the extreme shortage of flash space.
That has been cured (for now), but still I think you should see this as a low-end home router and access point, not as the central piece of your datacenter-like IP infrastructure.
When you have bought that and got excited about RouterOS possibilities, consider buying a more powerful device (maybe RB5009) for that, and continue to use it as a WiFi AP. Or maybe a hAP ax3 when you really want to combine router and AP.

I can agree that AC2 is not a datacenter device but up to ROS 7.15.x the SMB transfer worked now the device goes into kernel panic if used together with the new wifi-qcom-ac drivers (I think I understood that with legacy drivers the problem does not occur correct?) it seems to me a serious bug especially because it is not reproduced anywhere not to use SMB and new drivers and it is not a good image if a stable version behaves like this. If Mikrotik makes it official then they should make sure that in WinBox-WebFig in case of presence of the wifi-qcom-ac driver the IP>SMB entry disappears because I repeat if a system goes into Kernel Panic without any notification from the manufacturer regarding an incompatibility, then it is a bug!

infabo · Thu Jan 16, 2025 11:46 am

I backed my most problematic router off from 7.16.2 to 7.15.3 and the BGP problems seem to have stopped. I saw some appear on other routers due to a bouncing session due to faulty BFD, and so I anticipate moving them all to 7.15.3 (BGP cores and reflectors).
Thanks for confirming that! I was quite sure that it worked OK very shortly before upgrading to 7.16 but I did not remember at
what version. I had to upgrade our RB5009UPr+S+IN routers due to PoE issues, but I think that was an update pushed to the
PoE controllers and a downgrade may leave that in place. Fortunately I have a spare so I can try that.

Still I think it is a shame that there is total silence from MikroTik about the BGP issues, both on this topic and from support.
(I have an open ticket)

I wouldn’t go as far as calling it a shame, but it is certainly irritating. Let’s hope for the best and that it gets fixed soon. Perhaps if someone affected can reliably reproduce the issue and submits a detailed bug report to support, it might help move things along?

nichky · Thu Jan 16, 2025 11:51 am

@fischerdouglas, thanks

CGGXANNX · Thu Jan 16, 2025 12:52 pm

I can agree that AC2 is not a datacenter device but up to ROS 7.15.x the SMB transfer worked now the device goes into kernel panic if used together with the new wifi-qcom-ac drivers (I think I understood that with legacy drivers the problem does not occur correct?) it seems to me a serious bug especially because it is not reproduced anywhere not to use SMB and new drivers and it is not a good image if a stable version behaves like this. If Mikrotik makes it official then they should make sure that in WinBox-WebFig in case of presence of the wifi-qcom-ac driver the IP>SMB entry disappears because I repeat if a system goes into Kernel Panic without any notification from the manufacturer regarding an incompatibility, then it is a bug!

They have recently updated the WiFi doc, it now warns that wifi-qcom-ac uses significant more RAM and is more resource-heavy:

https://help.mikrotik.com/docs/spaces/R ... edexamples

Valerio5000 · Thu Jan 16, 2025 12:57 pm

I can agree that AC2 is not a datacenter device but up to ROS 7.15.x the SMB transfer worked now the device goes into kernel panic if used together with the new wifi-qcom-ac drivers (I think I understood that with legacy drivers the problem does not occur correct?) it seems to me a serious bug especially because it is not reproduced anywhere not to use SMB and new drivers and it is not a good image if a stable version behaves like this. If Mikrotik makes it official then they should make sure that in WinBox-WebFig in case of presence of the wifi-qcom-ac driver the IP>SMB entry disappears because I repeat if a system goes into Kernel Panic without any notification from the manufacturer regarding an incompatibility, then it is a bug!

They have recently updated the WiFi doc, it now warns that wifi-qcom-ac uses significant more RAM and is more resource-heavy:

https://help.mikrotik.com/docs/spaces/R ... edexamples

We agree that they take up more RAM but then eliminate the SMB entry on these devices so that a stable version cannot go into Kernel Panic for functions that the manufacturer itself makes available, do you agree?

CGGXANNX · Thu Jan 16, 2025 1:03 pm

Well it may goes out of memory with SMB, but if wifi-qcom-ac really takes a large chunk of RAM, then OOM might also happen if you run a container (that worked fine with wireless), or if you use adlist with huge lists, etc... If they disable and hide SMB, then should they do that with container and adlist too?

Currently you have to explicitly remove wireless and install wifi-qcom-ac. It is assumed that you read the doc before doing that, and from now on, the doc has the warning about the RAM usage. If your router suffers from OOM, your first thought now would be to revert back to wireless.

infabo · Thu Jan 16, 2025 1:07 pm

We agree that they take up more RAM but then eliminate the SMB entry on these devices so that a stable version cannot go into Kernel Panic for functions that the manufacturer itself makes available, do you agree?

That is not how it works. But I agree with, Mikrotik could improve memory reporting so we get better insights on how the RAM is used/distributed by process. So to get the bigger picture.

pe1chl · Thu Jan 16, 2025 2:22 pm

Still I think it is a shame that there is total silence from MikroTik about the BGP issues, both on this topic and from support.
(I have an open ticket)
I wouldn’t go as far as calling it a shame, but it is certainly irritating. Let’s hope for the best and that it gets fixed soon. Perhaps if someone affected can reliably reproduce the issue and submits a detailed bug report to support, it might help move things along?

"hope it will be fixed" exists when there are entries in the changelog for beta versions, and replies to open tickets about the issue.
The current situation is that there are none of these. For me that does not trigger hope, it triggers the fear that the knowledgeable developer is
not available to fix the problems at the moment. Just like in the early v7 days, when open BGP problems (and lacking features) also received no
attention at all for quite some time.

Thu Jan 16, 2025 2:45 pm

That is the beauty and the curse of RouterOS - sky is the limit. But the "sky" here is the administrator, who should be aware that possibilities are endless, but hardware resources are not. If we remove features, then others can not use them in different combinations of services or even the same services under smaller load, etc.

We as the vendor do try to reduce usage, improve performance, etc. But it is not possible to make every feature use 0% CPU and 0 bits of RAM etc.

Ullinator · Thu Jan 16, 2025 3:01 pm

Strods, I would prefer a separation in different packages for all the services, like it is in ROS6.
Or is this no longer possible in ROS7?

Guscht · Thu Jan 16, 2025 3:25 pm

I was not happy to have a "all-in-one" ROSv7 package.
Because it is a long proven best practice to disable unused features. And with ROSv7 everything is installed/enabled by default.

+1 for a separation in different packages

infabo · Thu Jan 16, 2025 4:00 pm

That is the beauty and the curse of RouterOS - sky is the limit. But the "sky" here is the administrator

@strods I completely agree. But this administrator needs the right tools to troubleshoot and analyze. On a regular Linux system one would just start by using something like ps/htop. Then take a look at "/proc/meminfo". If necessary one could use Valgrind to analyze memory usage of specific application. But ROS does not offer such fine grained analytics as far as I am aware of. I only know of "/system/resources/print" to check "free memory" - but it does not even tell me how much of consumed memory is "shared" or "cached (like one can see on a Linux "free" command).

Thu Jan 16, 2025 4:00 pm

RouterOS v7.17 has been released
viewtopic.php?t=213941