V7.17.2 [stable] is released!

[Dartmaul]

IKEv2 tunnels fail to establish after upgrading to 7.17 (between 7.17<->7.17 and 7.17<->7.16.2). However, 7.17 does establish IKEv2 with Huawei AR (same settings).
Rolling back to 7.16.2 does fix the issue.
Auth method is PSK, 7.17 peer sends “Delete” right after successful IKE_AUTH. Tested on both live RBs and GNS3 lab.

Am I the only one with this issue?

[nmt1900]

upgrade failed, free 9 kB of kernel disk space
First they have to figure out what does this message actually mean…

Maybe on some devices there is a separate partition for /boot ?
That used to be required/customary on some Linux filesystems or disk devices, to guarantee that the boot code was always within some area supported by the bootloader.
When for some reason the previous kernel version is not removed after upgrade, a next upgrade may be impossible.
(I know that issue from a server which was installed with a previous Debian version that by default created a “small” boot partition in certain circumstances)

On server-space it sounds quite logical, but here we have situation where some of same models succeed and some fail - while using same installation packages and sharing same architecture. It is hard to believe this has anything to do with userspace.

P. S. Even units with same hardware behave differently - hap ac2 with its’ 16 MB storage succeeds but RB450Gx4 with 512 MB storage fails while both have essentially same SoC

[vovan700i]

Ok, I have serious problem with DHCP client after upgrade to 7.17, as it drops default route on multiple type of devices (RB4011, SXTsq 5 ac). I experienced this on RCs and betas too. Routers creating autosupout.rif file after dropping def route. I try to figure out what triggers this issue.

Confirm, I have the same problem on RB5009. I’ve implemented a workaround script to trigger DHCP release once the obtained default route gets missing.

[mirolm]

I can confirm this - happened on my hEX Refresh too. Triggered a dhcp release and it went back to normal.

[oreggin]

Ok, I have serious problem with DHCP client after upgrade to 7.17, as it drops default route on multiple type of devices (RB4011, SXTsq 5 ac). I experienced this on RCs and betas too. Routers creating autosupout.rif file after dropping def route. I try to figure out what triggers this issue.

Confirm, I have the same problem on RB5009. I’ve implemented a workaround script to trigger DHCP release once the obtained default route gets missing.

It seems, it reinitializes all the IGPs after 5sec:

 2025-01-17 13:23:21 route,bgp,info JPoP_MTik1-IPv6-1 {l_addr: fc00::10:43:0:126, r_addr: fc00::10:7:255:255} Established
 2025-01-17 13:23:26 route,rip,info instance { 0 IP } created
 2025-01-17 13:23:26 route,rip,info instance { 0 IP6 } created
 2025-01-17 13:23:27 route,rip,info instance { 0 IP } interface { L2TP1 } created
 2025-01-17 13:23:27 route,rip,info instance { 0 IP6 } interface { L2TP1 } created
 2025-01-17 13:23:29 route,rip,info instance { 0 IP6 } interface { L2TP1 } neighbor fe80::eb47:9598:f0:28%*8 created
 2025-01-17 13:23:32 route,ospf,info instance { version: 3 router-id: 10.43.0.126 } created
 2025-01-17 13:23:32 route,ospf,info OSPFv3 { version: 3 router-id: 10.43.0.126 } area { 0.0.0.0 } created
 2025-01-17 13:23:32 route,ospf,info instance { version: 2 router-id: 10.43.0.126 } created
 2025-01-17 13:23:32 route,ospf,info OSPFv2 { version: 2 router-id: 10.43.0.126 } area { 0.0.0.0 } created

This is totally platform independent, experiencing on CHR too. If I add a static default then where forwarding works, where it doesn’t:

$ ping 10.43.0.126
PING 10.43.0.126 (10.43.0.126) 56(84) bytes of data.
64 bytes from 10.43.0.126: icmp_seq=11 ttl=60 time=10.5 ms
64 bytes from 10.43.0.126: icmp_seq=12 ttl=60 time=12.1 ms
64 bytes from 10.43.0.126: icmp_seq=13 ttl=60 time=10.6 ms
64 bytes from 10.43.0.126: icmp_seq=14 ttl=60 time=12.0 ms
64 bytes from 10.43.0.126: icmp_seq=15 ttl=60 time=10.3 ms
64 bytes from 10.43.0.126: icmp_seq=16 ttl=60 time=10.3 ms
64 bytes from 10.43.0.126: icmp_seq=17 ttl=60 time=12.1 ms
64 bytes from 10.43.0.126: icmp_seq=18 ttl=60 time=10.1 ms
64 bytes from 10.43.0.126: icmp_seq=19 ttl=60 time=9.82 ms
64 bytes from 10.43.0.126: icmp_seq=20 ttl=60 time=12.5 ms
64 bytes from 10.43.0.126: icmp_seq=21 ttl=60 time=15.8 ms
64 bytes from 10.43.0.126: icmp_seq=22 ttl=60 time=10.4 ms
64 bytes from 10.43.0.126: icmp_seq=23 ttl=60 time=10.2 ms
64 bytes from 10.43.0.126: icmp_seq=24 ttl=60 time=10.2 ms
64 bytes from 10.43.0.126: icmp_seq=25 ttl=60 time=11.6 ms
64 bytes from 10.43.0.126: icmp_seq=26 ttl=60 time=10.2 ms

64 bytes from 10.43.0.126: icmp_seq=75 ttl=60 time=8.75 ms
64 bytes from 10.43.0.126: icmp_seq=76 ttl=60 time=11.5 ms
64 bytes from 10.43.0.126: icmp_seq=77 ttl=60 time=10.0 ms
64 bytes from 10.43.0.126: icmp_seq=78 ttl=60 time=11.7 ms
64 bytes from 10.43.0.126: icmp_seq=79 ttl=60 time=10.8 ms
64 bytes from 10.43.0.126: icmp_seq=80 ttl=60 time=10.6 ms
64 bytes from 10.43.0.126: icmp_seq=81 ttl=60 time=10.8 ms
64 bytes from 10.43.0.126: icmp_seq=82 ttl=60 time=11.8 ms
64 bytes from 10.43.0.126: icmp_seq=83 ttl=60 time=12.2 ms
64 bytes from 10.43.0.126: icmp_seq=84 ttl=60 time=10.1 ms
64 bytes from 10.43.0.126: icmp_seq=85 ttl=60 time=10.5 ms
64 bytes from 10.43.0.126: icmp_seq=86 ttl=60 time=10.2 ms

^C
--- 10.43.0.126 ping statistics ---
201 packets transmitted, 28 received, 86.0696% packet loss, time 202355ms
rtt min/avg/max/mdev = 8.746/10.988/15.813/1.273 ms

[Guscht]

What is this field (Netwatch)?

[Belyache]

After updating from 7.16.2 to 7.17 yesterday the 5ghz wifi has stopped working.

I have a hAP ax^3 (C53UiG+5HPaxD2HPaxD). The wifi1 interface has all of the configurations that it previously had, but is offline.

Both wifi interfaces are members of Bridge1, Bridge ports show wifi2 (2ghz) is up and running and it transmitting its SSID, whereas wifi1 shows it is not up and is not broadcasting its SSID.

I’ve looked at the config pre-update and post-update and it has not changed.

I manually uploaded the wifi-qcom package hoping it was just corrupt, that didn’t help. I uninstalled the wifi-qcom package and then reinstalled it, no luck.

Any ideas?

Thanks,

Glenn

[wispmikrotik]

Hi,

Arggg it seems like there are too many bugs in this version …

[nmt1900]

While usual stable release may sometimes be beta-level quality, this endless polishing of device-mode produced a release of alpha-level quality if not even worse…

[Sit75]

It might be possible, it is related to some scenarios only. For example: majority of IPv6 traffic, heavy load, traffic handovers between 2,4 and 5 GHz bands, fast BSS transition according IEEE 802.11r etc. etc. If I would know, it would be excellent, but I don’t know root cause. Reality is that in my quite simple case and simple config always ending with not only Linux OOPS, but even kernel panic crash and restart with autosupout.rif generated.

All autosupout.rif had been provided to Mikrotik. And result was - nothing, it is fine, old HW, use “wireless.apk”. On the other hand “wirelles.apk” works fine. But in this case is big question, why Qualcomm native drivers on Qualcomm HW work so badly in specific cases? And it seems I am not alone. Majority of my connected devices are Apple products and there were more complains from other users about the usage, traffic fluctuation, sudden disconnections and reconnections etc.

