MikroTik

Posted: **Sat Jul 06, 2019 11:50 pm**

Read before write. And then for example: https://wiki.mikrotik.com/wiki/Manual:API#Initial_login

Posted: **Sun Jul 07, 2019 12:12 am**

Dear Sir,

I have CCR 1036 8G-2S+ Router. When Router os update V6.45.1 ( stable) this code doesn't working, or login mikrotik router how to change please help.

You're using outdated API client, it was updated for v6.45 a year ago!
https://github.com/BenMenking/routeros-api

Posted: **Sun Jul 07, 2019 2:02 am**

Hi all!

I've noticed (suffered) that ALL my SXT G-5HPnD r2 in my network hang randomly. Had to power down them to recover access, and they work for 1 or 2 hours before recrash. Had to downgrade all them to 6.44.4 to take stability again.

So, the 921 system stability announced on changelog works fine with my problematic ones with had 6.44.3, and now on 6.45.1 they are fine; but my rock-solid SXT SA5 with 6.44.3 are now a headache on 6.45.1, so they are downgraded.

Too many SA5 on my net to be a casual failure.

PD. Sorry for my english.

Posted: **Sun Jul 07, 2019 2:21 am**

Does someone have a problem with mac telnet login via neighbours?

Won't login with any user and pass or without pass, nor admin..

Unfortunately yes, not all devices though and resetting credentials does not help...

Posted: **Sun Jul 07, 2019 10:55 pm**

Does someone have a problem with mac telnet login via neighbours?

Won't login with any user and pass or without pass, nor admin..
Unfortunately yes, not all devices though and resetting credentials does not help...

Yes, resetting credentials doesn't help.
I noticed that it happens to device that are in bridge mode.
Any help or solution?

Posted: **Sun Jul 07, 2019 11:35 pm**

Mine upgraded hAP lite, files login using Winbox the first time I try. Second try ok.
Seems to be every time.

Posted: **Mon Jul 08, 2019 10:35 am**

Hi everyone,

I have a problem with queue and idle timeout in my default profile with radius authaticated users.

When a user try to login with the radius authetication (this one works for me), he will use my default user profile.
BUT he won't get my custom IDLE-TIMEOUT and won't create a NEW QUEUE in queues list, that are both in my user default profile.

If I use a local user with the same user profile, I don't have this problem.
If I use different parameters, I tried for example "keepalive-timeout", they will work as usual.

I don't know why, but these two paramethers are skipped in the authetication process with radius.
In addition to that my radius doesn't provide these two paramethers...

Problem only in v.6.45.1, in v6.44.3 (my previous version) all ok.

Thanks

Someone has a solution for these problems?

Posted: **Mon Jul 08, 2019 12:23 pm**

Someone has a solution for these problems?

Please enable RADIUS debug logs and send us the supout.rif file to support@mikrotik.com:

/system logging add topics=radius

Posted: **Mon Jul 08, 2019 1:32 pm**

Just to let you all know:
SNMP v.3 problem with "unsupported v3 security level" error was already reported to Mikrotik with ticket number [Ticket#2019070422003642].
I have been asked for some additional information, I provided response, but after that no news. Hope Mikrotik is working on correction.

Posted: **Mon Jul 08, 2019 1:32 pm**

Does someone have a problem with mac telnet login via neighbours?

Won't login with any user and pass or without pass, nor admin..

I have the same problem.

Posted: **Mon Jul 08, 2019 1:43 pm**

Someone has a solution for these problems?
Please enable RADIUS debug logs and send us the supout.rif file to support@mikrotik.com:
Code: Select all
/system logging add topics=radius

Hi Skylark, it's the first log that I checked.

Jul/08/2019 12:30:32 radius,debug new request 3f:138 code=Access-Request service=hotspot called-id=ServerWiFi
Jul/08/2019 12:30:32 radius,debug sending 3f:138 to 10.97.0.254:1812
Jul/08/2019 12:30:32 radius,debug,packet sending Access-Request with id 64 to 10.97.0.254:1812
Jul/08/2019 12:30:32 radius,debug,packet Signature = 0x189a769b54e49eb471f324542ca88611
Jul/08/2019 12:30:32 radius,debug,packet NAS-Port-Type = 19
Jul/08/2019 12:30:32 radius,debug,packet Calling-Station-Id = "C0:3F:D5:5B:00:EC"
Jul/08/2019 12:30:32 radius,debug,packet Called-Station-Id = "ServerWiFi"
Jul/08/2019 12:30:32 radius,debug,packet NAS-Port-Id = "ether5"
Jul/08/2019 12:30:32 radius,debug,packet User-Name = "username"
Jul/08/2019 12:30:32 radius,debug,packet NAS-Port = 2147483668
Jul/08/2019 12:30:32 radius,debug,packet Acct-Session-Id = "80000014"
Jul/08/2019 12:30:32 radius,debug,packet Framed-IP-Address = 10.10.250.250
Jul/08/2019 12:30:32 radius,debug,packet MT-Host-IP = 10.10.250.250
Jul/08/2019 12:30:32 radius,debug,packet User-Password = 0x4d34746963
Jul/08/2019 12:30:32 radius,debug,packet Service-Type = 1
Jul/08/2019 12:30:32 radius,debug,packet WISPr-Logoff-URL = "http://10.10.250.1/logout"
Jul/08/2019 12:30:32 radius,debug,packet NAS-Identifier = "Test"
Jul/08/2019 12:30:32 radius,debug,packet NAS-IP-Address = 10.97.0.103
Jul/08/2019 12:30:34 radius,debug,packet received Access-Accept with id 64 from 10.97.0.254:1812
Jul/08/2019 12:30:34 radius,debug,packet Signature = 0x65367fa61743ee7525aa52a67d3b8f7e
Jul/08/2019 12:30:34 radius,debug,packet Session-Timeout = 79503
Jul/08/2019 12:30:34 radius,debug,packet WISPr-Redirection-URL = "welcome.html"
Jul/08/2019 12:30:34 radius,debug received reply for 3f:138

There are only two variables in my radius reply:
- Session-Timeout = 79503
- WISPr-Redirection-URL = "welcome.html"

No idle timeout variable.

Anyway, I manage to get an idle-timeout with this change

/ip hotspot set ServerWiFi idle-timeout=1h
/ip hotspot user profile unset default idle-timeout

It seems that the idle-timeout for user profile doesn't count anymore in radius authentication.

I still have the problem with queue... I can't create them with radius authentication.

Posted: **Mon Jul 08, 2019 1:59 pm**

Last Link Up/Down Time botched. It started happening to me (951G-2HnD, 941-2nD) on the latest stable ROS 6.45.1 / WinBox 3.19. Ethernet and ppp links.

WinBox Terminal - correct:
last-link-down-time=jul/08/2019 12:31:21

WinBox Interface List - wrong:
Last Link Down Time: Jul/14/2019 09:44:52

Today is Jul/08.

Mikrotik seriously, are you drunk? Search on this forum reveals, this or very similar similar issue was reported years or months ago.

Posted: **Mon Jul 08, 2019 2:15 pm**

Last Link Up/Down Time botched. It started happening to me (951G-2HnD, 941-2nD) on the latest stable ROS 6.45.1 / WinBox 3.19. Ethernet and ppp links.

WinBox Terminal - correct:
last-link-down-time=jul/08/2019 12:31:21

WinBox Interface List - wrong:
Last Link Down Time: Jul/14/2019 09:44:52

Today is Jul/08.

Mikrotik seriously, are you drunk? Search on this forum reveals, this or very similar similar issue was reported years or months ago.

This is a Winbox bug, not a RouterOS bug. And it didn't appear on 6.45.1, but long before that.
It has been reported numerous times but MikroTik says it's just a cosmetic bug, so no fix yet.

Posted: **Mon Jul 08, 2019 3:40 pm**

Last Link Up/Down Time botched. It started happening to me (951G-2HnD, 941-2nD) on the latest stable ROS 6.45.1 / WinBox 3.19. Ethernet and ppp links.
This is a Winbox bug, not a RouterOS bug. And it didn't appear on 6.45.1, but long before that.
It has been reported numerous times but MikroTik says it's just a cosmetic bug, so no fix yet.

I don't expect a winbox release for this, but it surprised me a little that the 3.19 release did not include the fix for this long-known issue...

Posted: **Mon Jul 08, 2019 5:13 pm**

I tried upgrading 2 routers that had minimal clients. OSPF has routers running at 100% CPU after upgrade and routes are not forwarding. After downgrade all works as expected. Not sure what is causing this.

Posted: **Mon Jul 08, 2019 5:22 pm**

my web proxy not work on this version. may somebody give me help?

the same issue

Posted: **Mon Jul 08, 2019 6:45 pm**

After upgrade some BSU for test, i have problem with mac authentication on my centralized radius.

I'm come back to 6.44.3

Mikrotik team, please fix bug.

Posted: **Mon Jul 08, 2019 6:46 pm**

hi
just to let you know if you are also not able to upgrade your hap lite.

Solution from mikrotik:

Hello,

Based on your provided information:
system,error not enough space for upgrade 

Please use the Netinstall utility to reinstall the device:
https://wiki.mikrotik.com/wiki/Manual:Netinstall

How this can be done remote ? I dont know.

And does this mean we have now to do this everytime, as the sw is now to large for 16M Flash ?

Posted: **Mon Jul 08, 2019 7:47 pm**

I was running the 45RC betas and I did not notice these issues. but maybe I was not using the features that now have issues.

So all the issues in this thread were in the RC ?

Or were these issues introduced after the RC ?

Were the 5 CVEs patched in the RCs or did those patches only get included in the stable ?

Im just wondering how these issues got all the way into a stable release and how to prevent this in the future.

Posted: **Mon Jul 08, 2019 10:05 pm**

Hi
now i have upgraded 3 of my 4 hAP lite and i noticed that the one having the issue is only showing 7.4 MB free-hdd-space. The others are all showing more or equal to 7.5 MB.
What is consuming the space ? The config is "just" 98 lines other configs in the other haPlite were 154 lines or more.

How can i see what is stored on the flash ?

Anybody an idea ?

Posted: **Mon Jul 08, 2019 10:20 pm**

You can't see what's taking the space.
Netinstall it and use the unbundled packages (just the ones you need, not all of them).

Posted: **Mon Jul 08, 2019 11:04 pm**

Anyone having poor/worse wifi performance after the update?
Edit:
Tried reverting (downgrading) RouterOS to 6.44.3 (firmware too) and wifi is fixed. This update basically returned the issues mentioned in viewtopic.php?t=131960
worse performance over 2ghz and terrible performance over 5ghz on the hAP AC^2.I was getting ~500ms ping over AC wifi, but with the older routeros and firmware its ~3ms under the same conditions. Clearly something broke with this update for this particular device. The other end of the wireless connection is Intel AC 3160 (the version with bluetooth). Tell me if you need more info on this in order to fix it.

Posted: **Tue Jul 09, 2019 11:08 am**

I installed a new switch and access points at a client site yesterday running 6.45.1. The existing equipment onsite is all running 6.42.7. I wasn't able to upgrade it at the time (would have caused an interruption).
While onsite, I didn't have any problems, but now that I'm back in my office and trying to connect to these devices via RoMON, I'm finding the same authentication issue others have reported (ERROR: wrong username or password).
I've upgraded to Winbox 3.19 and this hasn't solved the problem.
I'm still able to access the devices via SSH from the router.

Posted: **Tue Jul 09, 2019 11:50 am**

11:36:27 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:36:37 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:37:07 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:37:18 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:37:47 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:37:58 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:38:27 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:38:39 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:39:08 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:39:20 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:39:48 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:40:01 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:40:28 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:40:42 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:41:08 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:41:22 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:41:48 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:42:02 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:42:28 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:42:43 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:43:08 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:43:23 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:43:48 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:44:04 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:44:28 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:44:45 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:45:08 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:45:26 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:45:48 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:46:07 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:46:29 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:46:48 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:47:09 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way
11:47:29 route,ospf,info OSPFv2 neighbor 10.9.0.1: state change from Loading to 2-Way

downgrade 6.44, ospf works :[

about 20 routers, half was updated, all updated did this. downgrade fixes ;[

ospf with backbone and 23 nssa areas.
two links from bbone to nssa.

‍♂️
vrf.

edit.
added a nokia to the mix:

"LCL_RTR_ID 10.9.0.1: Neighbor 0.0.0.6 on TEST-NBR router state changed to exchangeStart (event SEQ_MISM)"

Posted: **Tue Jul 09, 2019 12:12 pm**

new switch and access points running 6.45.1

The existing equipment onsite is all running 6.42.7

Looks like that is the answer. You cannot connect to >= 6.45 from <= 6.42.

Posted: **Tue Jul 09, 2019 1:28 pm**

How do I exclude an IP Range from an IPsec Policy in 6.45.1. Previously I did the following, like mentioned here viewtopic.php?t=118224

/ip ipsec policy
add action=none comment="do not tunnel local network" dst-address=10.11.1.0/24 src-address=0.0.0.0/0
add dst-address=10.0.0.0/8 proposal=phase2 sa-dst-address=1.2.3.4 sa-src-address=4.3.2.1 src-address=10.11.1.0/24 tunnel=yes

With 6.45.1 I cannot set the first policy. When I assign an existing peer, I get "Couldn't change IPsec Policy. Addresses in transport mode are updated automatic (6)". When I create a new peer having the address 10.11.1.0/24 and assign the policy, it's not excluding anything and stays red.

/ip ipsec peer
add address=10.11.1.0/24 exchange-mode=ike2 name=local passive=yes profile=phase1
/ip ipsec policy
add action=none dst-address=10.11.1.0/24 peer=local src-address=0.0.0.0/0

What's actually the correct way to exclude an overlapping IP Range when using IPsec?

Posted: **Tue Jul 09, 2019 1:36 pm**

Add the policy with action=none and no peer:

/ip ipsec policy
add action=none dst-address=10.11.1.0/24 src-address=0.0.0.0/0

Peer is displayed as "unknown" in Winbox, but that's a cosmetic issue.

Posted: **Tue Jul 09, 2019 1:41 pm**

Or set tunnel=yes for action=none policies. We will fix action=none policies in next release.

EDIT: actually this is not correct and addresses will change after the phase 1 recreation.

Posted: **Tue Jul 09, 2019 2:54 pm**

Add the policy with action=none and no peer:
Code: Select all
/ip ipsec policy
add action=none dst-address=10.11.1.0/24 src-address=0.0.0.0/0
Peer is displayed as "unknown" in Winbox, but that's a cosmetic issue.

Perfect! That works! I forgot to try via Terminal... Thank you!

Or set tunnel=yes for action=none policies. We will fix action=none policies in next release.

That's also working, if I use a "dummy" local peer. Otherwise it keeps changing the dst-address. Still, I'll prefer the first, more simple, solution! Thank you both!

Posted: **Tue Jul 09, 2019 11:52 pm**

Does someone have a problem with mac telnet login via neighbours?

Won't login with any user and pass or without pass, nor admin..
I have the same problem.

I have too

Wysłane z mojego SM-G975F przy użyciu Tapatalka

Posted: **Wed Jul 10, 2019 1:48 pm**

Same problem, after upgrade i was unable to login again on router via IP in winbox 3.19

I need a solution for that...

Posted: **Wed Jul 10, 2019 2:13 pm**

Same problem, after upgrade i was unable to login again on router via IP in winbox 3.19
I need a solution for that...

Try Tools > Clear Cache

Posted: **Wed Jul 10, 2019 2:23 pm**

Same problem, after upgrade i was unable to login again on router via IP in winbox 3.19
I need a solution for that...
Try Tools > Clear Cache

already have done that and the problem persistes.. its a Mini LTE Router .. and i m trying to connect via IP remotelly... and keep telling me wrong username or password

Posted: **Wed Jul 10, 2019 3:44 pm**

Hi Colleagues,

After reading the whole topic and testing using my own prod

("CRS326-24G-2S+" < GRE over IKEv2 tunnel > "HAPac") site it is still unclear for Me which firewall configuration expected to be 'proper' since fixing CVE-2014-8160 in RoS 6.45.1

My observations after update from RoS 6.44.3 to RoS 6.45.1 are the following:
- IKEv2 based tunnel works as expected, nothing changes
- HAPac can up GRE tunnel to CRS326-24G-2S+ without any issues
- CRS326-24G-2S+ can't up GRE tunnel to HAPac
- Adding of only ONE of the suggested in this topic rule "/ip firewall filter add chain=input action=accept protocol=gre ipsec-policy=in,ipsec" or "/ip firewall raw add chain=prerouting action=notrack protocol=gre" for both ends doesn't help to bring up GRE tunnel from CRS326-24G-2S+ to HAPac
- Adding of BOTH of the mentioned rules in 'filter->input' and 'raw->prerouting' respectively helps to bring up GRE tunnel from CRS326-24G-2S+ to HAPac

According to viewtopic.php?f=21&t=149786&start=150#p737612 'filter->input' rule is obvious "MUST to HAVE" for allowing new incoming GRE connections since RoS 6.45.1.
What about 'raw->prerouting' rule suggested in viewtopic.php?f=21&t=149786&start=50#p737382 which also seems influences behavior of GRE in my setup?

Mikrotik guys and forum Gurus could you please provide neat answer on this matter?

Thank you!

I will try the temporal fix later when users are not working.
Temporary? Please read the topic once again, carefully. This version fixes a bug that allowed GRE to work even when your device was configured improperly. So you do not need to apply a temporary fix, but rather permanently fix your configuration.

Posted: **Wed Jul 10, 2019 5:14 pm**

Mikrotik guys and forum Gurus could you please provide neat answer on this matter?

It is not possible to say which is the "correct" way because the firewall rules form up an inter-dependent system:

if you have no firewall rules at all (which is by no means recommended, just to illustrate the case), any packet from anywhere, including the GRE ones, will be accepted, because the default handling in all filter chains is "accept";
if you have the default firewall rules for SOHO devices (hEX, hAP, RB2011, ...), there are two important rules in input chain:
- action=accept connection-state=established,related,untracked
- action=drop in-interface-list=!LAN
The output chain in this default firewall setup is empty which means the Mikrotik itself can send anything anywhere.
The default firewall setup follows the concept of a stateful firewall, which depends on existence of a connection tracking module in the firewall. When using a stateful firewall, you only have to deal in detail with the initial packet of each connection; if you accept it, a record describing the properties of the resulting connection is created in the connection tracking, so subsequent packets belonging to either direction of that connection are attributed with "connection-state=established", whereas packets related to that connection in some way (like upstream icmp packets informing about packet being dropped due to size) are attributed with "connection-state=related", so in both cases the first rule above accepts them without inspecting their other properties.
Now if you use a rule in /ip firewall raw table, saying "action=untrack protocol=gre [in-interface[-list]=... src-address-[list]=...]", you tell the connection tracking to ignore packets matching the criteria, so in filter, they are attributed with "connection-state=untracked" and thus the first rule mentioned above accepts them. If you don't do this, the initial GRE packet coming from outside matches none of the three connection-states for which the first rule checks, so unless you place some action=accept rule for protocol=gre into /ip firewall filter table before the last one mentioned above (which is the other possibility suggested earlier in this topic), the first GRE packet coming from outside will be dropped by that last rule in input chain of filter and the GRE tunnel will not come up (and as no tracked connection will be created, all subsequent received GRE packets will be treated as first ones again). But if the local Mikrotik sends some payload packet to the GRE tunnel (it doesn't matter whether a locally-originated or a transit one), or if keepaliving is activated on the tunnel's configuration, the outgoing GRE packet encapsulating that payload one will create a tracked connection (because it is handled by the empty chain output of /ip firewall filter which accepts it), so a GRE packet in the opposite direction (with swapped src and dst IP addresses) should be accepted even without any of the two suggested rules in place. However, there used to be an issue in connection tracking, where instead of a single bi-directional connection, each direction of a GRE connection was treated as a separate tracked connection; I don't know whether this issue has been fixed in 6.45.1 or not. If not, you need one of the rules above even if the local side sends first.
yet another case is where a GRE "session" is established under control of come control protocol, like PPTP (where a TCP session is used for control communication and GRE is used for the actual transport of data). In this case, the GRE packets with corresponding source and destination address match the "connection-state=related" in the first rule above so it accepts them; but for this to happen, a process (usually called "helper") in the firewall, which analyses the control communication of the PPTP, has to be enabled so that it would tell the connection tracker what GRE connection to expect. To enable that process, you need to enable the pptp item in /ip firewall service-port

So if your firewall is different from the default SOHO one (e.g. because it has been kept unchanged from older versions of ROS where connection-state=untracked was not supported), you have to choose the right rule and put it to the right place in the chain. Same applies if GRE connections only transit through your Mikrotik between other devices - the filter rule suggested in this topic only help GRE tunnels running on the Mikrotik itself, you need a similar rule in chain=filter for transit GRE connections. On the other hand, the PPTP helper works also for transit connections.

Posted: **Wed Jul 10, 2019 5:43 pm**

Does someone have a problem with mac telnet login via neighbours?
Won't login with any user and pass or without pass, nor admin..
I have the same problem.

MAC telnet works perfect here

Posted: **Wed Jul 10, 2019 8:12 pm**

Does someone have a problem with mac telnet login via neighbours?
Won't login with any user and pass or without pass, nor admin..
I have the same problem.
MAC telnet works perfect here

Good for you..

On device in bridge or station mode?

Posted: **Wed Jul 10, 2019 8:38 pm**

On device in bridge or station mode?

I have used it in a unit with bridged ports (Ether/WiFi) and worked without issues.

Posted: **Wed Jul 10, 2019 10:38 pm**

good afternoon! here after update all my ipv6 has stopped! ospf v3 works by the mikrotik terminal I ping out via ip v6 but even with the local v6 pool and prefix ipv6 delegation on pppoe server my clients do not get prefixes anyone else with this problem after updating? I did this in 8 ccr and all stopped ipv6

Posted: **Thu Jul 11, 2019 6:51 am**

Upgraded RB4011 from 6.44.3 to 6.45.1 - no issues
Well, actually there is one - the bridge MAC address has changed so the network discovery on Windows must be done again. In my case the bridge MAC addr is the same as for eth7 interface. Interesting what it depends on...
Best
Bam

Here same issue on 3 Devices upgraded from 6.44.3 to 6.45.1.

In my case this cause two major problems :
1. Static DHCP offer of DHCP Server didn't work because of changed MAC -> Login to know IP Address didn't work anymore because get no or a dynamic address from DHCP server
2. The Bridge get the MAC from the WLAN Interface which cause major porblem's in CAPSMAN configuration. There was a lot of 'receive packet from same interface, may loop' messages in the CPASMAN log. The cap client interface's repeatedly connect / disconnect from the CAPSMAN -> WLAN dead

I fix this issue by set the Admin MAC of each bridge manualy.

In my case, it is due to CAPsMAN certificate issue and after I revoke the certificate, CAPsMAN works again in all AP devices.

Posted: **Thu Jul 11, 2019 9:46 am**

Issues we have noticed:
1. cannot create support file, router goes offline, and come back but needs to be rebooted.
2. ospf, crashes, reboot is only resort.

Thanks.

Posted: **Thu Jul 11, 2019 9:56 am**

Upgraded RB4011 from 6.44.3 to 6.45.1 - no issues
Well, actually there is one - the bridge MAC address has changed so the network discovery on Windows must be done again. In my case the bridge MAC addr is the same as for eth7 interface. Interesting what it depends on...
Best
Bam

Good to know. At the moment i do not use certificates.

Here same issue on 3 Devices upgraded from 6.44.3 to 6.45.1.

In my case this cause two major problems :
1. Static DHCP offer of DHCP Server didn't work because of changed MAC -> Login to know IP Address didn't work anymore because get no or a dynamic address from DHCP server
2. The Bridge get the MAC from the WLAN Interface which cause major porblem's in CAPSMAN configuration. There was a lot of 'receive packet from same interface, may loop' messages in the CPASMAN log. The cap client interface's repeatedly connect / disconnect from the CAPSMAN -> WLAN dead

I fix this issue by set the Admin MAC of each bridge manualy.
In my case, it is due to CAPsMAN certificate issue and after I revoke the certificate, CAPsMAN works again in all AP devices.

Good to know. At the moment I do not use certificates.

Posted: **Thu Jul 11, 2019 10:04 am**

joserudi - Please send supout file to support@mikrotik.com. Generate file while the problem is present and name at least single user which does not get rate-limit;
LeftyTs, Ulypka, gepelbaum, nostromog, CharlyBrown, xtrans - Please send supout file to support@mikrotik.com. Generate file while the problem is present;
mserge - Make sure that you use Winbox 3.19. If the problem persists, then generate a new supout file on your router after failed Winbox login attempt and send it to support@mikrotik.com;
owsugde - Is it possible that you are using a certificate verification feature which was introduced in this release? "ovpn - added "verify-server-certificate" parameter for OVPN client (CVE-2018-10066)"
dlausch - Sound like you have the same problem as we did with Winbox. Also new iOS MikroTik mobile application update will be released very soon;

Everyone - Everyone who is experiencing RADIUS related problems with authentication since v6.45, we will soon release 6.46beta version with potential fix for the problem;
Everyone - Long-term version will be released as soon as possible. There is no ETA since everyone will want version as stable as possible. We can not simply name date and time when the version will be released. It depends on test results.
CCR1036-8G-2S+ , having random reboot by watchdog after upgrade to 6.45.1.
I have sent the supout file

thx

dear mikrotik,

router still stable after downgraded to 6.44.3, routerboard firmware still using 6.45.1
please fix this issue.

thx

Posted: **Thu Jul 11, 2019 11:43 am**

I wonder why Mikrotik guys don't pin this instruction to every hAP lite (may be other cheap, low memory, smips) device:

Don't expect too many features of it, especially memory hangry ones!
Don't use bundled "Main package" RouterOS at all -- that files are too heavy for lite devices. Download only full "Extra packages" *.zip to your computer.
Setup, configure and tune the device with only needed functions and DISABLE all unneeded packages (grey them off in System->Packages)
Backup and download to computer your current config (binary and /export file=config.rsc too)!!!
When upgrade first time, unpack and upload into Files ONLY enabled new *.npk from *.zip "Extra packages" (all used -- or you can loose some config, for example, wireless -- then you'll need to replay some parts from saved config.rsc in terminal)
REBOOT (cross your fingers and pray

After that your will have only neccessary packages set on your device, plenty (I hope) space for updates and the ability to do it automatically later.

Posted: **Thu Jul 11, 2019 11:57 am**

Well that is mostly standard for every MikroTik device deployment and upgrade... except point #1 for the more powerful devices.

Posted: **Thu Jul 11, 2019 12:23 pm**

6.45.1 works fine on hAP AC, hAP AC lite, RB932, RB952, wAP AC. RB4011 - everything works except 5ghz, Colleagues! fix 5ghz on RB4011 and i will be happy

Posted: **Thu Jul 11, 2019 1:20 pm**

Anyone who had problems with OSPF (/routing ospf lsa print triggers busy loop) in this version please try 6.46beta9 if possible.

Posted: **Thu Jul 11, 2019 3:34 pm**

It is not possible to say which is the "correct" way because the firewall rules form up an inter-dependent system:
if you have no firewall rules at all (which is by no means recommended, just to illustrate the case), any packet from anywhere, including the GRE ones, will be accepted, because the default handling in all filter chains is "accept";

if you have the default firewall rules for SOHO devices (hEX, hAP, RB2011, ...), there are two important rules in input chain:
action=accept connection-state=established,related,untracked

action=drop in-interface-list=!LAN
The output chain in this default firewall setup is empty which means the Mikrotik itself can send anything anywhere.
The default firewall setup follows the concept of a stateful firewall, which depends on existence of a connection tracking module in the firewall. When using a stateful firewall, you only have to deal in detail with the initial packet of each connection; if you accept it, a record describing the properties of the resulting connection is created in the connection tracking, so subsequent packets belonging to either direction of that connection are attributed with "connection-state=established", whereas packets related to that connection in some way (like upstream icmp packets informing about packet being dropped due to size) are attributed with "connection-state=related", so in both cases the first rule above accepts them without inspecting their other properties.
Now if you use a rule in /ip firewall raw table, saying "action=untrack protocol=gre [in-interface[-list]=... src-address-[list]=...]", you tell the connection tracking to ignore packets matching the criteria, so in filter, they are attributed with "connection-state=untracked" and thus the first rule mentioned above accepts them. If you don't do this, the initial GRE packet coming from outside matches none of the three connection-states for which the first rule checks, so unless you place some action=accept rule for protocol=gre into /ip firewall filter table before the last one mentioned above (which is the other possibility suggested earlier in this topic), the first GRE packet coming from outside will be dropped by that last rule in input chain of filter and the GRE tunnel will not come up (and as no tracked connection will be created, all subsequent received GRE packets will be treated as first ones again). But if the local Mikrotik sends some payload packet to the GRE tunnel (it doesn't matter whether a locally-originated or a transit one), or if keepaliving is activated on the tunnel's configuration, the outgoing GRE packet encapsulating that payload one will create a tracked connection (because it is handled by the empty chain output of /ip firewall filter which accepts it), so a GRE packet in the opposite direction (with swapped src and dst IP addresses) should be accepted even without any of the two suggested rules in place. However, there used to be an issue in connection tracking, where instead of a single bi-directional connection, each direction of a GRE connection was treated as a separate tracked connection; I don't know whether this issue has been fixed in 6.45.1 or not. If not, you need one of the rules above even if the local side sends first.

sindy,

Thank you for detailed explanation.

You was right about absence of 'untracked' connection type in state-full allow rule, now I have got why BOTH of rules in 'filter->input' and 'raw->prerouting' was fixing my setup

But one unclear fact still present: If I left only "/ip firewall filter add chain=input action=accept protocol=gre ipsec-policy=in,ipsec" rule, GRE tunnel still not start UP until I disable ''/ip firewall filter add chain=input action=drop connection-state=invalid" which is placed as the FIRST rule of 'filter->input' chain.
So it seems in my setup RoS marked the very first incoming GRE packet with "connection-state=invalid", and seems this happens before packet reach "...action=accept protocol=gre..." rule.(That is why "...action=untrack protocol=gre.." helped packet to reach "...action=accept protocol=gre..." rule) o_0

Posted: **Thu Jul 11, 2019 3:49 pm**

@baks this is why the drop invalid rule is placed AFTER the accept established,related,untracked rule.

1    ;;; defconf: accept established,related,untracked
      chain=input action=accept connection-state=established,related,untracked log=no log-prefix="" 

 2    ;;; defconf: drop invalid
      chain=input action=drop connection-state=invalid log=no log-prefix=""

Posted: **Thu Jul 11, 2019 4:02 pm**

6.45.1 works fine on hAP AC, hAP AC lite, RB932, RB952, wAP AC. RB4011 - everything works except 5ghz, Colleagues! fix 5ghz on RB4011 and i will be happy

Hey, a few quick questions.
Is that the hAP AC2 version?
What exactly is the issue you have with wifi? Mine is huge ping, low throughput, like 10mbit in just the one direction.
Im trying to get more info. So far ive noticed that the previous stable is fine, the current long term is fine too.
Can I have your wifi settings and compare? Thanks.

Posted: **Thu Jul 11, 2019 4:11 pm**

6.45.1 works fine on hAP AC, hAP AC lite, RB932, RB952, wAP AC. RB4011 - everything works except 5ghz, Colleagues! fix 5ghz on RB4011 and i will be happy
Hey, a few quick questions.
Is that the hAP AC2 version?
What exactly is the issue you have with wifi? Mine is huge ping, low throughput, like 10mbit in just the one direction.
Im trying to get more info. So far ive noticed that the previous stable is fine, the current long term is fine too.
Can I have your wifi settings and compare? Thanks.

Hi, I have a hAP AC (RB962), the device just fine. There were no problems with him.

Problems with RB4011, read the thread: viewtopic.php?f=3&t=142298&start=100

Posted: **Thu Jul 11, 2019 5:01 pm**

@baks this is why the drop invalid rule is placed AFTER the accept established,related,untracked rule.
Code: Select all
1    ;;; defconf: accept established,related,untracked
      chain=input action=accept connection-state=established,related,untracked log=no log-prefix="" 

 2    ;;; defconf: drop invalid
      chain=input action=drop connection-state=invalid log=no log-prefix=""

Well... it does explain the behaviour, but I can see no reason why the first ever incoming GRE packet from a given IP address to another given IP address should be attributed with "connection-state=invalid", it should bear a normal "connection-state=new" attribute. For me, connection-state=invalid is for plain TCP packets coming after a packet with FIN flag has already been seen and stuff alike, so to me it looks like another bug.

Posted: **Thu Jul 11, 2019 5:12 pm**

As per my observation 6.45.1 is more resource hungry than the long-term 6.44.5 on hAP ac2. The router has a default configuration and not connected to WAN link. I would say that 5-10% of CPU utilization for a device in idle state is quite high. When running at 6.44.5, the CPU utilization is 1-4%. Another interesting fact is at 6.44.3 CPU utilization of a similar device (another hAP ac2 unit) in idle state rarely jumps over 2%.

6.45.1

2019-07-11_hAPac2_6.45.1.png

6.44.5

2019-07-11_hAPac2_6.44.5.png

Posted: **Thu Jul 11, 2019 5:41 pm**

I can see no reason why the first ever incoming GRE packet from a given IP address to another given IP address should be attributed with "connection-state=invalid", it should bear a normal "connection-state=new" attribute. For me, connection-state=invalid is for plain TCP packets coming after a packet with FIN flag has already been seen and stuff alike, so to me it looks like another bug.

This change is a bit of a mystery. You would think that there usually is some background traffic on networks, and when a GRE tunnel is setup there will usually be some outgoing packet that creates a connection and then the incoming packets are accepted as "established" on that connection. It would probably be tough to setup a test setup where there is really no outgoing traffic and all incoming is dropped.

However, I think that this change (likely the result of some misunderstanding) has now introduced the situation where a registered GRE "connection" does not accept incoming traffic until that has been accepted at least once. I.e. the outgoing GRE traffic does not setup a fully valid connection, there first has to be incoming accepted traffic as well. Incoming traffic on a "half open" GRE "connection" (that has only seen outgoing traffic) is apparently now labeled as "invalid".

Like you, I do not see why this would be done. I expect someone has come up with a test case where traffic was unexpectedly allowed (maybe under the threat of a CVE) and changes were made to close that "leak" without fully researching what was happening and if that indeed is a leak. Usually cases where connectionless traffic "meets in the middle" (both sides sending traffic to eachother, e.g. ISAKMP) are accepted as "established" without further matching.

Posted: **Thu Jul 11, 2019 6:00 pm**

Unlike TCP, GRE is completely stateless, there's no way the router knows if an incoming GRE packet is new, related, established or something else. On both endpoints of the tunnel you need to have these firewall rules set up.
Output chain's default action is accept, so you only have to do it for input chain.

Posted: **Thu Jul 11, 2019 6:45 pm**

Unlike TCP, GRE is completely stateless, there's no way the router knows if an incoming GRE packet is new, related, established or something else.

This is of course incorrect. Yes, it is stateless, but no, the router can know if an incoming GRE packet is "established" when it has previously sent a GRE packet to the same address.
This is similar to the handling of UDP. While UDP is stateless, replies on outgoing UDP requests (like DNS) are still accepted as "established".

This is how GRE was handled in versions before 6.45. I have several routers with input rules that first accept established/related and then e.g. GRE with IPsec policy in:ipsec, and
that rule has only a few matches. The bulk is accepted by the established/related rule.
I have not yet tested what happens on a router running 6.45.1 in this regard. I expect my config will still work, as it already had the accept rule for GRE/IPsec. Configs without
that rule (i.e. default settings for the firewall) would now fail.

Posted: **Thu Jul 11, 2019 7:52 pm**

After upgrade some BSU for test, i have problem with mac authentication on my centralized radius.

I'm come back to 6.44.3

Mikrotik team, please fix bug.

Posted: **Thu Jul 11, 2019 8:01 pm**

I agree with sindy and pe1chl. To my mind "IP/Firewall/Connection tracking" in RoS is equivalent of RHEL 'conntrack-tool' which operate with raw network packets that get into firewall processing and try to bind each packet to 'new/established/related/untracked' connection state in terms of 'Connection tracking' logic even if the protocol itself not support any 'connections' or similar states.

For now situation with 6.45.1 looks like the following( based on '/system default-configuration print' from HAPac):
- Default ACCEPT rues configured in Filter->Input' chain

                     
...
                     /ip firewall {
                       filter add chain=input action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"
                       filter add chain=input action=drop connection-state=invalid comment="defconf: drop invalid"
...

- As suggested by strods (MikroTik Support) in viewtopic.php?f=21&t=149786&start=100#p737462 add ADDITIONAL ACCEPT rule AFTER default rules mentioned above

 
filter add chain=input action=accept protocol=gre ipsec-policy=in,ipsec

- Very first incoming GRE packet will be dropped by "chain=input action=drop connection-state=invalid" and will never reach ADDITIONAL ACCEPT rule, GRE tunnel is DOWN
- As workaround it is possible to skip 'Connection tracking' processing by adding 'raw add chain=prerouting action=notrack protocol=gre'. In such a case very first incoming GRE packet will be accepted by default rule 'chain=input action=accept connection-state=established,related,untracked' however it will not reach ADDITIONAL ACCEPT rule either, GRE tunnel is UP

In my initial setup I have no rule matching 'untracked', so packet finally was accepted by ADDITIONAL ACCEPT rule but this fact not changes situation much.

The main question now why very first GRE packet is marked as 'invalid' by 'Connection tracking' mechanism? ( I suppose that this issue occurred since RoS 6.45.1, however hasn't managed to perform tests with downgrade so far)

Posted: **Thu Jul 11, 2019 8:58 pm**

Has anyone solved these password issues as yet to access the routers ?

We have one remote router which is in a different country. We have a STTP VPN direct to the router which is showing as connected but the username and password are not working - It was working fine before it was upgraded.

It has or at least had a 16 digit random password on it with a custom username.

Tried using the username without a password
Tried the admin account with no password
Tried asking a staff member to reboot it

Still no access and we're not really sure what to try next - Any help much appreciated
I have the same problem, see post #55. I have not found a workaround.

Sent from my Pixel 3 using Tapatalk
Thanks for the response.

Good to know it works on the same network at least - we can get access to a local machine to get on it and downgrade again so we have access, giving us some time to do some testing in the office.

If you do manage to work this out please do let me know - i will of course do the same if we can find a solution.

Downgrading it doesn't work for me.

but I'm able to login with winbox on local network. not from remote network. even when no vpn is setup on the router in question. this is on x86. it's like there is a timeout and and it's coming back with the wrong username or password.

Here's current config.

 
  MMM      MMM       KKK                          TTTTTTTTTTT      KKK
  MMMM    MMMM       KKK                          TTTTTTTTTTT      KKK
  MMM MMMM MMM  III  KKK  KKK  RRRRRR     OOOOOO      TTT     III  KKK  KKK
  MMM  MM  MMM  III  KKKKK     RRR  RRR  OOO  OOO     TTT     III  KKKKK
  MMM      MMM  III  KKK KKK   RRRRRR    OOO  OOO     TTT     III  KKK KKK
  MMM      MMM  III  KKK  KKK  RRR  RRR   OOOOOO      TTT     III  KKK  KKK

  MikroTik RouterOS 6.44.3 (c) 1999-2019       http://www.mikrotik.com/

[?]             Gives the list of available commands
command [?]     Gives help on the command and list of arguments

[Tab]           Completes the command/word. If the input is ambiguous,
                a second [Tab] gives possible options

/               Move up to base level
..              Move up one level
/command        Use command at the base level
jul/11/2019 17:40:16 system,error,critical login failure for user blindrain from 1
0.8.0.3 via winbox
[blindrain@vSEP] > /export compact     
# jul/11/2019 17:49:42 by RouterOS 6.44.3
# software id = 5HM8-QX9C
#
#
#
/interface bridge
add name=lo
/interface ethernet
set [ find default-name=ether1 ] advertise=\
    10M-half,10M-full,100M-half,100M-full,1000M-half,1000M-full
set [ find default-name=ether2 ] advertise=\
    10M-half,10M-full,100M-half,100M-full,1000M-half,1000M-full
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/tool user-manager customer
set admin access=\
    own-routers,own-users,own-profiles,own-limits,config-payment-gw
/user group
add name=api policy="local,ssh,read,write,test,sensitive,api,!telnet,!ftp,!reboo\
    t,!policy,!winbox,!password,!web,!sniff,!romon,!dude,!tikapp"
add name=ssh policy="ssh,!local,!telnet,!ftp,!reboot,!read,!write,!policy,!test,\
    !winbox,!password,!web,!sniff,!sensitive,!api,!romon,!dude,!tikapp"
/ip address
add address=192.168.253.74 interface=lo network=192.168.253.74
/ip cloud
set update-time=no
/ip dhcp-client
add dhcp-options=hostname,clientid disabled=no interface=ether1
add dhcp-options=hostname,clientid disabled=no interface=ether2
/system identity
set name=vSEP
/system lcd
set contrast=0 enabled=no port=parallel type=24x4
/system lcd page
set time disabled=yes display-time=5s
set resources disabled=yes display-time=5s
set uptime disabled=yes display-time=5s
set packets disabled=yes display-time=5s
set bits disabled=yes display-time=5s
set version disabled=yes display-time=5s
set identity disabled=yes display-time=5s

set lo disabled=yes display-time=5s
set ether1 disabled=yes display-time=5s
set ether2 disabled=yes display-time=5s
/system package update
set channel=long-term
/system scheduler
add interval=1d name=Upgrade on-event=":if ([/system clock get date]~\"/25/\") d\
    o={\r\
    \n#place instructions here\r\
    \n /system package update install\r\
    \n};" policy=\
    ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon \
    start-date=jul/11/2019 start-time=06:12:16
/tool user-manager database
set db-path=user-manager
[blindrain@vSEP] >

Posted: **Thu Jul 11, 2019 9:18 pm**

- Very first incoming GRE packet will be dropped by "chain=input action=drop connection-state=invalid" and will never reach ADDITIONAL ACCEPT rule, GRE tunnel is DOWN
- As workaround it is possible to skip 'Connection tracking' processing by adding 'raw add chain=prerouting action=notrack protocol=gre'. In such a case very first incoming GRE packet will be accepted by default rule 'chain=input action=accept connection-state=established,related,untracked' however it will not reach ADDITIONAL ACCEPT rule either, GRE tunnel is UP

In my initial setup I have no rule matching 'untracked', so packet finally was accepted by ADDITIONAL ACCEPT rule but this fact not changes situation much.

The main question now why very first GRE packet is marked as 'invalid' by 'Connection tracking' mechanism? ( I suppose that this issue occurred since RoS 6.45.1, however hasn't managed to perform tests with downgrade so far)

/ip firewall raw add action=notrack chain=prerouting in-interface-list=internet protocol=gre
/ip firewall filter add action=accept chain=input connection-state=established,related,new,untracked in-interface-list=internet protocol=gre

if you have deny rules in raw table in end, than put after notrack action:

/ip firewall raw add action=accept chain=prerouting in-interface-list=internet protocol=gre

Posted: **Fri Jul 12, 2019 2:27 am**

Just upgraded my Dude server and a few devices to 6.45.1, all of the 6.45.1 devices don't get any information of SNMP V3 service and security private, MD5 DES settings. After, I upgrade only devices to beta 6.46beta9, but problem persists.
I downgrade only devices to 6.44.3 and works fine SNMP again.

Is there an issue with SNMP V3 Security private MD5 DES in 6.45.1 and newest ?

Posted: **Fri Jul 12, 2019 4:34 am**

Just a FYI...

Going to 6.45.1 on a RB4011iGS+5HacQ2HnD-IN and then dropping 6.44.3 on and downgrading because a list iist of issues caused the WLAN interfaces to be scrambled. Lost all settings and even lost WLAN 1 replaced with a greyed out WLAN 3 with the WLAN 1 chip.

The newly created WLAN 3 and the still present WLAN 2, lost bridge entires leaving "unknown" behind.

So even going back to 6.44.3 did not fix everything and 6.45.1 scrambled settings.

Clearly, IMHO, 6.45.1 is a RC level, and has a list of serious issues. It should clearly not be a "stable" release..

Posted: **Fri Jul 12, 2019 7:55 pm**

( s i g h )

So I had a CCR1036-8G-2S+ that I am using as a beta as my clients all have these in high end homes. I had it on 6.45.1 and it *SEEMED* fine. I decided to move it to 6.46rc6 because 6.45.1 seemed unstable and I was hoping some issues were addressed in the RC.. Again, everything *seemed* fine..

Today I decided to remove a port from a bridge. The router lost all connectivity immd. No port worked.

I rebooted. It would not boot, it hung for a long time.

I rebooted again and was hooked up RS232 and used the boot menu to switch back to my 6.44.3 partition. Everything came right back up. I copied the 44.3 to the bad partition and booted back into that.

So. FYI. 6.46RC6&9 also seem unstable with maybe the same issues from 6.45.1

ALWAYS work with partitions as backup. ALWAYS do a backup and a export compact and drag both files off the router before you upgrade stables or RCs.

Posted: **Fri Jul 12, 2019 10:59 pm**

Regarding protocol 47.
Tested on CHR 6.45.1 (stable) with no default configuration.
Added the folowing 3 filters:

Code: Select all


/ip firewall filter

add action=passthrough chain=input connection-state=invalid protocol=gre

add action=passthrough chain=input connection-state=new protocol=gre

add action=passthrough chain=input connection-state=\

    established,related,untracked protocol=gre

Sending gre packets to this chr instance behaved as expected. There were hits on the connection-state=new (2nd filter rule)
Disabling pptp helper with /ip firewall service-port set pptp disabled=yes
Will cause the first filter rule to get all the hits (connection-state=invalid)
Packets were generated by a eoIP tunnel from another chr instance, so there seems to be a bug in witch all protocol 47 packets are treated as invalid if pptp helper is disabled.
Counter-intuitive if you actually want to use gre tunnel or eoip and no pptp.

Posted: **Sat Jul 13, 2019 12:33 am**

Lots of wierdness in this release on 317s.

Working OSPF stops working - neighbour is not seen from 317 but adjacent 1016 sees ospf neighbor.

Romon stops working.

Downgrade to 6.44.5 works but that breaks some of the SFPs with autoneg that was broken until 6.45 in 317s and early 6.42.x with old autoneg where all works has security bugs.

Ive been using Mikrotik for a long time and these last releases has been devastating quality wise.

Dont change things in the middle of a long-term branch. Right now we have a production network caught between bad releases.

This has been discussed with mikrotik for weeks - they have access to sample switches and no response and still they keep pushing bad releases.

I just halted my order of 30 317s. Not that I think Mikrotik will notice, but this is unacceptable.

Posted: **Sat Jul 13, 2019 7:35 am**

I have a possible bug v6.45.1
Consentrator with L2TP/IPSEC clients
On IPSEC Installed SAs tab, I flush SAs and they don't repopulate until reboot.

The IPSEC Policies tab all clients show PH2 State is "no phase2"

Reboot Consentrator and clients connect normally
LOG

 echo: ipsec,error phase1 negotiation failed due to send error

I have updated about 20 remote clients and several Consentrators without any other unreported problems.

Posted: **Sat Jul 13, 2019 8:30 am**

I have posted some pretty negative posts in this thread about 6.45.1.. So.. I have run across something good and I thought I would pass it along..

Well.. Sorta good..

I netinstalled a CCR1036 on 6.44.3 which was the last stable I knew worked for sure in all the things I do. I then restored a backup I made from before this 6.45.1 mess.

I then pkg updated from WInbox to 6.46beta9... This has gone flawlessly. So far I have no issues, but, I am limited in what I am doing with it.

Still this was good news and I wanted to post it.

Im not sure what the official recommendation is from Mikrotik on 6.45.1, is it best to just skip it and go direct to 6.46beta9 ? Or is a 6.45.2 almost here ?

Posted: **Sat Jul 13, 2019 3:28 pm**

Could someone else please check if routing crashes when viewing OSPF LSAs via Winbox or running '/routing ospf lsa print' via CLI?

Posted: **Sat Jul 13, 2019 9:43 pm**

for me, this release completely bricked my hex
even netinstall didn't work

had to install the long term release, now it works again

Posted: **Sun Jul 14, 2019 10:23 pm**

Could someone else please check if routing crashes when viewing OSPF LSAs via Winbox or running '/routing ospf lsa print' via CLI?

It seems this command is broken on 6.45.1

>/routing ospf lsa print 
AREA                                                                                                                                    TYPE         ID             ORIGINATOR     SEQUENCE-NUMBER        AGE
action timed out - try again, if error continues contact MikroTik support and send a supout file (13)

Seen this issue on multiple devices. Also LSA table on Winbox shows only a subset of the true list.

Posted: **Sun Jul 14, 2019 10:45 pm**

Anyone who had problems with OSPF (/routing ospf lsa print triggers busy loop) in this version please try 6.46beta9 if possible.

Will try and report back.

Posted: **Mon Jul 15, 2019 11:40 am**

I have problem with 6.45.1 version. I can't login via api anymore.

It says "login failure"

This is the code which I am using from php

<?php
use PEAR2\Net\RouterOS;

require_once 'PEAR2/Autoload.php';

try {
    $client = new RouterOS\Client('1.1.9.3', 'admin', 'xxx');
} catch (Exception $e) {
    die('Unable to connect to the router.');
    //Inspect $e if you want to know details about the failure.
}

Posted: **Mon Jul 15, 2019 3:05 pm**

update your api
https://wiki.mikrotik.com/wiki/Manual:API#Initial_login

Posted: **Mon Jul 15, 2019 3:57 pm**

I am not very experienced in php , could someone show me example how to modify the code ?

Posted: **Mon Jul 15, 2019 3:58 pm**

If you are not good in PHP, I suggest to find somebody who is. API programming is not a simple thing to do.

Posted: **Mon Jul 15, 2019 4:04 pm**

Yes, I am using this library PEAR2\Net\RouterOS, I have to contact the author , and tell him to update the api.

Posted: **Mon Jul 15, 2019 4:09 pm**

Hi,
I confirm there is something weird with 5Ghz on HAP ac2. My transfers seems limited to ~20Mb/s with http, and only http. Even 2.4Ghz where faster.
I done several tests, like speedtest, nperf, I was able to reach ~200Mbits/s. I tried iperf and I was able to go up to 100Mb/s, same with SCP transfer. And when I go back to http transfer I always be limited at ~20Mb/s.
I downgrade to 6.44.5 and everything go fine, I can reach ~200Mb/s with http.
I hope you will solve this issue

Posted: **Mon Jul 15, 2019 4:59 pm**

Same problem with mac-telnet login from RouterBoard here.

Tested:
RB2011 with v6.45.1 stable - login via Winbox mac address -> OK;
RB2011 with v6.45.1 stable - login via another RB2011 v6.43.14 stable via mac-telnet - ERROR: "Login failed, incorrect username or password";
RB2011 with v6.45.1 stable - login via another RB2011 v6.45.1 stable via mac-telnet - ERROR: "Login failed, incorrect username or password".

Both RBs was reseted after upgrade and with no default configuration.

Posted: **Mon Jul 15, 2019 5:26 pm**

Another user affected by de issue with RADIUS (User Manager Package). It´s works normally (client authorizations) some time 5-6 days until it stop working, and pppoe clients receive "radius not responding, time out". If the RB is restarted, the RADIUS works again. Coming back to 6.44.3 as soon as possible.

Posted: **Mon Jul 15, 2019 11:20 pm**

Another user affected by de issue with RADIUS (User Manager Package). It´s works normally (client authorizations) some time 5-6 days until it stop working, and pppoe clients receive "radius not responding, time out". If the RB is restarted, the RADIUS works again. Coming back to 6.44.3 as soon as possible.

I have this problem too

Wysłane z mojego SM-G975F przy użyciu Tapatalka

Posted: **Tue Jul 16, 2019 7:04 am**

Same problem with mac-telnet login from RouterBoard here.

Tested:
RB2011 with v6.45.1 stable - login via Winbox mac address -> OK;
RB2011 with v6.45.1 stable - login via another RB2011 v6.43.14 stable via mac-telnet - ERROR: "Login failed, incorrect username or password";
RB2011 with v6.45.1 stable - login via another RB2011 v6.45.1 stable via mac-telnet - ERROR: "Login failed, incorrect username or password".

Both RBs was reseted after upgrade and with no default configuration.

I have the same problem. did you find a solution??

Posted: **Tue Jul 16, 2019 7:30 am**

Upgrade to 6.45.1 OK, but after install UPS package (same version) winbox became unresponsive. Files box is empty, menus not opening, unable to do nothing. SSH very very slow and unresponsive too.

Hex S device

Posted: **Tue Jul 16, 2019 10:35 am**

How about downgrade only the user manager package to 6.44.3 and mantain the main package in 6.45.1, it will work ¿? (only by the circunstances, and supposing that the issue is in this module).

Posted: **Tue Jul 16, 2019 10:43 am**

All packages have to be the same version (and system package leads the game).

Posted: **Tue Jul 16, 2019 10:50 am**

Regarding protocol 47.
Tested on CHR 6.45.1 (stable) with no default configuration.
Added the folowing 3 filters:
Code: Select all
/ip firewall filter add action=passthrough chain=input connection-state=invalid protocol=gre add action=passthrough chain=input connection-state=new protocol=gre add action=passthrough chain=input connection-state=\ established,related,untracked protocol=gre
Sending gre packets to this chr instance behaved as expected. There were hits on the connection-state=new (2nd filter rule)
Disabling pptp helper with /ip firewall service-port set pptp disabled=yes
Will cause the first filter rule to get all the hits (connection-state=invalid)
Packets were generated by a eoIP tunnel from another chr instance, so there seems to be a bug in witch all protocol 47 packets are treated as invalid if pptp helper is disabled.
Counter-intuitive if you actually want to use gre tunnel or eoip and no pptp.

Hi All,

Mikrotik has confirmed this behaviour of 'Connection tracking' tool against GRE traffic as bug in support ticket 2019071222004555

> Re: [Ticket#2019071222004555] GRE configuration inconsistency in RoS 6.45.1
> On Mon, 15 Jul 2019 at 12:32, Arturs C. [MikroTik Support] <support@mikrotik.com> wrote:
> Hello,
> Thank you for reporting this. Yes, there is an issue in RouterOS v6.45.1. We will look forward to fixing it in upcoming RouterOS versions.
> Best regards,
> Arturs C.

Posted: **Tue Jul 16, 2019 11:34 am**

Regarding protocol 47.
Tested on CHR 6.45.1 (stable) with no default configuration.
Added the folowing 3 filters:
Code: Select all
/ip firewall filter add action=passthrough chain=input connection-state=invalid protocol=gre add action=passthrough chain=input connection-state=new protocol=gre add action=passthrough chain=input connection-state=\ established,related,untracked protocol=gre
Sending gre packets to this chr instance behaved as expected. There were hits on the connection-state=new (2nd filter rule)
Disabling pptp helper with /ip firewall service-port set pptp disabled=yes
Will cause the first filter rule to get all the hits (connection-state=invalid)
Packets were generated by a eoIP tunnel from another chr instance, so there seems to be a bug in witch all protocol 47 packets are treated as invalid if pptp helper is disabled.
Counter-intuitive if you actually want to use gre tunnel or eoip and no pptp.
Hi All,

Mikrotik has confirmed this behaviour of 'Connection tracking' tool against GRE traffic as bug in support ticket 2019071222004555

> Re: [Ticket#2019071222004555] GRE configuration inconsistency in RoS 6.45.1
> On Mon, 15 Jul 2019 at 12:32, Arturs C. [MikroTik Support] <support@mikrotik.com> wrote:
> Hello,
> Thank you for reporting this. Yes, there is an issue in RouterOS v6.45.1. We will look forward to fixing it in upcoming RouterOS versions.
> Best regards,
> Arturs C.

Great! Very good news!!! Waiting for a bugfix

Posted: **Tue Jul 16, 2019 3:29 pm**

Upgraded to 6.45.1 on LHG LTE Kit.
Email send fails with Auth Fail.
Used to work on 6.44.3

Posted: **Tue Jul 16, 2019 5:41 pm**

The first time I updated a RB951 to 6.45.1, I started receiving the error of invalid user and password. I somehow managed to access it via web access, downgraded to 6.44.3, and everything started working again.

Then I tried again, updated the RB951 to 6.45.1 and winbox to 3.19. Everything seamed ok, but after 24 hours, I started receiving the same error of invalid user and password, but this time both from winbox and web access.

I cannot access the device, although it seams to be working fine (except for the remote access detail).

Any solution?

Posted: **Tue Jul 16, 2019 7:31 pm**

I found a bug in this version. I have a Basebox 5 and it has a radius enabled PPPoE Server, evertyhing there works fine, but when the user connects, it does not assing a queue to limit traffic.
I had to Downgrade to 6.44.3 to have this working.
Thanks

Posted: **Tue Jul 16, 2019 9:48 pm**

I just want to understand why when updating to this version 6.45.1 my ipv6 has broken through the network? and just go back to another version that works!

Posted: **Wed Jul 17, 2019 1:16 am**

Quite nice mess. I'll add my two cents...
Old, good RB450G. Just upgraded to 6.45.1 from something like 6.40 and now can't connect through any port. 4 ports switched and one with DHCP client.
Winbox says nothing (even after updating it and clearing cache).
The only solution seems to be a rs232 (not tried yet).
Any thoughts on that?

Posted: **Wed Jul 17, 2019 7:43 am**

6.40.x still had the "Ethernet master port" instead of current "hardware accelerated bridge", so I would be afraid to jump that deep into future from there directly.

Other than that, I usually export the configuration so that if the upgrade failed (so far only RC/beta versions did in my case), I could reset the configuration to defaults and then recreate it from the export. Files on device survive reset to defaults so it makes sense even where you have to instruct someone at remote location how to do the recovery.

Right now yes, serial is your last chance to see what went wrong and not lose the configuration completely.

Posted: **Wed Jul 17, 2019 8:10 am**

Is it me or 6.45.1 is giving everyone a different type of headache? I don't remember an update with soooo many problems, right?

Any fix coming soon?

Thanks.

Posted: **Wed Jul 17, 2019 8:27 am**

Is it me or 6.45.1 is giving everyone a different type of headache?

Judging from posts in this tread it does seem that 6.45.1 is a troublesome child of MT.

This is not my personal experience though, have updated 6 pieces (2x hAP ac lite, 1x hAP, 2x RB951G and 1xhAP ac2) from 6.44.x and I didn't have a single problem ... neither during upgrade nor afterwards (after 15 days of uptime running 6.45.1). Disclaimer: I did upgrade all devices quite regularly, so not many entries from the changelog were there to bite.

Posted: **Wed Jul 17, 2019 8:52 am**

Since a long time i use a script to get my public ip and a log entry if it has changed. I found it here in the forum.
It creates also an entry in the adress lists with my public ip named "external-ip"
Since the upgrade to 6.45.1 this script doesnt work anymore.
No error message but also no adress list will be created. It was flawless until 6.45.1

Any ideas? Thanx

# Set needed variables
:global ExtIpListName "external-ip"
:global ExtIp ""
:global ExtIpOld ""

# Get IP and save it to "mypublicip.txt"
/tool fetch url="http://myip.dnsomatic.com/" mode=http dst-path=mypublicip.txt
# Save IP from "mypublicip.txt" to variable
:global ExtIp [file get mypublicip.txt contents]

:if ([:len [/ip firewall address-list find list="$ExtIpListName"]] > 0) do={
 :set ExtIpOld [/ip firewall address-list get [/ip firewall address-list find list="$ExtIpListName"] address];
 :if ($ExtIpOld != $ExtIp) do={
 /ip firewall address-list set [/ip firewall address-list find list="$ExtIpListName" address="$ExtIpOld"] address="$ExtIp"
 :log info "External IP relpaced from $ExtIpOld to $ExtIp."
 } else={
 :log info "External IP $ExtIp not changed."
 };
} else={
 /ip firewall address-list add list="$ExtIpListName" address="$ExtIp" comment="script generated"
 :log info "New external IP $ExtIp added."
};

Posted: **Wed Jul 17, 2019 10:03 am**

Old, good RB450G. Just upgraded to 6.45.1 from something like 6.40 and now can't connect through any port. 4 ports switched and one with DHCP client.
Winbox says nothing (even after updating it and clearing cache).
The only solution seems to be a rs232 (not tried yet).
Any thoughts on that?

Try connecting within Mac Address. If doesn't works, and RS232 neither you should do a reset of the config.
Jumping from 6.40 to 6.45.1 it's a very very big jump and there was a lot of changes between that two versions. One of those changes was the elimination of master and slave ports. Now all needs to be done within bridges.

Posted: **Wed Jul 17, 2019 10:25 am**

Upgraded a RB960PGS-PB from 6.42 something (factory) and lost administration connectivity. Almost empty config, no firewall, only a bridge1 with all ports and IP was set on bridge1. Reboot did nothing. I used reset button and it worked again at 192.168.88.1 but as soon as I removed config and added bridge1 and my IP back on bridge1 it stopped working again. Downgraded to 6.44.3 and winbox connected directly without touching anything else. 6.45.1 certainly has connectivity issues

Posted: **Wed Jul 17, 2019 12:59 pm**

Upgraded a RB960PGS-PB from 6.42 something (factory) and lost administration connectivity.

And with lost conectivity I mean I could not discover the device in winbox, not even see any of it's ports MAC addresses and connect to that while I was directly on one of it's ports. So not really an IP address issue only, even lower layer...

However the device continued to function as a switch, that traffic still worked so device was alive.

Posted: **Wed Jul 17, 2019 2:52 pm**

It is a "known issue" (I don't know if MikroTik is aware of it but it has been mentioned on the forum before) that configuring the device in bridge mode from the quickset menu results in a bad configuration where you are locked out. When you configure it as a router and then remove the ether1-specific configuration (DHCP client etc) and the firewall forward rules, you can add ether1 to the bridge and the result should be the same.

Posted: **Wed Jul 17, 2019 3:15 pm**

configuring the device in bridge mode from the quickset menu results in a bad configuration where you are locked out.

I did not do it exactly this way, I removed config completely after first startup (after factory reset). Then connected by MAC address, did the bridge config by hand and not trough quickset and boom, device disappeared from network...

But when I think about it again, it is not completely reproducible, sometimes only IP connectivity was gone, MAC access still worked. It was that way I could do a downgrade so at least once MAC access still worked and only IP was blocked. Damn hard to remember all the steps you make when you are just trying to get a device to work again hehe....

Posted: **Wed Jul 17, 2019 4:40 pm**

Does it work OK when you configure it as a router in quickset? It should.
Then you can investigate what is going on.

Posted: **Wed Jul 17, 2019 4:51 pm**

Yes the factory default nat router config works so I can reset it back to that. It's when I apply the bridge config that things gets weird...

Posted: **Wed Jul 17, 2019 5:13 pm**

It's when I apply the bridge config that things gets weird...

As @pe1chl wrote: you have to remove router functionality by hand (either via GUI or CLI, just don't use quickset).

Posted: **Wed Jul 17, 2019 5:50 pm**

Yes as I wrote before, just keep the bridge settings made by the router config but remove the ether1 address config (dhcp client) and join it to the bridge (and change interface list membership, remove it from WAN).
Not by using the quickset but as separate steps in the configuration. Then it could be you also want to change the firewall.

Posted: **Wed Jul 17, 2019 6:14 pm**

update your api
https://wiki.mikrotik.com/wiki/Manual:API#Initial_login

Is this the new API that sends the password in plain text?? I cannot figure WHY you guys would revert to that way of operation.

Posted: **Wed Jul 17, 2019 7:07 pm**

The old API login method used CHAP (challenge authentication protocol), which requires the router to store the password in plain text. Passwords are now stored as a hash so you need to send the original password, which the router then hashes to compare to the stored password.

Use API-SSL if you are transmitting API over an untrusted network...

Posted: **Wed Jul 17, 2019 7:26 pm**

The process for the API, is the same one that follows winbox for the user authentication? May that be related to the issue with incorrect user and password error?

Posted: **Wed Jul 17, 2019 9:16 pm**

Yes as I wrote before, just keep the bridge settings made by the router config but remove the ether1 address config (dhcp client) and join it to the bridge (and change interface list membership, remove it from WAN).
Not by using the quickset but as separate steps in the configuration. Then it could be you also want to change the firewall.

I think you are talking about another problem, this was strictly related to 6.45.1 as downgrading made the problem disappear. And I did not use quickset, I directly answered no to the question if I want to keep the config. Then the router reboots without a config. Everything still works fine as expected. The problem starts when creating a bridge.

Posted: **Thu Jul 18, 2019 12:40 am**

Try connecting within Mac Address. If doesn't works, and RS232 neither you should do a reset of the config.
Jumping from 6.40 to 6.45.1 it's a very very big jump and there was a lot of changes between that two versions. One of those changes was the elimination of master and slave ports. Now all needs to be done within bridges.

Of course, I tried with MAC. That's actually the only method I use on a daily basis. I treat that box as a regular (well, almost) switch, hence only one port (ether1) has dhcp client (just in case) and is not connected most of the time.

Right now yes, serial is your last chance to see what went wrong and not lose the configuration completely.

Thanks for advises both of you. I've tried serial and guess what... Winbox connection (via MAC) suddenly started to work. No idea what happened. It's a quite basic config.
My switching configuration is untouched - besides lack of slave/master ports settings.
Anyway, I'm not planning to make a network bridge of native switching device. Sounds ridiculous.
It's enough that I've lost switching possibility for ether1 after some prior upgrade (from 6.3x.x to 6.4x).

Posted: **Thu Jul 18, 2019 2:35 am**

It's enough that I've lost switching possibility for ether1 after some prior upgrade (from 6.3x.x to 6.4x).

What does /interface ethernet switch print detail show?

Posted: **Thu Jul 18, 2019 5:39 pm**

I don't know if these things are strictly related to 6.45.x but..

Yesterday I've added a secondary ethernet link from my main switch (CRS326) and my firewall (RB3011) in the knowledge my CRS326 would handle the backup link correctly (STP was already active on my CRS326); previously there was only the SFP-cable connecting them:

1) if I use the ether1 on my RB3011 (witch is the PoE-in capable port) the RB3011 switches off immediately (no matter what port I use on the CRS326 side). If I try to connect the ether1 port of the RB3011 to a spare CRS125 all is fine instead.
2) (using a different port on RB3011 than ether1) switching on STP on RB3011 (beside of the up and running STP process on the CRS326) the STP process select the root port correctly but I've noticed a lot of packet losses; the packet loss is reproducibile easily pushing repeatedly the button "Refresh" on Winbox to force a quick discovery in LAN!! Switching off the STP process on RB3011 and relying only on the STP process of the CRS326 is fine and there is no evident packet loss any more.
3) With STP active only on CRS326, the dual link (active/backup) to the firewall seems to behave correctly but I've noticed the main switch (CRS326) has some issues with ARP( e.g. my ip phone snom-370 is unable to get a DHCP response, connecting to the switch via Winbox needs 2-3 tries, ..).
4) removing the secondary/backup ethernet link from CRS326 and RB3011 solves all the problems: no ARP issues (slow/weird), my ip phone get his address normally. All is back to normal.

P.S. Every firmwares are updated along with the ros versions (so 6.45.1) and I've also tried with a fresh netinstall for both of them (CRS326/RB3011) and I reimported the configurations line by line from a previous export. Setups on CRS326 and RB3011 are quite well tried and I'm sure I've already tried in the past to put a redundant link between them without noticing any similar issues.

The weirdest thing, however, is the fact that the RB3011 will immediately switch off if I connect the ether1 (PoE-in capable port) to any port of the CRS326 !!

Has anyone any insights ?

Posted: **Thu Jul 18, 2019 5:47 pm**

No idea. As far as I am reading, everyone seams to be experiencing different issues, but for me they look completely unrelated. Maybe v6.45.1 is not that stable?

Posted: **Thu Jul 18, 2019 5:49 pm**

My thinking is that using STP to create redundant links between two directly attached devices is (slight) abuse.

In this case it would be better to use bonding. There are many varieties, if you only want to have backup line, you can use active-backup mode.

Posted: **Thu Jul 18, 2019 5:54 pm**

Is there any ETA for...

Wrong question! At MikroTik, there never is an ETA!
"it is ready when it's ready".
Typical time for things to be ready is late friday afternoon.

Posted: **Thu Jul 18, 2019 5:56 pm**

Is there any ETA for...
Wrong question! At MikroTik, there never is an ETA!
"it is ready when it's ready".

This is just spam to advertise Bitcoin/Cryptocurrency Trading Exchange Platform. (See signature.)

Posted: **Thu Jul 18, 2019 7:27 pm**

My thinking is that using STP to create redundant links between two directly attached devices is (slight) abuse.
In this case it would be better .. bonding..

I can agree on this, but consider that just phisically plugging ether1 of rb3011 to one port of the crs326 immediately kills the rb3011 (switched off, dead untill I unplug the cable and it reboots) ..no matter what configuration you have. Furthermore a backup link should be a standby/blocked link with no activity, beside stp messaging, and so pretty stable! ARP issues with this simple scenario is clearly a nonsense.
Bonding (active/backup) might be my best choice here, but it sounds like something to avoid now if I haven't got the chance to figure out what the hell it's happening in the first place

MikroTik

v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!

Re: v6.45.1 [stable] is released!