v7.10beta [testing] is released!

It’s an oxidized problem, so ask on oxidized forum for it to be updated.

Oh, did I? My intention was to confirm that datum changes affects oxidized too. And so it’s written…
Why is the kitty so pitbully?

It just happened to me too, I only use wpa2.
Supout.rif generated before reboot and sent (SUP-116928), I hope it helps the support.

Hi Massinia,
do you know if it was only on one radio? 2,4 or 5,4? I tried to split one ssid to two and I hope when one will be blocked laptop will join the next one.

BFD has been marked as “initial support” in 7.10 here:
https://help.mikrotik.com/docs/display/ROS/Routing+Protocol+Overview

it is coming soon!!!

I didn’t drink alcohol for about 3 years but now it’s time i think :smiley:

I would prefered to have stable wifi than BFD :slight_smile:

I must have expressed myself badly, but in addition to complaining about how the code was written wrong, I also provided the solution.

Yeah, that was just one example of the consequences with the new date format that totally unnecessary breaks script compatibility. I really hope MT rethinks and fixes this asap.

Pure stupidity IMO!

Sorry, but unfortunately it is the oxidized code that is done with the feet, in this case
https://forum.mikrotik.com/viewtopic.php?p=1003427#p1003306
If it was written right from the start, there was no problem.
Then the fact that it excludes other lines that I consider important from the comparison is another story…

.
By Mikrotik staff comments, I would say it’s here to stay, and scripts will have to be adjusted. At least for me, adjusts were simple to make, 2 minutes and everything was done.

Is possible to write scripts that work on both regardless the date format:
http://forum.mikrotik.com/t/warning-routeros-v7-10-will-break-all-scripts-based-on-system-clock-get-date-or-other-date-s/166576/1

Well, we’ll see what they decide.

I want to emphasize that we welcome the new date format. HOWEVER, implementing it in a way that breaks compatibility, and in addition absolutely unnecessarily, is just plain stupidity.

And of course, you can “fix” the problem with various modifications, but the level of effort required varies depending on its occurrence. People who don’t understand the implications of this issue shouldn’t comment on the matter IMO.

.
Well, I believe that you’re having me among those “who don’t understand the implications” … and i’d say you’re really wrong on that one. Accepting it will happen doesn’t means I don’t understand it. But that decision is not on me. I would have made it on different ways, but that’s really not on me.
.
And that all being said, seems kind of censorship expecting that only those who agree with you can comment on something, doesn’t it ??? Everybody is free to comment, no matter their opinions.

You are, of course, entitled to say whatever you want!

And I still stand by the belief that individuals with a “fixer-upper” attitude (i.e., hacker hero) who lack insight into the implications of large-scale operations should refrain from commenting on that particular matter (in my opinion!)

Please feel free to continue this debate in the thread: “WARNING: RouterOS v7.10+ will break all scripts based on [/system clock get date] or other date(s)

@larsa
so you shouldn’t comment?


Tell us from your wisdom what these blessed “implications of large-scale operations” are, that only you seem to know about them.
That by chance these operations are installing a beta in production? Or the inability to distribute “commands” beyond the update?
Tell me, from your highest and deepest vision, what these problems are, instead of continuing to insinuate that others don’t have the insight.
Maybe the others are better than the mediocre employees of these large companies?


Yeah, a stupid and insignificant little person who can act in an instant,
instead of the giants who don’t know what mediocre and banal employees they hire,
those big companies, they are much more organized and efficient, who are put into crisis MONTHS/YEARS before something beta and unstable go into production…

Yeah, luckily there are big companies that have smarter and better people who go into crisis for so little.

hap-ax3.png

@daaf
Chalenge accepted but no clue what you report?

Same sentiments when I saw it …

I guess the error line about “no such item” ?

@daaf:
you need to be A LOT more detailed about what your specific issue is.
You’re running a customized default script or the default ?
What are you expecting which is not there now ?

hAP ax3 + hAP ax2 + cAP ax
After only two days the problem with the wifi returns.
No one can log in : wrong password error.

Now I have added a scheduled reboot every 24 hours but, please mikrotik, this bug is really urgent to fix…

Why is it urgent to fix? This is a beta, just for testing and not for production.