RouterOS version 7.5rc1 has been released "v7 testing" channel!

Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.

What's new in 7.5rc1 (2022-Aug-19 13:23):

*) bgp - fixed remote refuse capability options, max prefix limit errors and administrative stop;
*) bgp - improved stability when "default-originate" is configured;
*) bridge - fixed "new-priority" value validation for NAT rules;
*) capsman - added randomized range option for "reselect-interval" parameter (CLI only);
*) certificate - fixed handling of empty AKID by SCEP client;
*) console - fixed automatic command completion with keypress;
*) container - added tun/tap support for containers;
*) container - fixed free disk space checking;
*) container - fixed handling of mounted directories;
*) container - fixed imported tar image path logging message;
*) defconf - fixed loading of default configuration on RB4011 with WifiWave2 package enabled;
*) dhcpv4-server - fixed removal of dynamic leases when server is removed;
*) dhcpv6-client - moved invalid lifetime logging message from "debug" to "error" topic;
*) dhcpv6-client - use /128 prefix for IA_NA addresses;
*) dhcpv6-relay - fixed relay forwarding (introduced in v7.1.5);
*) dhcpv6-server - improved stability when acquiring binding;
*) dns - added "address-list" parameter for static DNS entries (CLI only);
*) dns - added "match-subdomain" option for static entries (CLI only);
*) firewall - added support for RTSP helper;
*) health - fixed "temperature" and "power-consumption" readings on RB1100x4;
*) health - improved voltage reading on CRS112-8P-4S;
*) health - renamed "CPU" to "switch" for temperature reading information on CRS518-16XS-2XQ;
*) hostpot - fixed Walled Garden functionality for HTTPS sites;
*) hotspot - automatically reject all HTTPS requests passing through HotSpot server for unauthorized users;
*) hotspot - improved stability when receiving bogus packets;
*) hotspot - limit maximum allowed connections based on free RAM resources;
*) hotspot - removed "https-redirect" option;
*) ike2 - allow sending certificate chain as initiator;
*) interface - fixed default interface naming on RB1100x2;
*) l3hw - fixed HW offloaded NAT;
*) leds - fixed default LED configuration for RBwsAP-5Hac2nD;
*) leds - fixed wireless LED functionality on LHGG;
*) lora - do not ignore negative sign for spoofed GPS coordinates;
*) lte - added "SIM not inserted" and "SIM failure" messages to "status" and "monitor" commands for AT modems;
*) lte - added at-chat and NMEA port support for Simcom modems, USB composition (device id - 0x9003);
*) lte - added at-chat support for Simcom modems, USB composition (device id - 0x9005);
*) lte - changed cell ID info display to short format for 3G connections;
*) lte - disallow empty APN name only for default entry;
*) lte - fixed AT channel for Sierra Wireless modems with device ID 0x9091;
*) lte - fixed LTE interface presence for Telit LN940;
*) lte - fixed UDP performance on MMIPS devices;
*) lte - improved antenna scan for Chateau devices with switchable antennas;
*) lte - improved configuration export when multiple LTE interfaces are present;
*) lte - modem dialer, do not reset dialing sequence if modem reply with error to user set init-string;
*) netinstall - fixed Netinstall procedure for ARM devices;
*) netwatch - automatically start migrated probes from previous RouterOS versions;
*) netwatch - changed ICMP default packet loss fail threshold to 85%;
*) ntp - fixed NTP server when "use-local-clock" is used;
*) ospf - fixed handling of external forwarding address;
*) ospf - improved stability when interface is being disabled during database exchange;
*) ovpn - fixed encryption key renewal process which caused periodic session disconnects;
*) ovpn - improved system stability when hardware acceleration is used on ARM64 devices;
*) ovpn - moved disconnected user logging message from "debug" to "info" topic;
*) ping - improved service stability;
*) port - added support for D-Link DWM-222 in serial/PPP mode (device id - 0xac01/0x7e3d);
*) port - added support for Huawei/ZTE K5006z in serial/PPP mode (device id - 0x1017/0x1018);
*) ppp - improved service stability under high load;
*) ppp - use /32 as default netmask if not specified for "routes" parameter;
*) ptp - improved system stability on CRS devices;
*) quickset - removed PPTP and SSTP server addition for "VPN" checkbox;
*) rb5009 - fixed ether1 status reporting after system reboot;
*) route-filter - fixed "delete bgp-communities" command;
*) routerboard - added "reset-button" script feature for TILE devices;
*) sfp - fixed "eeprom" reading on single SFP port ARM devices;
*) sfp - fixed QSFP+ and QSFP28 interface disable when using breakout cable;
*) sfp - fixed unresponsive "sfp1" interface after disabling "ether1" on NetMetal devices;
*) sfp - improved combo SFP ports initialization handling on CRS312-4C+8XG, CRS328-4C-20S-4S+;
*) sfp - improved stability when using 2.5G optical modules in CCR2116, CCR2216 and CRS518;
*) snmp - fixed usage of VRF after system startup;
*) socks - fixed "dst-port" usage when checking access list;
*) ssh - added AES support for PEM decryption;
*) ssh - fixed importing of public keys;
*) ssh - fixed minor typo issue when importing public key;
*) sstp - fixed client stuck in "nonce matching" state;
*) switch - fixed ACL rules for 98DXxxxx switches with more than 28 ports (introduced in v7.3);
*) switch - removed limit for number of hardware-offloaded bonding interfaces;
*) swos - enabled SwitchOS support for CRS310-1G-5S-4S+;
*) swos - fixed SwOS upgrade procedure on CRS305-1G-4S+;
*) traceroute - added "do-not-fragment" parameter support (CLI only);
*) traceroute - increased packet size limit to 65535;
*) vrrp - added "sync-connection-tracking" compatibility with preemption-mode;
*) vrrp - fixed HW offloaded bridge MAC address learning when changing from VRRP master to backup;
*) vrrp - fixed high CPU usage when "sync-connection-tracking=yes" and the backup router goes offline;
*) vrrp - fixed initial connection tracking synchronization, a backup router now always receives all existing connections;
*) vrrp - improved connection tracking synchronization protocol (CTSYNC), the new protocol is incompatible with previous RouterOS versions with "sync-connection-tracking=yes";
*) webfig - allow to specify NTP server as domain name;
*) webfig - fixed displaying of grahs in status pages;
*) webfig - fixed floating point field's negative value in -0.*** format;
*) wifiwave2 - added "sae-pwe" parameter with hash-to-element mechanism for SAE PWE derivation;
*) wifiwave2 - added support for 802.11k;
*) wifiwave2 - disable wireless interface after wireless configuration reset;
*) wifiwave2 - fixed displaying of AKM in scan results;
*) wifiwave2 - fixed duplicated AKM in RSN message;
*) wifiwave2 - fixed group key update for client devices which connect via fast BSS transition;
*) wifiwave2 - fixed incorrect AKM usage for FT-WPA3-EAP-192;
*) wifiwave2 - fixed reassociation response sending for fast transition over DS;
*) wifiwave2 - fixed setting of "ft-nas-identifier" parameter;
*) wifiwave2 - fixed usage of Canada country setting on US locked devices;
*) wifiwave2 - improved default channel width selection for interfaces in station mode;
*) winbox - do not show previously attached LTE interfaces while establishing LTE connection;
*) winbox - enabled all filters by default under "Tools/Torch" menu;
*) winbox - fixed "Enable", "Disable" and "Comment" functions for L2TP-ether type interfaces;
*) winbox - fixed "Next Run" parameter displaying under "System/Scheduler" menu;
*) winbox - fixed "Type" and "Value" field displaying under "System/Health" sub-menu's;
*) winbox - show warning messages for BGP connection entries;
*) wireless - fixed interface initialization on x86 devices;
*) x86 - allow downgrading to RouterOS v6 only if it was previously installed;
*) x86 - fixed advertising of 2500M and 5000M link speeds on ixgbe driver;

