v6.44.5 [long-term] is released!

emils · Tue Jul 09, 2019 12:09 pm

RouterOS version 6.44.5 has been released in public "long-term" 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.5 (2019-Jul-04 10:32):

MAJOR CHANGES IN v6.44.5:
----------------------
!) security - fixed vulnerabilities CVE-2018-1157, CVE-2018-1158;
!) security - fixed vulnerabilities CVE-2019-11477, CVE-2019-11478, CVE-2019-11479;
!) security - fixed vulnerability CVE-2019-13074;
----------------------

Changes in this release:

*) bridge - correctly handle bridge host table;
*) capsman - fixed CAP system upgrading process for MMIPS;
*) capsman - fixed interface-list usage in access list;
*) certificate - removed "set-ca-passphrase" parameter;
*) cloud - properly stop "time-zone-autodetect" after disable;
*) conntrack - fixed GRE protocol packet connection-state matching (CVE-2014-8160);
*) defconf - automatically set "installation" parameter for outdoor devices;
*) dhcpv6-client - fixed status update when leaving "bound" state;
*) dhcpv6-server - fixed dynamic IPv6 binding without proper reference to the server;
*) dhcpv6-server - override prefix pool and/or DNS server settings by values received from RADIUS;
*) discovery - fixed CDP packets not including address on slave ports (introduced in v6.44);
*) e-mail - properly release e-mail sending session if the server's domain name can not be resolved;
*) firewall - fixed fragmented packet processing when only RAW firewall is configured;
*) firewall - process packets by firewall when accepted by RAW with disabled connection tracking;
*) gps - strip unnecessary trailing characters from "longtitude" and "latitude" values;
*) hotspot - moved "title" HTML tag after "meta" tags;
*) ipv6 - improved system stability when receiving bogus packets;
*) ovpn - added "verify-server-certificate" parameter for OVPN client (CVE-2018-10066);
*) rb3011 - improved system stability when receiving bogus packets;
*) rb921 - improved system stability ("/system routerboard upgrade" required);
*) snmp - improved reliability on SNMP service packet validation;
*) ssh - fixed non-interactive multiple command execution;
*) supout - added IPv6 ND section to supout file;
*) supout - added "pwr-line" section to supout file;
*) supout - changed IPv6 pool section to output detailed print;
*) winbox - do not allow setting "dns-lookup-interval" to "0";
*) wireless - improved DFS radar detection when using non-ETSI regulated country;
*) wireless - improved installation mode selection for wireless outdoor equipment;
*) wireless - updated "china" regulatory domain information;
*) www - improved client-initiated renegotiation within the SSL and TLS protocols (CVE-2011-1473);

For a full changelog please visit https://mikrotik.com/download/changelogs

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 specific RouterOS release.

deem · Tue Jul 09, 2019 1:23 pm

There is critical issue for me, firewall input chain with drop action on invalid connection state now drops incoming EoIP packets with no reason.

Chupaka · Tue Jul 09, 2019 1:35 pm

Isn't EoIP using GRE?

*) conntrack - fixed GRE protocol packet connection-state matching (CVE-2014-8160);

So make sure you're allowing GRE before dropping invalid connections.

DenisPDA · Tue Jul 09, 2019 1:39 pm

after upgrading from 6.43.16 to 6.44.5 ipsec dropped
/ ip ipsec identity
add peer = peer1 became one for all connections

deem · Tue Jul 09, 2019 1:46 pm

Isn't EoIP using GRE?

*) conntrack - fixed GRE protocol packet connection-state matching (CVE-2014-8160);
So make sure you're allowing GRE before dropping invalid connections.

You are right, the problem is in GRE state matching, but why EoIP tunnels is in invalid connection state now?

DenisPDA · Tue Jul 09, 2019 1:58 pm

upgrading from 6.43.16 to 6.44.5
lost users /ip ipsec user
Where to looking for ?

karlisi · Tue Jul 09, 2019 2:13 pm

Mikrotik, please, write changelogs properly! Since separating stable and long-term channels they ar incomplete, at least for long-term. Every changelog must contain all changes and fixes from previous same channel release, not from previous release by number. It will eliminate such problems, as in one of previous comments about lost /ipsec users. Yes, this change (ipsec - removed "users" menu, XAuth user configuration is now handled by "identity" menu) is mentioned in changelog, in version 6.44 stable changelog. But nothing about it in 6.44.5 long-term changelog! Yes, I am angry, months are gone and nothing changes.

Tue Jul 09, 2019 3:47 pm

karlisi, it is hard to judge about proper and improper ways for changelogs syntax. However, we will try to improve it for the next versions, thank you for the report.

DenisPDA · Tue Jul 09, 2019 3:54 pm

karlisi, it is hard to judge about proper and improper ways for changelogs syntax. However, we will try to improve it for the next versions, thank you for the report.

It is enough to lay out the full list of changes v6.44.5 relative to 6.43.16 long-term

bajodel · Tue Jul 09, 2019 4:52 pm

The [netinstall-6.44.5.zip] seems corrupted, please confirm ..thanks

DenisPDA · Tue Jul 09, 2019 5:07 pm

The [netinstall-6.44.5.zip] seems corrupted, please confirm ..thanks

Try using Mozilla Firefox to download a netinstall 6.44.5

https://download.mikrotik.com/routeros/6.44.5/netinstall-6.44.5.zip

osc86 · Tue Jul 09, 2019 8:20 pm

File from 159.148.147.204 is corrupted.
https://159.148.172.226/routeros/6.44.5 ... 6.44.5.zip seems ok.

DenisPDA · Tue Jul 09, 2019 9:30 pm

File from 159.148.147.204 is corrupted.
https://159.148.172.226/routeros/6.44.5 ... 6.44.5.zip seems ok.

confirm

Net_6445.JPG

Chupaka · Tue Jul 09, 2019 9:41 pm

File from 159.148.147.204 is corrupted.
https://159.148.172.226/routeros/6.44.5 ... 6.44.5.zip seems ok.
confirm

