v6.39.2 [current]

Njumaen · Sat Jul 08, 2017 11:35 pm

I feel your pain but hope MT guys will fix more serious things first.

Sure. No big issue...

Test471 · Sun Jul 09, 2017 12:48 pm

Hello

I just upgraded my hap ac via webfig to this version and it is dead since then. There is no beep and by looking at LEDs it looks like it keeps restarting after 10 seconds. I've tried to do restart by holding the button but the only thing that happens is that SFP LED starts blinking and nothing... it restarts again and so on. Any suggestions?

Sun Jul 09, 2017 1:02 pm

Any suggestions?

Reinstall RouterOS via Netinstall.

Test471 · Sun Jul 09, 2017 1:27 pm

I've tried that but, as I said, holding down reset button does nothing except flashing SFP led a few times and then reset again.

My computer says "cable unplugged" all the time. I've tried with connecting it to eth1. Any other suggestion?

pe1chl · Sun Jul 09, 2017 1:43 pm

I've tried that but, as I said, holding down reset button does nothing except flashing SFP led a few times and then reset again.

You must carefully read the instructions on how long to press the button.

Sun Jul 09, 2017 1:44 pm

I've tried that but, as I said, holding down reset button does nothing

You said you tried to reset your device, not using Netinstall. Anyways, when some device does not boot, your set of options is rather limited:

If the device has serial console, plug the cable and see what's wrong. You are using hAP ac, so, obviously, this options is not available to you.
Try to reset. You said you tried that, didn't work.
Try using a backup bootloader.
Reinstall OS via Netinstall.
RMA.
Go buy another device.

Check this wiki page out to learn what backup bootloader is, and how reset button works (hint- it does different things depending on when it is pressed and how long it is being hold).

Test471 · Sun Jul 09, 2017 1:52 pm

I've tried that but, as I said, holding down reset button does nothing except flashing SFP led a few times and then reset again.
You must carefully read the instructions on how long to press the button.

I did. I've tried to hold it until SFP starts flashing fast (this is the only LED that shows something actullay is happening). Nothing.

Tried to hold it until it stops flashing - nothing.

Tried to hold it until it starts flashing again slowly - nothing.

[*] Go buy another device.[/list]

Well, thank you very much for that but, since it is clear that this is not my fault, I am not going to throw 100 eur in the garbage. I just clicked "Upgrade" button and nothing else.

Check this wiki page out to learn what backup bootloader is, and how reset button works (hint- it does different things depending on when it is pressed and how long it is being hold).

Well, I did actually read everything I could find before coming here. Reset button does not help in any way.

NikNikols · Sun Jul 09, 2017 10:14 pm

Same here/

After upgrading to the current RouterOS (6.39.2) and rebooting my new hAP ac lite tower won't boot.

Reset buttont doesn't work in any way. I've used all the variants. Looks like the device starts then after 10 seconds reboots and so on

Kraken2k · Tue Jul 11, 2017 11:16 am

[*] Go buy another device.[/list]
Well, thank you very much for that but, since it is clear that this is not my fault, I am not going to throw 100 eur in the garbage. I just clicked "Upgrade" button and nothing else.

Meaning: you should try steps above before buying a replacement. Nothing else.

Deantwo · Thu Jul 13, 2017 4:16 pm

IPsec is still creating a lot of what looks like debug log messages.
I have had this logging for a long time, but with the newer versions of RouterOS it is now useless.

/system logging action
add memory-lines=100 name=ipsec target=memory
/system logging
add action=ipsec topics=ipsec,!debug

Now I just get this:

