Page 2 of 2

Re: v7.8beta [testing] is released!

Posted: Thu Feb 09, 2023 2:31 pm
by fragtion
I guess you could confirm if your original code worked in 7.8beta2...

Like I say, I also experienced this issue since 7.8beta3.. Before I was using:
/tool fetch keep-result=no url=("http://url")

Now I'm using this (based on dksoft's suggestion), which works:
/tool fetch url=("http://url") as-value output=none

I'm definitely concerned about whether anything is being written to nand/disk on either of these approaches... ?

The documentation (https://wiki.mikrotik.com/wiki/Manual:Tools/Fetch) states:

keep-result (yes | no; Default: yes) If yes, creates an input file.

output (none|file|user; Default: file) Sets where to store the downloaded data.
none - do not store downloaded data
file - store downloaded data in a file
user - store downloaded data in the data variable
Since default for keep-result is yes, and yes creates a file, then logically, wouldn't it be a bad idea to remove keep-result=no, since if the documentation is accurate, that would imply a file is being created somewhere? 🤔

But my understanding of setting output=none is that it does the same thing? So is there something going on behind the scenes that we don't know, or are these literally two redundant settings and they were "in the process" of removing keep-result and some changes slipped through the cracks without showing up in the changelog?

What is interesting, is passing keep-result=no, with output=none:
[admin@MikroTik] > /tool/fetch url=http://url as-value output=none keep-result=no
failure: please use 'output' option
If the intention is to redirect users to use output instead of keep-result going forward, then the error message is not being triggered under the right conditions. It should give the error whenever keep-result is used, not only when it is paired with output. Also none of this explains why the manual execution is fine but system-executed scripts fail.

Re: v7.8beta [testing] is released!

Posted: Thu Feb 09, 2023 3:02 pm
by pe1chl
When you are worried about wearing out your flash: you can now create a RAMdisk and write the temporary files there.
Then you can also keep logging info etc.

Re: v7.8beta [testing] is released!

Posted: Thu Feb 09, 2023 4:08 pm
by Amm0
Since default for keep-result is yes, and yes creates a file, then logically, wouldn't it be a bad idea to remove keep-result=no, since if the documentation is accurate, that would imply a file is being created somewhere? 🤔
I'm on record as saying they shouldn't do things to break old script & instead should add params as new things are needed, which has been MT's approach for a long while. Now this does let to duplicate syntax (e.g. /export hide-sensitive show-sensitive), which I think is okay as a side-effect for backwards compatibility.

On output=none vs keep-result=no – they both should work the same IMO & why this sounds like a bug. I only asked about beta2 since MAYBE that might help Mikrotik narrow down the issue - not suggest that as an end-solution. This is a beta (meaning "testing") release after all.

One detail here gaves me pause...the docs simply say "If yes, creates an input file." in help for /tool/fetch – even thought it's really an output file, is why I asked about if it worked.

Re: v7.8beta [testing] is released!

Posted: Thu Feb 09, 2023 4:57 pm
by username2
Just letting you know, after updating my rb5009 from 7.7 to 7.8beta3 there was no link detected on my Huawei MA5671A ONT.

Reverted back to 7.7 and everything works perfectly fine again.
Not sure if this might be SUP-105042 (on which I could not find any more Information on) but it was also mentioned with sfp issues.

Feel free to contact me if I can help with anything.

Thanks!

Re: v7.8beta [testing] is released!

Posted: Fri Feb 10, 2023 8:04 am
by An5teifo
Not sure if this is relevant on 7.8 beta but one of my Wireguard peers is not working after a router reboot. I need to disable and reenable the peer manually to get it running.

Re: v7.8beta [testing] is released!

Posted: Fri Feb 10, 2023 8:17 am
by holvoetn
Probably related to not being able to resolve the name of the endpoint you're connecting with at the moment wireguard gets activated.
The way it is implemented in ROS, that interface only checks once, never again afterwards.
So if it fails at startup, it's stuck.
There are examples available of scripts or netwatch setups to circumvent this problem (and yes, most will simply toggle peer activation).

The REAL solution would be that ROS does NOT start wireguard when DNS resolution is not working yet. Only after that service works, it should start wireguard. Not earlier.

Re: v7.8beta [testing] is released!

Posted: Fri Feb 10, 2023 10:12 am
by EdPa
RouterOS v7.8rc1 has been released
viewtopic.php?t=193473

Re: v7.8beta [testing] is released!

Posted: Mon Oct 30, 2023 3:33 pm
by nz_monkey
Routing is MT's business and the main focus should be on improving and delivering new functions, with their fastest possible fixes. As much as I like new functions, like ROSE, Containers, Wireguard... It gives me the feeling that the MT is not keeping the focus. As the resolution and improvement of:
BFD fixed
BGP-VPNv4-VRF RR fixed
EVPN
MPLS Fast Reroute
BGP Multipath
L3HW off loading that is compatible with MLAG and VRRP
L3HW off loading for VXLAN
L3HW off loading for QinQ
OSPF improvements
IPsec Virtual Tunnel Interface

I think that such requirements already satisfies almost all of the public, as it opens up potential possibilities for us.

Improvement of the wireless network, I also support it, I see it as a business rule for you too, but secondary. I see such more enterprise features like:
band steering,
roaming,
wireless bridging for wifiwave2,
Are you me ?


;)