v6.44.3 [stable] is released!

Announcements
1

RouterOS version 6.44.3 has been released in public “stable” channel!

Before an upgrade:

  1. Remember to make backup/export files before an upgrade and save them on another storage device;
  2. Make sure the device will not lose power during upgrade process;
  3. Device has enough free storage space for all RouterOS packages to be downloaded.

What’s new in 6.44.3 (2019-Apr-23 12:37):

Changes in this release:

*) certificate - fixed SAN being duplicated on status change (introduced in v6.44);
*) conntrack - fixed “loose-tcp-tracking” parameter not taken in action (introduced in v6.44);
*) dhcpv4-server - fixed commenting option for alerts;
*) dhcpv6-server - fixed binding setting update from RADIUS;
*) ike1 - improved stability for transport mode policies on initiator side;
*) ipsec - fixed freshly created identity not taken in action (introduced in v6.44);
*) ipsec - fixed possible configuration corruption after import (introduced in v6.44);
*) ipv6 - adjusted IPv6 route cache max size;
*) ipv6 - improved IPv6 neighbor table updating process;
*) lte - reset LTE modem only when SIM slot is changed on dual SIM slot devices;
*) rb2011 - removed “sfp-led” from “System/LEDs” menu;
*) smb - fixed possible buffer overflow;
*) snmp - added “radio-name” (mtxrWlRtabRadioName) OID support;
*) ssh - added “both”, “local” and “remote” options for “forwarding-enabled” parameter;
*) ssh - do not generate host key on configuration export;
*) ssh - fixed multiline non-interactive command execution;
*) switch - fixed possible crash when interface state changes and DHCP Snooping is enabled;
*) userman - updated authorize.net gateway DNS name;
*) wireless - added support for US FCC UNII-2 and Canada country profiles for LHG-5HPnD-US, RBLHG-5HPnD-XL-US and SXTsq5HPnD-US devices;
*) wireless - improved wireless country settings for EU countries;

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 some problem has appeared on device

Please keep this forum topic strictly related to this particular RouterOS release.

2

Yes, it looks like it is working again!

3

I had hoped for this:

*) lte - fixed session reactivation on R11e-LTE in UMTS mode;

Will we see it in another stable update?

Other than that everything looks good, already updated ~ 30 devices of different type.

4

Upgraded 3xHAP AC 6.44.1, 6.44.2 → 6.44.3 - no issues.

Thank you!

5

I have just upgraded an hAP AC 2 RBD52G-5HacD2HnD from 6.44.2 to 6.44.3 and for some reason my iPhone 5s doesn’t seem to “detect” the 5GHz wireless network which worked just fine before upgrading.

My configuration regarding wireless is:

/interface wireless
set [ find default-name=wlan1 ] antenna-gain=3 band=2ghz-g/n channel-width=20/40mhz-XX country=romania disabled=no disconnect-timeout=15s distance=\
    indoors frequency=auto frequency-mode=regulatory-domain guard-interval=long hw-protection-mode=rts-cts hw-retries=15 mode=ap-bridge \
    preamble-mode=long security-profile=XXXX ssid=XXXX/2 wireless-protocol=802.11 wps-mode=disabled
add disabled=no mac-address=XXX master-interface=wlan1 name=wlan1/XXYY security-profile=XXYY ssid=\
    XXYY/2 wps-mode=disabled
add disabled=no mac-address=XXXX master-interface=wlan1 name=wlan1/XXZZ security-profile=XXZZ ssid=\
    XXZZ/2 wps-mode=disabled
set [ find default-name=wlan2 ] antenna-gain=3 band=5ghz-n/ac channel-width=20/40/80mhz-XXXX country=romania disabled=no disconnect-timeout=15s \
    distance=indoors frequency=auto frequency-mode=regulatory-domain guard-interval=long hw-protection-mode=rts-cts hw-retries=15 mode=ap-bridge \
    preamble-mode=long security-profile=XXXX ssid=XXXX/5 wireless-protocol=802.11 wmm-support=required wps-mode=disabled
