v6.39.2 [current]

Tue Jun 06, 2017 2:04 pm

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

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

What's new in 6.39.2:
*) 6to4 - fixed wrong IPv6 "link-local" address generation;
*) arp - fixed "make-static";
*) bonding - do not add bonding interface if "could not set MTU" error is received;
*) bridge - fixed connectivity between bridges when "fast-forward" feature is enabled;
*) conntrack - load IPv6 connection tracking independently from IPv4;
*) console - fixed "No such file or directory" warnings on upgrade reboots;
*) export - removed spare "caller-id-type" value from compact export;
*) fetch - fixed "user" and "password" argument parsing from URL for FTP;
*) firewall - fixed "address-list" entry "creation-time" adjustment to timezone;
*) firewall - do not allow to set "rate" value to 0 for "limit" parameter;
*) firewall - fixed "address-list" entry changing from IP to DNS and vice versa;
*) gps - removed duplicate logs;
*) ike1 - fixed crash on xauth message;
*) ike1 - removed xauth login length limitation;
*) ike2 - fixed rare kernel failure on address acquire;
*) ike2 - fixed situation when traffic selector prefix was parsed incorrectly;
*) ipsec - fixed generated policy priority;
*) ipsec - fixed peer "my-id" address reset;
*) ipsec - renamed "remote-dynamic-address" to "dynamic-address";
*) ipv6 - fixed address becoming invalid when interface was removed from bridge/mesh;
*) led - fixed turning off LED when interface is lost;
*) lte - improved info channel background polling;
*) lte - improved relialibility on SXT LTE;
*) lte - replaced "user-command" with "at-chat" command;
*) ppp - fixed "change-mss" functionality (introduced in 6.39);
*) ppp - fixed MLPPP over multiple channels/interfaces (introduced in v6.39);
*) ppp - send correct IP address in RADIUS "accounting-stop" messages (introduced in 6.39);
*) pppoe - fixed warning on PPPoE server, when changing interface to non-slave interface;
*) pppoe-client - removed false warning from client interface if it starts running on non-slave interface;
*) pppoe-server - fixed "one-session-per-host" issue where 2 simultaneous sessions were possible from the same host;
*) queue - fixed queuing when at least one child queue has "default-small" and other/s is/are different (introduced in 6.35);
*) quickset - fixed LTE "signal-strength" graphs;
*) sniffer - fixed VLAN tags when sniffing all interfaces;
*) snmp - fixed limited walk;
*) switch - fixed disabling of MAC learning on CRS1xx/CRS2xx;
*) tile - fixed EoIP keepalive when tunnel is made over VLAN interface;
*) tile - fixed rare encryption kernel failure when small packets are processed;
*) traffic-flow - fixed IPFIX IPv6 data reporting;
*) winbox - do not allow to open multiple same sub-menus at the same time;
*) winbox - fixed firewall port selection with Winbox v2;
*) winbox - fixed LTE info button;
*) winbox - removed spare values from "loop-protect" setting for EoIPv6 tunnels;
*) wireless - reduced load on CPU for high speed wireless links;

ebreyit · Tue Jun 06, 2017 3:26 pm

I just popped this on a ccr1009 and it removed all the settings from my main pppoe client interface preventing it from connecting to the internet.

lty1993 · Tue Jun 06, 2017 3:49 pm

The upgrade auto disabled ipv6 package.

MartijnVdS · Tue Jun 06, 2017 3:56 pm

Neither of those things happened on my 1100AHx2 - PPPoE client and IPv6 are still there and enabled.

Tue Jun 06, 2017 3:57 pm

Neither of those things happened on my 1000AHx2 - PPPoE client and IPv6 are still there and enabled.

same here - so far so good.

Tue Jun 06, 2017 4:13 pm

The upgrade auto disabled ipv6 package.

You, used the bundle package for the upgrade?
On what RouterBOARD you saw this and what RouterOS version you had before?

Cha0s · Tue Jun 06, 2017 4:30 pm

Neither of those things happened on my 1000AHx2 - PPPoE client and IPv6 are still there and enabled.
same here - so far so good.

Same here on an RB850Gx2.

lty1993 · Tue Jun 06, 2017 4:33 pm

You, used the bundle package for the upgrade?
On what RouterBOARD you saw this and what RouterOS version you had before

Yes, bundle package.

It happens on CCR1009-8G-1S / RB912UAG-2HPnD / RB912UAG-5HPnD / CRS125-24G-1S. All upgrading from 6.39.1 to 6.39.2.

support.rif sended.

Tue Jun 06, 2017 4:48 pm

lty1993 - Was bundle installed on device before an upgrade? All devices were running 6.39.1 with bundle package installed and IPv6 package enabled and after upgrade package got disabled? Can you upgrade device, make sure package is disabled, without any reboots in the middle generate supout file and send it to support@mikrotik.com together with explanation of your problem?

We have tested this here locally with same packages, versions and different devices and problem does not appear. Either this is something very specific or actually IPv6 package was scheduled to be disabled after reboot and administrator forgot about it and simply the next reboot was upgrade.

Tue Jun 06, 2017 4:49 pm

ebreyit - Client is not changed within this version. maybe you did by accident change something in QuickSet?

ebreyit · Tue Jun 06, 2017 4:55 pm

ebreyit - Client is not changed within this version. maybe you did by accident change something in QuickSet?

