Does the change log list differences to 7.3 or to 7.4beta5?

*) ntp - added VRF support for client and server;

*) system - added "shutdown" parameter for reset-configuration (CLI only);

For 802.11r - you mentioned 'local' interfaces. Does this include those connected/generated by CAPsMan? Could you define 'local' in this case?

is there any device compatible with 802.11r? HAP AC3 is compatible?

seems 7.4beta and 7.4rc1 has issue on CCR2216 and 100G modules by FS.COM
upgrading from 7.3.1 to 7.4rc1 we lost the interface because they flap continuosly, I changed the modules to anpther vendor and they workd, I reverted back to 7.3.1 and FS:COm modules worked!

GRE tunnel is broken. v7.4 rc1 on both ends between RB5009 and HAP AC^2

a lot of instability on bgp sessions about hold timer expired (where sessions were stable with v6.49):

a lot of instability on bgp sessions about hold timer expired (where sessions were stable with v6.49):

You upgraded straight from v6.49 to v7.4rc1 and this is your first experience with v7? Then you likely need to make BGP config changes, auto conversion is not complete.
Also when you have installed v7 before, downgraded, then worked with v6 a while and now again try the upgrade to v7, you can also expect issues.
Those can be resolved by doing an export (don't forget show-sensitive parameter), then a fresh netinstall of v7 without default config, and import the config again.

My router has 2 BGP templates (what used to be "instances") and 8 peers, on a 4-core router. It does not have that issue, it only logs this when a peer link is failing.
(of course the log messages suck as they do not specify which connection has failed, but I am complaining about that for a long time and it seems the BGP programmer left the scene)

What's new in 7.4rc2 (2022-Jul-07 15:29):
*) netwatch - added support for more advanced probing;

*) defconf - fixed default configuration loading on devices with WifiWave2 package;

Request for src-address is logged in our system.

*) defconf - fixed default configuration loading on devices with WifiWave2 package;

Can you please provide more info on what this exactly fixes ? What was the problem ?

jul/08/2022 11:05:41 system,error,critical error while running customized default configuration script: bad command name wireless (line 979 column 25)
jul/08/2022 11:05:41 system,error,critical

Just guessing: in all ROS versions, when wifiwave2 driver is installed, device emits error message like this:

Code: Select all

jul/08/2022 11:05:41 system,error,critical error while running customized default configuration script: bad command name wireless (line 979 column 25)
jul/08/2022 11:05:41 system,error,critical

It seems benign, but it's ugly as hell.

So perhaps quoted change log entry refers to this problem.

FWIW I can not recall having ever seen that message in the logs (just checked to be sure on an AC3 which was still running 7.2beta5) ... so what should trigger it ?

VRF support was already present since beta versions:
https://help.mikrotik.com/docs/display/ROS/Netwatch
ipv4@vrf
ipv6@vrf

My guess: there's some default config which has hard-coded reference to legacy /interface/wireless configuration subtree ... which doesn't exist in wifiwave2 installs, where /interface/wifiwave2 subtree replaces it completely.

Does it make sense to open a ticket, or should I just go back straight to 6.49.6?

Thanks & regards
W

[admin@RB5009] /partitions> copy-to part1
status: ERROR: /flash/rw/run/netns/22-user: Invalid argument

WINBOX is showing this ERROR only very short. And all looks ok, but it isn't.

Does it make sense to open a ticket, or should I just go back straight to 6.49.6?

Thanks & regards
W

OSPF: I've seen that on previous ROS 7 installs coming from ROS6. Probably you will not see that if you use netinstall on that device.
CPU: Some (older) devices are not really suited for ROS7.

You can always file a ticket, they should respond.

OSPF: I've seen that on previous ROS 7 installs coming from ROS6. Probably you will not see that if you use netinstall on that device.
CPU: Some (older) devices are not really suited for ROS7.

You can always file a ticket, they should respond.

Thanks holvoetn!
I went straight back to 6.49.6.
W

fs.com sfpplus modules still don't work stable in ccr2004 & ccr2116 and randomly loose their link on boot.

Thanks holvoetn!
I went straight back to 6.49.6.
W

I'm unable to recreate this on my hAP Lite that's a simple wireless bridge/repeater

• CCR1009-7G-1C-1S+
• RBcAPGi-5acD2nD
• RBwAPGR-5HacD2HnD
• RouterBOARD 750GL
• RouterBOARD 962UiGS-5HacT2HnT
• RouterBOARD cAP Gi-5acD2nD
• RouterBOARD cAP L-2nD
• RouterBOARD D52G-5HacD2HnD-TC
• RouterBOARD mAP 2nD
• RouterBOARD mAP L-2nD
• SXT G-2HnD
• SXT G-5HPacD r2

fs.com sfpplus modules still don't work stable in ccr2004 & ccr2116 and randomly loose their link on boot.

*) netwatch - added support for more advanced probing;
=
*) netwatch - fixed using $host, $status, $since and $comment in on-up/down/test scripts;
*) netwatch - fixed failed tests counter;

/ip/ssh/always-allow-password-login, regardless of the value, allows SSH login with username and password.
Tested on RB750Gr3, hAP ac3. ROS 7.4rc2.

Script:
Global variables disappear, the run counter returns to 0 shortly after the script has been run.