To upgrade, click "Check for updates" at /system package in your RouterOS configuration interface, or head to our download page: http://www.mikrotik.com/download

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after some problem has appeared on device

Please keep this forum topic strictly related to this particular RouterOS release.

Some users have reported that the they still experience issues with wireless on Intel Haswell and older x86 platforms.
This will be addressed in future releases.

Progress is looking good.

I am hoping to see BFD support in the very near future !

Chateau LTE12 and RB750GR3 upgraded successfully from RC11 with no issues.

Two CHRs running containers upgraded with no issues from RC11. Scheduler script started containers successfully at power on.

Updated my RB3011 from RC11 without issues. 2 containers (Adguard & Pihole) running fine. Will create some more

RB5009 upgraded without issue. Looking forward for more bgp related fixes.Uptime still showing 497 days for bgp sessions.

upgrade beta11 to rc1 container AdGuard not start
please fix it

upgrade beta11 to rc1 container AdGuard not start

Code: Select all

 09:53:50 container,info,debug 2022/08/23 06:53:50.373246 [info] AdGuard Home, version v0.107.10
 09:53:50 container,info,debug 2022/08/23 06:53:50.468336 [info] Initializing auth module: /opt/adguardhome/work/data/sessions.db
 09:53:50 container,info,debug 2022/08/23 06:53:50.471175 [error] auth: open DB: /opt/adguardhome/work/data/sessions.db: open /opt/adguardhome/work/data/sessions.db: [b]permission denied[/b]
 09:53:50 container,info,debug 2022/08/23 06:53:50.472157 [fatal] Couldn't initialize Auth module