I don't use quickset.

original version 6.39.1

upgrade to 6.39.2 via system > packages

on reboot pppoe-client was there but contained no settings as If I had just gone to create new one

Other packages I have installed are NTP and GPS

ksteink · Tue Jun 06, 2017 7:01 pm

Updated my RB2011 from 6.39.1 and no issues. I have IPv6 (HLE tunnel broker) and VPNs (using OVPN) working fine.

Tue Jun 06, 2017 8:08 pm

Nothing about dude in this version? I should post some feature requests to move the dude development forward a bit... Lol.

null31 · Tue Jun 06, 2017 10:09 pm

Upgraded with no problems on RB750Gr2 from 6.39.1 (l2tp/ipsec server, 6to4 broker, pppoe-client, snmp), RB951Ui-2HnD from 6.39.1 (l2tp/ipsec client, simple queue, samba), hAP lite from 6.38.5 and hAP ac lite from 6.39.1.

105547111 · Wed Jun 07, 2017 3:06 am

CCR 1016-12G, 3 x CRS125-24G, 7 x RB951G, 2 x SXT5AC and 3 CHR's no issue at all. 6.39.1 to 6.39.2

complex1 · Wed Jun 07, 2017 10:39 am

Updated my RB2011 from 6.39.1 and found no issues.

psannz · Wed Jun 07, 2017 11:30 am

Just upgraded 15 wAP ac and RB751U running in CAP mode from 6.39.1 without any problems.

andreadg88 · Wed Jun 07, 2017 11:56 am

I have updated 4 CCR1072 units without any problems
PPP accounting-stop was fixed!

0x001 · Wed Jun 07, 2017 12:43 pm

CRS125-24G-1S 6.39.2

CISCO 2911 15.5

ip ipsec proposal print
Flags: X - disabled, * - default
0 * name="default" auth-algorithms=sha1 enc-algorithms=aes-256-cbc lifetime=30m pfs-group=modp1024

Flags: X - disabled, D - dynamic, R - responder
0 address=65.29.2.3/32 auth-method=pre-shared-key secret="qwwerr" generate-policy=no policy-template-group=default exchange-mode=main
send-initial-contact=yes nat-traversal=no proposal-check=obey hash-algorithm=sha1 enc-algorithm=aes-256 dh-group=modp1024 lifetime=1d dpd-interval=2m
dpd-maximum-failures=5

GRE, ph2
19:46:40 ipsec 65.29.2.2 ignore RESPONDER-LIFETIME notification.
19:46:40 ipsec Expecting IP address type in main mode when using preshared key for authorization (see RFC 2409 section 5.4),but FQDN.
19:46:40 ipsec 65.29.2.2 invalid ID payload
i tried auto, address ... not working

how to fix?

haik01 · Wed Jun 07, 2017 1:54 pm

Updated:

RB2011 (2 x )
RB962
RB951-2n (2 x )
RB750 Gr3
Omnitik

No issues at all.

lordcoke · Wed Jun 07, 2017 11:55 pm

*) ipsec - renamed "remote-dynamic-address" to "dynamic-address";
is this 'dynamic-adress' feature already documented ? Did not found any note in Wiki.

acidvenom · Thu Jun 08, 2017 12:15 am

cAP bricked (again), RB3011 is OK, 951G is OK too.

LynxChaus · Thu Jun 08, 2017 1:11 am

Inadequate CPU consumption on 1100AHx2:

> tool profile cpu=all 
NAME                    CPU        USAGE
ovpn                      0           0%
console                   0         0.5%
firewall                  0         1.5%
networking                0           8%
winbox                    0           0%
management                0           0%
bfd                       0           0%
routing                   0           0%
profiling                 0           0%
queuing                   0         0.5%
unclassified              0           0%
cpu0                               10.5%
ovpn                      1           0%
ethernet                  1         0.5%
firewall                  1         0.5%
networking                1          80%
winbox                    1           0%
management                1           1%
bfd                       1           0%
routing                   1        13.5%
profiling                 1           0%
queuing                   1           0%
bridging                  1           0%
unclassified              1           1%
cpu1                               96.5%

networking is going crazy. Total load on all interfaces ~ 5Mbit/s.

AzAel76 · Fri Jun 09, 2017 2:55 am

I updated my production ccr1009 and ccr1036 both configured as PPPoE servers to 6.39.1 and then 6.39.2 with this week and on both versions connected PPPoE clients had major issues browsing.

Due to being production systems i rolled back to 6.37.5 (Bugfix) as soon as it became evident that 6.39.2 did not resolve the issue, I didn't take the time to pull a suppout but the issue was the same but without uniform results across different pppoe clients. One client on PPPoE server B for example could not access for example beta.speedtest.net, page would time out. it could get a ping and the trace route reported 9 hops. A second client identical cpe setup on the the same PPPoE server B could access the site and traceroute reported 8 hops.. however other pages would not load.

Thats the best i can describe in short.

Cha0s · Fri Jun 09, 2017 3:27 pm

Upgraded the following devices without any issues.

CCR1036-8G-2S+ (x2)
RB3011UiAS-RM (x1)
RB2011UiAS-RM (x2)
RB2011UiAS-2HnD (x3)
RB1200 (x1)
RB850Gx2 (x1)
RB433AH (x1)
RB750G (x2)
RB951G-2HnD (x2)
SEXTANTG (911G-5HPnD) (x3)
SXT 5HPnD (x2)
RB Groove A-52HPn (x1)
cAP L-2nD (x2)
mAP L-2nD (x3)
hAP Lite (941-2nD) (x2)
x86 (x14)

All updates where done from either v6.38.5 or v6.39.

pe1chl · Fri Jun 09, 2017 7:22 pm

I updated my production ccr1009 and ccr1036 both configured as PPPoE servers to 6.39.1 and then 6.39.2 with this week and on both versions connected PPPoE clients had major issues browsing.

Your issues are probably MTU related, you need to check that everything is configured at correct MTU and that you have some form of MSS clamping configured.

floeff · Fri Jun 09, 2017 9:32 pm

hEX 6.39.1 to 6.39.2
Update killed my DNS settings that I did via

/ip dns set allow-remote-requests=yes servers=2001:4860:4860::8888,2001:4860:4860::8844,8.8.8.8,8.8.4.4

The servers were removed, which also blocked (or delayed) incoming SSH requests

floeff · Fri Jun 09, 2017 10:18 pm

I also discovered a couple of

always-broadcast=yes

in my DHCP settings that were not supposed to be there, plus one

server=lan

that was missing. On these two, however, not sure if they had been in place before a previous upgrade.

pe1chl · Fri Jun 09, 2017 10:57 pm

hEX 6.39.1 to 6.39.2
Update killed my DNS settings

I updated a CCR with similar DNS settings, no problem.

astraliens · Sat Jun 10, 2017 5:25 pm

After upgrade from 6.35.1 to 6.39.2 found a problem with pptp client. Every pptp tunnel on a 2011 uias-2hnd became very slow, or I'm not sure how to describe this correctly, when downloading something on a single thread everything is fine, but when I'm browsing any website - they loading too slow, looks like browser requests are queued and processing one by one... in a same tine pptp tunnel from windows itself to the same servers works without any issues..
There are no any active queue rules, direct traffic is normal, the only problem is traffic through pptp tunnels. Tried to connect to more than 5 different vpn servers and the same situation on each.
Already tried to change mtu, but still no luck...

Kindis · Sat Jun 10, 2017 6:06 pm

After upgrade from 6.35.1 to 6.39.2 found a problem with pptp client. Every pptp tunnel on a 2011 uias-2hnd became very slow, or I'm not sure how to describe this correctly, when downloading something on a single thread everything is fine, but when I'm browsing any website - they loading too slow, looks like browser requests are queued and processing one by one... in a same tine pptp tunnel from windows itself to the same servers works without any issues..
There are no any active queue rules, direct traffic is normal, the only problem is traffic through pptp tunnels. Tried to connect to more than 5 different vpn servers and the same situation on each.
Already tried to change mtu, but still no luck...

Do you use fast track? If so can you please disable the fasttrack rule and test?

Sat Jun 10, 2017 6:16 pm

Kindis,

Please do not cite full post. Do you think that readers are not able to follow thread ?

raffav · Sat Jun 10, 2017 6:20 pm

@BartoszP

Agree

Enviado de meu XT1580 usando Tapatalk

Sat Jun 10, 2017 6:23 pm

Raffav,

Do you think if it is funny that you cite my post just under this post ?
I'm asking as moderator. Do not want to be rude but please, plese ... do not do that.
EDIT: Raffav edited his post

astraliens · Sat Jun 10, 2017 6:27 pm

Kindis
Thanks for idea, without active fastpath option pptp works fine like before upgrade.
Any idea how to remain fasttrack active and work with pptp in a same time

raffav · Sat Jun 10, 2017 6:40 pm

BartoszP

I edited my post,
I was not making funny, don't exaggerate

Enviado de meu XT1580 usando Tapatalk

Kindis · Sat Jun 10, 2017 10:15 pm

Kindis,

Please do not cite full post. Do you think that readers are not able to follow thread ?

No I expect them to use a browser that fixes that

For a more serious note its hard as hell to remove quotes on a mobile without breaking it.

Kindis · Sat Jun 10, 2017 10:22 pm

Kindis
Any idea how to remain fasttrack active and work with pptp in a same time

No not in this case. I have a active case at Mikrotik regarding this. Hopefully they can find what is the issue.

nigslaysa · Sun Jun 11, 2017 6:09 am

Hi After updating to 6.39.2

My Simple queue seems not catching upload traffic it only catches download it was working fine before the update.

Jotne · Sun Jun 11, 2017 10:41 am

With 6.39.2 I still have NTP problems, see here:
viewtopic.php?f=2&t=116106&p=602402#p602402

I also would like something written in the log that tells me that my system was upgraded.
I do see this as first info after reboot:

12:04 interface,info MikroTik: ether3 link up (speed 1G, full duplex)
12:04 interface,info MikroTik: ether1 link up (speed 1G, full duplex)

I would like to see some like this:

12:04 interface,info MikroTik: ether3 link up (speed 1G, full duplex)
12:04 interface,info MikroTik: ether1 link up (speed 1G, full duplex)
12:04 system,info MikroTik: upgraded to 6.39.2 ok
12:04 system,info MikroTik: starting up
12:01 system,info MikroTik: rebooting
12:01 system,info MikroTik: upgrading from 6.39.1 to 6.39.2

Marino · Sun Jun 11, 2017 11:07 am

Kindis
Thanks for idea, without active fastpath option pptp works fine like before upgrade.
Any idea how to remain fasttrack active and work with pptp in a same time

Do you use a separate subnet for pptp clients? Then you could use a raw rule in the firewall with action = no track for that subnet.

astraliens · Sun Jun 11, 2017 11:24 am

Marino
Thanks for idea, yes, every tunnel has it's own subnet. Tried to create raw rule in firewall with prerouting chain and specify IP directly / specify IP list, also tried output chain + output pptp interface, but still no luck.
Counter in rule showing it works, but situation with traffic is the same as mentioned before..

pe1chl · Sun Jun 11, 2017 11:57 am

I also would like something written in the log that tells me that my system was upgraded.
I do see this as first info after reboot:

12:04 interface,info MikroTik: ether3 link up (speed 1G, full duplex)
12:04 interface,info MikroTik: ether1 link up (speed 1G, full duplex)

I would like to see some like this:

12:04 interface,info MikroTik: ether3 link up (speed 1G, full duplex)
12:04 interface,info MikroTik: ether1 link up (speed 1G, full duplex)
12:04 system,info MikroTik: upgraded to 6.39.2 ok
12:04 system,info MikroTik: starting up
12:01 system,info MikroTik: rebooting
12:01 system,info MikroTik: upgrading from 6.39.1 to 6.39.2

It is already there, but it is only in the internal log and not in the remote syslog. Maybe you are looking there?
Of course entries in the remote syslog are shown only after the interfaces come up.

asaf23 · Sun Jun 11, 2017 5:30 pm