15:11:37 ipsec <IP A> notify: R_U_THERE_ACK 
15:11:37 ipsec sendto Information notify. 
15:11:37 ipsec receive Information. 
15:11:37 ipsec <IP B> notify: R_U_THERE_ACK 
15:11:38 ipsec receive Information. 
15:11:38 ipsec <IP C> notify: R_U_THERE 
15:11:38 ipsec sendto Information notify. 
15:11:38 ipsec sendto Information notify. 
15:11:38 ipsec receive Information. 
15:11:38 ipsec <IP C> notify: R_U_THERE 
15:11:38 ipsec sendto Information notify. 
15:11:38 ipsec receive Information. 
15:11:38 ipsec <IP C> notify: R_U_THERE_ACK 
15:11:39 ipsec sendto Information notify. 
15:11:39 ipsec receive Information. 
15:11:39 ipsec <IP C> notify: R_U_THERE_ACK 
15:11:57 ipsec receive Information. 
15:11:57 ipsec <IP A> notify: R_U_THERE 
15:11:57 ipsec sendto Information notify. 
15:11:57 ipsec sendto Information notify. 
15:11:57 ipsec sendto Information notify. 
15:11:57 ipsec receive Information. 
15:11:57 ipsec <IP A> notify: R_U_THERE_ACK 
15:11:57 ipsec receive Information. 
15:11:57 ipsec <IP B> notify: R_U_THERE_ACK 
15:11:58 ipsec receive Information. 
15:11:58 ipsec <IP C> notify: R_U_THERE 
15:11:58 ipsec sendto Information notify. 
15:11:58 ipsec receive Information. 
15:11:58 ipsec <IP C> notify: R_U_THERE 
15:11:58 ipsec sendto Information notify. 
15:11:58 ipsec sendto Information notify. 
15:11:58 ipsec receive Information. 
15:11:58 ipsec <IP C> notify: R_U_THERE_ACK 
15:11:59 ipsec sendto Information notify. 
15:11:59 ipsec receive Information. 
15:11:59 ipsec <IP C> notify: R_U_THERE_ACK 
15:12:17 ipsec receive Information. 
15:12:17 ipsec <IP A> notify: R_U_THERE 
15:12:17 ipsec sendto Information notify. 
15:12:17 ipsec sendto Information notify. 
15:12:17 ipsec sendto Information notify. 
15:12:17 ipsec receive Information. 
15:12:17 ipsec <IP B> notify: R_U_THERE_ACK 
15:12:17 ipsec receive Information. 
15:12:17 ipsec <IP A> notify: R_U_THERE_ACK 
15:12:18 ipsec receive Information. 
15:12:18 ipsec <IP C> notify: R_U_THERE 
15:12:18 ipsec sendto Information notify. 
15:12:18 ipsec sendto Information notify. 
15:12:18 ipsec receive Information. 
15:12:18 ipsec <IP C> notify: R_U_THERE 
15:12:18 ipsec sendto Information notify. 
15:12:18 ipsec receive Information. 
15:12:18 ipsec <IP C> notify: R_U_THERE_ACK 
15:12:19 ipsec sendto Information notify. 
15:12:19 ipsec receive Information. 
15:12:19 ipsec <IP C> notify: R_U_THERE_ACK 
15:12:37 ipsec receive Information. 
15:12:37 ipsec <IP A> notify: R_U_THERE 
15:12:37 ipsec sendto Information notify. 
15:12:37 ipsec sendto Information notify. 
15:12:37 ipsec sendto Information notify. 
15:12:37 ipsec receive Information. 
15:12:37 ipsec <IP B> notify: R_U_THERE_ACK 
15:12:37 ipsec receive Information. 
15:12:37 ipsec <IP A> notify: R_U_THERE_ACK 
15:12:38 ipsec receive Information. 
15:12:38 ipsec <IP C> notify: R_U_THERE 
15:12:38 ipsec sendto Information notify. 
15:12:38 ipsec sendto Information notify. 
15:12:38 ipsec receive Information. 
15:12:38 ipsec <IP C> notify: R_U_THERE 
15:12:38 ipsec sendto Information notify. 
15:12:38 ipsec receive Information. 
15:12:38 ipsec <IP C> notify: R_U_THERE_ACK 
15:12:39 ipsec sendto Information notify. 
15:12:39 ipsec receive Information. 
15:12:39 ipsec <IP C> notify: R_U_THERE_ACK 
15:12:57 ipsec receive Information. 
15:12:57 ipsec <IP A> notify: R_U_THERE 
15:12:57 ipsec sendto Information notify. 
15:12:57 ipsec sendto Information notify. 
15:12:57 ipsec sendto Information notify. 
15:12:57 ipsec receive Information. 
15:12:57 ipsec <IP B> notify: R_U_THERE_ACK 
15:12:57 ipsec receive Information. 
15:12:57 ipsec <IP A> notify: R_U_THERE_ACK 
15:12:58 ipsec receive Information. 
15:12:58 ipsec <IP C> notify: R_U_THERE 
15:12:58 ipsec sendto Information notify. 
15:12:58 ipsec sendto Information notify. 
15:12:58 ipsec receive Information. 
15:12:58 ipsec <IP C> notify: R_U_THERE 
15:12:58 ipsec sendto Information notify. 
15:12:58 ipsec receive Information. 
15:12:58 ipsec <IP C> notify: R_U_THERE_ACK 
15:12:59 ipsec sendto Information notify. 
15:12:59 ipsec receive Information. 
15:12:59 ipsec <IP C> notify: R_U_THERE_ACK

