Community discussions

  • 1
  • 5
  • 6
  • 7
  • 8
  • 9
 
ludvik
Frequent Visitor
Frequent Visitor
Posts: 57
Joined: Mon May 26, 2008 4:36 pm

Re: v6.45.1 [stable] is released!

Sat Jul 06, 2019 11:50 pm

Read before write. And then for example: https://wiki.mikrotik.com/wiki/Manual:API#Initial_login
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8291
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: v6.45.1 [stable] is released!

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
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

For every complex problem, there is a solution that is simple, neat, and wrong.

MikroTik. Your life. Your routing.
 
bellotaman
just joined
Posts: 2
Joined: Thu Aug 04, 2016 3:51 pm

Re: v6.45.1 [stable] is released!

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.
 
bbs2web
Member Candidate
Member Candidate
Posts: 197
Joined: Sun Apr 22, 2012 6:25 pm
Location: Johannesburg, South Africa
Contact:

Re: v6.45.1 [stable] is released!

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...
 
Iwanche
just joined
Posts: 3
Joined: Thu Mar 29, 2018 2:26 pm

Re: v6.45.1 [stable] is released!

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?
 
User avatar
Jotne
Forum Guru
Forum Guru
Posts: 1234
Joined: Sat Dec 24, 2016 11:17 am
Location: Magrathean

Re: v6.45.1 [stable] is released!

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.
 
How to use Splunk to monitor your MikroTik Router

MikroTik->Splunk
 
 
GambarottoM
just joined
Posts: 3
Joined: Fri Jun 21, 2019 3:18 pm

Re: v6.45.1 [stable] is released!

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?
 
User avatar
skylark
MikroTik Support
MikroTik Support
Posts: 102
Joined: Wed Feb 10, 2016 3:55 pm

Re: v6.45.1 [stable] is released!

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
 
jarda
Forum Guru
Forum Guru
Posts: 7601
Joined: Mon Oct 22, 2012 4:46 pm

Re: v6.45.1 [stable] is released!

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.
 
dadaniel
Member Candidate
Member Candidate
Posts: 155
Joined: Fri May 14, 2010 11:51 pm

Re: v6.45.1 [stable] is released!

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.
 
GambarottoM
just joined
Posts: 3
Joined: Fri Jun 21, 2019 3:18 pm

Re: v6.45.1 [stable] is released!

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:
/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.
 
Wintermute
just joined
Posts: 21
Joined: Fri Jan 15, 2010 1:22 pm

Re: v6.45.1 [stable] is released!

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.
 
User avatar
Cha0s
Forum Veteran
Forum Veteran
Posts: 880
Joined: Tue Oct 11, 2005 4:53 pm

Re: v6.45.1 [stable] is released!

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.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5544
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.45.1 [stable] is released!

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...
 
User avatar
gabrielpike
Frequent Visitor
Frequent Visitor
Posts: 84
Joined: Thu Apr 17, 2014 4:17 pm

Re: v6.45.1 [stable] is released!

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.
Gabriel Pike
MTCNA
 
vorona
just joined
Posts: 1
Joined: Mon Jul 08, 2019 5:07 pm

Re: v6.45.1 [stable] is released!

Mon Jul 08, 2019 5:22 pm

my web proxy not work on this version. may somebody give me help?
the same issue
 
tonymobile
newbie
Posts: 37
Joined: Mon Jul 07, 2008 2:10 am

Re: v6.45.1 [stable] is released!

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.
 
tesme33
newbie
Posts: 45
Joined: Mon May 26, 2014 10:25 pm

Re: v6.45.1 [stable] is released!

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 ?
 
User avatar
Xymox
Member
Member
Posts: 387
Joined: Thu Jan 21, 2010 5:04 pm
Location: Phoenix, Arizona US
Contact:

Re: v6.45.1 [stable] is released!

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.
 
tesme33
newbie
Posts: 45
Joined: Mon May 26, 2014 10:25 pm

Re: v6.45.1 [stable] is released!

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 ?
 
sid5632
Member
Member
Posts: 348
Joined: Fri Feb 17, 2017 6:05 pm

Re: v6.45.1 [stable] is released!

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).
 
DanchoDimitrov
just joined
Posts: 5
Joined: Wed Jul 03, 2019 10:10 pm
Location: Bulgaria

Re: v6.45.1 [stable] is released!

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.
hAP AC^2
 
turnip
Frequent Visitor
Frequent Visitor
Posts: 66
Joined: Wed Sep 11, 2013 7:01 pm

Re: v6.45.1 [stable] is released!

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.
 
rekeds
just joined
Posts: 10
Joined: Fri Mar 14, 2014 10:45 pm

Re: v6.45.1 [stable] is released!

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)" :D
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8291
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: v6.45.1 [stable] is released!

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.
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

For every complex problem, there is a solution that is simple, neat, and wrong.

MikroTik. Your life. Your routing.
 
seb13
just joined
Posts: 2
Joined: Mon Sep 12, 2016 10:11 pm

Re: v6.45.1 [stable] is released!

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?
 
nescafe2002
Long time Member
Long time Member
Posts: 612
Joined: Tue Aug 11, 2015 12:46 pm
Location: Netherlands

Re: v6.45.1 [stable] is released!

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.
 
User avatar
emils
MikroTik Support
MikroTik Support
Topic Author
Posts: 460
Joined: Thu Dec 11, 2014 8:53 am