I have already posted in the RC topic about some mess in the LTE interface (viewtopic.php?f=21&t=121198&start=50#p599564
Here (not Release Candidate) we have same things which somehow was implemented in stable version.
Maybe only I have this bug in my current router board? Did anybody from MikroTik just pay some attention?

[img]
http://savepic.ru/14368074.png
[/img]

Jotne · Sun Jun 11, 2017 10:26 pm

It is already there, but it is only in the internal log and not in the remote syslog. Maybe you are looking there?
Of course entries in the remote syslog are shown only after the interfaces come up.

I did not know it was in the internal log. Why is the internal log different from the syslog log?
Interfaces needs off course to be up before I get the syslog, but send all out after.

pe1chl · Mon Jun 12, 2017 11:37 am

I did not know it was in the internal log. Why is the internal log different from the syslog log?

Because the messages written to the log before there is a connection to the log server are lost.

Interfaces needs off course to be up before I get the syslog, but send all out after.

It is not as simple as that. The syslog server might be on a VPN, WiFi link, whatever.
And there could be another link further down the path that the router does not know about.
The syslog server itself could still be booting (e.g. after a total power failure).

za7 · Mon Jun 12, 2017 6:18 pm

I have a RB750gr3 the upgrade from RouterOS 6.39.1 to 6.39.2 bricked the device. I tried on two different computers to netinstall 6.39.2 but that did not work.
Any advice would be appreciated. I contacted the seller about RMA and was told post here first.

Thanks

pe1chl · Mon Jun 12, 2017 6:37 pm

What happens during your netinstall? Do you see the device in netinstall?

za7 · Mon Jun 12, 2017 6:44 pm

The device is seen in netinstall, when press the install button it last 12 seconds and then go back ready with no actual install.

routerjunkie · Tue Jun 13, 2017 8:08 am

I'm getting "aa:bb:cc:dd:ee:ff@wlan2: disconnected, extensive data loss" multiple times per hour on my hAP ac (mipsbe) device when the wireless client is an Intel(R) Dual Band Wireless-AC 7260 (PCI\VEN_8086&DEV_08B1&SUBSYS_40708086&REV_BB) on 5GHz within very good range. In other words, the wireless client is constantly disconnecting. I'm not sure if the issue only happens on 5GHz, or if any other wireless clients are affected (or not affected.)

I do know however that for the environment described above, the bug is reproducible; that is, when I downgrade the hAP ac to 6.39.1 the issue goes away, and when I upgrade to 6.39.2 the issue returns shortly after the first boot.

I first noticed this issue in the RC builds (unsure which build number specifically.) Unfortunately it looks like it made it into current.

Should I file a bug for this somewhere?

--

Edit: Sorry, I got the versions mixed up; the disconnections were happening for me on the 6.41rc versions (which might be fixed by now.) 6.39.2 is working great.

dadaniel · Tue Jun 13, 2017 9:54 am

The device is seen in netinstall, when press the install button it last 12 seconds and then go back ready with no actual install.

Close netinstall, open it again and press install a second time. This time it will work.

gyropilot · Tue Jun 13, 2017 8:20 pm

Updated the following devices from ROS v6.39.1 to v6.39.2 with no difficulties noted:

hAP ac Lite
Metal 52 ac

zcybercomputing · Tue Jun 13, 2017 9:07 pm

Updated RB-3011, RB750, and RB2011 from 6.38.5 to 6.39.2 without incident.

zilf · Tue Jun 13, 2017 9:59 pm

RB 850Gx2

6.39.2 - PPTP with mtu 1400 does not work, with mtu 1380 working
6.39 - PPTP with mtu 1400 working, with mtu 1380 working.

jmartins · Tue Jun 13, 2017 11:03 pm

I have a snmp bug with RB750GL and firmware v6.39.2 and routerboard firmware 3.33

snmpget -c public -v 1 192.168.11.189 .1.3.6.1.4.1.14988.1.1.3.10.0
Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: SNMPv2-SMI::enterprises.14988.1.1.3.10.0

solelunauno · Wed Jun 14, 2017 11:30 am

I Use RB750UP for its poe out and monitor functions.
If you give this instruction:

/interface ethernet poe monitor [find name=ether5] once do={:put $"poe-out-current"}

with 6.37.5 it shows the correct value of the variable "poe-out-current";
with 6.39.2 it shows the value of "poe-out-voltage";
and all those variables are so shifted: "poe-out-current shows" the voltage, "poe-out-power" shows the current, and so on.

ropbo · Wed Jun 14, 2017 10:44 pm

I can't edit any NAT rule via webfig (tried different browsers on MAC and PC). Seems like a bug. I can edit everything else on any other window. Just under firewall->NAT that I can't. I click on any NAT rule and nothing happens. I can create new rules but not edit existing ones.

-> firewall -> NAT

RB3011UiAS
6.39.2 (stable)
arm

It happened in two different units. Upgraded via system->packages

pe1chl · Wed Jun 14, 2017 11:00 pm

I can't edit any NAT rule via webfig (tried different browsers on MAC and PC). Seems like a bug.

Works OK for me (both CCR1009 and RB3011)
Try to clear the browser cache...

ropbo · Wed Jun 14, 2017 11:11 pm

I can't edit any NAT rule via webfig (tried different browsers on MAC and PC). Seems like a bug.
Works OK for me (both CCR1009 and RB3011)
Try to clear the browser cache...

Tried that, same thing, can't edit it. My co-worker on a Linux box can't edit it either. Really strange problem, I think it's happened after the upgrade. There're about 38 items in the NAT page. The other Mikrotik unit that is also showing this problem also has a large number of NAT rules (RB1100AHx2, powerpc, 6.39.1 (stable))

I just upgraded another unit (750GL, mipsbe) that only has 14 NAT rules. This one worked.

Puzzling.

UPDATE: I just added about 30 NAT rules to the 750GL and it didn't cause the problem. So I can edit NAT rules on the mipsbe but not on the powerpc nor the arm units.

LukasL · Thu Jun 15, 2017 10:28 pm

Is "*) capsman - fixed EAP identity reporting in “registration-table”;" ported to the 6.39.x version? can't see it in the chnagelog. Just running CAPSMAN 6.40RC for this (no other problems}

jBrain · Fri Jun 16, 2017 5:02 pm

Update to 6.39.2 from 6.39, the web interface is now gone. The underlying configuration seems to be in tact, but I'm no longer able to access the admin web interface, from chrome the connection fails with a time out. The download and update were performed using the web interface, no other changes have been made. I've tried rebooting from the LCD panel, as well as accessing any sort of useful information from the available LCD info screens but was not able to find anything relative to the admin web interface.

All suggestions welcome.

UPDATE: At first it was only the web interface and local IPs I was not able to connect with, then outside hosts such as GMail intermittently until a final collapse of all WIRED ethernet connections to 3 different machines. I noticed I was able to still access internal and external addresses using a device on the wireless ethernet, as well as the admin webfig. All the settings seemed to be in order so I rebooted, the wired connections partially returned in that I can access external hosts from devices plugged into Eth1 - Eth5, but nothing internal on the wireless ethernet which includes the admin web access for some reason

UPDATE 2: I was able to restore the backup of 6.39 and things seem to be back to normal. I'll give this another try sometime but this upgrade was problematic for a seemingly simple no-dhcp bridge configuration with ~12 hosts split between wired/wireless. 6.39 seems rock solid though.

mzahor · Sat Jun 17, 2017 8:27 am

I have the same problem on a CRS109-8G-1S-2HnD after upgrading to 6.39.2. Tried chrome firefox and IE

I can't edit any NAT rule via webfig (tried different browsers on MAC and PC). Seems like a bug. I can edit everything else on any other window. Just under firewall->NAT that I can't. I click on any NAT rule and nothing happens. I can create new rules but not edit existing ones.

-> firewall -> NAT

RB3011UiAS
6.39.2 (stable)
arm

It happened in two different units. Upgraded via system->packages

Kevo · Sat Jun 17, 2017 3:51 pm

The new style webfig terminal seems buggy. It doesn't seem to work the first time I click the button. I have to click out to webfig and click back to terminal.

Also, on Safari, the terminal size flashes back and forth like it's opening up too big to fill the window, which triggers the scrollbars, which triggers the sizing code to shrink, which triggers the scrollbars to go away, and that repeats over and over again. If I play around with the window size enough, I can eventually make it stop flashing, but it's very annoying. On Chrome you can sort of see the same thing happening while resizing the window, but it is fine once you stop resizing.

driven · Sat Jun 17, 2017 10:05 pm

When using the built-in DNS, the server cache fills in unfinished (ip 0.0.0.0) queries with the type "unknown" (empirically found out that this is PTR) and non-zero TTL, which leads to overflow of the cache and service inoperability. The problem is not only on the latest firmware.

pe1chl · Sat Jun 17, 2017 10:14 pm

somebody has set the .lan default search suffix. remove that!

driven · Sun Jun 18, 2017 1:49 am

Sorry, the screenshot is not the one. In this video on time 0:34 the list of empty PTRs is visible.

aviper · Sun Jun 18, 2017 10:40 am

I have a question with respect the release numbering:

Why 6.37.x is Bugfix and 6.39.x is current.
Where are the 6.38.x releases? I think all the 6.38.x must be Bugfix if my logic is right.

Sun Jun 18, 2017 5:13 pm

Where are the 6.38.x releases? I think all the 6.38.x must be Bugfix if my logic is right.

The bugfix channel is supposed to only offer the most stable releases, ideally without any known regressions. A new release in the current channel does not (and should never) automatically promote the previous current to bugfix. In my opinion the 6.38.x release series was somewhat buggy, so I'm happy Mikrotik have not promoted it to bugfix.

PS. You can still find 6.38 releases in the download archive, if you need to for whatever reason.

mpho1010 · Mon Jun 19, 2017 4:49 pm

Hi

Can you please give me the DDNS script for NO-IP. Am currently on Version 6.39.2

Regards
Mpho

fbianchi · Mon Jun 19, 2017 4:59 pm

Hi,

I'm trying to install the dude for the first time in a RB3011 with 6.39.2. I uploaded the arm package with the same version, but I get the following error in the log:

Can not install dude-6.39.2: system 6.39.2 is not installed, but is required

And I have that version installed!!!

Any ideas?

Thanks!!!

bajodel · Mon Jun 19, 2017 7:56 pm

..
Can not install dude-6.39.2: system 6.39.2 is not installed, but is required
Any ideas?

Probably wrong arch, try this:
https://download2.mikrotik.com/routeros ... .2-arm.npk

HeadCraft · Thu Jun 22, 2017 12:26 am

Upgraded to 6.39.2. IPSec tunnel stopped working.
I saw that if my clients who have dynamic external ip with IPIP tunnel configured with ipsec passphrase cannot initialize phase1 with send error.
It is because of dynamic entry in ipsec policies and peers not changing to new one. As example:
after this command:

/interface ipip set [ find ipsec-secret=1234 local-address=1.1.1.1 remote-address=2.2.2.2 ] local-address=3.3.3.3

entry in /ip ipsec policies stays src-address=1.1.1.1 not 3.3.3.3 even if I disable\enable ipip interface.

RN3QTB · Thu Jun 22, 2017 10:01 am

HELP!!!! HELP!!!! HELP!!!!
SXT r2 5nD
v6.39.2
Yesterday went to the spot, saw that there was an upgrade to version v6.39.2, pressed "update and restart".The firmware is loaded, point and rebooted... now it won't turn on!!! The point itself is working, but it is not detected by Winbox.Tried to restart - nothing helps. What to do???

pe1chl · Thu Jun 22, 2017 11:12 am

Upgraded to 6.39.2. IPSec tunnel stopped working.
I saw that if my clients who have dynamic external ip with IPIP tunnel configured with ipsec passphrase cannot initialize phase1 with send error.
It is because of dynamic entry in ipsec policies and peers not changing to new one.

You have some scripting to change the tunnel endpoint address in that case? And also at the server side?
I would think it is better to use e.g. L2TP/IPsec or some other "roadwarrior oriented" VPN solution in such cases, as you don't need to configure the
dynamic address of the client anywhere.

RN3QTB · Fri Jun 23, 2017 9:19 am

HELP!!!! HELP!!!! HELP!!!!
SXT r2 5nD
v6.39.2
Yesterday went to the spot, saw that there was an upgrade to version v6.39.2, pressed "update and restart".The firmware is loaded, point and rebooted... now it won't turn on!!! The point itself is working, but it is not detected by Winbox.Tried to restart - nothing helps. What to do???

Hello! The problem is solved! Found online program Nelinstall. Is the bootloader firmware in the access point. Connect it to the laptop directly, then rebooted while pressing the "reset" button. Point booted and appeared in the program. I downloaded from the site of the original firmware version 5.26 (Legacy) uploaded it to the spot, "MIRACLE!!!" Point rebooted and worked!!! I think now .to upgrade or not to v6.39.2 or not worth it )))