All those logs only have the "ipsec" topic, so there is no way to filter them out. Can you pretty please add the "debug" topic to those otherwise useless logs?
Since monitoring the "ipsec,!debug" logs is a nice way to see if an IPsec tunnel is unstable. You can compare the differences between v6.35 and v6.39.2.

And this is a router that has just 3 IPsec tunnels. Imagine what would happen if I upgraded my core router that has around 1000 IPsec tunnels running.

pe1chl · Thu Jul 13, 2017 5:18 pm

Probably they have some other tag as with the default config of logging only info/error/warning/critical these do not show up and other ipsec items do.

Thu Jul 13, 2017 5:30 pm

Not really sure where is the problem, if you do not want to see ispec logs, then remove/disable this entry
add action=ipsec topics=ipsec,!debug

pe1chl · Thu Jul 13, 2017 5:55 pm

Not really sure where is the problem, if you do not want to see ispec logs, then remove/disable this entry
add action=ipsec topics=ipsec,!debug

Well I can understand that he wants to have ipsec logs in a separate logging action. I also sometimes make separate
logging actions for certain debug purposes. Apparently there are a lot of ipsec messages that are captured by "ipsec"
and have no "debug" but also no "info", "error", "warning" or "critical" tag (or they would show up in the default log).
Maybe they are in the "notice" level? Try adding "!notice".

Deantwo · Thu Jul 13, 2017 8:26 pm

Not really sure where is the problem, if you do not want to see ispec logs, then remove/disable this entry
add action=ipsec topics=ipsec,!debug

That would leave the logging action unused.

IPsec logging messages used to have the topic "info,ipsec", which meant they would show up in the info log. I had changed the info logging to exclude the "ipsec" topic and then had the logging rule I mentioned above log to a separate logging action memory.

But since those new logs don't have any other topic than "ipsec" they are just flood the logging action. Hence my question as to why those new logs don't have the debug topic.

Maybe they are in the "notice" level? Try adding "!notice".

I would be surprised if they have a topic that isn't listed in the log, but sure I will try it out tomorrow.

I actually forget what happens if I change the topic of my logging rule to "ipsec,info". Will it include both "ipsec" and "info" logs? Or will it only include logs that have both topics?

Example of the logs that I want being indistinguishable from the "R_U_THERE_ACK" logs.