add disabled=no mac-address=XXXX master-interface=wlan2 name=wlan2/XXYY security-profile=XXYY ssid=\
    XXYY/5 wmm-support=required wps-mode=disabled
add disabled=no mac-address=XXXX master-interface=wlan2 name=wlan2/XXZZ security-profile=XXZZ ssid=\
    XXZZ/5 wmm-support=required wps-mode=disabled

Of special interest is wmm-support=required which some time ago I’ve determined to be the only setting that combined with channel-width=20/40/80mhz-XXXX allows it to work with iPhone 5s and other smart phones.

Thanks,
Ciprian.

6

cipriancraciun - What is the status on your 5 GHz AP? Sounds like it might be detecting radar and you simply need to wait for a few minutes.

7

Indeed it seems that “waiting for a few minutes” did the trick… Although before reporting this issue I “waited” for about half an hour…

Anyway, perhaps it was an iOS / iPhone fluke… Sorry for the false alarm. :slight_smile:

What do you mean by “status on your AP”? Inside the WLAN interface view, under the Status section I only have values for the following properties:

# for the "main" WLAN interface
Channel		5620/20-eeCe/ac/DP(24dBm)
Overall Tx CCQ		83 %
Noise Floor		-105 dBm
# for the "alias" WLAN interface
Last Link Down Time		Apr/24/2019 16:28:11
Last Link Up Time		Apr/24/2019 16:46:18
Link Downs		5
Registered Clients		3
Authenticated Clients		3
8

updating to 6.44.3 went smooth … from 6.44.2 to 6.44.3 with some help from the dude :wink:
No problems so far

9

The waiting times for DFS channels vary by channel and country, and it appears that sometimes manufacturers (who are in discussion with authorities)
implement the longest wait times when the situation is not completely clear (e.g. local authorities and EU have different requirements).

When you want troublefree operation in the presence of radar and DFS, 5620 is about the worst frequency you can select...
(maybe you selected it because it was the most quiet channel in terms of number of other APs and traffic from others, then now you know why that is!!)

10

cipriancraciun - You would be able to see this under wireless monitor command (“/interface wireless monitor wlan2 once” would return “status: radar-detecting”), on CAPsMAN CAP interface if you use CAPsMAN (":put [/caps-man interface get 5GHz-guest current-state] would return “detecting-radar”) and on wireless debug logs (“wireless,debug wlan2: search for radars on 5260000”).

11

Hello

do not set frequency=auto, use my example.

set

  1. frequency=5180, disconnect-timeout=00:00:03, guard-interval=any, hw-retries=5(or max 7), channel-width=20/40/80mhz-Ceee, band=5ghz-a/n/ac

or

  1. frequency=5200, disconnect-timeout=00:00:03, guard-interval=any, hw-retries=5(or max 7), channel-width=20/40/80mhz-eCee, band=5ghz-a/n/ac

or

  1. frequency=5220, disconnect-timeout=00:00:03, guard-interval=any, hw-retries=5(or max 7), channel-width=20/40/80mhz-eeCe, band=5ghz-a/n/ac

or

4.frequency=5240, disconnect-timeout=00:00:03, guard-interval=any, hw-retries=5(or max 7), channel-width=20/40/80mhz-eeeC, band=5ghz-a/n/ac

Good luck Ciprian.!

Hello Strods, by the way - what about RB4011 duplicate mac address on sfpplus and wlan1? and wlan1 disabling itself.

Can you honestly say when solve this problem? or we will not solve it.

12

I just updated some test devices to 6.44.3 from 6.44.1. SSH port forwarding was working fine before the upgrade, but did not work after.

It looks like the default setting for “/ip ssh forwarding-enabled” has been changed from “both” to “remote”. To fix this:
/ip ssh set forwarding-enabled=both
While you are there, this seems like a good idea:
/ip ssh set strong-crypto=yes allow-none-crypto=no

13

It seems that the list of possible values has changed … on my 6.44.2 it’s like this:
/ip ssh set forwarding-enabled=?

ForwardingEnabled ::= yes | no

14

From 6.44.3 changelog:

*) ssh - added “both”, “local” and “remote” options for “forwarding-enabled” parameter;