wowooshkah · Mon Jun 26, 2017 12:42 am

After upgrading to v6.39.2 i can't edit any NAT rule in webfig (hAP AC lite)
Very unpleasant bug
(via WinBox work fine)

KitMikro · Mon Jun 26, 2017 1:40 pm

Hi Sorry if this has been posted already, but don't have time to read whole thread...

After update the speed on my RB750gr3 is incorrect. I can't change it back to any other setting.

viewtopic.php?t=116969

jBrain · Wed Jun 28, 2017 5:46 pm

An interesting problem that might be critical to some in more public environments: It's not possible to logout of webfig. In that clicking the logout icon directs you to the log-in page, but simply going to the root address allows full access to webfig. In fact it seems you don't even have to authenticate the first time, there seems to be no session checking going on at all. (with or without SSL) I'm able to access and interact with the webfig front-end on any device in the local subnet.

This is from a config reset that fixed the SSL certificate problem I encountered on update. (had to reset config and regen certificates)

update: this was something I had overlooked before, and expected behavior when using the default admin user without setting the password.

Wed Jun 28, 2017 8:17 pm

In fact it seems you don't even have to authenticate the first time, there seems to be no session checking going on at all.

WebFig auto-logins you by default until you change the default admin password or disable or rename the default admin user. This is a documented behavior.