please fix it

Did you create a NEW container or what this your already existing Adguard container that you simply started after the upgrade to RC1 ???
Note that I'm not running the latest Adguard 0.107.x release but still on 0.107.9



EDIT : Permission are not fixed it seems. Tried to deploy fresh Adguard image, same permission errors like in the past.
Not using any mounts or env_variables as a test

Progress is looking good.

I am hoping to see BFD support in the very near future !

We could have dreamed that version 7.5 would achieve feature parity with v6, but it looks like it is not going to be.
The progress around BGP/BFD is not looking good at all. BFD is already mentioned to be a "work in progress" since Sep 4, 2021. Almost a year.

As it seems the BGP programmer has left and there has been some development on "netwatch", may I suggest to build a "BFD" mode into netwatch so at least we can have a workaround until the apparently very hard BFD feature will be finished?
(like most people we do not need any fancy BFD behavior and capabilities at all, just a fast link check and failover)

Did you create a NEW container or what this your already existing Adguard container that you simply started after the upgrade to RC1 ???

using an existing container.

bfd in netwatch would be a nice improvement and even more important, please make the bfd option in check-gateway work.

*) container - fixed handling of mounted directories;

Nope, still broken. Unfortunately I can't unplug the drive to see the what's wrong this time.
LE: Nevermind, this entry is from 7.5beta4 (2022-Jul-22 12:46) which only fixed the creation of mounted directories, not the current broken permissions of the created directories.

bfd in netwatch would be a nice improvement and even more important, please make the bfd option in check-gateway work.

I'm trying to get things going forward so that at least we can install v7 in some locations where it is now unusable due to the lack of BFD.
We only need the original v6 functionality of BFD, not additional bells and whistles. That can come later.
Besides, when a BFD mode is added to netwatch, you can do whatever you want in the up and down scripts. I would enable/disable a BGP peer, you can enable/disable a route when you want to.

BFD mode in netwatch should be quick and easy to implement given the framework for different checking methods already is available.
Only particular thing to BFD is that setting a remote system to be monitored implies that the remote can also monitor us (i.e. the local UDP socket acts as a server as well).
It certainly should not require a man-year of coding, as the "super duper BFD under construction" apparently does.

Hi!
*) rb5009 - fixed ether1 status reporting after system reboot;
My rb5009 connected to the cable modem lost connection several times a day if the 2.G port was used (last tested in 7.5beta8). It´s state was reported correctly (1G FDX). I have moved the uplink connection to ether3 and the problem was gone. I can´t test again until next weekend. (I did not see other performance related issues with the 2.5G port, but my uplink speed is only 300Mbps.)

Does someone know if this fix is related to this problem?

Thanks
W

WPA3 on hAP AC3 stopped working after update from 7.4 - there is no error info in log.

7.5rc1 still same issue, With 7.4.1 all works fine.

If anyone is having problem connecting devices with WPA3, try also, GCMP encryption should work with WPA3-Personal? Unable to connect any device.

*) sfp - fixed QSFP+ and QSFP28 interface disable when using breakout cable;

still doesn't work - ccr2116 qsfp to original mikrotik breakout cable 'Q+BC0003-S+' still has no link. last known working version was ros 7.2.3.

Just to be sure...you have upgraded both packages?

yes, packages and firmware too

RB4011, standard configuration
Update from 7.1.3 -> 7.5 RC1

• Ipsec/ikev 2 private VPN ok!

• Ipsec/ikev 2 work VPN ok!

• Scripts ok!

• NTP Server/Client ok!

First time i read about container support, so let's give it a try:

• Pi Hole ok!

• Adguard not ok!

[fatal]: Cannot create DNS data dir at /opt/adguardhome/work/data: mkdir /opt/adguardhome/work/data: permission denied