Your image is corrupted

attl · Tue Jul 09, 2019 9:51 pm

Dude client 6.44.5 file size 0kb
https://download.mikrotik.com/routeros/ ... 6.44.5.exe

DenisPDA · Tue Jul 09, 2019 10:00 pm

Your image is corrupted

corrected

mkx · Tue Jul 09, 2019 11:31 pm

Your image is corrupted
corrected

Now it's encrypted in cyrillic

HzMeister · Wed Jul 10, 2019 12:59 am

Upgraded from 6.44.3 on rb750gr3 without issue. Everything works great.

105547111 · Wed Jul 10, 2019 1:10 am

More download issues to add to above : Dude and x86 server packages are also 0 bytes.

No issues 6.43.16 LT to 6.44.5 LT on: CCR1016, CRS125, CHR, wAP60G, RB951G, SXT5AC

StevenGT · Wed Jul 10, 2019 8:19 am

It is enough to lay out the full list of changes v6.44.5 relative to 6.43.16 long-term

Exactly!

skylark · Wed Jul 10, 2019 9:02 am

Isn't EoIP using GRE?

*) conntrack - fixed GRE protocol packet connection-state matching (CVE-2014-8160);
So make sure you're allowing GRE before dropping invalid connections.
You are right, the problem is in GRE state matching, but why EoIP tunnels is in invalid connection state now?

EoIP is based on GRE RFC 1701

More download issues to add to above : Dude and x86 server packages are also 0 bytes.

How did you download these packages: manually, fetch or another method? Can you reproduce it or it happened once?

Wed Jul 10, 2019 9:45 am

How do you guys propose we make such a changelog? This is the long term branch, where releases are very rare, and the jumps are very big.
Imagine there could be 15 fixes, new bugs, fixes again, then the feature could be already removed, then a new one added, removed again, and then a new feature made and fixed.

Listing fixes for non existing feature would be useless.

DenisPDA · Wed Jul 10, 2019 10:18 am

How do you guys propose we make such a changelog? This is the long term branch, where releases are very rare, and the jumps are very big.
Imagine there could be 15 fixes, new bugs, fixes again, then the feature could be already removed, then a new one added, removed again, and then a new feature made and fixed.

Listing fixes for non existing feature would be useless.

People fly into space.
And You can't make the rules list of changes

Wed Jul 10, 2019 11:02 am

I don't fly into space, though

DenisPDA · Wed Jul 10, 2019 11:04 am

I don't fly into space, though

You are not posting the full list of changes.

TimurA · Wed Jul 10, 2019 11:13 am

I don't fly into space, though
You are not posting the full list of changes.

there is a feeling that the gentlemen are changing wheels on the go. In the future, this method may tear off your hands.
Sorry for not exact expression in English. and Sorry for my French.

karlisi · Wed Jul 10, 2019 11:29 am

How do you guys propose we make such a changelog? This is the long term branch, where releases are very rare, and the jumps are very big.
Imagine there could be 15 fixes, new bugs, fixes again, then the feature could be already removed, then a new one added, removed again, and then a new feature made and fixed.

Listing fixes for non existing feature would be useless.

Are you serious? OK, I'll explain. List only changes from last long-term release. List fixes to features which exist in latest long-term release. Skip fetaures and fixes added and then removed in between. And, yes, it takes some time. You know, there's a big secret - on every long-term release we, your customers, are reading all changelogs in all branches, consolidate them, in fact, we are doing your job.

Wed Jul 10, 2019 11:32 am

Kārli, your points make me think you did not read my post at all. You just said you want ALL changes, now you say you don't want all changes. Long term releases don't come after each other, they are "elected" to be long term, from the "Stable" branch.

sch · Wed Jul 10, 2019 11:46 am

What's the point if you do not read it anyway?

Splash · Wed Jul 10, 2019 1:18 pm

Isn't EoIP using GRE?

*) conntrack - fixed GRE protocol packet connection-state matching (CVE-2014-8160);
So make sure you're allowing GRE before dropping invalid connections.
You are right, the problem is in GRE state matching, but why EoIP tunnels is in invalid connection state now?
EoIP is based on GRE RFC 1701

Yup, we have had the same problem spread across our network affecting EoIP PPTP tunnels. As above we have disabled the drop input invalid rule as a work around.

Jotne · Wed Jul 10, 2019 1:28 pm

Most important, you should say from what change it is from.
I would say, only list changes from 6.44.4 to 6.44.5
If you like to see other change, you look for change log for 6.44.4 or 6.44.3 etc

This is how Cisco does it.

Cisco also has a tool that can compere version and see what function are different form x and y release of the software.

eworm · Wed Jul 10, 2019 2:06 pm

Let's cool down on the changelog topic.
IMHO this is just another matter of communication. Just add a note to the changelog: A new stable release moved to long-term. For full changelog see changes up to version 6.44.3.
At least this is a first step and clarifies what changes can be expected in changelog.

aidan · Wed Jul 10, 2019 3:05 pm

Let's cool down on the changelog topic.
IMHO this is just another matter of communication. Just add a note to the changelog: A new stable release moved to long-term. For full changelog see changes up to version 6.44.3.
At least this is a first step and clarifies what changes can be expected in changelog.

I agree. It is not difficult for users to review the change log for stable 6.44-6.44.4 and long-term 6.44.5.

https://mikrotik.com/download/changelog ... lease-tree
https://mikrotik.com/download/changelog ... lease-tree

karlisi · Wed Jul 10, 2019 3:22 pm

Every changelog must contain all changes and fixes from previous same channel release, not from previous release by number.

It's about this sentence? For long-term channel there are no other intermediate releases, only long-term. Similarly as for stable channel there is no beta releases. Changelogs should be written accordingly. IMHO.
But I see other users don't care about it, so topic closed.

Chupaka · Wed Jul 10, 2019 4:11 pm

Imagine there could be 15 fixes, new bugs, fixes again, then the feature could be already removed, then a new one added, removed again, and then a new feature made and fixed.

Listing fixes for non existing feature would be useless.

Well, that info can be useful also: you know what parts of OS were officially touched, so you can pay more attention into testing them

Just my 2c.

petern · Wed Jul 10, 2019 6:07 pm

I noticed that after upgrade from 6.43.16 to 6.44.5, allow-none-crypto=yes was set in /ip ssh. This seems to be a new setting and is documented as defaulting to no.

eworm · Wed Jul 10, 2019 6:11 pm

I noticed that after upgrade from 6.43.16 to 6.44.5, allow-none-crypto=yes was set in /ip ssh. This seems to be a new setting and is documented as defaulting to no.

You have set strong-crypto=yes? I think it depends on that setting.

kriszos · Wed Jul 10, 2019 6:31 pm

Can I migrate my router from 6.44 Stable to Long term without worrying about configuration?

eworm · Wed Jul 10, 2019 6:44 pm

Can I migrate my router from 6.44 Stable to Long term without worrying about configuration?

Yes, it's just a small bugfix release then.

petern · Wed Jul 10, 2019 6:57 pm

I noticed that after upgrade from 6.43.16 to 6.44.5, allow-none-crypto=yes was set in /ip ssh. This seems to be a new setting and is documented as defaulting to no.
You have set strong-crypto=yes? I think it depends on that setting.

Yes strong-crypto=yes was already set.

anuser · Wed Jul 10, 2019 10:46 pm

An user send my a report about his wifi connection problems connecting to a cAP ac with 5 GHz and channel 120 configured:

- client: Apple MacBook Pro 11,3 (Retina, 15-inch, Late 2013).
- macOS X 10.13.6
- CAPSMAN based forwarding
- cAP ac v6.44.5 + channel 120

The Macbook sees the channel, but hangs while connecting to it:
'campus' <651231212 6f2321d>, bssid=b8:69:f4:01:a1:5a, channel=[120, width=20], cc=(null),
type=11ac, rssi=-60, rsn=[mcast=aes_ccm, ucast={ aes_ccm }, auths={ 8021x }, caps=0x0],
wpa=(null), wep=no, ibss=no, ph=no, swap=no, hs20=no, airport=no,

The Macbook does connect to any other tested cAP ac running with the same CAPsMAN configuration except the channel. So all other tested channels works, except channel 120.
Other clients can happily connect to the same cAP ac at the same time.

Any ideas?

roe1974 · Thu Jul 11, 2019 11:26 am

Can I migrate my router from 6.44 Stable to Long term without worrying about configuration?
Yes, it's just a small bugfix release then.

So i also can go from 6.44.3 (stable) to 6.44.5 (LT) without any major changes/problems ?

Richard

petern · Thu Jul 11, 2019 12:32 pm

So i also can go from 6.44.3 (stable) to 6.44.5 (LT) without any major changes/problems ?

You can review the changes for 6.44.4 and 6.44.5 to determine if any of them will affect you?

deem · Thu Jul 11, 2019 2:58 pm

Isn't EoIP using GRE?

*) conntrack - fixed GRE protocol packet connection-state matching (CVE-2014-8160);
So make sure you're allowing GRE before dropping invalid connections.
You are right, the problem is in GRE state matching, but why EoIP tunnels is in invalid connection state now?
EoIP is based on GRE RFC 1701

Yes, i know, but RouterOS knows my EoIP settings and for him these appropriate GRE packets MUST NOT be in invalid state. Please fix that.

Anumrak · Thu Jul 11, 2019 4:09 pm

Installed with a first attempt on hAP lite without any problem unlike 6.45.1.

roe1974 · Thu Jul 11, 2019 6:56 pm

perhaps this could affect me:

*) ovpn - added "verify-server-certificate" parameter for OVPN client (CVE-2018-10066);

i use certicates created on RB4011
i have an ovpn connection from a ltAP to the RB4011
so if i upgrade the ltAP ... this parameter is default on or off ?
richard

Darryl · Fri Jul 12, 2019 4:20 pm

Hello !

I left a bunch of RB's on 6.40.9 but the latest CVE's no longer make that suitable for internet traffic. Is there any concerns making the jump to 6.44.5 ? Other then changes to bridge and password storage method. My hope is to just press the Download&Install button remotely so I don't have to do it in person from device lock-ups and bricking.

Fri Jul 12, 2019 5:12 pm

Was it "Upgrading on the edge" by Aerosmith?

Jump from 6.40 directly to 6.45 .... you are brave man. Have you read changelogs in the 6.41?

Darryl · Fri Jul 12, 2019 6:05 pm

I've read it. I see what I use shouldn't be affected. But its quite a jump, considering the changes to switch and bridge. Just wondering if anyone else made such a jump. In the past I've gone from 4.x to 6.x and that wasn't an issue. But so much has changed. I don't need any new features, but I can't have the devices vulnerable to hacking.

Was it "Upgrading on the edge" by Aerosmith?

Jump from 6.40 directly to 6.45 .... you are brave man. Have you read changelogs in the 6.41?

sanitycheck · Sat Jul 13, 2019 8:39 am

I connect to manage routers with ssh using an rsa ssh key. SSH stong-crypto is set to yes. I upgraded a remote test router from 6.43.16 long-term to 6.44.5 long-term.

It allows me to make a connection using Putty as usual, the connection terminal window displays correctly. But when I try to manage the router through ssh port tunnel (redirect) to winbox or telnet it disconnects the ssh session with this error:

Strange packet received: type 82

The firmware was not upgraded to 6.44.5 because I could never reconnect to do it (user with ssh permissions is limited to just ssh, so management has to be through a redirected winbox or telnet unless there is a way to change users inside the ssh console window).

My Winbox is 3.19. If there is a change in the changelog that explains this problem I don't see it.

mkx · Sat Jul 13, 2019 12:02 pm

Can't you connect via ssh but using administrative user name?

sanitycheck · Sat Jul 13, 2019 7:32 pm

Can't you connect via ssh but using administrative user name?