14:59:20 ipsec sendto Information notify. 
14:59:20 ipsec receive Information. 
14:59:20 ipsec <IP A> notify: R_U_THERE_ACK 
14:59:39 ipsec receive Information. 
14:59:39 ipsec <IP A> notify: R_U_THERE 
14:59:39 ipsec sendto Information notify. 
14:59:40 ipsec sendto Information notify. 
14:59:40 ipsec receive Information. 
14:59:40 ipsec <IP A> notify: R_U_THERE_ACK 
14:59:59 ipsec receive Information. 
14:59:59 ipsec <IP A> notify: R_U_THERE 
14:59:59 ipsec sendto Information notify. 
15:00:00 ipsec sendto Information notify. 
15:00:00 ipsec receive Information. 
15:00:00 ipsec <IP A> notify: R_U_THERE_ACK 
15:00:20 ipsec sendto Information notify. 
15:00:21 ipsec <IP A> DPD: remote (ISAKMP-SA <IP B>[500]<=><IP A>[500] spi=4ab151a42b54a0c4:9a01fa76c1e10987) seems to be dead. 
15:00:21 ipsec purged IPsec-SA spi=0x9805042 
15:00:21 ipsec purged IPsec-SA spi=0xd7a4b4 
15:00:21 ipsec purged IPsec-SA spi=0xe9fbe69 
15:00:21 ipsec purged IPsec-SA spi=0x73063ec 
15:00:21 ipsec purged ISAKMP-SA <IP B>[500]<=><IP A>[500] spi=4ab151a42b54a0c4:9a01fa76c1e10987. 
15:00:27 ipsec sent phase1 packet <IP B>[500]<=><IP A>[500] b3f71d77b6b5680e:0000000000000000 
15:00:27 ipsec received Vendor ID: CISCO-UNITY 
15:00:27 ipsec received Vendor ID: DPD 
15:00:28 ipsec sent phase1 packet <IP B>[500]<=><IP A>[500] b3f71d77b6b5680e:0ee9cf89d80c8924 
15:00:28 ipsec sent phase1 packet <IP B>[500]<=><IP A>[500] b3f71d77b6b5680e:0ee9cf89d80c8924 
15:00:28 ipsec ph2 possible after ph1 creation 
15:00:28 ipsec initiate new phase 2 negotiation: <IP B>[500]<=><IP A>[500] 
15:00:28 ipsec sent phase2 packet <IP B>[500]<=><IP A>[500] b3f71d77b6b5680e:0ee9cf89d80c8924:bdb16d2f 
15:00:28 ipsec IPsec-SA established: ESP/Tunnel <IP A>[500]-><IP B>[500] spi=0x4a17936 
15:00:28 ipsec IPsec-SA established: ESP/Tunnel <IP B>[500]-><IP A>[500] spi=0x8d8c73c 
15:00:28 ipsec ph2 possible after ph1 creation 
15:00:28 ipsec initiate new phase 2 negotiation: <IP B>[500]<=><IP A>[500] 
15:00:28 ipsec sent phase2 packet <IP B>[500]<=><IP A>[500] b3f71d77b6b5680e:0ee9cf89d80c8924:8a4f2dc1 
15:00:28 ipsec IPsec-SA established: ESP/Tunnel <IP A>[500]-><IP B>[500] spi=0xe3f85b5 
15:00:28 ipsec IPsec-SA established: ESP/Tunnel <IP B>[500]-><IP A>[500] spi=0x975fad7 
15:00:48 ipsec receive Information. 
15:00:48 ipsec <IP A> notify: R_U_THERE 
15:00:48 ipsec sendto Information notify. 
15:00:48 ipsec sendto Information notify. 
15:00:48 ipsec receive Information. 
15:00:48 ipsec <IP A> notify: R_U_THERE_ACK 
15:01:08 ipsec sendto Information notify. 
15:01:08 ipsec receive Information. 
15:01:08 ipsec <IP A> notify: R_U_THERE 
15:01:08 ipsec sendto Information notify. 
15:01:08 ipsec receive Information. 
15:01:08 ipsec <IP A> notify: R_U_THERE_ACK

Fri Jul 14, 2017 12:10 pm

Problem already solved in v6.40rc now DPD logs have ipsec,debug topics.

ziegenberg · Fri Jul 14, 2017 2:42 pm