Is this still a bug? Or am i missing something?

Anyway thanks for the release ;)

From 7.4.1 to 7.5rc1, on a RB5009; everything looks to be in working order.

Are there any fixes coming for MPLS experimental bits not getting set by set-priority actions? We rely on MPLS EXP bits a lot for our QoS solution and the fact that this functionality is broken means that we can't move routers to v7 that we otherwise could.

MPLS and BGP development in MT is next to none, to be blunt we are a minority as far as MT is concern our use case is minuscule a lot of people here share the same sentiments as I am. If only i have a power and influence to change our network gear to something else I'll be happy to do it and won't turn back, there's a saying patience is a virtue for those who wait but this not holds true in MT world no road-map, no commitment just plain nada. This is a technical forum but always turn to something else we are not really a happy camper here

You are not in a "minority". MPLS is a very common use case with Mikrotik. I was consulting to Mikrotik based ISP's for over ten years and I would say 90% of these ISP's are running MPLS on their networks, with a wide range of topologies and designs whether it is VPLS + LDP, VPLS + RSVP, L3 + LDP or L3 + RSVP. This is not on a handful of routers, its on tens of thousands of Mikrotik routers cumulatively.

I know we are not minority that's why I said as far as MT is concern or POV, anyway honestly it makes me wonder why BGP and MPLS is in the bottom of their priorities just tired stressing this enough for over and over not only me but with a few others here

Are you stressing with support tickets too? or just the forum?

People with AdGuard errors, make sure you make a completely new container, not use the old one. And if there are errors in the log, make sure they are new, from the newly created container

WPA3 on hAP AC3 stopped working after update from 7.4 - there is no error info in log.

7.5rc1 still same issue, With 7.4.1 all works fine.

As suggested by Simonej, you can try setting security.sae-pwe to 'hunting-and-pecking', but please open a support ticket and provide more information on the client devices you're experiencing issues with (phone model/wireless module/OS version).

also, GCMP encryption should work with WPA3-Personal? Unable to connect any device.

In theory, yes.
In practice, the vast majority of client devices we test compatibility with, will only accept CCMP (128) for WPA2/3 and, (if they support it) GCMP-256 for WPA3-EAP-192.
Exceptions to this rule are RouterOS wifiwave2 station interfaces and wpa_supplicant.

People with AdGuard errors, make sure you make a completely new container, not use the old one. And if there are errors in the log, make sure they are new, from the newly created container

I've removed all the containers, deleted all the container related directories (including the one used as tmpdir) and readded the container, same results. I've posted some stuff in the Docker topic, I'm guessing the permissions are still set in the same manner with the wrong uid/gid.
Starting from here: viewtopic.php?t=178342&start=300#p952528

MPLS and BGP development in MT is next to none, to be blunt we are a minority as far as MT is concern our use case is minuscule a lot of people here share the same sentiments as I am.

You are not in a "minority". MPLS is a very common use case with Mikrotik. I was consulting to Mikrotik based ISP's for over ten years and I would say 90% of these ISP's are running MPLS on their networks

We are running an amateur radio network (AMPRnet/HAMNET) almost entirely on MikroTik. We need BGP and BFD to be working as well as they did in v6.
At work I use BGP/BFD in a VPN (the traditional meaning of VPN, not the newfangled one). Both of these networks cannot migrate to v7 as it is.

But all together that is just a small number (maybe 100) of routers, probably indeed a "minority use case" compared to consumer use. And it seems MikroTik lately is focusing more on consumer use than on that commercial use (which was including WISP and small ISP).
Sure there is likely more money to be made from consumer volume sales (especially when equipment is distributed via ISP), but it sure is a pity that the original loyal customers of MikroTik, that loved the full-featured routers at affordable prices, are now left in the dark.

People with AdGuard errors, make sure you make a completely new container, not use the old one. And if there are errors in the log, make sure they are new, from the newly created container

create new container AdGuard on beta11, update to rc1, error persist.
[error] auth: open DB: /opt/adguardhome/work/data/sessions.db: open /opt/adguardhome/work/data/sessions.db: permission denied
create new container AdGuard on rc1, work.

We are running ...

I want to join it. How do I join? I have an amprnet allocation.

@mafiosa at the bottom of:
https://www.pb0fh.ampr.org/index.php/projects/hamnet/

Upgraded from 6.49.6 to 7.5rc on MikroTik hAP ac. EAP-TLS authentication for wireless stopped working.