jBrain · Wed Jun 28, 2017 9:28 pm

In fact it seems you don't even have to authenticate the first time, there seems to be no session checking going on at all.
WebFig auto-logins you by default until you change the default admin password or disable or rename the default admin user. This is a documented behavior.

Thank you! I was actually reading through the manual and discovered my error, and was coming back here to correct it. I suppose I had never noticed before as I had only set the password once for each unit (4 here on site). This is great, thanks again!

Kraken2k · Thu Jun 29, 2017 12:05 pm

Upgraded RB1100AHx2 from 6.37.5 to 6.39.2 and encountered problems with IPsec tunnels: I have site2site tunnels (other side are also mostly RB2011UAS-2HnD with RoS 6.39.2, that were upgraded from the same version at the same moment). I made no config changes and tunnels worked for a really long time before, but since upgrade I got messages in log:

ipsec, error memory failed to pre-process ph2 packet.
ipsec, error memory peer sent packet for dead phase2
ipsec, error memory peer sent packet for dead phase2

the tunnels are usually down just or a moment and then they are re-established. Strange is, that this messages are only in RB1100AHx2 router log, not other other side. The settings are same on both sides, some just tunnels have NAT-T, some not, but this occur for both cases.

Any ideas what could be wrong?

schadom · Fri Jun 30, 2017 12:14 am

Currently in 6.39.2 BGP sessions are reconnecting when adding/changing the comment of a session.
This makes no sense to me. Maybe this behaviour could be removed in an upcoming release?

Thanks

k6ccc · Fri Jun 30, 2017 9:37 pm

Upgraded my RB-750Gr3 from ver. 6.39.1 to 6.39.2 this morning and so far no problems. I'll do the RB-750r2 sometime overnight.

Kindis · Sat Jul 01, 2017 10:28 am

Finely a working fasttrack. I have been having strange issues with internal web pages not loading correct, slow speed during some scenarios. MT support cracked the issue yesterday. I have several bonded interfaces and after added forced mac on all those interfaces and a reboot, now all my issues are gone

Resolved for both 3011 and 750Gr3.

avdvyver01 · Mon Jul 03, 2017 3:17 pm

Hi,

I am using a Mikrotik virtual appliance in Amazon Web Services running v6.39.2. I terminate a AWS VPC VPN (from another AWS region) on this Mikrotik. The AWS VPN consist out of 2 IPSec tunnels (for redundant purposes) and there is a know issue where one of the tunnel policies on the Mikrotik is always marked as invalid. I was hoping that the policy priority fix in the v6.39.2 release would fix this issue but it still seems to be there (perhaps I misunderstood the details of the fix). Does anyone know of a way to get around this problem? Is there a possibility to script something that will mark the invalid policy (priority 0) as valid if the primary tunnels (policy priority 1) fails and reverses the process when the primary is back up? Of has anyone another way to automatically deal with this?

Thanks!

l0pes · Mon Jul 03, 2017 4:33 pm

Hello Folks,

I upgraded a CCR1009-7G-1C-1S+ from 6.37.4 via System > Packages and after trying to create a VLAN with the same name and different ID of another VLAN by mistake. RouterOS show me a message: "Couldn't change Interface <vlan-name> - already have interface with such name (6)" but remove the older VLAN interface.

Regards,

--
Rafael Lopes

upower3 · Wed Jul 05, 2017 12:39 am

Quite impressive with this silly thing, but as I do on freshly installed CCR1009-7G-1C-1S+ with ROS 6.39.2 (stable) and fw 3.33:

[admin@Mikrotik] > /system resource cpu print oid 
 0 load=.1.3.6.1.2.1.25.3.3.1.2.0 
 1 load=.1.3.6.1.2.1.25.3.3.1.2.1 
 2 load=.1.3.6.1.2.1.25.3.3.1.2.2 
 3 load=.1.3.6.1.2.1.25.3.3.1.2.3 
 4 load=.1.3.6.1.2.1.25.3.3.1.2.4 
 5 load=.1.3.6.1.2.1.25.3.3.1.2.5 
 6 load=.1.3.6.1.2.1.25.3.3.1.2.6 
 7 load=.1.3.6.1.2.1.25.3.3.1.2.7 
 8 load=.1.3.6.1.2.1.25.3.3.1.2.8

and that's looking fine, but as I do snmpwalk on it, I see different OIDs:

# snmpwalk -v2c -c public 192.168.88.1 .1.3.6.1.2.1.25.3.3.1.2
iso.3.6.1.2.1.25.3.3.1.2.1 = INTEGER: 0
iso.3.6.1.2.1.25.3.3.1.2.2 = INTEGER: 0
iso.3.6.1.2.1.25.3.3.1.2.3 = INTEGER: 0
iso.3.6.1.2.1.25.3.3.1.2.4 = INTEGER: 0
iso.3.6.1.2.1.25.3.3.1.2.5 = INTEGER: 1
iso.3.6.1.2.1.25.3.3.1.2.6 = INTEGER: 5
iso.3.6.1.2.1.25.3.3.1.2.7 = INTEGER: 0
iso.3.6.1.2.1.25.3.3.1.2.8 = INTEGER: 0
iso.3.6.1.2.1.25.3.3.1.2.9 = INTEGER: 0