Problem already solved in v6.40rc now DPD logs have ipsec,debug topics.

That's awesome to read. Thank you very much, 'tik! Looking forward to v6.40 coming out of RC!

greetings, Daniel

Deantwo · Fri Jul 14, 2017 4:06 pm

Problem already solved in v6.40rc now DPD logs have ipsec,debug topics.

Ah awesome, thank you. I guess I haven't tried the newest version of the release candidates.

I didn't even know those logs were from the DPD, but with the snippit I just got I can see that it is.

tangram · Tue Jul 18, 2017 12:50 pm

Hi,

I upgraded from 6.37.3 to 6.39.2 and I have some problems. I'm load balancing 2 ISPs, before update I could ping both wan ips, after update only the primary works. If i disconnect ISP1 then ISP2 replies to ping. Connections from LAN->WAN balance over both ISPs and traceroute,ping work ok from LAN->WAN. Only problem is that I can't connect to Mikrotik over ISP2, no ping, nothing while ISP1 is active.

/ip firewall mangle
add action=accept chain=prerouting comment="Bypass for DVR forward" dst-port=\
56565 in-interface=ISP1-PPPoE protocol=tcp
add action=accept chain=prerouting comment=\
"Connected Network Accept - Main RT" dst-address-list=Connected \
src-address-list=Connected
add action=mark-connection chain=input comment=M-ISP1-ROS connection-mark=\
no-mark in-interface=ISP1-PPPoE new-connection-mark=ISP1_ROS passthrough=\
yes
add action=mark-connection chain=input comment=M-ISP2-ROS connection-mark=\
no-mark in-interface=ether2-ISP2 new-connection-mark=ISP2_ROS \
passthrough=yes
add action=mark-routing chain=output comment=A-ISP1-RT connection-mark=\
M-ISP1-ROS new-routing-mark=ISP1_Route passthrough=yes
add action=mark-routing chain=output comment=A-ISP2-RT connection-mark=\
M-ISP2-ROS new-routing-mark=ISP2_Route passthrough=yes
add action=mark-connection chain=forward comment=M-ISP1-LAN connection-mark=\
no-mark in-interface=ISP1-PPPoE new-connection-mark=ISP1_LAN passthrough=\
yes
add action=mark-connection chain=forward comment=M-ISP2-LAN connection-mark=\
no-mark in-interface=ether2-ISP2 new-connection-mark=ISP2_LAN \
passthrough=yes
add action=mark-routing chain=prerouting comment=A-ISP1-LAN connection-mark=\
ISP1_LAN new-routing-mark=ISP1_Route passthrough=yes
add action=mark-routing chain=prerouting comment=A-ISP2-LAN connection-mark=\
ISP2_LAN new-routing-mark=ISP2_Route passthrough=yes
add action=mark-connection chain=prerouting comment=M-LAN-WAN \
connection-mark=no-mark dst-address-list=!inside new-connection-mark=\
LAN_WAN passthrough=yes src-address-list=LAN
add action=mark-routing chain=prerouting comment=SplitISP1 connection-mark=\
LAN_WAN new-routing-mark=ISP1_Route passthrough=yes \
per-connection-classifier=dst-address:2/1 src-address-list=LAN
add action=mark-routing chain=prerouting comment=SplitISP2 connection-mark=\
LAN_WAN new-routing-mark=ISP2_Route passthrough=yes \
per-connection-classifier=dst-address:2/0 src-address-list=LAN
add action=mark-connection chain=prerouting comment=M-BIND-ISP1 \
connection-mark=LAN_WAN new-connection-mark=Bind_ISP1 passthrough=yes \
routing-mark=ISP1_Route
add action=mark-connection chain=prerouting comment=M-BIND-ISP2 \
connection-mark=LAN_WAN new-connection-mark=Bind_ISP2 passthrough=yes \
routing-mark=ISP2_Route
add action=mark-routing chain=prerouting comment=A-BIND-ISP1 connection-mark=\
Bind_ISP1 new-routing-mark=ISP1_Route passthrough=yes src-address-list=\
LAN
add action=mark-routing chain=prerouting comment=A-BIND-ISP2 connection-mark=\
Bind_ISP2 new-routing-mark=ISP2_Route passthrough=yes src-address-list=\
LAN