Re: v6.45.1 [stable] is released!

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.
 
seb13
just joined
Posts: 2
Joined: Mon Sep 12, 2016 10:11 pm

Re: v6.45.1 [stable] is released!

Tue Jul 09, 2019 2:54 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.
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!
 
powerek
just joined
Posts: 4
Joined: Sat Jun 21, 2014 12:49 pm

Re: v6.45.1 [stable] is released!

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

 
micaelhenriques
just joined
Posts: 4
Joined: Thu Feb 28, 2019 2:10 pm

Re: v6.45.1 [stable] is released!

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 :shock: :shock: :shock:
I need a solution for that...
 
User avatar
skylark
MikroTik Support
MikroTik Support
Posts: 102
Joined: Wed Feb 10, 2016 3:55 pm

Re: v6.45.1 [stable] is released!

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 :shock: :shock: :shock:
I need a solution for that...
Try Tools > Clear Cache
 
micaelhenriques
just joined
Posts: 4
Joined: Thu Feb 28, 2019 2:10 pm

Re: v6.45.1 [stable] is released!

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 :shock: :shock: :shock:
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
 
User avatar
baks
just joined
Posts: 14
Joined: Fri Jul 19, 2013 9:05 pm
Location: Ukraine

Re: v6.45.1 [stable] is released!

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.
RB435G+R52Hn+PSU24V2A+CustomIndoorCase
CRS125-24G-1S-RM
CRS326-24G-2S+
RB962UiGS-5HacT2HnT (HAPac)
 
sindy
Forum Guru
Forum Guru
Posts: 3757
Joined: Mon Dec 04, 2017 9:19 pm

Re: v6.45.1 [stable] is released!

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.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
LeftyTs
Frequent Visitor
Frequent Visitor
Posts: 67
Joined: Thu Nov 03, 2016 2:39 am
Location: Athens, Greece
Contact:

Re: v6.45.1 [stable] is released!

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
 
Iwanche
just joined
Posts: 3
Joined: Thu Mar 29, 2018 2:26 pm

Re: v6.45.1 [stable] is released!

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?
 
LeftyTs
Frequent Visitor
Frequent Visitor
Posts: 67
Joined: Thu Nov 03, 2016 2:39 am
Location: Athens, Greece
Contact:

Re: v6.45.1 [stable] is released!

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.
 
danieltecnet
just joined
Posts: 8
Joined: Tue Jan 31, 2017 10:35 pm
Location: https://www.google.com.br/maps/@-4.9872 ... 128006,16z

Re: v6.45.1 [stable] is released!

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
 
ckleea
newbie
Posts: 47
Joined: Sun Apr 21, 2013 12:19 pm

Re: v6.45.1 [stable] is released!

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.
 
Abdock
Member Candidate
Member Candidate
Posts: 245
Joined: Sun Sep 25, 2005 10:50 pm

Re: v6.45.1 [stable] is released!

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.
 
UMarcus
Frequent Visitor
Frequent Visitor
Posts: 90
Joined: Wed Jan 21, 2015 10:11 am
Location: Europe

Re: v6.45.1 [stable] is released!

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.
 
buset1974
Frequent Visitor
Frequent Visitor
Posts: 50
Joined: Wed Sep 13, 2006 12:12 pm
Location: Jakarta

Re: v6.45.1 [stable] is released!

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
 
Ansy
Frequent Visitor
Frequent Visitor
Posts: 72
Joined: Mon Oct 17, 2011 1:32 pm
Location: Russia
Contact:

Re: v6.45.1 [stable] is released!

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:
  1. Don't expect too many features of it, especially memory hangry ones!
  2. 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.
  3. Setup, configure and tune the device with only needed functions and DISABLE all unneeded packages (grey them off in System->Packages)
  4. Backup and download to computer your current config (binary and /export file=config.rsc too)!!!
  5. 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)
  6. 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.
Last edited by Ansy on Thu Jul 11, 2019 6:33 pm, edited 1 time in total.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5544
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.45.1 [stable] is released!

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.
 
TimurA
Member Candidate
Member Candidate
Posts: 138
Joined: Sat Dec 15, 2018 6:13 am
Location: Tashkent
Contact:

Re: v6.45.1 [stable] is released!

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
Image
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 5910
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: v6.45.1 [stable] is released!

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.
 
User avatar
baks
just joined
Posts: 14
Joined: Fri Jul 19, 2013 9:05 pm
Location: Ukraine

Re: v6.45.1 [stable] is released!

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
RB435G+R52Hn+PSU24V2A+CustomIndoorCase
CRS125-24G-1S-RM
CRS326-24G-2S+
RB962UiGS-5HacT2HnT (HAPac)
 
User avatar
osc86
newbie
Posts: 46
Joined: Wed Aug 09, 2017 1:15 pm

Re: v6.45.1 [stable] is released!

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=""
CCR1009-7G-1C-1S+ ROS6.45.2
 
DanchoDimitrov
just joined
Posts: 5
Joined: Wed Jul 03, 2019 10:10 pm
Location: Bulgaria

Re: v6.45.1 [stable] is released!

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.
hAP AC^2
  • 1
  • 5
  • 6
  • 7
  • 8
  • 9

Who is online

Users browsing this forum: No registered users and 6 guests