v7.12.1 [stable] is released!

Announcements
101

dhcp server on x86 no longer working after upgrading from 7.11.2, status became “offered”, anyone suffer the same ?

102

Perhaps you missed this part from the announcement?

Notice - SFP/QSFP functionality has been refactored for consistent behavior and better scalability. Now, compliance with SFP/SFP+/QSFP MSA standard is mandatory. This may cause issues with SFP/QSFP modules that are not fully compliant. All current MikroTik modules abide this standard.

It may have worked before this release, but changes have been made to SFP functionality. It would seem that your SFP module is non-compliant. In that case, replace the SFP module with a compliant one or roll-back to any version before 7.12 if you’re not ready to replace the module just yet but need it working.

103

I’d love to replace my SFP module with compliant, however, as far as I understand, Mikrotik is NOT have any compliant (such a simple thing) SFP EPON ONU. :frowning:

Now, I believe, this phrase should be deleted “MikroTik devices and SFP, SFP+, SFP28, QSFP+, and QSFP28 modules do not have any restrictions for other vendor equipment.”

Mikrotik has just clearly restricted me from using other vendor equipment. Unbelievable.

104

To be fair, “SFP-ONU” modules are not just simple transceivers, as defined in the MTA
they are full-blown router/bridges , with firmware, folded into a SFP mechanical form-factor (sometimes disregarding electrical and thermal specs)
let alone the firmware(and simulated EEPROM responses), those are amongst the crappiest CPE’s possible, from a support, and stability standpoints.

To the point that Mikrotik themselves, and even finisar (that specializes in high-end transceivers), had products in this category, and pulled them from the market

The modules themselves are CRAP, This is not mikrotik’s fault.

105

Come on, it’s not just SFP-ONU. I have a ticket open for six months for a simple SFP+ from Ubiquity (to replace S+RJ10), it’s crickets, I test every new release, and it’s still the same.

I wouldn’t mind paying 2-3x for Mikrotiks own S+RJ10, if they wouldn’t consume 2x power as the most recent chips.

106

MLAG again began to lose the secondary switch.
This behavior was noticed before, but it worked on 7.11.
Treat the variable by rebooting both switches until the second one becomes available.
Although this may have never been fixed…

CRS326-24S+2Q+ x2

107

Apparently the mlag is broken again, after about an hour, the primary switch went to 100% load.
And Zabbix started yelling: “Interface bond0: Ethernet has changed to lower speed than it was before”. Оn all servers connected to the switches
There is nothing in the logs of the switches themselves

108

Updated D53G-5HacD2HnD successfully, Two things spotted:

  • the blue led light flashed pink when performing a modem upgrade, had to reboot twice.
  • defconfig script changed the wireless specification from 7.11.2 to 7.12?

7.11.2

set $ifcId mode=ap-bridge band=2ghz-b/g/n disabled=no wireless-protocol=802.11
distance=indoors installation=indoor

to

7.12

set $ifcId mode=ap-bridge band=2ghz-b/g disabled=no wireless-protocol=802.11
distance=indoors installation=indoor

and

From:

7.11.2

set $ifcId mode=ap-bridge band=5ghz-a/n/ac disabled=no wireless-protocol=802.11
distance=indoors installation=indoor
set $ifcId channel-width=20/40/80mhz-XXXX;

To:

7.12

set $ifcId mode=ap-bridge band=5ghz-a disabled=no wireless-protocol=802.11
distance=indoors installation=indoor
set $ifcId channel-width=20mhz;

Any reason why the change?

109

In my case it was a new instance which I created around Oct 15th and this date is shown as “Last Seen” on the license management as well. I guess the “Next Renewal Date” would be around Nov 15th, can’t tell because it’s broken :slight_smile:

Gladly it was still the Trial License and I did not assigned the prepaid key, expiration date for that was Dec14th.

I created a new instance and hope for the best, the update process needs to be rock solid.

–Michael

110

I tried updating from 6.49.10 to 7.12 bootloop and tried netinstall, the result was the same, downgrading to 7.11.2, it worked with netinstall, I used an RB 850 GX2, for those of you, it’s best to have the same as me, avoid 7.12

111

My device (SFP ONU) was working on RB5009. Now Mikrotik decided that is a CRAP (without offering any equivalent) and forbid me to install any future updates. Nice. Well done, Mikrotik!

112

Thanx to tell us on what kind of router, please…

113

rb850gx2

114

What is requirements for station-bridge mode? Is it possible using old wireless 7.12 devices in station-bridge mode with wave2 7.12 ap or it’s only for wifiwave2 station-bridge < - > wifiwave2 ap devices?

upd

found answer in the doc

The station-bridge mode, as implemented in the wifiwave2 package, is incompatible with APs running the bundled ‘wireless’ package and vice versa.

115

fixed my problems.

116

Updated my AX^3 and the old but gold CRS125, everything is fine!

117

My rb850gx2 became unusable after updating to version 7.12. Apparently I’m not the only one, Mikrotik has to solve it or raise an alert.

118

Why not switch to HMAC-SHA-X Algorithm instead of MD5?

FRRouting 9.0 OSPFv3 docs

I have OSPFv3 running with HMAC-SHA-512 Auth between Bird 2.0.14 and ROS 7.12 with success. After the inclusion of bugfix > “ospf - fixed OSPFv3 authentication header length calculation”

ROS 7.12

/routing ospf interface-template
add area=ospf3-backbone auth=sha512 auth-id=0 auth-key=
gsCHixQReM8cITbm8-8iedXG63ao8i9s dead-interval=20s disabled=no
hello-interval=5s interfaces=bridge1.3999 retransmit-interval=2s

>
> Bird 2.0.14 (on Debian Linux 12)
>
> ```text
protocol ospf v3 ospf3_main {
  area 0 {
    interface "br0.3999" {
      type broadcast;
      hello 5; retransmit 2; wait 10; dead 20;
      authentication cryptographic;
      password "gsCHixQReM8cITbm8-8iedXG63ao8i9s" { id 0; algorithm hmac sha512; };
      check link on;
    };
  };
}

Unless you capture the OSPFv3 packets on the wire and analyze the Authentication contents in e.g. Wireshark. It is hard to know what is going wrong for your setup with FRR 9.0.1 and ROS 7.12.

My problem was the the authentication header length before 7.12 was set to an incorrect value. Where ROS missed the addition of 16 bytes in the len field in the OSPFv3 authentication header. ( HMAC-SHA-512 / 8 = 64 bytes, instead of HMAC-SHA-512 / 8 + 16 = 80 bytes)

@netravnen
Thanks for your answer. Yes I know about this option, but I guess to simplify my configuration file I prefer MD5, which I also use in OSPFv2. OSPFv2 can only do MD5 - https://docs.frrouting.org/en/stable-9.0/ospfd.html

I also want to alert Mikrotik guys to this problem so that they can fix it and make all variants functional.

119

OSPF stopped exporting local areas, again :-/ Has been working fine with 7.11.2, now everything needs to go into the backbone area to be functional. Looks very much like a regression to me, as I’ve seen this in the past but it then got better (and now worse again sigh)

120

@vecino
From the GitHub Issue tracker (frrouting/frr#14398) It would seem HMAC SHA support in OSPFv2 is on the way for the next FRR 9 point release :sign_of_the_horns: