v6.44.3 [stable] is released!

emils · Wed Apr 24, 2019 10:07 am

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.

pe1chl · Wed Apr 24, 2019 12:40 pm

*) conntrack - fixed "loose-tcp-tracking" parameter not taken in action (introduced in v6.44);

Yes, it looks like it is working again!

eworm · Wed Apr 24, 2019 12:44 pm

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.

ofer · Wed Apr 24, 2019 1:56 pm

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

Thank you!

cipriancraciun · Wed Apr 24, 2019 4:43 pm

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.

Wed Apr 24, 2019 5:15 pm

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.

cipriancraciun · Wed Apr 24, 2019 5:28 pm

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.

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. :)

----

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

eddieb · Wed Apr 24, 2019 5:34 pm

updating to 6.44.3 went smooth ... from 6.44.2 to 6.44.3 with some help from the dude

No problems so far

pe1chl · Wed Apr 24, 2019 7:03 pm

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

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!!)

Wed Apr 24, 2019 10:16 pm

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").

TimurA · Wed Apr 24, 2019 11:38 pm

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.

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

2. 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

3. 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.

typicalwisp · Thu Apr 25, 2019 7:00 am

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:

Code: Select all

/ip ssh set forwarding-enabled=both

While you are there, this seems like a good idea:

Code: Select all

/ip ssh set strong-crypto=yes allow-none-crypto=no

mkx · Thu Apr 25, 2019 4:55 pm

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:
Code: Select all
/ip ssh set forwarding-enabled=both

It seems that the list of possible values has changed ... on my 6.44.2 it's like this:

Code: Select all


/ip ssh set forwarding-enabled=?



ForwardingEnabled ::= yes | no

krisjanisj · Thu Apr 25, 2019 4:57 pm

It seems that the list of possible values has changed ... on my 6.44.2 it's like this:

Code: Select all
/ip ssh set forwarding-enabled=? ForwardingEnabled ::= yes | no

From 6.44.3 changelog:

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

mkx · Thu Apr 25, 2019 5:04 pm

From 6.44.3 changelog:
*) ssh - added "both", "local" and "remote" options for "forwarding-enabled" parameter;

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?

willianwrm · Thu Apr 25, 2019 8:51 pm

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).

pe1chl · Thu Apr 25, 2019 9:00 pm

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.

willianwrm · Thu Apr 25, 2019 9:16 pm

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.

Thanks, I'll do it later

xbar7networks · Fri Apr 26, 2019 1:15 am

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<SAFE> 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<SAFE> 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?

BRMateus2 · Fri Apr 26, 2019 4:21 am

@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?

xbar7networks · Fri Apr 26, 2019 7:48 am

@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?

Well assuming the power isn't failing. As I mentioned the DC system power is stable because there are 19 other devices which would fail if system power failed. System voltage and routerboard voltage are monitored w/ snmp. They are always between 24.5 and 28. It is of course possible that the power to the router is failing while the system power is stable but that seems pretty unlikely since there are 2 independent feeds from the man power buss and we have tested both independently. What is the probability that the wire or buss connectors would fail in two spots simultaneous and only for a few min, every 6-7 hours? Seems hard to believe.

Regarding the supout file, yes I will send it to MT support but if I read their docs right, they said they want the file which is generated when the device crashes. Probably I'm missing something but the only way I know how to do that is w/ the system watchdog process and so far the watchdog process has not been invoked in all of the crashes.

IvanChisca · Fri Apr 26, 2019 10:09 am

Hi, tonight I gave myself a wonderful time of debugging and reverse engineering

Just because I didn't make backup before software update.
My RB1100AHx2 (powerpc) after update lost all it's IPsec configuration and that was just beginning. It is not a problem to restore a few tens of IPsec policies, but it gives me an error:

could not add IPsec policy: std failure: timeout (13)

Successfully I found a few month old backup and restored my router and then spent two hours adding changes. So what I want to say

1.Do backup your router before update. 2. Mikrotik guys, please check that version for this error. I downgraded to 6.44.2, it seems to be STABLE.

Thank you all and have a nice day.

krisjanisj · Fri Apr 26, 2019 10:17 am

From 6.44.3 changelog:
*) ssh - added "both", "local" and "remote" options for "forwarding-enabled" parameter;

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?

As mentioned in wiki the default value for it is "no". If before upgrade "forwarding-enabled=no", after upgrade it will be "forwarding-enabled=remote", if before upgrade "forwarding-enabled=yes", after upgrade it will be "forwarding-enabled=both".

dvm · Fri Apr 26, 2019 10:48 am

As mentioned in wiki the default value for it now is "remote".

Default values should not be displayed in /export compact, but "remote" value does.

krisjanisj · Fri Apr 26, 2019 10:52 am

Default values should not be displayed in /export compact, but "remote" value does.

There was a mistake in wiki, edited my previous post to clear it. Since default value is "no" - any other value (both, remote, local) should appear in "/export".

TimurA · Fri Apr 26, 2019 4:47 pm

RB4011, if I turn on the RSTP, the switch chip stops working.

krisjanisj · Fri Apr 26, 2019 4:58 pm

RB4011, if I turn on the RSTP, the switch chip stops working.

By switch chip You mean hardware offload?
Hardware offload for switch chip that RB4011 uses (RTL8367), while STP/RSTP is enabled, is not supported. use "protocol-mode=none" on bridge for offloading to work again. See this wiki page for more info.

TimurA · Fri Apr 26, 2019 5:07 pm

RB4011, if I turn on the RSTP, the switch chip stops working.
By switch chip You mean hardware offload?
Hardware offload for switch chip that RB4011 uses (RTL8367), while STP/RSTP is enabled, is not supported. use "protocol-mode=none" on bridge for offloading to work again. See this wiki page for more info.

thanks a lot.

MichalPospichal · Fri Apr 26, 2019 7:15 pm

.... and wlan1 disabling itself.

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

I have been running RB4011 for more than a month and never had this reported issue on wlan. Not even when there was no client connected to it for a few days. So it seems it is not happening on all units.

pcunite · Fri Apr 26, 2019 8:49 pm

I have been running RB4011 for more than a month and never had this reported issue on wlan. Not even when there was no client connected to it for a few days. So it seems it is not happening on all units.

Can you export your config (between code tags) for this thread to see what you might be doing differently?

pavlov · Sat Apr 27, 2019 2:32 am

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.

i have the same problem with hap ac and iphone x in 5ghz

TimurA · Sat Apr 27, 2019 6:03 am

i have the same problem with hap ac and iphone x in 5ghz

Hi pavlov,

channel frequency set auto? set the initial range, starting frequency at 5180

TimurA · Sat Apr 27, 2019 6:11 am

.... and wlan1 disabling itself.

Can you honestly say when solve this problem? or we will not solve it.
I have been running RB4011 for more than a month and never had this reported issue on wlan. Not even when there was no client connected to it for a few days. So it seems it is not happening on all units.

And you start connecting to wlan1 Macbook pro 2016-2018, iPad pro 2018, MSI LeopardPro, and try to work constantly on wlan1, load it with traffic, transfer clients from it to another point and back. He starts losing packets and turns off. If the support keeps silence, after so many sent debugs, there is a reason to think.
PS
Here there is a device RB962(hAp AC) - it works perfectly on it 5G. RB4011 - some problems.

pe1chl · Sat Apr 27, 2019 11:08 am

Those Apple devices are partly guilty, I think. There have been reports before that some Apple devices cause spurious radar detection, and the AP changes to another
channel and listens for a while before it gets on air again. When the same device is still present, the same problem may re-occur. And in case of some software
bug it may even be the cause of the permanent shutdown.

It does not affect only MikroTik! At work we have Ubiquiti accesspoints and sometimes the same thing happens (radar detect on a channel where there definitely is ni radar
but where a couple of Apple devices are nearby).
But those accesspoints do not change to a random other channel, they always change to a channel in the range 36-48 where radar detection is not required, and stay there
for the remainder of the day. During the night they change back to their configured channel and the same thing may happen the next day when the users come in.
(never during night or weekends! confirming that it indeed is a problem caused by the client devices)

Now, to solve this is kind of tricky. The regulating authorities put pressure on the manufacturers to make their radar detection work well, and in the past years there
were many incidents where new firmware from several different manufacturers caused new problems in this area. Not only with MikroTik!

TimurA · Sat Apr 27, 2019 1:08 pm

Those Apple devices are partly guilty, I think. There have been reports before that some Apple devices cause spurious radar detection, and the AP changes to another
channel and listens for a while before it gets on air again. When the same device is still present, the same problem may re-occur. And in case of some software
bug it may even be the cause of the permanent shutdown.

It does not affect only MikroTik! At work we have Ubiquiti accesspoints and sometimes the same thing happens (radar detect on a channel where there definitely is ni radar
but where a couple of Apple devices are nearby).
But those accesspoints do not change to a random other channel, they always change to a channel in the range 36-48 where radar detection is not required, and stay there
for the remainder of the day. During the night they change back to their configured channel and the same thing may happen the next day when the users come in.
(never during night or weekends! confirming that it indeed is a problem caused by the client devices)

Now, to solve this is kind of tricky. The regulating authorities put pressure on the manufacturers to make their radar detection work well, and in the past years there
were many incidents where new firmware from several different manufacturers caused new problems in this area. Not only with MikroTik!

In my case, RB962 with the same firmware version is working, RB4011 is buggy for the crap. RB4011 falls on channels 36-48, in general, the radar is not being. In the same situation, RB962 works. Let's go without these epuses about radar.

MichalPospichal · Sat Apr 27, 2019 9:25 pm

I have been running RB4011 for more than a month and never had this reported issue on wlan. Not even when there was no client connected to it for a few days. So it seems it is not happening on all units.

Can you export your config (between code tags) for this thread to see what you might be doing differently?

Here is the Wireless config I use:

/interface wireless
set [ find default-name=wlan2 ] antenna-gain=3 band=2ghz-onlyn bridge-mode=disabled channel-width=20/40mhz-eC country="czech republic" default-authentication=no disabled=no distance=indoors frequency=2472 frequency-mode=regulatory-domain installation=indoor \
    keepalive-frames=disabled max-station-count=50 mode=ap-bridge multicast-buffering=disabled multicast-helper=disabled name=WLAN-2.4GHz security-profile= ssid=2.4G wireless-protocol=802.11 wmm-support=enabled wps-mode=\
    disabled
set [ find default-name=wlan1 ] antenna-gain=3 band=5ghz-n/ac bridge-mode=disabled channel-width=20/40/80mhz-eeCe country="czech republic" default-authentication=no disabled=no distance=indoors frequency=5220 frequency-mode=regulatory-domain installation=indoor \
    keepalive-frames=disabled max-station-count=50 mode=ap-bridge multicast-buffering=disabled multicast-helper=disabled name=WLAN-5GHz secondary-channel=auto security-profile= ssid=5G wireless-protocol=802.11 wmm-support=enabled \
    wps-mode=disabled
add default-forwarding=no keepalive-frames=disabled mac-address= master-interface=5GHz max-station-count=10 multicast-buffering=disabled multicast-helper=disabled name= security-profile= ssid=\
    Guest wds-cost-range=0 wds-default-cost=0 wmm-support=enabled wps-mode=disabled

Both WLANs are bridged with some ether ports in bridge-LAN.

I do not own Apple devices, but my parents and brother do own iPhones and they come and are connected regularly with no issues. No Macbooks or iPads though.
I was really afraid it would misbehave when I was considering upgrade from RB2011 and saw these reports about WiFi issues, but RB4011 is working flawlessly for me so far.

gyropilot · Sat Apr 27, 2019 11:48 pm

Update not working with 952Ui-5ac2nD; downloads file to memory but doesn't apply after reboot

Willian,

Curious if you've fixed this?

John

TimurA · Sun Apr 28, 2019 7:31 am

I have been running RB4011 for more than a month and never had this reported issue on wlan. Not even when there was no client connected to it for a few days. So it seems it is not happening on all units.

Can you export your config (between code tags) for this thread to see what you might be doing differently?
Here is the Wireless config I use:
Code: Select all
/interface wireless
set [ find default-name=wlan2 ] antenna-gain=3 band=2ghz-onlyn bridge-mode=disabled channel-width=20/40mhz-eC country="czech republic" default-authentication=no disabled=no distance=indoors frequency=2472 frequency-mode=regulatory-domain installation=indoor \
    keepalive-frames=disabled max-station-count=50 mode=ap-bridge multicast-buffering=disabled multicast-helper=disabled name=WLAN-2.4GHz security-profile= ssid=2.4G wireless-protocol=802.11 wmm-support=enabled wps-mode=\
    disabled
set [ find default-name=wlan1 ] antenna-gain=3 band=5ghz-n/ac bridge-mode=disabled channel-width=20/40/80mhz-eeCe country="czech republic" default-authentication=no disabled=no distance=indoors frequency=5220 frequency-mode=regulatory-domain installation=indoor \
    keepalive-frames=disabled max-station-count=50 mode=ap-bridge multicast-buffering=disabled multicast-helper=disabled name=WLAN-5GHz secondary-channel=auto security-profile= ssid=5G wireless-protocol=802.11 wmm-support=enabled \
    wps-mode=disabled
add default-forwarding=no keepalive-frames=disabled mac-address= master-interface=5GHz max-station-count=10 multicast-buffering=disabled multicast-helper=disabled name= security-profile= ssid=\
    Guest wds-cost-range=0 wds-default-cost=0 wmm-support=enabled wps-mode=disabled
Both WLANs are bridged with some ether ports in bridge-LAN.

I do not own Apple devices, but my parents and brother do own iPhones and they come and are connected regularly with no issues. No Macbooks or iPads though.
I was really afraid it would misbehave when I was considering upgrade from RB2011 and saw these reports about WiFi issues, but RB4011 is working flawlessly for me so far.

is ipv6 present on RB4011?

MichalPospichal · Sun Apr 28, 2019 7:37 am

is ipv6 present on RB4011?

Nope. Also, I did not know about the duplicated MAC with SFP mentioned in the other thread, so it is running ok with the same MAC, but SFP is disabled.

TimurA · Sun Apr 28, 2019 7:55 am

is ipv6 present on RB4011?
Nope. Also, I did not know about the duplicated MAC with SFP mentioned in the other thread, so it is running ok with the same MAC, but SFP is disabled.

I will try to cut down ipv6, and conduct tests again.

TimurA · Sun Apr 28, 2019 8:45 am

I disabled the ipv6 interface, checked roaming from RB4011 to RB962 and back (RB4011 channel 48, RB962 channel 36), there are no packet losses, it works.

It turns out the problem on RB4011 with ipv6, as soon as ipad pro 2018, mixes up with RB4011 on RB962 and then back from ipv6, wlan1 on RB4011 drops.

if RB4011 and RB962 are on the same channel 36, then wlan1 on RB4011 with ipv6 interface turned on does not fall.

MichalPospichal · Sun Apr 28, 2019 9:08 am

Interesting find, good work.

TimurA · Sun Apr 28, 2019 8:07 pm

Interesting find, good work.

Today I tested the hAP ac scheme (RB962) and wAP AC with ipv6, everything worked fine. Why so with RB4011 - I do not understand: (

TimurA · Mon Apr 29, 2019 7:37 am

Interesting find, good work.

I did another experiment with ipv6, turned off the access list in wifi and checked the reconnection from RB4011 to RB962 and back. While working stably. Miracles and only.

PS
RB4011 wlan1 fell again after 10 minutes.

russman · Mon Apr 29, 2019 7:33 pm

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:
Code: Select all
/ip ssh set forwarding-enabled=both

While you are there, this seems like a good idea:
Code: Select all
/ip ssh set strong-crypto=yes allow-none-crypto=no

Thanks we were just troubleshooting this issue with 6.44.3, it seems they changed the default behavior in this update but then didn't give you the option to change it back in winbox and no further detail provided in release notes... Not cool!

typicalwisp · Mon Apr 29, 2019 10:04 pm

As mentioned in wiki the default value for it is "no". If before upgrade "forwarding-enabled=no", after upgrade it will be "forwarding-enabled=remote", if before upgrade "forwarding-enabled=yes", after upgrade it will be "forwarding-enabled=both".

The behavior above is what I would expect. It looks like there was a bug in previous versions that allowed SSH forwarding even though "/ip ssh forwarding-enabled=no". I assumed that they went from "forwarding-enabled=yes" to "forwarding-enabled=remote" because I could no longer connect to devices on the other side of the router through SSH forwarding after the update. Thanks for pointing this out.

zoltan1980 · Mon Apr 29, 2019 11:04 pm

[This problem report turned out to be due to a misconfiguration unrelated to the release. Shortening irrelevant long post as I can't delete it.]

sindy · Mon Apr 29, 2019 11:22 pm

The problem may be with connection tracking, but I don't know how to debug that. The Neato worked fine before the upgrade and even after the upgrade all other devices work fine except the Neato. Any advice?

At first place the responses from the DNS should not get to input chain of the firewall if it is really Neato who sends the queries and not your Mikrotik itself. Please create a new topic on that and post there the configuration export as my automated signature suggests. Even though it may actually be a version related issue, it will need some communication for which this topic is not the right one; however, place here a link to the new topic.

zoltan1980 · Tue Apr 30, 2019 12:04 am

Please create a new topic on that and post there the configuration export as my automated signature suggests. Even though it may actually be a version related issue, it will need some communication for which this topic is not the right one; however, place here a link to the new topic.

With your help I already found the problem, thanks a lot!

While following the instructions from your signature and going through the output of

/export hide-sensitive

sanity-checking it for any remanining sensitive information, I found the misconfiguration. You were right, it was not related to the upgrade, just an old misconfiguration coincidentally surfaced at the same time. I plan to delete my unrelevant post (and this update as well) within an hour to keep this thread focused on the release, but didn't want to do it without first stating that the issue was not caused by the release and also taking the opportunity to say thanks.

sysnotdown · Wed May 01, 2019 11:12 am

6.44.x have many bugs! far from stable, it breakdown 5G wifi.

Samot · Wed May 01, 2019 4:34 pm

6.44.x have many bugs! far from stable, it breakdown 5G wifi.

And what bugs are those? Just saying it has "many bugs" isn't insightful or helpful at all. If it has many bugs please list them so the developers and others can be aware of them and try to replicate them in order to prove they are bugs. You've opened two threads about this already and they are just as insightful. You say there are numerous bugs and your 5G doesn't work but you've failed to provide any real substance of information and data.

So what are we exactly looking for and supposed to do about this? What type of configuration did you have? Anything special? Just a flat network?

gpuser · Thu May 02, 2019 8:28 pm

Hello,

anyone experienced issue with cpu temperature after last upgrade?

I upgraded my device (CCR1036-12G-4S) from 6.42.3 to 6.44.3, and after that CPU temperature increase exponentially, I attach a screen

Thanks
Best Regards

pe1chl · Thu May 02, 2019 9:04 pm

I upgraded my device (CCR1036-12G-4S) from 6.42.3 to 6.44.3, and after that CPU temperature increase exponentially, I attach a screen

What does the CPU load show?
Also, your inlet air temperature seems to be 62C, maybe something else has failed?

gpuser · Thu May 02, 2019 9:25 pm

Hi,
I attach CPU Graph, it does not seems changed

I tried to disable all drop firewall rules but problem persists

Any idea what could cause high temperature?

Regards

godzillante · Fri May 03, 2019 10:54 am

Also, your inlet air temperature seems to be 62C, maybe something else has failed?

Hi,

are you 100% sure that it refers to 'inlet' air temp and not some different sensors on the routerboard? Because the room can't be at 62°C (144°F)... unless their office is located in hell

pe1chl · Fri May 03, 2019 12:38 pm

That is why I think they need to do some research. Either the cabinet is cooking or something else has failed (like a failed airconditioner or rack fan).
In my experience, the temperature sensor on a CCR indicates only a little more than inlet air temperature, maybe it is a sensor on the motherboard that is close to the air pulled in.
(the fans blow the hot air outward so the cool air flows in through some vents and over the motherboard)

gpuser · Fri May 03, 2019 6:19 pm

Thank you for your response. We're still investigating about problem to find the root cause.

However room temperature is around 22°C. On the same rack there are others mikrotik devices with a device temp around 30°C and CPU temp 45-50°C, so we have excluded external causes at the moment.

pe1chl · Fri May 03, 2019 6:47 pm

Yes, 30C in a rack in a room at 22C is the normal situation for a CCR.
CPU is always around 50C, I think the fans are regulated towards that target.
(of course it can be higher when fans are at full speed)

ddff · Fri May 03, 2019 8:37 pm

Evening, gents!

Did an upgrade to this version, but now I can't seem to be able to log on it anymore. Not via webfig nor Winbox 3.18.
Don't remember if I left on SSH access, but even if so that doesn't respond as well. Any tips?

pe1chl · Fri May 03, 2019 10:27 pm

You tried connecting to the MAC address?

sindy · Fri May 03, 2019 11:05 pm

Or, if it doesn't work either, maybe you have a serial port on the device or can connect an USB to serial converter to it and use command line to check and fix the configuration?

ddff · Sat May 04, 2019 12:17 am

Yes, I tried both- IP and MAC, neither works. Just gives me a connection timeout, doesn’t get to login screen. Router works fine, VPN as well, just can’t access it, Winbox finds it in neighbour search, but that is basically it. I was thinking to use JTAG cable or at least hard reset, but it is really hard to get to the router as it is in remote location. So I wanted to check what other options I have.

pe1chl · Sat May 04, 2019 11:06 am

When it is at a remote location, of course you need to try the MAC access local at that location. E.g. from a server machine that is connected to the LAN side of the router.
When that is not available, you probably need to go there with a laptop.
Bring the "netinstall" program (downloaded from the website), an uptodate set of packages (those you require for the router), and your recent backup of the configuration (that you make regularly, especially before doing an upgrade).
Then you can do a hard-reset and be back up in reasonable amount of time, when local attempts to access it fail as well.
(of course you try the MAC and serial access locally, or even via the LCD screen if it has one)

Another thing to do when using the routers with more than 16MB flash that are currently sold (e.g. CCR but even RB2011 or old RB750): partition the device!
When you go to the partition menu you can make 2 partitions (it will reboot), then copy part0 to part1 before every upgrade, and when something goes wrong it is possible to make the router switch to part1 by powercycling it during its startup sequence, and it boots your previous version. You can also switch to part1 and reboot remotely, e.g. when a new update does not work well, so you can go back operating to the previous working version. This is especially convenient when your router is on a remote site, it has saved me before when updates were released that corrupted the storage.
(when a new version works OK and/or when major changes have been made to the configuration it is best to always re-do the copy, especially when the site has unreliable power, or else you may suddenly find the router running the old version after some glitch in the power)

alejosalmon · Sat May 04, 2019 8:17 pm

Mikrotik please add support for Sxtsq ac US version equipment .Thanks

banan · Mon May 06, 2019 8:10 pm

Problem with FreePBX and 6.44.3 - don't allow to register on external sip account
version 6.43.14 fix the problem

cdemers · Tue May 07, 2019 3:58 am

I'm using 6.44.3 with freepbx without any issues.

Sent from my SM-A520W using Tapatalk

LeftyTs · Tue May 07, 2019 4:20 am

Problem with FreePBX and 6.44.3 - don't allow to register on external sip account
version 6.43.14 fix the problem

You should check and review your firewall rules

LeftyTs · Tue May 07, 2019 4:26 am

Hello,

anyone experienced issue with cpu temperature after last upgrade?

I upgraded my device (CCR1036-12G-4S) from 6.42.3 to 6.44.3, and after that CPU temperature increase exponentially, I attach a screen
Thanks
Best Regards

Check your fans. I don't have any problems with the upgrades in a few of CCR1036s. Sounds more like a fan failure. Check if both fan RPMs are around 4000 or so.

PS: Just noticed your fans are WAY too high. It seems more like a configuration (ROS?) issue. If you have the luxury to do so, you could reset all to factory defaults and check if everything works ok. If yes then while monitoring slowly just start adding things up.

SJB · Tue May 07, 2019 11:52 pm

Hi there, I’m about to setup load balancing on a routerboard running 6.44.3
Is anyone aware if load balancing works under this OS version. I’ve read there have been some issues on previous versions in the past.
Thank you.

sindy · Wed May 08, 2019 12:43 am

Is anyone aware if load balancing works under this OS version. I’ve read there have been some issues on previous versions in the past.

There is a dedicated topic on that but the OP never came back with the answers to my questions.

LeftyTs · Wed May 08, 2019 1:33 am

Hi there, I’m about to setup load balancing on a routerboard running 6.44.3
Is anyone aware if load balancing works under this OS version. I’ve read there have been some issues on previous versions in the past.
Thank you.

I am using 2 load balanced routers in 2 different locations (PCC load balancing) and none of them had any issues so far. This is a very general question though. There are a few ways to setup load balancing. Which one are you referring to?

https://wiki.mikrotik.com/wiki/Load_Balancing

pe1chl · Wed May 08, 2019 10:54 am

Usually when people refer to "there are load balancing issues in this version", what they really mean is "I had a configuration that was incorrect but worked on version X, but no longer works on version X+1", and then proceed to blame version X+1, rather than their incorrect configuration, for it.
Usually this is because version X+1 had more support for fast path (fasttrack), and therefore it fasttracked their traffic (which version X did not do), and they do not realize that fasttracking breaks those configurations.
Once you remove the fasttrack and fast path, it normally works OK.
(of course you need a router that can handle the load-balanced traffic without using fasttrack, so don't get a hAP mini to use as your corporate load balancer!!)

SJB · Wed May 08, 2019 2:47 pm

Is anyone aware if load balancing works under this OS version. I’ve read there have been some issues on previous versions in the past.
There is a dedicated topic on that but the OP never came back with the answers to my questions.

Given a remote area with no cable connections I need to go through the air.
The idea is to setup 2 x LHG lte dishes together with 1 x Wimax, so actually 3 x Wan.
If it wasn’t for a fixed ip adres I’d drop the Wimax as unreliable on connection.
As I read from all the response, setting up PCC load balance with 3 x static IP should work, providing making sure not to add default routing in the interfaces and disabling fasttracks?

SJB · Wed May 08, 2019 2:52 pm

PCC method with 3 x Wan with static IP’s on a HEX.
It’s not really the amount of users (2-3 ) but to cope with varying unreliable down/up speeds. So basically I’m trying to spread the risk of bring down and/ or having low speeds.

Wed May 08, 2019 2:56 pm

SJB, please start a new thread and keep this one strictly for the 6.44.3 version related discussions.

rzirzi · Thu May 09, 2019 8:09 am

I have NO IPSEC configuration, but at ROS 6.44.3 export file is:
#error exporting /ip ipsec mode-config
#error exporting /ip ipsec peer
#error exporting /ip ipsec policy group
#error exporting /ip ipsec profile
#error exporting /ip ipsec proposal

BUG, BUG, BUG

docmarius · Thu May 09, 2019 9:38 am

Those are only comments in your export and will be ignored...
There are some default template entries in IPsec which the system probably expects NOT to be missing (e.g. the default policy template, default proposal, default group, default profile, default mode-profile), and can not be normally deleted.
So it's more like 'maybe cosmetic bug', not "BUG BUG BUG'.

/ip ipsec mode-config
set [ find default=yes ] name=request-only responder=no
/ip ipsec policy group
set [ find default=yes ] name=default
/ip ipsec profile
set [ find default=yes ] dh-group=modp1024 dpd-interval=2m dpd-maximum-failures=5 enc-algorithm=aes-128,3des hash-algorithm=sha1 lifetime=1d name=default nat-traversal=no proposal-check=\
    obey
/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha1 disabled=no enc-algorithms=aes-256-cbc,aes-192-cbc,aes-128-cbc lifetime=30m name=default pfs-group=modp1024
/ip ipsec policy
set 0 disabled=no dst-address=::/0 group=default proposal=default protocol=all src-address=::/0 template=yes
/ip ipsec settings
set xauth-use-radius=no

pe1chl · Thu May 09, 2019 11:50 am

There are some default template entries in IPsec which the system probably expects NOT to be missing (e.g. the default policy template, default proposal, default group, default profile, default mode-profile), and can not be normally deleted.

Maybe it can be done like this (I did not try):
- remove security package
- maybe reset-configuration (to be sure there is no ipsec configuration)
- add security package again (e.g. after discovering it also does SSH)
Now there is no config for the ipsec defaults and it could be they are not re-created because no default config build is done anymore

I do know that it is an issue with the IPv6 package.
IMHO a package that finds itself newly installed/enabled should run its default-configuration script and tell the admin it did that, similar to the way the router initially builds default config and asks if this is to be accepted or removed.
Without that, e.g. the IPv6 package does not populate the firewall when installed/enabled.
It could be that this bug (indeed a cosmetic bug, not very fatal) results from the same design issue.

LeftyTs · Thu May 09, 2019 12:43 pm

I have NO IPSEC configuration, but at ROS 6.44.3 export file is:
#error exporting /ip ipsec mode-config
#error exporting /ip ipsec peer
#error exporting /ip ipsec policy group
#error exporting /ip ipsec profile
#error exporting /ip ipsec proposal

BUG, BUG, BUG

If I recall it correctly, these "errors" appeared a couple of ROS versions ago if you did an upgrade with the DHCP package disabled. Try enabling the dhcp package if you have it disabled. These "errors" should be gone after that.

Marino · Thu May 09, 2019 8:25 pm

I have NO IPSEC configuration, but at ROS 6.44.3 export file is:
#error exporting /ip ipsec mode-config
#error exporting /ip ipsec peer
#error exporting /ip ipsec policy group
#error exporting /ip ipsec profile
#error exporting /ip ipsec proposal

BUG, BUG, BUG

Same at my configuration: CHR on KVM. First it appears after a reboot on 6.44 firmware. I upgraded to 6.44.2 and restored a backup. All fine until I upgraded to 6.44.3. All IPSec configs and default templates gone again. I couldn't change the IPsec configuration either. I had to downgrade to 6.43.14 and restored an old backup.

pe1chl · Thu May 09, 2019 8:37 pm

Did you restore a backup made on a lower version? Should not do that, because sometimes configuration structure is changed and the conversion is only made during the upgrade.
So the new version will not be able to handle the old configuration.
This is even mentioned in some of the release notes...

Marino · Thu May 09, 2019 9:58 pm

Did you restore a backup made on a lower version? Should not do that, because sometimes configuration structure is changed and the conversion is only made during the upgrade.
So the new version will not be able to handle the old configuration.
This is even mentioned in some of the release notes...

For version 6.44 and 6.44.2 I restored a backup made with that version. For 6.43.14 an older one, made with some 6.43 version.

isoppo · Thu May 09, 2019 11:10 pm

Is there someone else having Radius Timeout issues, like me and this guy: viewtopic.php?t=146485&start=50#p722261 -?

We were running on 6.43.4 across the board.
I upgraded our RouterOS gear due to the IPv6 soft lockup fixes provided on 6.44.2. That's when we started experiencing these Radius Timeout issues.

The only way to get around that is to reboot the router. Disabling/Enabling Radius options doesn't help.

When it happens, the Radius Server's IP address is still reachable, but no packets from the affected router are received on the server side.

I've noticed this only on our busiest routers (CCRs). RB3011 and other models, with less PPPoE clients, didn't behave this way yet.

Sample from a CCR-1036-8G-2S+:

(Link: https://imgur.com/a/zOAWZ4K)

Edit: Even though the issue started on 6.44.2, I'm on 6.44.3 right now, facing exactly the same.

LeftyTs · Fri May 10, 2019 11:17 am

In a couple of CRS326 switches I have the exact same problem for a few months now. Ports that appear to have high rx-overlows in interface ethernet statistics, for some strange reason after a certain time become unresponsive. Before v6.44 if I was disabling and re-enabling the problem port, it would come back to life. Now I have to reboot the whole switch. Ticket id 2018122022004844

Fedes · Fri May 10, 2019 9:58 pm

Hello,

Can I ask why was the sfp-led removed from rb2011 system/leds menu?

*) rb2011 - removed "sfp-led" from "System/LEDs" menu;

I was kinda using this.

Thanks,

buzzlightyear · Sat May 11, 2019 7:50 pm

6.44.3 is not stable in my opinion. Upgraded my RB433 three days ago, and ever since I had MAJOR wifi stability issues, it would just dropout. Reboot would help temporarily, and not always.

I've downgraded to 6.42.12, which is what I had before, and all issues disappeared.

mikeeg02 · Mon May 13, 2019 6:52 pm

I upgraded our system to 6.44.3 a few weeks ago. My "hub" router is a rb1100AHx4 dude edition that runs also the dude. After a few weeks of running, the routeros and http services on every device that utilized them timed out. Ping, and the other dude services worked, as well as the ospf and mpls services that are running. Thats all the router is doing, no firewall filtering, etc as its all private backhaul. I noticed cpu utilization on cpu2 "unclassified" was running maxed out. Tried stopping the dude and a few other tricks, but couldnt get it to stop. Rebooted and usage is back down to almost nothing. Anyone have any idea what the "unclassified" service might have been? Nothing in the log looked out of place.

usage.png

CuninganReset · Thu May 16, 2019 1:39 pm

Hello.

I think Router OS V6.44.X has introduced an issue with the GPS package.
Since I upgraded to 6.44.X (2 or 3) the latitude and longitude values of the GPS are 32 characters long rather than the normal length.

I am using the GPS to send information to a webpage using the GPS example but now it is failing because of the new length, new characters are read as "NULL"

Captura3.PNG

Captura4.PNG

I have tracked the issue and it is related to the size of "latitude" and "longitude" in the RouterOS 6.44
Here with RouterOS 6.44.3 you can see the length is 32.

Captura.PNG

Here with RouterOS 6.43.2 you can see the length is 16.

Captura2.PNG

eworm · Thu May 16, 2019 2:10 pm

Hello.

I think Router OS V6.44.X has introduced an issue with the GPS package.
Since I upgraded to 6.44.X (2 or 3) the latitude and longitude values of the GPS are 32 characters long rather than the normal length.

Already fixed in latest beta version, will be available in stable soon.

Jipp · Mon May 20, 2019 4:38 pm

We are having issues with the R11e-2HPnD wireless module on RBM33G.
R11e-2HPnD is not identified in the 6.44.3 release?
Not showing in interfaces.
If we downgrade everything is honkydory.

Anyone else having issues with wlan modules or is it just this combo ?

anuser · Tue May 21, 2019 10:18 pm

Just rebooted a CCR1036 with v6.44.3. Well the switch it is attached to says that all interfaces plus 1x LACP are up. But I cannot ping the CCR from it, on none of the interfaces.

CuninganReset · Wed May 22, 2019 11:48 pm

Thanks!

Hello.

I think Router OS V6.44.X has introduced an issue with the GPS package.
Since I upgraded to 6.44.X (2 or 3) the latitude and longitude values of the GPS are 32 characters long rather than the normal length.
Already fixed in latest beta version, will be available in stable soon.

anuser · Thu May 23, 2019 12:11 am

Enabling FastPath handler on CCR1036 kills VRF performance (some kbit/s of throughput). After disabling FastPath, I get full routing performance back.

anuser · Tue May 28, 2019 1:42 pm

I´m currently "watching" an Apple client (C8:3C:85:33:B3:10). The phone connects itself automatically to one specific cAP ac. What can I see repeatedly:

- The client connects to wifi successfully
- The DHCP server shows the MAC of the client. Within "DHCP Lease" windows I can see the status which is "offered".
- "Expires After" is couting down from 00:00:31 seconds to 0.
- Inbetween that time frame the client disconnects and reconnects.
- For some few seconds (~5), within the "DHCP Lease" window, it shows "bound"
- After that it changes from "bound" to "DHCP Lease" again.
- The whole process repeats now for over 10 minutes while writing this message.

Looking at the "DHCP Server" => "Leases" window and sort it by "offered status", I currently see the about 8 "...iPhone" with the same behaviour, i.e. they reoccur within the list saying "offered" over and over. Those iPhone don´t use the same access point as the Apple device above, but also some other cAP ac running 6.44.3 code.

Update 1:
- Within "DHCP Lease" windows activated "Make Static" => No change
- Within static DHCP lease windows: I changed step by step: "Lease Time", hit "Usr Src. MAC Address", changed "Insert Queue Before" to bottom => No change
Update 2:
- I downgraded another cAP ac to 6.43.16 which is next to the cAP ac from above and deacitvated both radios on the the cAP ac with version 6.44.3 => the Apple client connected to the cAP ac with 6.43.16, the status within "DHCP lease" is now on bound for over 20 minutes.
- I deactivated both radios one cAP ac mentioned above
Update 3:
The client changed the building. It is now on another cAP ac with 6.44.3. The client obviously works and is producing traffic.

MartijnVdS · Tue May 28, 2019 4:10 pm

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.

Maybe the AP is still in "DFS wait" mode, checking if there's radars on the frequency it/you chose?

pe1chl · Tue May 28, 2019 7:31 pm

I´m currently "watching" an Apple client (C8:3C:85:33:B3:10).

What is your DHCP lease time? I think some versions of Apple firmware do not like very short lease times. Set it to 1 day or higher.

Fedes · Tue May 28, 2019 7:36 pm

Hi,

I know this is not critical, but wanted to know the reason for this change, since it was a good visual aid:

*) rb2011 - removed "sfp-led" from "System/LEDs" menu;

Thanks!

anuser · Tue May 28, 2019 10:46 pm

I´m currently "watching" an Apple client (C8:3C:85:33:B3:10).
What is your DHCP lease time? I think some versions of Apple firmware do not like very short lease times. Set it to 1 day or higher.

DHCP lease time is 8 hours and 10 minutes. Shouldn´t this be enough...? As mentioned before. The problem was gone when I changed RouterOS version to 6.43.16 on the cAP ac only

SolarClint · Wed May 29, 2019 1:12 am

We are trying to upgrade to 6.44.3 from 6.29. I can download the file and it is in the files window. It will not install. I have tried to reboot 5 or 6 times and still nothing. Any advice?

AlainCasault · Wed May 29, 2019 1:22 am

We are trying to upgrade to 6.44.3 from 6.29. I can download the file and it is in the files window. It will not install. I have tried to reboot 5 or 6 times and still nothing. Any advice?

Look at the log. It should tell you why. Usually, you've chosen files for the wrong architecture.

Sent from my cell phone. Sorry for the errors.

pe1chl · Wed May 29, 2019 10:11 am

We are trying to upgrade to 6.44.3 from 6.29. I can download the file and it is in the files window. It will not install. I have tried to reboot 5 or 6 times and still nothing. Any advice?

That is not advisable! You have not updated for so many years that it cannot be expected to be a smooth process.
It is better to investigate what is configured, make a /export so you have complete notes, and then netinstall the new version and start from scratch.

Kindis · Wed May 29, 2019 1:40 pm

We are trying to upgrade to 6.44.3 from 6.29. I can download the file and it is in the files window. It will not install. I have tried to reboot 5 or 6 times and still nothing. Any advice?
That is not advisable! You have not updated for so many years that it cannot be expected to be a smooth process.
It is better to investigate what is configured, make a /export so you have complete notes, and then netinstall the new version and start from scratch.

I would say the same but if they want to try it out (make propper backup and export before attempting) test the following upgrade patch

6.30.1
6.34.5
6.40.9
6.42.9
6.43.16

I'm not saying this will work without issues but will give you a better odds at making it

mlenhart · Wed May 29, 2019 9:58 pm

BUG REPORT

Hello,

I would like to report a wrong Last Link Down Time showed in Winbox.
This issue has been seen on WW Dish, and hAP AC.
Time is in future, which is impossible.
Please see attached screenshot: https://paste.pics/5OJ84

Thulgar · Thu May 30, 2019 8:54 am

BUG REPORT

Hello,

I would like to report a wrong Last Link Down Time showed in Winbox.
This issue has been seen on WW Dish, and hAP AC.
Time is in future, which is impossible.
Please see attached screenshot: https://paste.pics/5OJ84

You didn't show the time in winbox (next to the Uptime). Your MK probably has wrong time settings.

mlenhart · Fri May 31, 2019 9:10 am

BUG REPORT

Hello,

I would like to report a wrong Last Link Down Time showed in Winbox.
This issue has been seen on WW Dish, and hAP AC.
Time is in future, which is impossible.
Please see attached screenshot: https://paste.pics/5OJ84
You didn't show the time in winbox (next to the Uptime). Your MK probably has wrong time settings.

Will this convince you it´s a bug ?

2nd hAP ac - 6_44_3.JPG

pe1chl · Fri May 31, 2019 11:13 am

That wrong time is a "known problem" that was introduced several versions ago, not with this version.
It likely is already on the list of things to fix.

Cha0s · Fri May 31, 2019 12:45 pm

That wrong time is a "known problem" that was introduced several versions ago, not with this version.
It likely is already on the list of things to fix.

Also I believe it's a winbox bug and not a ROS bug. CLI shows the correct times.
IIRC deleting the session on winbox also shows the correct times (until the next login using a previous session).

amojak · Fri May 31, 2019 2:38 pm

hi,

no mention of a recent routing bug we have experienced. Simple static routes stop working, to restore them you disable/re-enable them. Had this happen twice on two routers with 6.44.1 on them.

One occurred after a power cycle, the other for no apparent reason at all.

Has the dev team come across this at all ?

Thanks

pe1chl · Fri May 31, 2019 7:18 pm

no mention of a recent routing bug we have experienced. Simple static routes stop working, to restore them you disable/re-enable them. Had this happen twice on two routers with 6.44.1 on them.

Never seen that, likely there are more circumstances particular to your installation.
You should provide a supout.rif to support in such cases.

o4korez · Sat Jun 01, 2019 11:21 pm

Hi,

I know this is not critical, but wanted to know the reason for this change, since it was a good visual aid:

*) rb2011 - removed "sfp-led" from "System/LEDs" menu;

Thanks!

+, removed a very useful feature. wonder why

Beone · Sun Jun 02, 2019 12:27 am

Hi,

we are awaiting solution/response from helpdesk team already since march 2019.

[Ticket#2019030922002071] CAP not correctly forwarding tagged vlan traffic towards wired network

Quite often, the CAPs arent forwarding DHCP offers anymore towards the clients, resulting in loss of network connectivity.
Just a reprovision resolves this for awhile until it happens again...

We see this in 6.42.x, 6.43.x and even 6.43.x

We have sent multiple debug traces to support without any feedback except with "upgrade to 6.44.3" and as we can confirm, also that release is broken.

I'm pretty sure it has todo with new bridging implementation as 6.39.3 doesn't have this issue. (however most recent delivered devices cannot be downgraded to that release anymore).

Can you please look at this case which impacts/involves more then 5000 access-points

anuser · Wed Jun 05, 2019 9:37 pm

[Ticket#2019030922002071] CAP not correctly forwarding tagged vlan traffic towards wired network

Interesting, let´s quote myself:

I´m currently "watching" an Apple client (C8:3C:85:33:B3:10). The phone connects itself automatically to one specific cAP ac. What can I see repeatedly:

- The client connects to wifi successfully
- The DHCP server shows the MAC of the client. Within "DHCP Lease" windows I can see the status which is "offered".
- "Expires After" is couting down from 00:00:31 seconds to 0.
- Inbetween that time frame the client disconnects and reconnects.
- For some few seconds (~5), within the "DHCP Lease" window, it shows "bound"
- After that it changes from "bound" to "DHCP Lease" again.
- The whole process repeats now for over 10 minutes while writing this message.

Looking at the "DHCP Server" => "Leases" window and sort it by "offered status", I currently see the about 8 "...iPhone" with the same behaviour, i.e. they reoccur within the list saying "offered" over and over. Those iPhone don´t use the same access point as the Apple device above, but also some other cAP ac running 6.44.3 code.

Update 1:
- Within "DHCP Lease" windows activated "Make Static" => No change
- Within static DHCP lease windows: I changed step by step: "Lease Time", hit "Usr Src. MAC Address", changed "Insert Queue Before" to bottom => No change
Update 2:
- I downgraded another cAP ac to 6.43.16 which is next to the cAP ac from above and deacitvated both radios on the the cAP ac with version 6.44.3 => the Apple client connected to the cAP ac with 6.43.16, the status within "DHCP lease" is now on bound for over 20 minutes.
- I deactivated both radios one cAP ac mentioned above
Update 3:
The client changed the building. It is now on another cAP ac with 6.44.3. The client obviously works and is producing traffic.

=> I have 2 CCR1036 running with CAPSMAN forwarding mode. I have >200 cAP ac / wAP ac / ... on each CCR. I don´t know how many times I changed settings for VLAN, bridges, MTUs. I have one CCR + cAP running 6.43.16 completely, the other CCR + cAP are running 6.44.3. The "solution" I mentioned above wasn´t one. Still the same problem. I´m looking for a solution, too.

redbullsteve · Wed Jun 05, 2019 11:20 pm

[Ticket#2019030922002071] CAP not correctly forwarding tagged vlan traffic towards wired network
Interesting, let´s quote myself:
I´m currently "watching" an Apple client (C8:3C:85:33:B3:10). The phone connects itself automatically to one specific cAP ac. What can I see repeatedly:

- The client connects to wifi successfully
- The DHCP server shows the MAC of the client. Within "DHCP Lease" windows I can see the status which is "offered".
- "Expires After" is couting down from 00:00:31 seconds to 0.
- Inbetween that time frame the client disconnects and reconnects.
- For some few seconds (~5), within the "DHCP Lease" window, it shows "bound"
- After that it changes from "bound" to "DHCP Lease" again.
- The whole process repeats now for over 10 minutes while writing this message.

Looking at the "DHCP Server" => "Leases" window and sort it by "offered status", I currently see the about 8 "...iPhone" with the same behaviour, i.e. they reoccur within the list saying "offered" over and over. Those iPhone don´t use the same access point as the Apple device above, but also some other cAP ac running 6.44.3 code.

Update 1:
- Within "DHCP Lease" windows activated "Make Static" => No change
- Within static DHCP lease windows: I changed step by step: "Lease Time", hit "Usr Src. MAC Address", changed "Insert Queue Before" to bottom => No change
Update 2:
- I downgraded another cAP ac to 6.43.16 which is next to the cAP ac from above and deacitvated both radios on the the cAP ac with version 6.44.3 => the Apple client connected to the cAP ac with 6.43.16, the status within "DHCP lease" is now on bound for over 20 minutes.
- I deactivated both radios one cAP ac mentioned above
Update 3:
The client changed the building. It is now on another cAP ac with 6.44.3. The client obviously works and is producing traffic.
=> I have 2 CCR1036 running with CAPSMAN forwarding mode. I have >200 cAP ac / wAP ac / ... on each CCR. I don´t know how many times I changed settings for VLAN, bridges, MTUs. I have one CCR + cAP running 6.43.16 completely, the other CCR + cAP are running 6.44.3. The "solution" I mentioned above wasn´t one. Still the same problem. I´m looking for a solution, too.

Glad it is not just me, I have the same issue effecting 1000's of units, if you disable the CAP and enable everything works again for a period of time and stops again.

I have raised tickets with support to get Zero reply so a reply saying upgrade is further than I have got. I hope this gets resolved soon as its been going on for months.

Beone · Fri Jun 07, 2019 3:01 am

[Ticket#2019030922002071] CAP not correctly forwarding tagged vlan traffic towards wired network
Glad it is not just me, I have the same issue effecting 1000's of units, if you disable the CAP and enable everything works again for a period of time and stops again.

I have raised tickets with support to get Zero reply so a reply saying upgrade is further than I have got. I hope this gets resolved soon as its been going on for months.

Zero reply from support except upgrade to XXX (having same issues), provided them full packet capture and supouts when its happening showing the DHCP offer gets up to the LAN uplink on the CAP but isnt forwarded to the wireless client.

anuser · Fri Jun 07, 2019 9:30 pm

Glad it is not just me, I have the same issue effecting 1000's of units, if you disable the CAP and enable everything works again for a period of time and stops again.
I have raised tickets with support to get Zero reply so a reply saying upgrade is further than I have got. I hope this gets resolved soon as its been going on for months.

How many times a day do you provision your cAP devices?

whatever · Tue Jun 11, 2019 7:20 pm

[Ticket#2019030922002071] CAP not correctly forwarding tagged vlan traffic towards wired network
Glad it is not just me, I have the same issue effecting 1000's of units, if you disable the CAP and enable everything works again for a period of time and stops again.

I have raised tickets with support to get Zero reply so a reply saying upgrade is further than I have got. I hope this gets resolved soon as its been going on for months.

Zero reply from support except upgrade to XXX (having same issues), provided them full packet capture and supouts when its happening showing the DHCP offer gets up to the LAN uplink on the CAP but isnt forwarded to the wireless client.

Did you try setting multicast helper to full? This fixed some LAN to WiFi problems I was experiencing..

anuser · Fri Jun 14, 2019 9:35 am

Did you try setting multicast helper to full? This fixed some LAN to WiFi problems I was experiencing..

I have multicast helper activated since I needed IPv6 for CAPSMAN forwarding. This doesn´t fix the problem with "dhcp offering lease...for...without success"

djerodrigues · Sat Jun 15, 2019 11:35 pm

HI all!

I have some PWR-LINE AP units, and upgraded to v6.44.3.

Issues:
- There is no PWR-LINE interface in the terminal / command line !!!
Can't configure or check configuration/status (done with WinBox)

- When setting "PLC CCO Selection Mode", it will always show as "auto".

- When setting "Network Key" or "Network Password", it will always show as empty.

- Can't downgrade at Winbox with "Downgrade" button. At command line it works fine.

Tks...

oldcrow · Sun Jun 16, 2019 6:03 am

Hi all

upgraded to hAP ac2 to 6.44.3(stabe) and it does not remember which ethernet is attached to WAN/LAN on restarts, Defaults back to ether1 (POE in port so not available for internet modem). Addresses and routes similarly default to ether1 on reboot.

cheers
chris

oldcrow · Mon Jun 17, 2019 8:46 am

Hi all

mea culpa as per usual. turns out seeing 0.0.0.0/0 and changing it to fixed ip in QuickSet not a great idea. It is what changed ether1 back to being WAN port. My apologies for not picking up my error.

regards
Oldcrow

pe1chl · Mon Jun 17, 2019 11:51 am

Ah, the usual problem with QuickSet...
It has been requested many times to have some feature to make QuickSet readonly (either manually or even automatically after changes outside QuickSet have been made) but it is not picked up by MikroTik.
Now, QuickSet remains a ticking timebomb in routers with non-default configuration...

bbs2web · Sat Jun 22, 2019 10:41 am

We have identified an issue with IP neighbour discovery packets, specifically Cisco Discovery Packets (CDP), being transmitted when ports are members of a bridge and spanning tree has detected the port as an alternate path towards the root bridge. Whilst STP correctly disables forwarding it still transmits CDP messages which are then bridged by the remote routers. We presume this to be due to CDP using the same destination multicast MAC address that Spanning Tree Protocol (STP) messages use, namely 01:00:0C:CC:CC:CC.

Network structure:

3 sites with VPLS tunnels bridged between them, classic A B C triangle.
Router A has lower STP bridge priority (0x7000), so it becomes the root bridge
RSTP correctly sets one of the redundant VPLS bridge ports as alternate and disables learning and forwarding

Problem:
Bridge correctly drops all traffic on the alterative path port, except packets destined to the multicast address 01:00:0C:CC:CC:CC, used by STP and CDP.
I presume this to be so that the bridge can still process STP messages and unblock the port when necessary. The problem comes in that CDP neighbour discovery packets are still transmitted out the port which is in a non-forwarding state. This causes intermittent connectivity problems as remote bridges temporarily learn the path to the source MAC from the path/port which is in a non-forwarding mode.

Sample log message, showing MAC of blocked interface being received back on working port:

jun/20 23:57:16 interface,warning vpls-vlan2000-A: bridge port received packet with own address as source address (02:0f:f1:63:85:ea), probably loop

Expected behaviour:
Do not transmit CDP neighbour discovery packets out of a port when disabled by spanning tree protocol.

Configuration shows two VPLS interfaces, from ‘B’ to ‘A’ and ‘C’:

/interface vpls
  add disabled=no mac-address=02:0F:F9:48:BD:CA name=vpls-vlan2000-A remote-peer=192.168.255.1 vpls-id=1:22000
  add disabled=no mac-address=02:0F:F1:63:85:EA name=vpls-vlan2000-C remote-peer=192.168.255.3 vpls-id=3:22000

Router B’s bridge configuration, running RSTP:

/interface bridge
  add name=bridge-vlan2000
/interface bridge port
  add bridge=bridge-vlan2000 interface=vpls-vlan2000-A
  add bridge=bridge-vlan2000 interface=vpls-vlan2000-C

Spanning Tree correctly sets the ‘vpls-vlan2000-C’ interface's role as alternative-port, thereby disabling learning and forwarding:

[davidh@B] > /int bridge port print stats where bridge=bridge-vlan2000
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload
 0     interface=vpls-vlan2000-A bridge=bridge-vlan2000 priority=0x80 path-cost=10 internal-path-cost=10
       edge=auto point-to-point=auto learn=auto horizon=none auto-isolate=no restricted-role=no
       restricted-tcn=no pvid=1 frame-types=admit-all ingress-filtering=no unknown-unicast-flood=yes
       unknown-multicast-flood=yes broadcast-flood=yes tag-stacking=no bpdu-guard=no trusted=no
       multicast-router=temporary-query fast-leave=no status=in-bridge port-number=1 role=root-port
       edge-port=no edge-port-discovery=yes point-to-point-port=no external-fdb-status=no
       sending-rstp=yes learning=yes forwarding=yes root-path-cost=10 
       designated-bridge=0x7000.02:3A:EF:BC:95:B8 designated-cost=0 designated-port-number=2 

 1     interface=vpls-vlan2000-C bridge=bridge-vlan2000 priority=0x80 path-cost=10 internal-path-cost=10 
       edge=auto point-to-point=auto learn=auto horizon=none auto-isolate=no restricted-role=no 
       restricted-tcn=no pvid=1 frame-types=admit-all ingress-filtering=no unknown-unicast-flood=yes 
       unknown-multicast-flood=yes broadcast-flood=yes tag-stacking=no bpdu-guard=no trusted=no 
       multicast-router=temporary-query fast-leave=no status=in-bridge port-number=2 role=alternate-port 
       edge-port=no edge-port-discovery=yes point-to-point-port=no external-fdb-status=no 
       sending-rstp=yes learning=no forwarding=no root-path-cost=20 
       designated-bridge=0x8000.02:57:0E:3C:25:0E designated-cost=10 designated-port-number=2

6.44 made changes to transmit bond and bridge slave port information out via MNDP, CDP and LLDP, this is when the behaviour started. This also changes the previous behaviour in that these neighbour discovery packets are transmitted not just from the bridge itself, but additionally all slave ports. Herewith an example, showing the remote interface as being bridge-vlan2000/vpls-vlan2000-C:

[davidh@B] > /ip neighbor print detail 
 0 interface=vpls-vlan2000-A,bridge-vlan2000 mac-address=02:0F:F1:63:85:EA 
   identity="B" platform="MikroTik" version="6.44.3 (stable)" unpack=none age=9s
   interface-name="bridge-vlan2000/vpls-vlan2000-C" system-caps="" system-caps-enabled=""

Temporary work around:

Create an interface list called 'vpls' and add all VPLS interfaces to this list
Set IP neighbour discovery to use all interfaces except those in the 'vpls' interface list

emils · Mon Jul 01, 2019 10:14 am

New version 6.45.1 has been released in stable RouterOS channel:

viewtopic.php?f=21&t=149786

Who is online