Not in the standard configuration I use.

As a security measure the only user on the router with ssh rights is a special user for just that purpose, and it only has the ssh permission. I remove the ssh rights from admin. Admin user can only connect by remote through a second local login (Winbox, telnet) through ssh port redirect.

I can issue commands in the terminal window as the limited ssh user, but of course they are rejected because of no rights. From what I've found it is not possible to change users from within that window.

I have a server behind that router I connect to through ssh port redirect, in this case also with ssh. I can't connect to it either without the error and disconnection. So the problem isn't just trying to connect back to the router, it happens with any attempt to connect using an ssh port redirect.

tdw · Sun Jul 14, 2019 12:04 am

I connect to manage routers with ssh using an rsa ssh key. SSH stong-crypto is set to yes. I upgraded a remote test router from 6.43.16 long-term to 6.44.5 long-term.

It allows me to make a connection using Putty as usual, the connection terminal window displays correctly. But when I try to manage the router through ssh port tunnel (redirect) to winbox or telnet it disconnects the ssh session with this error:

Strange packet received: type 82

The firmware was not upgraded to 6.44.5 because I could never reconnect to do it (user with ssh permissions is limited to just ssh, so management has to be through a redirected winbox or telnet unless there is a way to change users inside the ssh console window).

My Winbox is 3.19. If there is a change in the changelog that explains this problem I don't see it.

Upgrading to 6.44.5 (and possibly prior 6.44.x releases) does bonkers things to the SSH settings, in particular:
If strong-crypto=yes then allow-none-crypto=no is added - AFAIK this is fixed in the latest beta.
Pertinent to your situation forwarding-enabled=remote is added - IIRC this has been mentioned in previous threads that forwarding-enabled=both, or at least forwarding-enabled=local, would be a better choice on upgrade.

Message ID (packet type) 82 is SSH_MSG_REQUEST_FAILURE

Unless you have a port allowed through the firewall through which you can fangle a remote SSH tunnel I see a long drive in your future.

oxy1 · Mon Jul 15, 2019 8:27 am

How do you guys propose we make such a changelog? This is the long term branch, where releases are very rare, and the jumps are very big.
Imagine there could be 15 fixes, new bugs, fixes again, then the feature could be already removed, then a new one added, removed again, and then a new feature made and fixed.

Listing fixes for non existing feature would be useless.

Realistically though, the introduction then removal of a feature in "stable" prior to moving to "long-term" is unlikely to occur often. It's supposed to be "stable".

The problem with reading the list of changes for "stable" is that often quite a few of the changes have already made it into the previous "long-term" branch. E.g. some fixes in 6.44.1 "stable" were also applied to 6.43.13 "long-term". So there's often quite a lot of duplicate information to wade through that may not be relevant at all. If I'm going from 6.43.16 to 6.44.5, I don't want to have to read a list of the changes that are already incorporated in the release I'm already running.