I can´t confirm that there´s a general problem with wifi-qcom-ac.
There are 4 devices running since 50days without any memory leaks or other problems:
hc_438.jpg

[Sit75]

Thank you Deniss for your effort. I wanted not to be rude, but closing the tickets with kernel crashes without any solution makes me little bit angry. And not only here, in my job (mobile telco industry) too. :-)) Resources are in my case fine, I have 256MB RAM, not only 128MB. I am willing to test it, if you want.

We are working towards optimizing wireless-qcom-ac as we try to optimize other packages to be less resource heavy, but it is still a work in progress. As of this moment, wifi-qcom-ac is known and expected to take up more resources (including RAM) than legacy wireless drivers.

[msilcher]

I upgraded to 7.17 on my hAP ax2 and realized that the bridge ports are not shown as “hardware offloaded” anymore. This was always the case on previous versions. Bug?

P.S: Setting “detect interface list” (Detect Internet) to “none” doesn’t fix the issue.

[msilcher]

IKEv2 tunnels fail to establish after upgrading to 7.17 (between 7.17<->7.17 and 7.17<->7.16.2). However, 7.17 does establish IKEv2 with Huawei AR (same settings).
Rolling back to 7.16.2 does fix the issue.
Auth method is PSK, 7.17 peer sends “Delete” right after successful IKE_AUTH. Tested on both live RBs and GNS3 lab.

Am I the only one with this issue?

Using Mikrotik as spoke (IKEv2 + PSK) to a Cisco Router and it still works fine after upgrading to 7.17.

[Guscht]

Arggg it seems like there are too many bugs in this version …

Yeah and some random guy here dreamed THIS will be a long-term, because it took so long… LOL
This is a typical MT point-zero release, 3 steps forward and 5 back… The long-term is as far away as with the v7.0 release.

[OOJSPI]

The issue with WiFi password being shown upon entering HTTPS login screen (even though “Hidden/Hide” is ticked) is still there.

[t0mm13b]

Am going to wait it out, would not be surprised if 7.17.1 or .2 release come out shortly to fix up minor issues.

[Sit75]

Try to add wifi1 (5 GHz) on bridge manually. It might help.

After updating from 7.16.2 to 7.17 yesterday the 5ghz wifi has stopped working.

Both wifi interfaces are members of Bridge1, Bridge ports show wifi2 (2ghz) is up and running and it transmitting its SSID, whereas wifi1 shows it is not up and is not broadcasting its SSID.

[Belyache]

It continues to be “Offline”.

I reset the wifi1 interface and re-configured also, still nothing.

Try to add wifi1 (5 GHz) on bridge manually. It might help.

After updating from 7.16.2 to 7.17 yesterday the 5ghz wifi has stopped working.

Both wifi interfaces are members of Bridge1, Bridge ports show wifi2 (2ghz) is up and running and it transmitting its SSID, whereas wifi1 shows it is not up and is not broadcasting its SSID.

[infabo]

Arggg it seems like there are too many bugs in this version …

Yeah and some random guy here dreamed THIS will be a long-term, because it took so long… LOL
This is a typical MT point-zero release, 3 steps forward and 5 back… The long-term is as far away as with the v7.0 release.

This is because many people wait for the final release to pull the trigger: “omg!!! it broke my xyz”. instead of evaluating the testing releases ao Mikrotik can fix release specific issues before final version.

[victorbayas]

There is no superchannel in the new wifi-qcom(-ac) drivers, also there is no no_country_set. (BTW, superchannel was a mode, no_country_set was regulatory domain, so you’re doing wrong things in the first place.)

The router is probably kicking you back to a default of Latvia, which is at 17.

And yes, I’m also running my wifi as “United States” because of high TX power, despite being in the EU. Isn’t that great? But the only reason I have that is because I can’t remember which South American country is better Was it Panama?

What are you even talking about, its literary in changelog of 7.17 update:
) wifi-qcom - added Superchannel country profile;
And it does work for higher channels i just tried like 5500 and 5600 it runs max power and skips DFS check, just not for lower ones for some reason so it seams as a bug..

Superchannel is working great on my hAP ax3, no DFS and max TX power allowed by the hardware just had to limit the frequency to 5180-5805 and 2412-2462. Otherwise it may pick a channel out of the usable spectrum for most WiFi clients.