People with AdGuard errors, make sure you make a completely new container, not use the old one. And if there are errors in the log, make sure they are new, from the newly created container

create new container AdGuard on beta11, update to rc1, error persist.
[error] auth: open DB: /opt/adguardhome/work/data/sessions.db: open /opt/adguardhome/work/data/sessions.db: permission denied
create new container AdGuard on rc1, work.

The "hack" posted by me to use as mount points some directories from inside the container does not mean that "it works".

MPLS and BGP development in MT is next to none, to be blunt we are a minority as far as MT is concern our use case is minuscule a lot of people here share the same sentiments as I am. If only i have a power and influence to change our network gear to something else I'll be happy to do it and won't turn back, there's a saying patience is a virtue for those who wait but this not holds true in MT world no road-map, no commitment just plain nada. This is a technical forum but always turn to something else we are not really a happy camper here

You are not in a "minority". MPLS is a very common use case with Mikrotik. I was consulting to Mikrotik based ISP's for over ten years and I would say 90% of these ISP's are running MPLS on their networks, with a wide range of topologies and designs whether it is VPLS + LDP, VPLS + RSVP, L3 + LDP or L3 + RSVP. This is not on a handful of routers, its on tens of thousands of Mikrotik routers cumulatively.

but what mikrotik does with BGP & MPLS development di v7 make MPLS and BGP's user feels like minority,

We are running ...

I want to join it. How do I join? I have an amprnet allocation.

Currently we are working on a project to extend the access network that we have here (and also other people have in other places) all over the world.
There will be access points where you can connect using a tunnel over internet, and running BGP to announce your area network to the worldwide network.
MikroTik appeared to be an attractive brand to use in that network, but when they cannot get their BGP completed in v7 we will have to look elsewhere...

I know we are not minority that's why I said as far as MT is concern or POV, anyway honestly it makes me wonder why BGP and MPLS is in the bottom of their priorities just tired stressing this enough for over and over not only me but with a few others here

I dont think its their lowest priority, its just that its the most complex, resource intensive and delicate portion of ROS to develop. Its just gonna take some time.

Just to give you some perspective, take a look at the difference in the changelogs from early v6 to v7 now.

I dont think its their lowest priority, its just that its the most complex, resource intensive and delicate portion of ROS to develop. Its just gonna take some time.

And in the meantime, they do not offer the possibility of using the old code, that worked fine in many cases.
Compare with wifiwave2 package (and other similar wireless packages in the past): you can opt to install that package, you get new wifi wav2 drivers with advantages and problems, but you can always use the existing code.
No such option with BGP (and MPLS, but I do not use that and have no knowledge about its situation). When there would be a separate package that one can install to get the old v6 BGP+BFD back (or it would be standard in v7 and you would install a bgp2 package to get the new code), you would not hear me. It would be fine.
But now when upgrading to RouterOS v7 you also get the incomplete BGP (and MPLS) code, and for some models you cannot even run v6.
That is not a good situation to persist for such a long time, with so little apparent progress.

Please work on BGP Monitoring and MPLS. MIkrotik have Powerful hardwares but with v7 which is totally in beta mode with still bugs and lagging major features.

If ROSv7 is still not ready please allow ROSv6 in CCR2004 and 2216 hardwares...

I am trying to mount a file into my container. It doesn't seem like any mount options end up mounting a file into the container. I have tried a real file, an empty file, nothing seems to create the mount point inside the container. I tried just for example but there is no mount point created with a simple alpine:latest image when I add the mount to my container.

If ROSv7 is still not ready please allow ROSv6 in CCR2004 and 2216 hardwares...

I think the reason that we don't see this is that the one CCR2004 model that can run RouterOS v6 has been shown to be unstable, with random reboots every few weeks, and they were unable to fix this without v7.

Until today as u can see, bugs still exist in v6 and a lot of people operate their CCR1xxxx with that poor condition, in some of my tickets MT always promised the bugs will be fix in v7,
now MT offer us new hardware CCR2xxx that works best in v7 and as we know v7 is not properly finished yet.
how can they sure that CCR2xxxx work better in v7 ?
Another promised ?
Event though v7 properly finished MT (all module finished) still have a responsibility to support CCR1xxxx users though.


thx

I want to join it. How do I join? I have an amprnet allocation.