Note, the ROS says the OIDs starts with 0 (e.g. all cores are 0..8), while snmpwalk display OIDs that started with 1, and goes 1..9.

Is this for a purpose?

Wed Jul 05, 2017 4:13 pm

l0pes, upower3 - Both these problems are reproduced and will be fixed in upcoming RouterOS releases.

upower3 · Wed Jul 05, 2017 4:16 pm

l0pes, upower3 - Both these problems are reproduced and will be fixed in upcoming RouterOS releases.

Thank you for this confirmation. I know guys ypu do your best to fix problems, and your work is really appreciated by all the users around.

But, please correct me if I'm wrong, the CPU OIDs will be changes again after the fix?

Are there any UID I can steady use to monitor 1 or 5 minute CPU load per each core?

Wed Jul 05, 2017 5:00 pm

upower3 - We will check where it is wrong and fix it in next releases. Most likely (but not promised) OIDs will start with .1 not .0 - OID print should be adjusted. At the moment you can only calculate average load by yourself. You can only read CPU usage per CPU core.

laca77 · Thu Jul 06, 2017 12:59 pm

Hi

On my 2 Hap AC Lite with CAPS if i modify anything in the CAPS part (fix the channel or TX power or whatever) after that applied it the next connected wifi client doesn't get IP from DHCP server that is on the CAPS manager too. I had to disable and enable again the DHCP row in the ip/dhcp-server menu and it works again. Until the next change when i had to disable-enable the DHCP server again.
Sorry but now i dont' have access to the APs so i am not able to do any debug or logs or configs. It is a very simple CAPS config with 1 SSID on 2.4G and 1 SSID on 5G. The wifis cap devices birdged to the local bridge where are all ports.. so nothing secpial.
I just would like to sign this problem to the communitiy.

Laca

mducharme · Fri Jul 07, 2017 7:55 pm

Can anybody else confirm - we are noticing a serious problem with EoIP and Packet Sniffer / Torch. If we run a packet capture or torch, all EoIP traffic stops. When we stop the capture or torch, EoIP traffic works again. This appears to be a bug?

pe1chl · Fri Jul 07, 2017 8:20 pm

Can anybody else confirm - we are noticing a serious problem with EoIP and Packet Sniffer / Torch. If we run a packet capture or torch, all EoIP traffic stops. When we stop the capture or torch, EoIP traffic works again. This appears to be a bug?

This could be the result of Fasttrack rules that are not correct (although usually the observed behaviour is reverse: it starts to work when you run packet sniffer or torch).

upower3 · Fri Jul 07, 2017 8:30 pm

This could be the result of Fasttrack rules that are not correct (although usually the observed behaviour is reverse: it starts to work when you run packet sniffer or torch).

By the way, is there any approach how to reset fasttrack state? i suspect I can see how it keep process traffic with old rules even when there are some changes or new rules added?

mducharme · Fri Jul 07, 2017 9:18 pm

Can anybody else confirm - we are noticing a serious problem with EoIP and Packet Sniffer / Torch. If we run a packet capture or torch, all EoIP traffic stops. When we stop the capture or torch, EoIP traffic works again. This appears to be a bug?
This could be the result of Fasttrack rules that are not correct (although usually the observed behaviour is reverse: it starts to work when you run packet sniffer or torch).

We don't have FastTrack rules - we are an ISP and fasttrack has no benefit for us. We have sites with up to a hundred customers on EoIP tunnel and they all go down if someone runs a torch or sniffer.

hairfarmer · Sat Jul 08, 2017 1:24 am

Updated a CRS125-24G-1S to 6.39.2.

Ethernet ports which have POE APs attached [RBcAP2n units] are now going up/down continuously on only 4 ports (total APs attached to the CRS=8).

I'm at a point where I'm not sure if I need to replace the cabling since direct attaching the APs will fix the issue.

At the same time I'm not sure we had an issue before the update.
Forcing the port to 100Mbit and turning off Autodection does nothing.

I'm at a loss, anyone have a similar issue?

upower3 · Sat Jul 08, 2017 7:25 pm

Looks like it worth to switch to bugfix branch and proceed with it.

Please, backport IPSec packets order fix for CCRs to bugfix!

hairfarmer · Sat Jul 08, 2017 9:04 pm

Looks like it worth to switch to bugfix branch and proceed with it.

Not sure if this was directed towards me but I did and the current bug-fix didn't do the trick.

Njumaen · Sat Jul 08, 2017 11:22 pm

Hi!

On hAPac (RB926UiGS-5HacT2HnT) it'n not possible to disable all LEDs.

Winbox System/LEDs/Settings ->immediate

results in

"Couldn't change LED Settings - This feature is not supported on this board (6)"

Ralf.

upower3 · Sat Jul 08, 2017 11:25 pm

On hAPac (RB926UiGS-5HacT2HnT) it'n not possible to disable all LEDs.

Winbox System/LEDs/Settings ->immediate results in

"Couldn't change LED Settings - This feature is not supported on this board (6)"

Frankly, I keep seeing this on every ROS version so far for every small device (951, 941, 926 etc), so looks like they should just hide this option for these devices. Not a big deal, anyway, not breaking anything.
I feel your pain

but hope MT guys will fix more serious things first.

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.

mrz · 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

mrz · 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

Who is online