v7.15.3 [stable] is released!

AX HW or older ARM AC with wave2 drivers?

Hap ax3

*) route - do not redistribute loopback address as connected route;

Good lord, why? Why would you do this?

You introduce loopbacks just long enough ago that a bunch of people will have started using them, the vast majority of them will have been configured to be redistributed, and now… they’re no longer part of “connected” routes? What are they if not connected? How do you envisage upgrading to this version if you’re already relying on loopbacks being redistributed? Who on earth asked for this when as far as I know every other vendor treats loopbacks as connected?

@PhilB, that’s exactly what I was thinking. Since v7.14 we finally have a real loopback interface, one release later it’s being stripped of its functionality. Guess I’ll keep using bridges then?

??? How not distributing 127.0.0.1 address is “stripping functionality”? It does not even make sense to distribute 127.0.0.1, it is called “localhost” for a reason.

When you are not distributing 127.0.0.1, you should have written that.
Loopback address is ambiguous as it can refer to the address of the loopback interface, which now can have other addresses than 127.0.0.1 as well.

@mrz: if it’s only 127.0.0.1 you’re no longer distributing, it makes total sense and my comment/complaint is not applicable.
As @pe1chl mentioned you might want to clarify that changelog entry though:

*) route - do not redistribute 127.0.0.1 as connected route;

247 listed. Exactly the same as in 7.14 :wink:

:retrun command called from script (eg. :return “”), not inside function, used to exit script if some condition matches where script doesn’t need to continue executing generates error log “executing script <script_name> from <winbox|scheduler> failed, please check it manually”, from terminal doesn’t produce error, eg:

{:return ""}

or:

:do {:return ""} on-error={:put error}

Error is not printed.
I had to mute script,error topic to avoid log bloat with these log records mainly generated from short interval schedulers. Please fix this.

as others have said, if the changelog entry really means “we won’t redistribute 127.0.0.1 as a connected route” then the changelog needs to say specifically that, because now that you have the loopback interface type, “loopback address” is extremely ambiguous!

Seriously, guys, cut them a little slack. Google “Loopback address” and >90% of the results refer to 127.0.0.1 (and a couple to ::1). You’ll note that the terse changelog entry said “loopback address” singular, as in the loopback address. It didn’t say “loopback interface” or “loopback addresses” or “addresses assigned to loopback.”

Besides, had this been a real issue, it would have broken things pretty quickly during the beta cycle.

The issue with wifi access-list or in other words, wrong signal levels recognised at the beginning of wifi client connection, has been reproduced, and we will solve it as soon as possible. We are very sorry for any inconvenience caused.

if you have OSPF and assign some local address like 10.255.255.1/32 on loopback (lo) interface this is connected route is this allowed or not? or just the hardcoded (127.0.0.1) is not allowed?

@loloski
just 127.0.0.1

Here is one example why I do wait some weeks before upgrade more that some test devices

The issue with wifi access-list or in other words, wrong signal levels recognized at the beginning of wifi client connection, has been reproduced, and we will solve it as soon as possible. We are very sorry for any inconvenience caused.

This is far from the first time some are broken on the first releases of new version.

Hello MikroTik team,

Was the REST API user logout issue solved, please? - topic is discussed here: http://forum.mikrotik.com/t/rest-api-active-users/175496/1 unfortunatelly there was no reply with SUP ticket ID.

Thank you

Update:
Topic will be solved in 7.16.

What about ::1 ?

Are there problems with the access list only in the wifi-qcom driver, or in the others too?

@baragoon
If I understand correctly, then there too.
That is, localhost in general

Scripts error is very annoying … :frowning: and dificult to check :frowning: at least for me.