Currently we are working on a project to extend the access network that we have here (and also other people have in other places) all over the world.
There will be access points where you can connect using a tunnel over internet, and running BGP to announce your area network to the worldwide network.
MikroTik appeared to be an attractive brand to use in that network, but when they cannot get their BGP completed in v7 we will have to look elsewhere...

I can see a lots of such complaints here lately. Working in a corporate space as well as co-owning a small ISP wifi-network, I will just ask one thing - do we really always need to use the latest and greatest? I can see lots of old boxes working just fine for years. What is the feature you need in v7, so that you can't eventually still use v6 for the time being? I also know, what it means to switch brands / ecosystems, so is that really easier to switch brands, or are you guys just upset at Mikrotik, to not work on BGP as a priority?

The reason we need v7 to have all features is that all the newly introduced router models support only v7, so we unavoidably get new users that have v7 on their router.
Also, our amprnet network consists of unrelated (hobbyist) users who are technicians. Time after time it happens that a user "sees that there is a newer version and upgrades", only then getting into trouble. We do not have the information channels and authority to always tell people "do not upgrade to v7 yet!". So it causes a lot of nuisance.
I hope you understand that.

Please fix this minor problem: when BGP session is disconnected due to hold time exceeded, the logged message is:
09:30:18 route,bgp,error HoldTimer expiredpeername-1
Note the lack of a space between "expired" and the peer name.

Currently we are working on a project to extend the access network that we have here (and also other people have in other places) all over the world.
There will be access points where you can connect using a tunnel over internet, and running BGP to announce your area network to the worldwide network.
MikroTik appeared to be an attractive brand to use in that network, but when they cannot get their BGP completed in v7 we will have to look elsewhere...

I can see a lots of such complaints here lately. Working in a corporate space as well as co-owning a small ISP wifi-network, I will just ask one thing - do we really always need to use the latest and greatest? I can see lots of old boxes working just fine for years. What is the feature you need in v7, so that you can't eventually still use v6 for the time being? I also know, what it means to switch brands / ecosystems, so is that really easier to switch brands, or are you guys just upset at Mikrotik, to not work on BGP as a priority?

In my case i don't have a power to make decision to switch brands because the owner of the business feels MT is the way to go in this hard and trying times and was force this platform on my throat I really like my Job and the company but my whole team is loosing sleep over this BGP instability of ros v7 and not to mentioned BFD missing feature is adding insult to the injury. If only we don't need RPKI validation we can stay on v6 in our multihome stub network with minimal issues and headache.

If only MT can backport RPKI validation in ROS v6 they won't going to hear my rant from time to time, since they won't do it for sure and the progress they made in ros v7 in terms of stabilizing BGP (less priority) this annoyed me and at times I think the only course of action for me is its either i change Job or wait for them for eternity

*) interface - fixed default interface naming on RB1100x2;

As you seem to be working on PowerPC platform devices, could you please show some ROS 7 -love to trusty old RB1200 (RouterBOARD 1200)?

RB1200 installs and boots 7.4.1 and 7.5rc1 just fine, but ethernet ports 1-8 do not have any IP connectivity. Link negotiation works ok for each port, but traffic does not flow through.

This has been reported by many users on this forum and elsewhere.

*) interface - fixed default interface naming on RB1100x2;

As you seem to be working on PowerPC platform devices, could you please show some ROS 7 -love to trusty old RB1200 (RouterBOARD 1200)?

RB1200 installs and boots 7.4.1 and 7.5rc1 just fine, but ethernet ports 1-8 do not have any IP connectivity. Link negotiation works ok for each port, but traffic does not flow through.

This has been reported by many users on this forum and elsewhere.

What's your support ticket number? People need to reference it in theirs.

@ormandj well said.

Running absolutely fine on a Chateau LTE12.

Off to create a new topic, Quectel are offering the latest EG12 firmware for download from their support forums:
https://forums.quectel.com/t/dear-quect ... vice/16272
Now I thought that I should be able to run: to update as this release is from 22nd July, but it will not take, any ideas?

If ROSv7 is still not ready please allow ROSv6 in CCR2004 and 2216 hardwares...

I think the reason that we don't see this is that the one CCR2004 model that can run RouterOS v6 has been shown to be unstable, with random reboots every few weeks, and they were unable to fix this without v7.

yes there was a reboot issue in v6 also and was possibly due to BGP but latest stable v7 we are not facing any random reboots...

Running absolutely fine on a Chateau LTE12.