After upgrade from 7.3.1 to 7.4rc2 SXT-LTE6 died. I will have to reinstall it with netboot :(

/ip/ssh/always-allow-password-login, regardless of the value, allows SSH login with username and password.
Tested on RB750Gr3, hAP ac3. ROS 7.4rc2.

Do you have an ssh key installed for your user? This setting decides if password login is still possible with a ssh key present.

# jul/10/2022 14:03:55 by RouterOS 7.4rc2
# software id = 
#
# model = RBD53iG-5HacD2HnD
# serial number = 
/system script
add dont-require-permissions=no name=hello-world owner=admin policy=\
    ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon source=\
    ":global helloWorld;\r\
    \n:set helloWorld do={:put \"Hello World.\";}"

@daaf

On what previous version your ssh configuration has worked?
Open separate topic and do not pollut this topic with all your problems.
First on separate topic check if are really a problem, or are you that have configured something on wrong way,
then, if is really a problem, report here the problem, with the link to the discussion topic.

Script:
Global variables disappear, the run counter returns to 0 shortly after the script has been run.

This is useless....

Open separate topic and put the script inside for debug.

A screenshot say nothing on what is wroted inside the script.

For the scripts, note that it has been happening since 7.4beta5, it is not a matter of debugging the script, because a simple script like the following happens the same, 5-10 minutes later it disappears from /system/script/environment, even if it is used or not:

Code: Select all

# jul/10/2022 14:03:55 by RouterOS 7.4rc2
# software id = 
#
# model = RBD53iG-5HacD2HnD
# serial number = 
/system script
add dont-require-permissions=no name=hello-world owner=admin policy=\
    ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon source=\
    ":global helloWorld;\r\
    \n:set helloWorld do={:put \"Hello World.\";}"

"Connection" is a template, there can be hundreds of "sessions" from one "connection" configuration.

"Connection" is a template, there can be hundreds of "sessions" from one "connection" configuration.

Code: Select all

/system script
add dont-require-permissions=no name=hello-world owner=admin policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon \
    source=":global helloWorld;\r\n:set helloWorld do={:put \"Hello World.\";}"

You try to create a function that write "Hello World." or set inside the variable helloWorld "Hello World."???...

"Connection" is a template, there can be hundreds of "sessions" from one "connection" configuration.

You already can see this info with:
session/print count-only where name~"connection_name"

If there is no session then there will be no counter. It won't help in case of md5 mismatch because connection is dropped before BGP can see it.

count-only will also show zero if there is no session.

This is unrelated to v7.4rc release, ask specific scripting questions here:
viewforum.php?f=9

This is unrelated to v7.4rc release

Are you sure that problem is actually in BGP and not in some problem with policy routing?
There is a known change in handling of "route marks" that may affect your configuration for cases like this.
When you want to advertise a default route you likely are running 2 (or more) route tables. When you load the BGP-advertised default route into the table, you must make sure that the original route for the BGP session to the peer router(s) stays in place and is not taken up by that default route, else the session would flap.
At the moment I am running v7 as test on a router with a BGP session to a v6 router that advertises the default route, and that works fine, the route gets and stays in the (2nd) table. I also advertise that route through to another v7 router and that also works. But I do not have the situation where the real origin is on a v7 router.
(I cannot update that router to v7 until BGP is improved further)

that can't be a policy routing issue, because the bgp session goes over two 'connected' ip's of the /29 transfernetwork between both boxes, which is more precise than a default route and also has the distance of '1' because it's directly conected.

that can't be a policy routing issue, because the bgp session goes over two 'connected' ip's of the /29 transfernetwork between both boxes, which is more precise than a default route and also has the distance of '1' because it's directly conected.

Still, that can be the reason when your /29 network route does not appear in both of your routing tables.
I have to explicity copy the automatically added "C" route from the main table to the 2nd table used with BGP to make things work correctly.
(I open the C route in winbox, click COPY, change the routing table field and set the distance to 1 (0 is invalid for manually added routes) and save it).
This would not be required when using VRF, but I still have too many issues with that.

Still, that can be the reason when your /29 network route does not appear in both of your routing tables.
I have to explicity copy the automatically added "C" route from the main table to the 2nd table used with BGP to make things work correctly.
(I open the C route in winbox, click COPY, change the routing table field and set the distance to 1 (0 is invalid for manually added routes) and save it).
This would not be required when using VRF, but I still have too many issues with that.

the /29 and the bgp is in the 'main' table and the connected route always exists there 'visible'. there is a vrf for management (which is not related to bgp or ospf or connected route), but the problem even pops up, when there is no management vrf.

can be that there is some strange workaround by making some things static, which are supposed to work dynamic, but anyhow, thats everything else than stable nor ready for production. and thats a serious issue, if you want to feed your transit customers with bgp transit with just a default route. ros7 just isn't able to do this yet.

But if that is true, then why did they even start rewriting it??

The talk about an "entirely new routing engine" already started ~10 years ago, when the mythical v7 was introduced that would solve all our problems and fulfill all our wishes.

RB1200 from 6.49.6 > all ros 7 version even 7.4rc2
ether1-8 not working
Only 9 and 10 eth working.
Downgrade to 6.49.6 working fine
Anyone with RB1200 and ros 7 with normal operation ?

The talk about an "entirely new routing engine" already started ~10 years ago, when the mythical v7 was introduced that would solve all our problems and fulfill all our wishes.

I believe that when MT Developers adopted the newer Linux Kernel [the very heart of the OS ] for version RoS v7 they came up with unexpected challenges ... I am also 100% certain that those same developers are far more frustrated by those challenges than you or I and the goal post would declare. Your BGP comments are very valid and I for one empathize. Patience is the only recourse available. I am also 100% certain that MT will resolve this issue sooner vs later.