The way it is now means everyone who wants to upgrade would need to lay out both "stable" and "long-term" changelogs, side-by-side in chronological order, with all the possible changes, and then cross-reference between the two lists to see if there any (probable) matches. It really does make sense for this to be done once (by the team that actually develop the software?), rather than everyone having to do it each time the minor version number is bumped (or possibly multiple times, if you don't actually keep a copy of what you worked out). Do it once properly, and everyone (else) benefits enormously. It really will save a lot of effort overall (and probably grief).

Matrix64 · Mon Jul 15, 2019 2:44 pm

I wish the "long-term" channel would only have releases with bugfixes and security fixes, not a bunch of new features and underlying changes that need to be tested before I can apply the update to fix a security vulnerability. IMO, "long-term" channel should stay in 6.43.x branch and just receive fixes for at least 1 year, preferably more.

Anumrak · Mon Jul 15, 2019 4:18 pm

I wish the "long-term" channel would only have releases with bugfixes and security fixes, not a bunch of new features and underlying changes that need to be tested before I can apply the update to fix a security vulnerability. IMO, "long-term" channel should stay in 6.43.x branch and just receive fixes for at least 1 year, preferably more.

This exactly what long-term branch is:

https://wiki.mikrotik.com/wiki/Manual:U ... _numbering

Matrix64 · Mon Jul 15, 2019 5:42 pm

I wish the "long-term" channel would only have releases with bugfixes and security fixes, not a bunch of new features and underlying changes that need to be tested before I can apply the update to fix a security vulnerability. IMO, "long-term" channel should stay in 6.43.x branch and just receive fixes for at least 1 year, preferably more.
This exactly what long-term branch is:

https://wiki.mikrotik.com/wiki/Manual:U ... _numbering

So why was 6.44 pushed to long-term if all we needed were a few Linux kernel fixes? I remember "long-term" channel going from 6.42 to 6.43 not long ago.

chebedewel · Tue Jul 16, 2019 1:28 am

An upgrade on a hAP ac lite from 6.43.16 to 6.44.5 had an issue, only one wireless interface came back => one wireless interface was missing hence no connexion to CAP'sMAN.
It was fixed with a routerboard upgrade an a reboot.
Hopefully it was just a glitch on this device, as I have 1500 more in the wild with autoupgrade ...

Anumrak · Tue Jul 16, 2019 11:01 am

I wish the "long-term" channel would only have releases with bugfixes and security fixes, not a bunch of new features and underlying changes that need to be tested before I can apply the update to fix a security vulnerability. IMO, "long-term" channel should stay in 6.43.x branch and just receive fixes for at least 1 year, preferably more.
This exactly what long-term branch is:

https://wiki.mikrotik.com/wiki/Manual:U ... _numbering
So why was 6.44 pushed to long-term if all we needed were a few Linux kernel fixes? I remember "long-term" channel going from 6.42 to 6.43 not long ago.

Cause previous version became stable enough?

sanitycheck · Tue Jul 16, 2019 7:15 pm

Upgrading to 6.44.5 (and possibly prior 6.44.x releases) does bonkers things to the SSH settings, in particular:
If strong-crypto=yes then allow-none-crypto=no is added - AFAIK this is fixed in the latest beta.
Pertinent to your situation forwarding-enabled=remote is added - IIRC this has been mentioned in previous threads that forwarding-enabled=both, or at least forwarding-enabled=local, would be a better choice on upgrade.

Thanks for that. Confirmed SSH changes you mention above were the problem. To upgrade any other routers with my SSH configuration to 6.44.x I will first have to create a temporary remote access method to prevent being locked out. Another riskier option would be to add a script in scheduler that sets the correct SSH options at next startup, since they can't be set in advance.

I agree that SSH forwarding-enabled might be better set to 'both' as a default, at least during upgrades, to prevent this type of problem.

ttaiw · Wed Jul 17, 2019 4:11 pm

I got problem with dhcp-relay , after upgrade my client cannot get address.
Now I downgrade to version 6.43.16 it work fine.

mducharme · Fri Jul 19, 2019 8:16 pm

I got problem with dhcp-relay , after upgrade my client cannot get address.
Now I downgrade to version 6.43.16 it work fine.

FYI we have tested this on our devices - DHCP relay is working fine for us on 6.44.5.

mszru · Fri Jul 19, 2019 9:56 pm

The Dude on hEX (6.44.3) shows weird Expires After time in DHCP Leases for hAP ac at the latest long-term build (6.44.5). The lease time for DHCP server at hAP ac is set to 1 day.

DHCP_Leases_Expires_Afterx.png

shujanster · Sat Jul 20, 2019 3:44 am

I can't update 6.43.16 to 6.44.5. Don't know why.

Sent from my Redmi Note 5 using Tapatalk

sindy · Sat Jul 20, 2019 8:34 am

I can't update 6.43.16 to 6.44.5. Don't know why.

Does the beginning of /log print show anything after reboot with the new package downloaded? Typical reasons are .npk for a wrong architecture or a mythical malware preventing upgrade to protect itself.

shujanster · Sat Jul 20, 2019 10:41 pm

shujanster · Sat Jul 20, 2019 10:43 pm

I can't update 6.43.16 to 6.44.5. Don't know why.
Does the beginning of /log print show anything after reboot with the new package downloaded? Typical reasons are .npk for a wrong architecture or a mythical malware preventing upgrade to protect itself.

It's show me after reboot.

Screenshot_20190721-012612_Chrome.jpg

Sent from my Redmi Note 5 using Tapatalk

sindy · Sat Jul 20, 2019 11:17 pm

So the router tells you that it cannot install an enabled package (security) because it requires another package (dhcp) to work. It's not a nonsense - since 6.44, IKEv2 (from the security package) responder responds to DHCPINFORM messages from Windows clients which explains the dependency. So enable the dhcp package before upgrade and you should be good.

gunther01 · Sun Jul 21, 2019 12:19 am

44.5 caused Mipse and CCR's to port flap.. I'm not sure why, but when we go to 44.3 it stops..
Going to 445 or above, including the latest BETA crashed an entire leg of our network. Ports were flapping that had nothing plugged in to them, and some where BH's were and it would just flap OSPF constantly to the point I couldn't change settings or keep a winbox open.. Going to 44.3 fixed this issue.

It was very bad.

shujanster · Sun Jul 21, 2019 2:36 am

So the router tells you that it cannot install an enabled package (security) because it requires another package (dhcp) to work. It's not a nonsense - since 6.44, IKEv2 (from the security package) responder responds to DHCPINFORM messages from Windows clients which explains the dependency. So enable the dhcp package before upgrade and you should be good.

Thanks sir, it's working. Best wishes for you.

Sent from my Redmi Note 5 using Tapatalk

phendry · Sun Jul 21, 2019 9:22 am

44.5 caused Mipse and CCR's to port flap.. I'm not sure why, but when we go to 44.3 it stops..
Going to 445 or above, including the latest BETA crashed an entire leg of our network. Ports were flapping that had nothing plugged in to them, and some where BH's were and it would just flap OSPF constantly to the point I couldn't change settings or keep a winbox open.. Going to 44.3 fixed this issue.

It was very bad.

We saw something similar on a CCR1036 when upgrading from v6.43.12 to v6.44.5. What is strange is that we upgraded another CCR1036 from v6.43.12 to v6.44.5 before that which has very similar config (BGP, MPLS, EoIP) but saw no issues. Could only log into the device via mac-telnet and when checking routing table we saw it populate and then completely disappear. Had to factory reset, downgrade to v6.43.12 then restore from backup file.

gunther01 · Sun Jul 21, 2019 6:30 pm

44.5 caused Mipse and CCR's to port flap.. I'm not sure why, but when we go to 44.3 it stops..
Going to 445 or above, including the latest BETA crashed an entire leg of our network. Ports were flapping that had nothing plugged in to them, and some where BH's were and it would just flap OSPF constantly to the point I couldn't change settings or keep a winbox open.. Going to 44.3 fixed this issue.

It was very bad.
We saw something similar on a CCR1036 when upgrading from v6.43.12 to v6.44.5. What is strange is that we upgraded another CCR1036 from v6.43.12 to v6.44.5 before that which has very similar config (BGP, MPLS, EoIP) but saw no issues. Could only log into the device via mac-telnet and when checking routing table we saw it populate and then completely disappear. Had to factory reset, downgrade to v6.43.12 then restore from backup file.

I was able to downgrade back to 44.3 and the problem went away. But, some other routers didn't seem to act the same way as the two that were totally freaking out either. I even went so far as to try the latest Beta to see if it stopped and it acted the exact same. Ports that weren't even part of OSPF were flapping like mad. Then other ports that were part of OSPF and BH's were flapping also. Which of course screwed up an entire leg of our network. It was very very bad.. 44.3 instantly fixed that issue. SOMETHING IS BROKEN PAST 44.3. I don't know what it is, but it is for sure.

Halfeez92 · Mon Jul 22, 2019 10:06 am

I got error "TLS Failed" on Mikrotik OVPN client when enabling the verify-server-certificate. Can tell me what is the reason? When disabled, my Mikrotik OVPN client can connect without problem. I have been reading the mikrotik wiki on https://wiki.mikrotik.com/wiki/Manual:Interface/OVPN but nothing mention on the "verify-server-certificate", it has not been update is not it?

Halfeez92 · Mon Jul 22, 2019 10:09 am

I got error "TLS Failed" on Mikrotik OVPN client when enabling the verify-server-certificate. Can tell me what is the reason? When disabled, my Mikrotik OVPN client can connect without problem. I have been reading the mikrotik wiki on https://wiki.mikrotik.com/wiki/Manual:Interface/OVPN but nothing mention on the "verify-server-certificate", it has not been update is not it?

Oh it's okay. I already found the solution.
Apparently you have to import the CA into the client mikrotik, then it will use the CA to verify the remote server certificate.

Tue Jul 23, 2019 8:27 am

44.5 caused Mipse and CCR's to port flap.. I'm not sure why, but when we go to 44.3 it stops..
Going to 445 or above, including the latest BETA crashed an entire leg of our network. Ports were flapping that had nothing plugged in to them, and some where BH's were and it would just flap OSPF constantly to the point I couldn't change settings or keep a winbox open.. Going to 44.3 fixed this issue.

It was very bad.
We saw something similar on a CCR1036 when upgrading from v6.43.12 to v6.44.5. What is strange is that we upgraded another CCR1036 from v6.43.12 to v6.44.5 before that which has very similar config (BGP, MPLS, EoIP) but saw no issues. Could only log into the device via mac-telnet and when checking routing table we saw it populate and then completely disappear. Had to factory reset, downgrade to v6.43.12 then restore from backup file.
I was able to downgrade back to 44.3 and the problem went away. But, some other routers didn't seem to act the same way as the two that were totally freaking out either. I even went so far as to try the latest Beta to see if it stopped and it acted the exact same. Ports that weren't even part of OSPF were flapping like mad. Then other ports that were part of OSPF and BH's were flapping also. Which of course screwed up an entire leg of our network. It was very very bad.. 44.3 instantly fixed that issue. SOMETHING IS BROKEN PAST 44.3. I don't know what it is, but it is for sure.

Updated some CCRs with OSPF and BGP and do not see this problem. Must be specific to your config/installation.

gunther01 · Tue Jul 23, 2019 4:54 pm

44.5 caused Mipse and CCR's to port flap.. I'm not sure why, but when we go to 44.3 it stops..
Going to 445 or above, including the latest BETA crashed an entire leg of our network. Ports were flapping that had nothing plugged in to them, and some where BH's were and it would just flap OSPF constantly to the point I couldn't change settings or keep a winbox open.. Going to 44.3 fixed this issue.

It was very bad.
We saw something similar on a CCR1036 when upgrading from v6.43.12 to v6.44.5. What is strange is that we upgraded another CCR1036 from v6.43.12 to v6.44.5 before that which has very similar config (BGP, MPLS, EoIP) but saw no issues. Could only log into the device via mac-telnet and when checking routing table we saw it populate and then completely disappear. Had to factory reset, downgrade to v6.43.12 then restore from backup file.
I was able to downgrade back to 44.3 and the problem went away. But, some other routers didn't seem to act the same way as the two that were totally freaking out either. I even went so far as to try the latest Beta to see if it stopped and it acted the exact same. Ports that weren't even part of OSPF were flapping like mad. Then other ports that were part of OSPF and BH's were flapping also. Which of course screwed up an entire leg of our network. It was very very bad.. 44.3 instantly fixed that issue. SOMETHING IS BROKEN PAST 44.3. I don't know what it is, but it is for sure.
Updated some CCRs with OSPF and BGP and do not see this problem. Must be specific to your config/installation.

Yeah, that's a lot of help..
Like I said, ports that aren't even part of OSPF were flapping.. Made no sense at all.

And last time I had issues with MPLS and OSPF Mikrotik told me to reboot after I spent the tiem to send them support files on my routers.

Jotne · Tue Jul 23, 2019 7:51 pm

Please stop quoting the quote. Quote only part needed to quote, use Post Reply in post to answer a post...

Thu Jul 25, 2019 11:08 am

Updateing to 6.44.5 brings a problem with PPOE Server. Using a Remote Address in PPP Secret which is from a pool this address is not reserved/blocked. So PPPOE-Server uses this IP twice. Hard to find the problem as pings alway go through from the server side but customers complain like mad. So the static IP has to be removed from the pool.

mducharme · Thu Jul 25, 2019 7:57 pm

Updateing to 6.44.5 brings a problem with PPOE Server. Using a Remote Address in PPP Secret which is from a pool this address is not reserved/blocked. So PPPOE-Server uses this IP twice. Hard to find the problem as pings alway go through from the server side but customers complain like mad. So the static IP has to be removed from the pool.

For us it has always had this behavior (from when we started using it at around 6.35.x onward) - if a customer is assigned a static remote address for PPP (through RADIUS for example) it doesn't get tracked in pool usage so the same address can be given to another customer.

Fri Jul 26, 2019 8:39 am

Updateing to 6.44.5 brings a problem with PPOE Server. Using a Remote Address in PPP Secret which is from a pool this address is not reserved/blocked. So PPPOE-Server uses this IP twice. Hard to find the problem as pings alway go through from the server side but customers complain like mad. So the static IP has to be removed from the pool.
For us it has always had this behavior (from when we started using it at around 6.35.x onward) - if a customer is assigned a static remote address for PPP (through RADIUS for example) it doesn't get tracked in pool usage so the same address can be given to another customer.

I hop from long term to long term and reduce updates where possible. Still got burnt with such changes. I read the changelog carefully but ... I am really tired with complaining customers.

DummyPLUG · Tue Jul 30, 2019 7:53 pm

when did routeros start support DNSSEC? with 6.44.5 I see it support dnssec but no validation, as I remember I didn't see it support DNSSEC before.

Sob · Tue Jul 30, 2019 11:41 pm

AFAIK only "support" for DNSSEC in RouterOS is when you ask its resolver for DNSSEC-related records, it will ask upstream resolver and if it gets them from there, it will pass them on. But it's nothing special, any resolver that's not horribly broken does that.

DummyPLUG · Wed Jul 31, 2019 7:47 am

AFAIK only "support" for DNSSEC in RouterOS is when you ask its resolver for DNSSEC-related records, it will ask upstream resolver and if it gets them from there, it will pass them on. But it's nothing special, any resolver that's not horribly broken does that.

well at least it pass the record instead of do nothing like before, now wish they can fully implement it

Sob · Thu Aug 01, 2019 7:17 am

@DummyPLUG: Since it's probably OT here, because I really doubt that anything changed, maybe you could open new thread and share some details about what differences you see. I don't remember RouterOS having trouble with DNS records of any kind.

wolfktl · Mon Aug 05, 2019 12:10 am

TLS+failed OpenVPN
Certificate migration issue
viewtopic.php?f=2&t=143045&p=743141#p743141

Deantwo · Wed Aug 07, 2019 11:02 am

Can you maybe update the security blog post to include this RouterOS version as a fix?
Here: https://blog.mikrotik.com/security/cve- ... 11479.html

sport80 · Thu Aug 08, 2019 5:19 pm

TLS+failed OpenVPN
Certificate migration issue
viewtopic.php?f=2&t=143045&p=743141#p743141

Same problem to me

xt22 · Fri Aug 09, 2019 12:51 am

has anyone had any wireless problems with cAP (RBcAPGi-5acD2nD) and 6.44.5? After upgrading from the great 6.43.16 (I didn't know about the devices for like a year) to 6.44.5, I started to receive complaints from users. I don't see anything in logs or monitoring, but users say internet drops for a while, or the wifi(s) disappear totally for a short while.

I have like 100 of them and it is not a single complaint, there probably are some other non-Mikrotik factors involved in this, but anyway - 6.43.16 seems rock solid to me compared to 6.44.5,, has anyone experienced this too?

bda · Wed Aug 14, 2019 6:58 pm

has anyone had any wireless problems with cAP (RBcAPGi-5acD2nD) and 6.44.5? After upgrading from the great 6.43.16 (I didn't know about the devices for like a year) to 6.44.5, I started to receive complaints from users. I don't see anything in logs or monitoring, but users say internet drops for a while, or the wifi(s) disappear totally for a short while.

I have like 100 of them and it is not a single complaint, there probably are some other non-Mikrotik factors involved in this, but anyway - 6.43.16 seems rock solid to me compared to 6.44.5,, has anyone experienced this too?

I have several cAPlite, wAP, wAPac. No any problem with wifi.
We have multiple any other issues, but no with WiFi,

What kind of problem do you have?

parham · Thu Aug 15, 2019 11:40 am

Hi All,

I believe the SMNP v3 is broken, I have chaged all my device to 2c.

Parham

nje431 · Thu Aug 15, 2019 10:28 pm

Yes, SNMPv3 is broken. The one configuration I've found that works is Authentication=MD5 / Privacy=None. Anything else fails for me.

S4bulba · Wed Aug 21, 2019 1:32 pm

This build is ok with 951Ui-2nD.

Kampfwurst · Fri Aug 23, 2019 12:35 pm

i use a HAP ac² and i crashes when i try to use the bandwitdh test. I tried to connect to a 1100X4 also with the 6.44.5 version.
The log it shows "kernel failure"

Has someone the same problem?
The mikrotik support wrote me to update to the 6.45.3. But this is no option. Mikrotik need to get there software more stable.

DenisPDA · Fri Sep 06, 2019 12:09 pm

viewtopic.php?f=19&t=151903
RouterOS v7 beta
http://mt.lv/v7
Only for hap ac2, wap ac

prawira · Sun Sep 15, 2019 8:19 am

hello all..

i just upgrade the CCR1009 on my client side from 6.42.12LTS to 6.44.5. and the following service totally does run so i have to return it into 6.42.12.
+ ip cloud does run
+ data on usermanager can not recognized by hotspot, has not tested with ppp and or other services yet.

but with 6.44.5 on other platform seems to be fine; such as arm, mipsbe, chr, etc. only on ccr having problem (at least at ccr1009 that i tried)

is there anyone having the similar problem

Thank you

Paul

Tonda · Tue Sep 24, 2019 1:07 pm

I am unable to disable package DHCP, I am able to mark it for disable, but after reboot it does not get disabled with warning: can not disable dhcp-6.44.5: security depends on it.

mkx · Tue Sep 24, 2019 2:45 pm

The log says it all: package security needs package DHCP. Period.

nmt1900 · Fri Sep 27, 2019 10:33 pm

I am not sure if this has been happening before, but it is not acceptable. At first I was seeing periodic CAPsMAN outages - when all remote CAP's became unbound and disappeared from "Remote CAPs" list and then everything was back and 5 GHz radios started radar detect all over again. It was only now that I found out what it was about.

Problem is simple - when any CAP detects a radar, all CAPsMAN goes down and everything goes as described above. Not just radios, which had detected a radar, but ALL goes down. This looks like CAPsMAN manager itself crashes or something like that. It is hard to believe that this sledgehammer behaviour can be "by design".

CAPsMAN configuration is nothing too complicated - data goes through local forwarding and CAPsMAN management connections are done on separate management VLAN. CAPsMAN manager IP address is readily set on all CAP's (no defined discovery interfaces in CAP settings).

maryaadmins · Thu Oct 24, 2019 4:41 pm

hi
we have dhcp-server behind cisco router (dhcp-relay server)
after upgrade dhcp-server stops giving leases and fills leases with mac-address 00:00:00:00:00:00 and status busy (upgrade to 6.45.6 gives same result with macs 00:00:00:00:00:00 and status conflict)
disabling conflict detection resolves the issue

lamno · Mon Oct 28, 2019 8:03 am

CCR 1036-8G-2S+
ROS: 6.44.5

Crash/Hang
Supout.rif output:

--- /nova/logs/panic0.log
v6.44.5 Jul/04/2019 10:32:21 at 2019.10.26-18:28:20
fffffff7000f3b68 out_of_memory+0x388/0x878 (sp 0xfffffe407c26f9a0)
<3>  frame 3: 0xfffffff7000f98d8 __alloc_pages_nodemask+0x900/0xad8 (sp 0xfffffe407c26fa40)
<3>  frame 4: 0xfffffff7000f1a80 filemap_fault+0x3e0/0x690 (sp 0xfffffe407c26fb80)
<3>  frame 5: 0xfffffff70011a348 __do_fault+0x128/0x848 (sp 0xfffffe407c26fc08)
<3>  frame 6: 0xfffffff70011e128 handle_pte_fault+0x278/0x1838 (sp 0xfffffe407c26fca0)
<3>  frame 7: 0xfffffff7000391f0 do_page_fault+0x760/0xc48 (sp 0xfffffe407c26fd30)
<3>  frame 8: 0xfffffff70051ff60 handle_interrupt+0x288/0x2a8 (sp 0xfffffe407c26fdc0)
<3>  <interrupt 7 while in user mode>
<3>  frame 9: 0x26380 0x26380 (sp 0x7fcdf838)
<3>Stack dump stopped; next frame identical to this one
<3>Stack dump complete
<4>------------[ cut here ]------------
<4>WARNING: at /home/build/6.44.5/kernel/linux6/arch/tile/kernel/smp.c:239 smp_send_reschedule+0x70/0xb8()
<3>
<3>Starting stack dump of tid 0, pid 0 (swapper/9) on cpu 9 at cycle 56482214520
<3>  frame 0: 0xfffffff70051fc00 dump_stack+0x0/0x20 (sp 0xfffffe007cd6f5c8)
<3>  frame 1: 0xfffffff70004ca08 warn_slowpath_common+0xe0/0x190 (sp 0xfffffe007cd6f5c8)
<3>  frame 2: 0xfffffff700033338 smp_send_reschedule+0x70/0xb8 (sp 0xfffffe007cd6f608)
<3>  frame 3: 0xfffffff700093990 try_to_wake_up+0x490/0x560 (sp 0xfffffe007cd6f620)
<3>  frame 4: 0xfffffff70007fa10 autoremove_wake_function+0x28/0x90 (sp 0xfffffe007cd6f688)
<3>  frame 5: 0xfffffff70008bb58 __wake_up_common+0xa8/0x130 (sp 0xfffffe007cd6f6a0)
<3>  frame 6: 0xfffffff70008c198 __wake_up+0x70/0xb8 (sp 0xfffffe007cd6f6f0)
<3>  frame 7: 0xfffffff7000f95b8 __alloc_pages_nodemask+0x5e0/0xad8 (sp 0xfffffe007cd6f730)
<3>  frame 8: 0xfffffff70014a3e0 new_slab+0x1d0/0x598 (sp 0xfffffe007cd6f870)
<3>  frame 9: 0xfffffff70051be40 __slab_alloc+0x388/0x8b8 (sp 0xfffffe007cd6f8c0)
<3>  frame 10: 0xfffffff70014d358 kmem_cache_alloc_node+0x90/0x208 (sp 0xfffffe007cd6f9b8)
<3>  frame 11: 0xfffffff7101f4288 fast_path_update_stats+0x898/0x1028 [packet_hook@0xfffffff7101f0000] (sp 0xfffffe007cd6f9e0)
<3>  frame 12: 0xfffffff7101f2b08 fast_path_rx_noinvalidate_nostats+0xa8/0x740 [packet_hook@0xfffffff7101f0000] (sp 0xfffffe007cd6fa38)
<3>  frame 13: 0xfffffff7101f86b0 fp_ipv4_exit+0x348/0x958 [packet_hook@0xfffffff7101f0000] (sp 0xfffffe007cd6fa98)
<3>  frame 14: 0xfffffff7101f2b08 fast_path_rx_noinvalidate_nostats+0xa8/0x740 [packet_hook@0xfffffff7101f0000] (sp 0xfffffe007cd6fab0)
<3>  frame 15: 0xfffffff710ee7f20 0xfffffff710ee7f20 [tilegx@0xfffffff710ee0000] (sp 0xfffffe007cd6fb10)
<3>  frame 16: 0xfffffff700418668 net_rx_action+0x2f0/0x3f0 (sp 0xfffffe007cd6fb98)
<3>  frame 17: 0xfffffff700057d38 __do_softirq+0x228/0x380 (sp 0xfffffe007cd6fc30)
<3>  frame 18: 0xfffffff7000582c8 do_softirq+0xc8/0x140 (sp 0xfffffe007cd6fcd0)
<3>  frame 19: 0xfffffff700058878 irq_exit+0xe8/0x170 (sp 0xfffffe007cd6fce8)
<3>  frame 20: 0xfffffff700026f28 tile_dev_intr+0x1e8/0x248 (sp 0xfffffe007cd6fcf8)
<3>  frame 21: 0xfffffff70051ff60 handle_interrupt+0x288/0x2a8 (sp 0xfffffe007cd6fd40)
<3>  <interrupt 29 while in kernel mode>
<3>  frame 22: 0xfffffff70051fcc0 _cpu_idle_nap+0x0/0x18 (sp 0xfffffe007cd6ffa0)
<3>  frame 23: 0xfffffff700029bb8 cpu_idle+0x340/0x420 (sp 0xfffffe007cd6ffa0)
<3>Stack dump complete
<4>---[ end trace 7b8d6a88c8c57a65 ]---
<0>BUG: soft lockup - CPU#30 stuck for 22s! [loader:315]

emils · Mon Oct 28, 2019 4:13 pm

New version 6.44.6 has been released in long-term RouterOS channel:

viewtopic.php?f=21&t=153379

Who is online