Off to create a new topic, Quectel are offering the latest EG12 firmware for download from their support forums:
https://forums.quectel.com/t/dear-quect ... vice/16272

Code: Select all

EG12EAPAR01A12M4G_01.001.01.001

Now I thought that I should be able to run:

Code: Select all

/interface/lte/firmware-upgrade lte1 upgrade=yes firmware-file="http://192.168.88.254/EG12EAPAR01A12M4G_01.001.01.001.zip"

to update as this release is from 22nd July, but it will not take, any ideas?

Just a wild guess, unzip it first? :)

Chateau has only 16MB of flash. the firmware is over 100MB. I think we have to wait for the Mikrotik release of the firmware and whatever method they use to do the upgrade.

Chateau has only 16MB of flash. the firmware is over 100MB. I think we have to wait for the Mikrotik release of the firmware and whatever method they use to do the upgrade.

It sure is ridiculous... 16MB flash in a product of that category and pricing.
But fortunately it has 256MB RAM and the process of uploading files and installing them is done from there.
So it could still work, depending on how the install actually is implemented and how much compression there is in that .zip

If only MT can backport RPKI validation in ROS v6 they won't going to hear my rant from time to time

This is of course a reason for them to not try this... while I would be very happy with just the v6 BGP (temporarily) available in v7 so we can wait for them to finish v7, invariably there will be people asking for backporting work to be done on that v6 version, taking away from the time actually spent on finishing v7.
No idea how much time it would take to "just compile the v6 BGP on v7", but apparently that would not be enough.

honestly the reason i ask if they can backport RPKI it's because out of desperation, if they can optionally bring BGP codebase of ROS v6 to V7 in the form of package just like what you are proposing that's also doable and besides backporting RPKI is a lot easier and less work for them, anyway all of this crazy ideas will not bring to life if only they give some priority of this unfinished BGP implementation.

What's your support ticket number? People need to reference it in theirs.

My ticket number for reporting RB1200 port 1-8 issues with ROS 7.x is SUP-90869

RB1200 installs and boots 7.4.1 and 7.5rc1 just fine, but ethernet ports 1-8 do not have any IP connectivity. Link negotiation works ok for each port, but traffic does not flow through.

What's your support ticket number? People need to reference it in theirs.

In addition to ticket SUP-90869, I've also created a forum post for RB1200 issue here: viewtopic.php?t=188742

Require add DHCPv6 DNS6 fields
also DNS6 add to ppp server profiles

Now I thought that I should be able to run:

Code: Select all

/interface/lte/firmware-upgrade lte1 upgrade=yes firmware-file="http://192.168.88.254/EG12EAPAR01A12M4G_01.001.01.001.zip"

to update as this release is from 22nd July, but it will not take, any ideas?

First, on v6, you could use a local file name rather than an url as firmware-file value, is that not the case with v7?
Second, if you cannot upload the unzipped firmware to the (RAM) disk, Chateau has an USB port, so placing the unzipped file on a USB drive should do the trick?

Downloading and unzipping the firmware results in a myriad of files and folders. No way to know which one to try so not even worth attempting it:

This is just tthe update folder:

*) sfp - improved stability when using 2.5G optical modules in CCR2116, CCR2216 and CRS518;

CCR2116
Link now comes up at 2.5Gbps, so it doesn't crash the switch chip anymore, but I still get psu/health fail and fans spin up/down non stop until I reboot it.

Now I thought that I should be able to run:

Code: Select all

/interface/lte/firmware-upgrade lte1 upgrade=yes firmware-file="http://192.168.88.254/EG12EAPAR01A12M4G_01.001.01.001.zip"

to update as this release is from 22nd July, but it will not take, any ideas?

First, on v6, you could use a local file name rather than an url as firmware-file value, is that not the case with v7?
Second, if you cannot upload the unzipped firmware to the (RAM) disk, Chateau has an USB port, so placing the unzipped file on a USB drive should do the trick?

Will try next, Chateau has 16mb flash so can't stick in files.

The size of the flash is indeed limited, but you don't need the firmware for the modem to survive a reboot of the Chateau, so it should be enough to copy it to the volatile part of the file system, which uses RAM. No idea whether it fits, but still worth trying first.

has disable/enable been fixed for l2tp-ether?

What's new in 7.5rc2 (2022-Aug-25 12:35):

*) container - fixed handling of mounted directories;

Please, enlighten me...
Why do you care about something non-important for routing purposes like virtualization platform (containers), when there are so many unfinished things crucial for RoS 7?