15

On behalf of @typicalwisp: when upgrading ROS 6.44.2 setting of forwarding-enabled=yes to ROS 6.44.3 … which value does this setting get? remote?

16

Update not working with 952Ui-5ac2nD; downloads file to memory but doesn’t apply after reboot
Current version is 6.44.1 with packages:

  • advanced-tools
  • dhcp
  • ntp
  • ppp
  • routing
  • security
  • system
  • wireless

The log is empty, nothing reported there. Any ideas?

PS: system backup is now broken (gets error message and an empty file).

17

sounds like your storage is full. clean it out.
if not, the filesystem is corrupted and you need to do a netinstall.
first connect using telnet/ssh and do a /export and cut it from the screen into a file.

18

Thanks, I’ll do it later :slight_smile:

19

Since Tue 4/22, we have a main / core router which crashes regularly at 6-7 hour intervals.

We have upgraded to the latest firmware and OS and replaced the device w/ a new / out of the box model, this is not fixing the problem.

I suspect some sort of DOS attack whether intentional or unintended. I have seen posts in MT Forums regarding IPV6 memory exhaustion issues which I think would be similar to what we are seeing.

I am monitoring the router for used memory via SNMP as of today. Unfortunately it was not properly monitored before today so I don’t have historical info on the memory utilization to relate to the timing of the crashes.

The basic info regarding the device is as follows:


[user@routername] /system resource print
uptime: 2h29m52s
version: 6.44.3 (stable)
build-time: Apr/23/2019 12:37:03
factory-software: 6.38.5
free-memory: 1740.4MiB
total-memory: 1984.0MiB
cpu: tilegx
cpu-count: 9
cpu-frequency: 1000MHz
cpu-load: 2%
free-hdd-space: 82.4MiB
total-hdd-space: 128.0MiB
architecture-name: tile
board-name: CCR1009-7G-1C-1S+
platform: MikroTik



Each time the router crashes the only log messages recorded are like these:

05:04:18 system,error,critical router rebooted without proper shutdown, probably power outage
05:04:24 interface,info sfpp-vlan3 link up
05:04:24 interface,info sfpp-vlan524 link up
05:04:24 interface,info sfpp-vlan532 link up
05:04:24 interface,info sfpp-vlan540 link up
05:04:24 bridge,info “192-168-3-0-24” mac address changed to 64:D1:54:E9:67:95
05:04:24 bridge,info “192-168-5-40-29” mac address changed to 64:D1:54:E9:67:99
05:04:24 bridge,info “192-168-5-24-29” mac address changed to 64:D1:54:E9:67:93
05:04:24 bridge,info “192-168-5-32-29” mac address changed to 64:D1:54:E9:67:93
05:04:25 interface,info sfp-sfpplus1 link up (speed 1G, full duplex)
05:04:26 interface,info ether2 link up (speed 100M, full duplex)
05:04:30 interface,info combo1 link up (speed 100M, full duplex)
05:04:38 interface,info ether3 link up (speed 100M, full duplex)
11:36:26 system,info sntp change time Apr/25/2019 05:05:22 => Apr/25/2019 11:36:26


Watchdog reset is enabled w/ option to send the support file. Email is configured and verified as working by sending email from /tool e-mail send.


[user@routername] /system watchdog print
watch-address: A.B.C.D (replaced to remove sensitive info)
watchdog-timer: yes
no-ping-delay: 30m
ping-timeout: 3m
automatic-supout: yes
auto-send-supout: yes


The watchdog process does not appear to be activated in each crash.

I should have mentioned that the device is dual powered (poe and direct dc via the barrel connector via different feeds). We have double checked power on both sources several times. The original source for both is a DC system which powers the entire tower and cabinet at the base of roughly 20 devices. No other devices exhibit any loss of power or other symptoms when the router reboots.

This is causing a tremendous amount of disruption to our customers. Can you help?

20

@xbar7networks
You might want to send supout to MikroTik support, as this kind of debugging might be out of the scope.

You sure the voltage is ok?