And routing is as follows. Gateway for ISP2 is ip address, for ISP1 the interface since it's pppoe. Nothing changed, just different firmware.

# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 A S ;;; ISP1-Default-Route
0.0.0.0/0 ISP1-PPPoE 1
1 A S ;;; ISP2-Default-Route
0.0.0.0/0 *********** 1
2 A S ;;; Main-Default-Route-ISP1
0.0.0.0/0 ISP1-PPPoE 1
3 S ;;; Main-Default-Route-ISP2
0.0.0.0/0 109.102.21.1 2
4 ADC 10.0.0.1/32 ************* ISP1-PPPoE 0
13 ADC 109.102.21.0/26 ************* ether2-ISP2 0

tangram · Wed Jul 19, 2017 10:38 am

I've managed to replicate this issue. The way load balancing was configured in 6.37 doesn't work in 6.39.2.
Using https://mum.mikrotik.com/presentations/US12/steve.pdf leads to the same issue. How can I fix this so both WANs are accessible.

If I change the distance for default route of ISP1 from 1 to >2 while ISP2 metric stays 2, both WANs reply. It seems that i'm not allowed to use ISP1 as primary

upower3 · Wed Jul 19, 2017 5:34 pm

The way load balancing was configured in 6.37 doesn't work in 6.39.2.
Using https://mum.mikrotik.com/presentations/US12/steve.pdf leads to the same issue.

Good link, thank you, but the news is not that nice, if the routing behavior changed between bugfix and current branches. Will wait for comments!

tangram · Thu Jul 20, 2017 7:24 am

I've found the issue:

add action=mark-routing chain=output comment=A-ISP1-RT connection-mark=\
M-ISP1-ROS new-routing-mark=ISP1_Route passthrough=yes
add action=mark-routing chain=output comment=A-ISP2-RT connection-mark=\
M-ISP2-ROS new-routing-mark=ISP2_Route passthrough=yes

Connection mark should be ISP1_ROS and ISP2_ROS. I've fixed it. The problem is that I've had about 200 devices updated and after update the comment from the mangle rule was set as connection-mark :

add action=mark-connection chain=input comment=M-ISP1-ROS connection-mark=\
no-mark in-interface=ISP1-PPPoE new-connection-mark=ISP1_ROS passthrough=\
yes

andreadg88 · Thu Jul 20, 2017 4:45 pm

Hi,
we are experiencing a lot of unit crash when we manage/add multiple vlan together.
We have 2 units and use them PPPoE server for the xDSL accesses that use q-in-q vlans and every vlan of C-TAG is bridged with the vlan on S-TAG.

Have anyone experienced same issue?

Wed Jul 26, 2017 1:24 pm

Version 6.40 has been released:
viewtopic.php?f=21&t=123931

v6.39.2 [current]

Re: v6.39.2 [current]

Re: v6.39.2 [current]

Re: v6.39.2 [current]

Re: v6.39.2 [current]

Re: v6.39.2 [current]

Re: v6.39.2 [current]

Re: v6.39.2 [current]

Re: v6.39.2 [current]

Re: v6.39.2 [current]

Re: v6.39.2 [current]

Re: v6.39.2 [current]

Re: v6.39.2 [current]

Re: v6.39.2 [current]

Re: v6.39.2 [current]

Re: v6.39.2 [current]

Re: v6.39.2 [current]

Re: v6.39.2 [current]

Re: v6.39.2 [current]

Re: v6.39.2 [current]

Re: v6.39.2 [current]

Re: v6.39.2 [current]

Re: v6.39.2 [current]

Re: v6.39.2 [current]

Who is online