They can work on multiples things at the same time. If they already fixed something, good.

Please, enlighten me...
Why do you care about something non-important for routing purposes like virtualization platform (containers), when there are so many unfinished things crucial for RoS 7?

Multiple developers are working on multiple projects. Moving a developer to a different project is not a trivial task due to the introduction overhead.

I think that's clear to everybody that we all have specialization... it was rather a philosophical question why containers at this stage instead of fully focused on RoS routing functions? From my perspective containers in RoS is so niche (you can easily replace them with many different platforms) that it only distracts you from important things.

You can also use containers to replace some missing/incomplete functions in ROS, so in my view that's pretty important.
And like the reply above mentions, if there are different teams working on different parts of ROS, there's no "distraction" involved.
LE: mounts are still broken in rc2, I'll do some digging later.

LE: mounts are still broken in rc2, I'll do some digging later.

Really? There have been several updates now purporting to fix the mounts issue so it seems a bit ridiculous that we're still battling with mounts like this... I need to recreate containers/mountpoints after each upgrade because of permission problems which occur after each upgrade. Same thing happened when migrating from 7.5rc1 to 7.5rc2.. I really hope it's fixed this time so I dont have to reconfigure all my containers again on the next update ^_^

Any yeah, hopefully @Panbambaryla is enlightened now. There are several of us who are actively battling with this container mounts issue it requires just as urgent attention as anything else IMO. Wait your turn xD

The Dude server was generally broken in version 7. It is not adapted to it at all. Are containers more important than part of the ecosystem?

The situation with the SFP+ and DAC links is also dire. A lot of instability and incompatibility, even manufactured by MikroTik. Finally, please pay attention to this!

Any yeah, hopefully @Panbambaryla is enlightened now. There are several of us who are actively battling with this container mounts issue it requires just as urgent attention as anything else IMO. Wait your turn xD

I agree with him and @CoUL that making v7 feature complete and "bugfree" in comparison with v6.49 should have a higher priority than working on new features introduced in v7.
First make v7 a worthy successor for v6 that can be installed as upgrade without breaking things, THEN work on making it even more powerful.

Any yeah, hopefully @Panbambaryla is enlightened now. There are several of us who are actively battling with this container mounts issue it requires just as urgent attention as anything else IMO. Wait your turn xD

Not at all.. :-) Tell me why you waste your time with the RoS container solution instead of doing it in some well known environment like Linux box (PC, Pi, others)? Is router a really good place for this?

Please ask any questions about general container usage under RouterOS on the dedicated topic for this, viewtopic.php?t=178342
And please write in this topic only about changes/bugs/etc regarding these specific versions mentioned in this topic (7.5rc1 and 7.5rc2), thank you!

The only bug I have found is that the Tool->Traceroute tool on the WebFig shows Count and Max Hops set to 1 - when they should be blank/not-set.
This is not the case with Winbox or via SSH/cli/terminal

*) ospf - fixed handling of external forwarding address;

was this a bug regarding ospf redistribution - does somebody have more info about it?

*) sfp - improved stability when using 2.5G optical modules in CCR2116, CCR2216 and CRS518;

CCR2116
Link now comes up at 2.5Gbps, so it doesn't crash the switch chip anymore, but I still get psu/health fail and fans spin up/down non stop until I reboot it.

How many time the router run until psu fail again?

A few minutes

I am now running this version (v7.5rc1) in production, a single CCR2116-12G-4S+ doing BGP, VLANS to end fibre customers and NAT and it is working.

BUT

There is still a BGP issue with the Equinix route server, please fix this asap, this error comes up every 2 hours. (this error does not happen with Facebook, Cloudflare, Hurricane Electric, Apple, RIPE RIS or bgp.tools peers, it's only with Equinix route servers).

Unfortunately this router can't go back to v6 so I am stuck with this error for now.

unneeded quotation - use "Post Reply" instead

you are an optimist ;)

this is for my understanding not a critical problem, just an unsupported refresh method. easiest fix is, to filter the logging ouput ;)
and so it will be for mikrotik just a cosmetical issue i guess...

serious bgp, sfp, ospf, bridge, pptp etc bugs are not fixed since ros7 is out or taking almost one year (eg. very criitcal bgp 'default originate always' bug now fixed with 7.5 after one year asking for a solution).

send a supout with a problem description, that they have a possibility to put it in their queue.

New version v7.5 has been released!

viewtopic.php?t=188851