v6.43.1 [stable] and v6.43.2 [stable] are released!

emils · Tue Sep 18, 2018 12:00 pm

RouterOS version 6.43.1 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.43.1 (2018-Sep-17 06:53):

Changes in this release:

*) crs317 - fixed packet forwarding on bonded interfaces without hardware offloading;
*) defconf - properly clear global variables when generating default configuration after RouterOS upgrade;
*) dhcpv6-client - log only failed pool additions;
*) hotspot - properly update dynamic "walled-garden" entries when changing "dst-host";
*) ike2 - fixed rare authentication and encryption key mismatches after rekey with PFS enabled;
*) lte - fixed LTE interface not working properly after reboot on RBSXTLTE3-7;
*) rb3011 - added IPsec hardware acceleration support;
*) routerboard - fixed memory tester reporting false errors on IPQ4018 devices ("/system routerboard upgrade" required);
*) sniffer - made "connection", "host", "packet" and "protocol" sections read-only;
*) switch - fixed port mirroring on devices that do not support CPU Flow Control;
*) upnp - improved UPnP service stability when handling HTTP requests;
*) webfig - allow to change user name when creating a new system user (introduced in v6.43);
*) webfig - fixed time interval settings not applied properly under "IP/Kid Control/Kids" menu;
*) winbox - added "allow-dual-stack-queue" setting to "IP/DHCP Server/Leases" menu;
*) winbox - added "allow-dual-stack-queue" setting to "IPv6/DHCPv6 Server/Bindings" menu;
*) winbox - fixed corrupt user database after specifying allowed address range (introduced in v6.43);
*) winbox - make bridge port "untrusted" by default when creating new port;
*) winbox - show "IP/Cloud" menu on CHR;
*) winbox - show "System/RouterBOARD/Mode Button" on devices that have such feature;
*) wireless - removed "czech republic 5.8" regulatory domain information as it overlaps with "ETSI 5.7-5.8";

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.

amt · Tue Sep 18, 2018 12:17 pm

Untitled.jpg

Tue Sep 18, 2018 1:19 pm

Maybe 6.43.1 was retracted or not available for automatic download yet/now.

amt · Tue Sep 18, 2018 1:50 pm

Maybe 6.43.1 was retracted or not available for automatic download yet/now.

I just installed over automatic download and this happen. its a simple error maybe :=)

bennyh · Tue Sep 18, 2018 2:15 pm

RouterOS version 6.43.1 has been released in public "stable" channel!
*) rb3011 - added IPsec hardware acceleration support;

Big thanx bro

Kraken2k · Tue Sep 18, 2018 2:15 pm

Maybe 6.43.1 was retracted or not available for automatic download yet/now.
I just installed over automatic download and this happen. its a simple error maybe :=)

Updated RB2011 the same way - this did not happen in my case (RouterOS versions are reported correctly)

mkx · Tue Sep 18, 2018 2:15 pm

Maybe it's winbox. CLI is fine:

> /system package update check-for-updates 
            channel: current
  installed-version: 6.43.1
     latest-version: 6.43.1
             status: System is already up to date

saaremaa · Tue Sep 18, 2018 2:23 pm

CCR1016-12G 6.43.1 - "Delegated-IPv6-Prefix" attribute for PPPoE not work.
viewtopic.php?f=1&t=89443&p=687058#p687058

pe1chl · Tue Sep 18, 2018 4:57 pm

Export issues still present - discovered when trying to cut/paste an existing export into 6.43.1:

- /ipv6 dhcp-server is exported before /ipv6 pool but server refers to pool names
- /ip neighbor discovery-settings set discover-interface-list=!somelistname forgets to export the ! (not)

Bierkameel · Tue Sep 18, 2018 5:02 pm

*) rb3011 - added IPsec hardware acceleration support;

Niceeeee, I've got 2 RB3011's.
Going to switch from VPN to my Synology to the RB3011

StubArea51 · Tue Sep 18, 2018 5:19 pm

Thanks! Just tried it on a CRS317-1G-16S+ and it worked perfectly for the RouterOS and Firmware upgrades

Cal5582 · Tue Sep 18, 2018 5:32 pm

This fixed my issues with my RBM11g not detecting mpcie wireless cards. thank you for all your hard work!

eddieb · Tue Sep 18, 2018 5:48 pm

Upgraded thru DUDE without any issues
CCR1009-8G-1S (running multiple l2tp/ipsec tunnels)
RB1100
RB750GL
CRS125
RB962UIGS (10x)
CHR running DUDE

plex2000 · Tue Sep 18, 2018 6:13 pm

Where is bugreport page or bugtracker?
I am using IGMP proxy and VLAN on 3011, after updete form 6.42.7 to 6.43.0 or 6.43.1 IGMP proxy working with errors
If i using 6.43 firmware without VLAN IGMP Proxy working normally.

Tue Sep 18, 2018 6:35 pm

Where is bugreport page or bugtracker?

Write an email to support@mikrotik.com

buntov · Tue Sep 18, 2018 8:01 pm

Just upgraded RB951G-2HnD v6.43 to v6.43.1. In both versions the multicast traffic doesn't go, though the same configuration works fine in v6.40.9 and worked in previous versions for couple of years. Why so? I use multicast package, IGMP proxy and firewall rules to allow iptv traffic.

thg3x · Tue Sep 18, 2018 8:21 pm

CCR1016-12G 6.43.1 - "Delegated-IPv6-Prefix" attribute for PPPoE not work.
viewtopic.php?f=1&t=89443&p=687058#p687058

+1

nichky · Tue Sep 18, 2018 8:22 pm

Why this?
*) winbox - added "allow-dual-stack-queue" setting to "IP/DHCP Server/Leases" menu;

MonkeyDan · Tue Sep 18, 2018 8:23 pm

Still having issues with multipoint Wireless Wires. Connections take forever to stabilize after first boot. They reconnect constantly during this time which seems to have gotten longer with this release. Took 30 minutes for the links to stop flapping on 6.43.1

WebLuke · Tue Sep 18, 2018 10:38 pm

I am still seeing high memory use on my CRS125-24G-1s-2HnD, I did see before doing a routerboard update the use down to 33MiB but after its up to 54MiB much better than the 102MiB. I will have to watch the graph and see if it rises over time like I was seeing in 6.43.

Looking forward to just using this as a switch and moving to a RB4011 as soon as I can find a supplier selling it on Amazon, it would be nice if MicroTik would sell directly on some of the major sites.

Anumrak · Wed Sep 19, 2018 10:55 am

What does this mean in details?

*) winbox - fixed corrupt user database after specifying allowed address range (introduced in v6.43); Does this mean that in ROS lower than 6.43 address range not working?

Deantwo · Wed Sep 19, 2018 12:21 pm

What does this mean in details?

*) winbox - fixed corrupt user database after specifying allowed address range (introduced in v6.43);

Does this mean that in ROS lower than 6.43 address range not working?

The "introduced in v6.43" means that it was a bug that was introduced (a.k.a. made) in RouterOS version 6.43 and only present in that version (since v6.43.1 is the first update after v6.43).
As for what the actual fix was, I don't know, but I would love to hear more.

Chupaka · Wed Sep 19, 2018 12:55 pm

Yesterday upgraded two CCRs from 6.41.3 to 6.43.1 in the hotel I had vacation in Greece

At least, now it's not vulnerable to WinBox user database reading xD Unfortunately, WinBox access is still allowed for every Free WiFi user in the hotel

Kindis · Wed Sep 19, 2018 2:57 pm

Yesterday upgraded two CCRs from 6.41.3 to 6.43.1 in the hotel I had vacation in Greece At least, now it's not vulnerable to WinBox user database reading xD Unfortunately, WinBox access is still allowed for every Free WiFi user in the hotel

Feel free to add a new title to you business card "Knight and Protector of the Internets"

You earned that title!

kleksiq · Wed Sep 19, 2018 6:07 pm

Upgraded one 3011 for tests, IPSEC diff:
- 6.42.7 - 50% CPU and 6 to 7 MB/s
- 6.43.1 - 40% CPU and full 10MB/s ( max bandwidth ) we will test it with smth like 1gbps/1gbps for lolz

For now working ok, we will see tomorrow...

thasser · Wed Sep 19, 2018 6:38 pm

Upgraded one 3011 for tests, IPSEC diff:
- 6.42.7 - 50% CPU and 6 to 7 MB/s
- 6.43.1 - 40% CPU and full 10MB/s ( max bandwidth ) we will test it with smth like 1gbps/1gbps for lolz

For now working ok, we will see tomorrow...

AWESOME more test results and specifics on config/type of vpn/encryption you are using PLZ!!!!!!!!!!

Good work!

gabeselig · Wed Sep 19, 2018 7:27 pm

Run into issues with this latest firmware. Happens on 2011 and on RB912 so far. Version 6.43.1. Reboot, software based or power cycle, the routers get stuck in a boot loop and start sending out bootp packets wanting a net install. (etherboot)

Existing routerboard settings:

/system routerboard settings
set silent-boot=no

Reverting back where possible.
Gabe

nostrax1 · Wed Sep 19, 2018 10:41 pm

Release 6.43.1 has broken five of my RB2011 routers, infinite boot loop.
Only Netinstall with longterm version 6.40 has revived the routers.

This one time i must say: not a good job from MTik :-/

minelli · Thu Sep 20, 2018 2:11 am

Bug in DHCPv6 PD Pool no PPP Profile. Set pool IPv6 and does not working.
Before 6.43 everything ok.

TheRealJLH · Thu Sep 20, 2018 2:24 am

I installed the mipsbe version of 6.43 to a CRS-112 and the cpu load went to 100% has this been fixed in 6.43.1

LeftyTs · Thu Sep 20, 2018 2:28 am

I can't get RoMON to work. When I try to connect with ssh it simply keeps on asking for password over and over again without actually connecting. Ping and discovery work. Anyone with same problem?

Railander · Thu Sep 20, 2018 3:05 am

still cant change any user names.
introduced in 6.43.0

mducharme · Thu Sep 20, 2018 4:55 am

Bug in DHCPv6 PD Pool no PPP Profile. Set pool IPv6 and does not working.
Before 6.43 everything ok.

Yes, the problem appears to be related to creating the DHCPv6 binding. If I manually create a DHCPv6 binding with the correct prefix, DUID, and IAID, then it works.

Spirch · Thu Sep 20, 2018 6:04 am

for a cAP AC

i'm trying to do a netinstall from a windows xp laptop that have nothing else activated than the lan local (old laptop with 10/100)

 netinstall.exe

 advanced-tools-6.43.1-arm.npk
 dhcp-6.43.1-arm.npk
 ntp-6.43.1-arm.npk
 ppp-6.43.1-arm.npk
 security-6.43.1-arm.npk
 system-6.43.1-arm.npk
 wireless-6.43.1-arm.npk

I see the cAP ac in netinstall, I select all packages and all is happening when i click on install is;

ready -> installing -> sending offer -> ready

I have tried with the stable release instead of current, same thing

I don't have the firewall activated and I don't have secureboot routerboard activated

I used this laptop before (few years ago) to do a netinstall and it worked #1

any idea?

mducharme · Thu Sep 20, 2018 6:17 am

for a cAP AC

i'm trying to do a netinstall from a windows xp laptop that have nothing else activated than the lan local (old laptop with 10/100)

any idea?

Have you tried netinstall using the ARM main package instead?

https://download.mikrotik.com/routeros/ ... 6.43.1.npk

Also, make sure you are using the newer netinstall 6.43.1 and not an older version. Each time there is a new ROS release, there is a new netinstall version, and using an older one may not work correctly.

Spirch · Thu Sep 20, 2018 6:23 am

Have you tried netinstall using the ARM main package instead?

https://download.mikrotik.com/routeros/ ... 6.43.1.npk

Also, make sure you are using the newer netinstall 6.43.1 and not an older version. Each time there is a new ROS release, there is a new netinstall version, and using an older one may not work correctly.

I will try tomorrow and let you know

Pea · Thu Sep 20, 2018 8:14 am

still cant change any user names.
introduced in 6.43.0

viewtopic.php?f=2&t=139091

kleksiq · Thu Sep 20, 2018 10:58 am

Upgraded one 3011 for tests, IPSEC diff:
- 6.42.7 - 50% CPU and 6 to 7 MB/s
- 6.43.1 - 40% CPU and full 10MB/s ( max bandwidth ) we will test it with smth like 1gbps/1gbps for lolz

For now working ok, we will see tomorrow...
AWESOME more test results and specifics on config/type of vpn/encryption you are using PLZ!!!!!!!!!!

Good work!

PPPoE on WAN port, rest is bridged, 25 firewall rules, mostly drop 80/443

, srcnat to public ip, ipsec sha1 / aes128cbc+aes192cbc+aes256cbc so nothing fancy

Ivoshiee · Thu Sep 20, 2018 11:11 am

On 60G devices if I do a scan and drop off (terminate winbox or winbox terminate because of network break), that wireless interface will remain in scan mode even if I log back in and to try press "stop" for that scan. Only remedy is to reboot that given device. It should act like regular wireless interfaces when they will drop out of that scan mode if there is no "winbox" around or whatever the logic.

apshenniy · Thu Sep 20, 2018 11:52 am

ether1: bridge port received packet with own address as source address (xx:xx:xx:xx:xx:xx), probably loop
On all updated devices mac address bridge = mac address of one of the interfaces

sindy · Thu Sep 20, 2018 1:25 pm

On all updated devices mac address bridge = mac address of one of the interfaces

This is a normal behaviour (in particular, it is the numerically lowest one of the MAC addresses of all bridged interfaces) unless you set a bridge mac address administratively. So it should not be different as compared to previous versions. Does it mean that the administrative (configuration) setting of the bridge mac stopped working, or that you haven't ever had a look in older versions because you never got the error regarding own MAC and loop?

eddieb · Thu Sep 20, 2018 1:44 pm

I just upgraded my RB2011UAS-RM from 6.43 to 6.43.1 ...
no problems.

dadaniel · Thu Sep 20, 2018 2:20 pm

still cant change any user names.
introduced in 6.43.0

Renaming is not possible anymore due to security changes, please see viewtopic.php?f=2&t=139091#p685742

anav · Thu Sep 20, 2018 2:21 pm

Yesterday upgraded two CCRs from 6.41.3 to 6.43.1 in the hotel I had vacation in Greece At least, now it's not vulnerable to WinBox user database reading xD Unfortunately, WinBox access is still allowed for every Free WiFi user in the hotel

Chupaka you seem tired. I would be more than happy to run around Europe configuring mikrotiks for you. All I ask is airplane fare from Canada to Europe, train tickets to destinations and airbnb and meals covered. (and cell phone plan). If I think of anything else I will let you know, maybe some tickets to La Liga games LOL.

mkx · Thu Sep 20, 2018 2:39 pm

Yesterday upgraded two CCRs from 6.41.3 to 6.43.1 in the hotel I had vacation in Greece At least, now it's not vulnerable to WinBox user database reading xD Unfortunately, WinBox access is still allowed for every Free WiFi user in the hotel
Chupaka you seem tired. I would be more than happy to run around Europe configuring mikrotiks for you. All I ask is airplane fare from Canada to Europe, train tickets to destinations and airbnb and meals covered. (and cell phone plan). If I think of anything else I will let you know, maybe some tickets to La Liga games LOL.

While you'll be running around Europe and working like crazy, I could fix a few Mikrotiks in Canada for you. I hear that Calgary isn't too bad place to be in winter time.

DenisPDA · Thu Sep 20, 2018 4:29 pm

New update ???

What's new in 6.43.2 (2018-Sep-18 12:12):

Changes in this release:

*) routerboot - fixed RouterOS booting on devices with particular NAND memory (introduced in v6.43);

emils · Thu Sep 20, 2018 4:35 pm

RouterOS version 6.43.2 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.43.2 (2018-Sep-18 12:12):

Changes in this release:

*) routerboot - fixed RouterOS booting on devices with particular NAND memory (introduced in v6.43);

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 these specific RouterOS releases.

emils · Thu Sep 20, 2018 4:39 pm

Release 6.43.1 has broken five of my RB2011 routers, infinite boot loop.
Only Netinstall with longterm version 6.40 has revived the routers.

This one time i must say: not a good job from MTik :-/

Please try upgrading to v6.43.2, the particular issue is addressed in this release.

R1CH · Thu Sep 20, 2018 4:41 pm

Breaking the bootloader in a "stable" release...

Thu Sep 20, 2018 4:44 pm

Breaking the bootloader in a "stable" release...

S..t happens, but i'm loving the reaction time tho.

RomanT · Thu Sep 20, 2018 5:17 pm

Greetings!
I`ve upgraded many routers to 6.43.1 (OS + firmware). Today one of RB2011 was rebooted and didn`t wake up! I can`t see it even using netinstall. It seems to be an endless boot cycle... By the way, the router made no sound till I`d used a "curcuit" reset instead of button.
Please, help me. I`m afraid that my another routers will do the same.

sid5632 · Thu Sep 20, 2018 5:37 pm

Three "stable" releases in just over a week seems to be rather a contradiction in terms to me.
Perhaps "current" really was the correct name.

WirelessRudy · Thu Sep 20, 2018 5:43 pm

Three "stable" releases in just over a week seems to be rather a contradiction in terms to me.
Perhaps "current" really was the correct name.

Agree.

Thu Sep 20, 2018 5:43 pm

Perhaps "current" really was the correct name.

Indeed!

WirelessRudy · Thu Sep 20, 2018 6:27 pm

Three "stable" releases in just over a week seems to be rather a contradiction in terms to me.
Perhaps "current" really was the correct name.

A version should only be called "stable" if the user community deemed it stable..... as long as users still report issues, it should be "current". Only if determined after 1 or 2 weeks a 'current' version is stable it can be called 'stable'.

To me it looks that with a user base as Mikotik a week is long enough to find out if a certain version indeed is stable to be called so.....
So either a 'current' is replace by a new 'current' version or after a week might upgrade to 'stable'.

And only 'stable' version should come up in the auto upgrade process.

You should be able to pick 5 options;
1. 'bugfix only' for those that wan't 100% security (doesn't exit but heho) with bux fixed if found and solved so far but not the latest features
2. 'current' for those that wan't the tested version of the most recent features but without the real world test of many thousands of different Mikrotik devices.
3. 'stable' is just the same version as '2' but after maturing process of one week... Only if the OS one week has no reports of issues from the user community.
4. 'release candidate' for those that want to see new features or new issues sorted out and tried out. NOT to be used in wide scale real world networks.
5. 'development' for the latest features, improvements or upgrading of the ROS. ONLY for players or those that would like to help MT ROS to lift to a higher level. DEFENITELY NOT for production environment.

I this list there can never be a 'current' version with the same number as a 'stable' version. A new version goes from 'current' into 'stable'. A new 'current' version then needs to have a higher number.

The aim is that if you wan't to upgrade your network to the latest feature level you can either go for the 'current' version but don't be surprised that the community (and that might be you!) still finds issues.
Or just wait a week (or longer) to see if it is really stable enough to go blind for it.....

In the present if you wan't 'current' of the now called 'stable' (which also happens to be the version that is represented and used in the 'auto upgrade') you still put your network in harms way since it is not been tested widely against all kind of different networks and hardware configurations. So you need to read and follow the forum to see if, and what kind of, issues emerge and if they might have an impact on your network. I can make better use of my time to be honest...

xvo · Thu Sep 20, 2018 6:36 pm

Totally agree with WirelessRudy.

stef84 · Thu Sep 20, 2018 6:42 pm

Hello.

With 6.43 i don't connect remote from wan with winbox or 80 port. I enter only from LAN.

were is the solution?

Thanks

vovchikkd · Thu Sep 20, 2018 6:48 pm

I have two bricked device after flashing with 6.43.1 firmware. sxt lite2 and groove5 in bootloop.
What should i do?

mducharme · Thu Sep 20, 2018 8:15 pm

I have two bricked device after flashing with 6.43.1 firmware. sxt lite2 and groove5 in bootloop.
What should i do?

It should be fixed in 6.43.2, you will need to netinstall v6.43.2.

I agree that the recent renaming of 'current' to 'stable' is probably unfortunate given these issues.

Perhaps 'current' should remain, and bugfix-only/long-term named 'stable' instead? the bugfix-only should certainly be stable. Then there is testing, current, and stable, those names are rather self explanatory, unlike bugfix-only or long-term.

Thu Sep 20, 2018 9:42 pm

bugfix-only/long-term named 'stable' instead?

I have a theory that they may want to support 6.40.x line (the last release branch before the bridge overhaul) for an extended period of time, hence the "long-term". This does not justify, however, renaming "current" to "stable".

bbs2web · Thu Sep 20, 2018 10:21 pm

RouterOS 6.43.2 still hasn't fixed VirtIO multi-queue CPU association problem, both input queues are pinned to the same CPU core:

Tx and Rx queues should share the same core, as detailed here:

Reference: https://www.linux-kvm.org/page/Multiqueue

Sent email to support@mikrotik.com [Ticket#2018091422005951]

TheRealJLH · Thu Sep 20, 2018 10:30 pm

Yesterday upgraded two CCRs from 6.41.3 to 6.43.1 in the hotel I had vacation in Greece At least, now it's not vulnerable to WinBox user database reading xD Unfortunately, WinBox access is still allowed for every Free WiFi user in the hotel

Proper Input chain filtering in the ip firewall solves the winbox issues quite well.

Hrobocop · Thu Sep 20, 2018 10:31 pm

Hi MikroTik,

sorry, but this wasn't good. Problems happen, but if you totally screw firmware upgrade, which will brick a lot of routers, resulting in a lot of troubles for your loyal customers, and even lot of kilometres and hours of driving, you should at least try to not screw your support. I know you have three-day response policy, but in this case, ignoring users with bricked routers is a really bad thing. And the same is for changelog. There should be a real and clear warning, that 6.43.1 can potentially brick your unit.

bbs2web · Thu Sep 20, 2018 10:33 pm

L2TP VPN security concern since upgrading 6.42.6 to 6.43.2, MPPE128 is disabled after VPNs connect in approximately 33.3% of the cases:

21:12:41 l2tp,info first L2TP UDP packet received from xxx.xxx.xxx.xxx
21:12:41 l2tp,ppp,info,account zzzzzzzzzz logged in, yyy.yyy.yyy.yyy
21:12:41 l2tp,ppp,info vpn-zzzzzzzzzz: authenticated
21:12:41 l2tp,ppp,info vpn-zzzzzzzzzz: connected
21:12:41 l2tp,ppp,info vpn-zzzzzzzzzz: using encoding - MPPE128 stateless
21:12:41 l2tp,ppp,info vpn-zzzzzzzzzz: disabling encoding - MPPE128 stateless

33.3% of the VPN connections have no encryption active on them:

Configuration:

/interface l2tp-server server
  set allow-fast-path=no authentication=mschap2 caller-id-type=ip-address default-profile=default-encryption enabled=yes ipsec-secret="" keepalive-timeout=30 \
    max-mru=1440 max-mtu=1440 max-sessions=unlimited mrru=disabled one-session-per-host=no use-ipsec=no
/ppp profile
  set *FFFFFFFE only-one=yes
/ppp secret
  add local-address=10.254.254.1 name=user password=***************** remote-address=10.254.254.2 service=l2tp

sid5632 · Thu Sep 20, 2018 11:36 pm

At time of writing, these would seem to fit:

Legacy: 5.26
Long-term/bugfix: 6.40.9
Stable: 6.42.7
Current: 6.43.2
Testing: 6.44beta9
Development: Who knows

Winbox still seems to have the old 4 categories though (bugfix, current, testing, development) - but I've never seen anything in 'development' so why have it (unless it's for internal use only)?
It seems like they only have 4 slots, so they ought to be Long-term/bugfix, Stable, Current, Testing

mducharme · Thu Sep 20, 2018 11:59 pm

L2TP VPN security concern since upgrading 6.42.6 to 6.43.2, MPPE128 is disabled after VPNs connect in approximately 33.3% of the cases:

You should really be using L2TP over IPsec, not just regular L2TP.

OldSwitchConfigLiker · Fri Sep 21, 2018 12:46 am

bugfix-only/long-term named 'stable' instead?
I have a theory that they may want to support 6.40.x line (the last release branch before the bridge overhaul) for an extended period of time, hence the "long-term". This does not justify, however, renaming "current" to "stable".

I have the same impression.... thankfully they understood the importance of stability for production environments. Much more than always having the latest features.
I can only applaud this.

But frankly, the only thing they really need to do to remain compatible with old config's is an extra package that restores masterports, and probably later (in a few versions, as bridge hardware vlan filtering etc. finally works for all RB's) also the switchconfig-menu, which seems to be oh-so-difficult for some to understand.

Limited distribution of such package is sufficient. And the code for set package is well known and well tested, since successfully in use for many years. Shouldn't need to much engineering effort.
There is also no need for such package for newly released hardware, since that never had a RoS release that supported masterports. So it will be of a limited scope and it is a self extinguishing service as time progresses...

In fact.... all functionality that is abandoned, and has a reasonable userbase, should be covered like that imho. It's called: taking your professional customers seriously. (not just the enthusiasts)

But don't get me wrong, I'm all for new features. That is progress. It is that what also made Routerboard great. There NEED to be new features in new versions, and those features will have bugs.
Put those new versions in a current branch (or whatever you like to call it), and leave a "long term" branch available for the reasonable lifetime of a product with only security and bugfixes.

As such, I'm happy with the 6.40.xxx as "long term", like they seem to do now. (As long as they do not abandon it in a few months or so...)

mducharme · Fri Sep 21, 2018 12:50 am

But frankly, the only thing they really need to do to remain compatible with old config's is an extra package that restores masterports, and probably later (in a few versions, as bridge hardware vlan filtering etc. finally works for all RB's) also the switchconfig-menu, which seems to be oh-so-difficult for some to understand.

Why do you need master ports back? You get the same thing with a bridge without vlan filtering and with hardware offloading enabled, and I believe MikroTik has added back all of the the switch menus that were removed in 6.41+. A lot of people seem to be under the (I believe mistaken) impression that certain configurations are no longer possible now that master ports are gone. I have not personally seen any configurations that you can do with the old switch chip that are no longer possible after 6.41, and can't really think of any. The master ports are still there under the hood, just hidden from view.

The only change is that you are now forced to have a bridge, but this bridge really has no impact on the configuration and changes nothing, as long as it is hardware offloaded, with STP off and VLAN filtering off. The switch chip VLAN configuration etc. is still possible in the same way.

So if you look at the old 6.40.x way if you have a 5 port router, you could have set it up without a bridge or with a bridge, and it really made no difference in the behavior of the device:

Old 6.40.x configuration (without bridge):

     ether2-master
  /        |       \     
ether3   ether4  ether5

Old 6.40.x configuration (with bridge):

       bridge
           |
     ether2-master
  /        |       \     
ether3   ether4  ether5

This bridge should have no effect on the behavior of the router and what you could do (this bridge would be standard on MikroTik wireless routers).

The new 6.41+ config behaves exactly the same as the old way with the bridge. You are now forced to use this bridge, but it really has no impact in terms of possible configurations and the router should behave the same as if it was not there. It should not be a show-stopper preventing upgrade. You can still do switch chip hardware VLANs etc as before.

r00t · Fri Sep 21, 2018 2:25 am

*) routerboot - fixed RouterOS booting on devices with particular NAND memory (introduced in v6.43);

It would be really helpful if you listed affected devices or at least product ranges. Is CCR affected? Or just MIPS maybe? Do I have to update wireless wire?
This is quite important information you are not giving us!
It's NO FUN updating large network of devices and if there is no reason to update some it could save a lot of time and possibly issues.
"devices with particular NAND memory" is as helpful as saying nothing...

Spirch · Fri Sep 21, 2018 3:42 am

Have you tried netinstall using the ARM main package instead?

https://download.mikrotik.com/routeros/ ... 6.43.1.npk

Also, make sure you are using the newer netinstall 6.43.1 and not an older version. Each time there is a new ROS release, there is a new netinstall version, and using an older one may not work correctly.

I have tried the exact same thing with 6.43.2, without using main package

this time it work #1 the first time, so ... not sure why it didnt work with 6.43.1 ...

flipylost · Fri Sep 21, 2018 5:44 am

RouterBOARD 941-2nD 6.43.1, upgrade error 6.43.2 "not enough space for upgrade"

several attempts same error, after erasing files(files empty) same error

after attempt, routeros-smips-6.43.2.npk remains in files. reboot causes same error.
deleted routeros-smips-6.43.2.npk file and reboot the router works correct in 6.43.1

2X RouterBOARD 750G r3 upgrade ok.

ailtojr · Fri Sep 21, 2018 8:04 am

Hello friends I just upgraded to version 6.43.2 and our clients stopped working with ipv6, after this last update I downgraded to version 6.42.7 and returned to normal function.

Fri Sep 21, 2018 8:05 am

Flipylost, Don't put upgrade files into flash but into ramdisk.

Fri Sep 21, 2018 8:16 am

*) routerboot - fixed RouterOS booting on devices with particular NAND memory (introduced in v6.43);
It would be really helpful if you listed affected devices or at least product ranges. Is CCR affected? Or just MIPS maybe? Do I have to update wireless wire?
This is quite important information you are not giving us!
It's NO FUN updating large network of devices and if there is no reason to update some it could save a lot of time and possibly issues.
"devices with particular NAND memory" is as helpful as saying nothing...

Why? IF your devices booted - stay on v6.43.1, if they didn't - use v6.43.2, in future use v6.43.2, feature wise both are identical versions.

mducharme · Fri Sep 21, 2018 8:33 am

Hello friends I just upgraded to version 6.43.2 and our clients stopped working with ipv6, after this last update I downgraded to version 6.42.7 and returned to normal function.

Yes, 6.43 - 6.43.2 have a problem with DHCPv6 server, the bindings do not get added. If manual bindings are present, they continue to work, but dynamic bindings are not properly created.

dadaniel · Fri Sep 21, 2018 10:08 am

It should be fixed in 6.43.2, you will need to netinstall v6.43.2.

Great, I did an upgrade to 6.43.1 on hEX and auto-upgrade of firmware was active. I did not reboot yet, so what to do now? I cannot upgrade to 6.43.2 bootloader before reboot! Will it be bricked afterwards?

emils · Fri Sep 21, 2018 10:11 am

No, a reboot or upgrade will not brick the router. If your router works with 6.43.1, there is no need to upgrade to 6.43.2.

dadaniel · Fri Sep 21, 2018 10:31 am

No, a reboot or upgrade will not brick the router. If your router works with 6.43.1, there is no need to upgrade to 6.43.2.

Ok, so it isn't the bootloader that bricks the devices?
My log says "firmware upgrade successfully, please reboot..." so it hasn't been rebooted since 6.43.1 upgrade.

mducharme · Fri Sep 21, 2018 10:43 am

Ok, so it isn't the bootloader that bricks the devices?
My log says "firmware upgrade successfully, please reboot..." so it hasn't been rebooted since 6.43.1 upgrade.

I have the same question, I know a few people who have upgraded RouterOS but haven't necessarily rebooted a second time for the firmware update to take effect.

ssbaksa · Fri Sep 21, 2018 11:01 am

I have high CPU usage on switch which does nothing. Only up-link port is connected and nothing else. There is no rules except bridge, admin IP, default route, NTP client, and DNS server.

[admin@mtKO3-SW] /system resource> print
uptime: 22m23s
version: 6.43.2 (stable)
build-time: Sep/18/2018 12:12:48
free-memory: 42.6MiB
total-memory: 64.0MiB
cpu: MIPS 24Kc V8.5
cpu-count: 1
cpu-frequency: 400MHz
cpu-load: 20%
free-hdd-space: 110.5MiB
total-hdd-space: 128.0MiB
write-sect-since-reboot: 144
write-sect-total: 584632
bad-blocks: 0%
architecture-name: mipsbe
board-name: CRS226-24G-2S+
platform: MikroTik

Fri Sep 21, 2018 11:15 am

ssbaksa, what is in /tool profile?

CsXen · Fri Sep 21, 2018 11:27 pm

But frankly, the only thing they really need to do to remain compatible with old config's is an extra package that restores masterports
Why do you need master ports back? You get the same thing with a bridge

NO ! If I have 2 swich chip in my RB2011, and one is 100M, another is 1G, I can make 2 individual "switch". No influence one on another.
If I must do it in bridge, my max. speed will be 100M and NOT 1G on any port. I tested it on 6.40.9 (eth1 - uplink, eth2 - master port of 1G lans, simple NAT): I got 240+Mbps throughput on my ISP.
Other test with 6.42.7 (eth1 - uplink, all other ports on bridge with HW offloading): I got stable 100Mbps on my ISP. Bridge limited my speed to its slowest port speed!

So not having master ports, only one bridge for everything... is a big drawback for us.

CsXen · Fri Sep 21, 2018 11:53 pm

RouterBOARD 941-2nD 6.43.1, upgrade error 6.43.2 "not enough space for upgrade"

several attempts same error, after erasing files(files empty) same error
after attempt, routeros-smips-6.43.2.npk remains in files. reboot causes same error.
deleted routeros-smips-6.43.2.npk file and reboot the router works correct in 6.43.1

This is a quote from normis

#35
2016. May 25. (Wed), 07:05
Is MikroTik really publicly committing to never allowing the combo package to increase in size to the point where it does not fit on a 16MB device?
Do you seriously suggest that our own software will one day no longer run on our own devices?

Best regards: CsXen

B.G.: "640K ought to be enough for anybody"

mducharme · Sat Sep 22, 2018 1:22 am

NO ! If I have 2 swich chip in my RB2011, and one is 100M, another is 1G, I can make 2 individual "switch". No influence one on another.
If I must do it in bridge, my max. speed will be 100M and NOT 1G on any port. I tested it on 6.40.9 (eth1 - uplink, eth2 - master port of 1G lans, simple NAT): I got 240+Mbps throughput on my ISP.
Other test with 6.42.7 (eth1 - uplink, all other ports on bridge with HW offloading): I got stable 100Mbps on my ISP. Bridge limited my speed to its slowest port speed!

So not having master ports, only one bridge for everything... is a big drawback for us.

With a 2011, you can make two bridges with 6.42.7, one with 1G lans and one with 100M LANs, both should get hardware offloading as long as they don't include any ports from the other switch chip. Performance should be unchanged from the equivalent master port configuration on 6.40.9.

If however you had both master ports connected via a bridge on 6.40.9 already, the bridge connecting everything-except-ether1 on 6.42.7 should behave in the same way. If it doesn't, this may be a bug, not a shortcoming of the new design.

OldSwitchConfigLiker · Sat Sep 22, 2018 1:26 am

Why do you need master ports back?

Hi,

It is not so much that I do not like the efforts of MT to make it easier for everyone. And by now, I know how to reconfigure it too... I'm all for having a proper 1-fits-all easy bridge config, although I personally never felt the old switch config was to hard, albeit specific for each device type.
I do however have a problem with the potential unavailability of the "old ways", at least if it is decided from one day to the next without regards.

Moreover, it is the fact that reconfiguration is NEEDED that is my problem. To be more exact: the industries problem. (I'm just relaying the message so to speak)
If you use Mikrotik devices in a production environment, especially in the food&pharma where every programming change needs to be tested and validated, a change like the masterports->bridge will require reprogramming, and therefore needs to go through the re-validation process. Meaning a lot of testing, documenting and re-certifying. And so, cost a lot of money!
People who ever had to take (for instance) a GAMP course for their work, know what I mean.

In general, in a production environment, companies have no desire to do any reprogramming if it does not mean that it adds something badly needed for that environment. It would only cause useless expenses.
So if something just works with 6.40.xxx and it needs a security fix, the industry expects just that. And not the need for qualified engineers to be contracted to reprogram numerous Mikrotik devices, since 6.41+ just does not work anymore with the old config. (And "no", the auto-convert function did not yield the desired results in many cases)

Anyway, I'm glad to see that MT now understands the needs of production environments and hope they continue to do so from now on.

And I'm also absolutely aware that this may conflict with the desire to have the most beautiful RoS that there can be.
I guess it's all part of growing up as a company. MT has pushed forward to also supply very expensive equipment to the big-boys, and not just target enthusiasts-devices anymore. And that comes with it's very own set of requirements, and one of it is 'configuration stability'.
RouterOS fits in very well in that model, both <6.40.xx or >6.41.xx. As long as each version can be relied on of being supported for a few years, without serious extra investments along the way to keep it secure. Cisco has that, HP has that, Dell and Juniper has that.... just to name a few...

And one way that would make it possible, if it is (from MT point of view) undesirable to keep many 'long term' versions in parallel, is to create a .npk with the removed functionality.
That is why I mentioned the package as a potential solution. Since it would avoid extensive reprogramming in existing environments, while keeping only ONE main "long term" branch alive.
That package would solve the issue for the industry, and RoS would remain state of the art for the rest of the community.

So it's not specific for the masterports-change per se, but more in general as a 'way of working' for MT. But the changeover from masterports to bridges was such a fundamental change that I basically use it as baseline to try to get this 'general point' of configuration stability across.
The masterport-change is however the no.1 reconfiguration issue I run into in production situations. Any previous MT changes were less impacting so far.
If MT would decide the current "long term" 6.40.xx line really is only for a few months (so actually more "short term"), I foresee many of these new big customers moving back to the more conventional suppliers the next time network hardware is needed.
And that would be a pity.

Few months ago I tried getting this point across here in the forum, but (almost) nobody understood or cared enough to agree....
When I see reason somewhere in a post to reiterate this point, I will. So I did that in my original reply.
But there is no need to make it into a "is-too is-not" kind of discussion. Everybody may feel about it as they wish. And it's not the place in this thread here.
I'm just relaying concerns I know already exist in the industry regarding MT long term strategies.

Yet, MT DOES still have a 6.40.xx as long term now, and I'm very glad they do!!
(I however do not pretend to be the reason for that fact. I'm sure they probably already understood the importance of that themselves, and are struggling with it too to keep everybody happy)

OldSwitchConfigLiker · Sat Sep 22, 2018 2:17 am

Why do you need master ports back?

Hi MduCharme,

I realize that it might be somewhat unclear why I take masterports and switch-config as a candidate in one legacy package.

In the past in the early public testing of the new bridge model (I believe it was 6.37rc or 6.38rc) it was stated that, because of the perceived complexity of the switch-config and the relation to masterports on that chip, MT would make efforts to make one new bridge model for both. One that would be the same for all MT devices, and no longer specific to the type of RB.
This was put in effect in 6.41, where some new types of RB no longer had a switch chip config.

Realizing that this had an impact on the functionality of those types (now lacking some features other types did have, and features that were available in hardware) MT added the switch menus again.
But in doing so, negating most of their original goal of creating a universal solution, since switch-config is still highly hardware dependent.
I'm pretty sure MT did not bury this goal just yet, they just weren't quite ready.

As such, since the bridge still can't do many things the switch-menu CAN, you still need the switch config as you clearly explained.
But also, I do expect this to be just a matter of time. As soon as they add this functionality to the bridge to form a universal solution, I fear the switch-menu will disappear.
From that moment onwards, configurations made with a configured switch-chip menu (vlan's, port mirroring etc) will need to be reprogrammed in the scripts to work in the bridge, which constitutes problems for production-environments I outlined in the other post.

That is why I basically see the two (masterports and switch-menu) as one. And both together as a candidate for a .npk after both dissappear.

But currently, if one would start a NEW config with vlan and hardware assist, it is indeed perfectly possible to do so in a bridge+switch-menu config.
You're absolutely correct about that.

ozone · Sat Sep 22, 2018 3:51 am

On Thu Sep 13, I reported in the 6.43 thread that after upgrading hap-lite to 6.43, it would no longer accept ipv4 addresses from our dnsmasq dhcpv4 server.
On the HAP-ac it did seem to work fine, as well as on all 6.42.6 and .7 RoS's before it on any RB.

Yesterday I upgraded out test Hap-ac to 6.43.2 (skipped 6.43.1), and now it too does not accept ipv4 addresses anymore from the dnsmasq dhcpv4 server.

Before spitting it out here on the forum, I first asked the admin of the dhcpv4 server if there were any specifics on his servers.
The answer was basically "no", accept for 5 extra dhcp options. I personally do not know what the reason was to add them, but apparently it was needed somehow.

Adding those exact 5 options to the routerboard DHCP-client options list, would fix the problem, and now RB successfully receives ipv4 leases from the dnsmasq-server.

All fine and well... But the million dollar question remains:
WHY do all previous versions of routeros (and all windows and linux clients we have) accept the dnsmasq dhcp-leases, but starting from 6.43 they do not anymore?
What changed in the DHCPv4 client of RoS6.43?

brg3466 · Sat Sep 22, 2018 5:33 am

Upgraded to 6.43.2 on CCR1009 (running CAPsMAN), but cannot upgrade the 5 cAPac with 6.42.7 ( running as CAP). Downloaded the OS and put under the /pub in CPAsMAN, then in CAPsMAN> Remote CAP, click upgrade, it doesn't work.

mducharme · Sat Sep 22, 2018 6:53 am

So if something just works with 6.40.xxx and it needs a security fix, the industry expects just that. And not the need for qualified engineers to be contracted to reprogram numerous Mikrotik devices, since 6.41+ just does not work anymore with the old config. (And "no", the auto-convert function did not yield the desired results in many cases)

It may be easier and more realistic to lobby them to improve the auto-convert function instead of keeping 6.40.xxx around forever, or adding an .npk to re-add master port function (which maybe sounds easy but I doubt would be that easy to code, and it becomes much easier to get the auto-convert more bulletproof for unusual configs).

I do not personally know what MikroTik's plans are in this regard, but I would caution against reading too much into the "bugfix-only" being renamed "long-term" as having anything to do with a long term continuation of the 6.40.x software, unless they have made a specific announcement in this regard. Yes, 6.40.x is still in the bugfix-only tree, but it is pretty common if you dig back to see that the bugfix-only firmware is typically two or three versions behind the current release, and so the situation we have now is not that unusual.

pe1chl · Sat Sep 22, 2018 10:46 am

What we need is a version that can auto-convert existing configurations that use a combination of master-port, VLAN subinterfaces on that master port, and switch configuration for tagged/untagged VLAN on the ports,
into a new configuation with a single bridge with VLAN filtering and full hardware acceleration just like the above configuration always had.

(i.e. the VLAN-filtering bridge just invisibly configures the switch chip for configurations where is is possible, and for simple VLAN tagging/untagging it clearly is possible because that works fine up to 6.40)

mkx · Sat Sep 22, 2018 11:13 am

What we need is a version that can auto-convert existing configurations that use a combination of master-port, VLAN subinterfaces on that master port, and switch configuration for tagged/untagged VLAN on the ports,
into a new configuation with a single bridge with VLAN filtering and full hardware acceleration just like the above configuration always had.

What we need is ROS version that fully HW offloads everything that underlying HW supports.

Only after that we will actually need auto-coversion functionality. My fear, though, is that the afore-mentioned all-HW-offload version will come so late thate there won't be enough adventurous users still running 6.40.x to thoroughly test the auto-conversion and thus the conversion will fail on some (more or less mission critical) setups making MT look bad (yet again).

pe1chl · Sat Sep 22, 2018 11:50 am

What we need is ROS version that fully HW offloads everything that underlying HW supports.

Well, I would be satisfied with the common scenario described above. There are so many obscure filter possibilities in some of the switch chips that probably nobody uses, that it would be too much work to move those all into the new bridge functionality.

But simple VLAN tagging/untagging in a config without spanning tree or bridge-level IP filtering should be simple enough to support, and in fact I always assumed during the 6.41RC development that this would be part of the finally released version. Then 6.41 went out without accelerated VLAN support, and now chances that it is ever going to be fixed become slimmer and slimmer.

Fortunately in most scenarios we have external switches connected to MikroTik routers so we have a way to migrate away from using MikroTik equipment as a switch...
But still...

ssbaksa · Sat Sep 22, 2018 12:33 pm

ssbaksa, what is in /tool profile?

@andriys

Strange! After changes form switch without any rules to switch with VLANs usage fell down. I must check another switch with this strange high usage.

[admin@mtKO3-SW] > /tool profile
NAME CPU USAGE
console 1%
networking 2%
winbox 0%
logging 0%
management 3.5%
profiling 1%
telnet 1%
bridging 0.5%
unclassified 3.5%
total 12.5%

mkx · Sat Sep 22, 2018 12:50 pm

While generally I agree with pe1chl I still think that vast majority of things that switch chips are capable of doing should be HW offloaded before "legacy" way of configuring them gets murdered. Problem is that as soon one configures one simple thing which is not HW offloaded, all HW offload stops and performance of the whole box drops to lowest level of underground.
Example (and I'm not sure if you can do it on SW bridge): port mirroring. Some switches can do it and some can not. While one had to configure it via switch chip settings, if it wasn't supported, it couldn't be configured and thus it didn't work. Period. If one is using modern bridge with HW offload enabled (e.g. simple port switching without VLANs and other bells and whistles) and configures port mirroring (again: I don't know if it's possible), she will get port mirrored but will loose all switching performance ... which in turn might change behaviour of device under investigation so much that symptoms, which made administrator to enable port mirroring, become completely obfuscated and whatever investigation might render results unrelated to reality.

nordex · Sun Sep 23, 2018 12:33 am

DO NOT upgrade it on 2011.
Bricked one from 43 to 43.2., me too.
Remote destination...tommorow will be looong day.

mducharme · Sun Sep 23, 2018 1:09 am

DO NOT upgrade it on 2011.
Bricked one from 43 to 43.2., me too.
Remote destination...tommorow will be looong day.

It is probably not the 43 to 43.2 upgrade that did it, but instead, the routerboot firmware upgrade for 43. If you didn't reboot a second time after 6.43, the routerboot upgrade would not take place until the following reboot, which is probably by happenstance when you rebooted to upgrade to 6.43.2.

OldSwitchConfigLiker · Sun Sep 23, 2018 7:30 am

I do not personally know what MikroTik's plans are in this regard, but I would caution against reading too much into the "bugfix-only" being renamed "long-term" as having anything to do with a long term continuation of the 6.40.x software, unless they have made a specific announcement in this regard.

Hi MduCharme

The renaming of the bugfix branch into long-term, just makes me a little hopeful

When I first posted my concerns, 6.41 wasn't even out as "current/stable". It was still in 6.41rc (testing).
But it was clear where MT was going with the bridge. Also they did not have a very good track record of keeping the bugfix-versions for long.
That's basically what made me do the post back then.

Today, 6.40.xxx can indeed be discarded at any time since it's already pretty old (measured against their previous lifecycles). But doing so would make their new title "long term" a little ludicrous.
A more serious "longer term" would be at least a few years of configuration stability.
This in itself does not mean keeping 6.40 indefinitely. It can ALSO mean some other way of still supporting the original config scripts, preferably without (auto)converting them (since this would mean re-certification in certain cases).
This is not at all unique in the industry. Eg., since Microsoft changed their update model with Windows10, they too added an LTSB edition to cater production environments....

I do not have real insight in MT's kitchen, but it at least 'seems' that they are becoming more sensitive to longer-term stability then the were before. And that makes me cautiously optimistic.
I hope I won't be disappointed....
And frankly, how they do it, makes no difference. (I just expressed how it seems to me to be easiest way for them)

mducharme · Sun Sep 23, 2018 7:40 am

It can ALSO mean some other way of still supporting the original config scripts, preferably without (auto)converting them (since this would mean re-certification in certain cases).

Almost every major version they have released lately has brought about config changes that, unless they are auto-converted by the upgrade process, prevents an older config from being loaded into a newer version router. Even simple changes like moving to interface lists for the MAC server / IP neighbor discovery lists breaks direct compatibility with old documented configs. These changes are unrelated to the new bridge code. There may be more re-certification needed already than is generally realized.

OldSwitchConfigLiker · Sun Sep 23, 2018 7:45 am

I agree with most of the points being made here, at least in a technical sense.

Sequentially:
1) First MT needs to add all current options into the bridge-menu, without disabling them in the switch-menu.
2) After "1", as 2nd step a proper (auto)conversion must be created (although there can be SOOOO many different configurations out there it will never work in all cases)
3) And after "2", a transition period should be organized (let's say 3-5 release versions) where it is released to the masses (many users don't even run rc's, or just stick with a certain version for over a year, so you need more time here to get proper new-feature-penetration).
This way the kinks can be properly be ironed out, instead of serving everyone with a buggy/incomplete version that we unfortunately seen all to often recently.

Only then can they start thinking of "murdering" the old options.
And even so, I would do the "assassinating" in phases... eg. first remove it in Webif and Winbox for again a few more release versions, but leave it in the CLI. (this way old scripts at least still work, but new users will most likely stop using it)

With all these phased steps and overlaps, almost automatically you get a grace period of "the old ways" of a few years...
(just thinking out loud here)

But all that is "the tech" part of me talking... But in the many years in the business I now sometimes have to wear a second hat.
And if I let the company-representative in me do the talking, the above might still be to progressive and uncertain.
I doubt if the pure company-guy in me should honestly advise in favor of a new MT purchase, if it's not absolutely clear that investments are going to be safe for a few years.... I know for a fact that this is a genuine concern at many companies.

The tech guy in me LOVES the Routerboards. But sometimes one needs to be upfront about why you choose a Routerboard device. And if it is for a business that needs it for certain purposes, current MT strategies just might not be best suited for it in the long run.
Even if the RB-device can do it, and even though RB is definitely an amazing piece of kit from an engineers point of view.

Ultimately it's up to MT to decide if they are serious about committing to this target group, or just stick with being an engineers dream.

OldSwitchConfigLiker · Sun Sep 23, 2018 7:59 am

Almost every major version they have released lately has brought about config changes that, unless they are auto-converted by the upgrade process, prevents an older config from being loaded into a newer version router. Even simple changes like moving to interface lists for the MAC server / IP neighbor discovery lists breaks direct compatibility with old documented configs. These changes are unrelated to the new bridge code. There may be more re-certification needed already than is generally realized.

Yes that's true.....
But it's no reason to ignore certain problems "just" converting something may create in the field. And the potential consequences of it.
Even if, in itself, it is a great idea.
Just one more reason to pursue certain feature-frozen versions imho.

Funny that you bring up this exact example ... as it was an issue I noticed on some devices suddenly not being able to be winboxed anymore.
The autoconvert hadn't worked just as it should have been working...

OndrejHolas · Sun Sep 23, 2018 11:57 am

It is probably not the 43 to 43.2 upgrade that did it, but instead, the routerboot firmware upgrade for 43. If you didn't reboot a second time after 6.43, the routerboot upgrade would not take place until the following reboot, which is probably by happenstance when you rebooted to upgrade to 6.43.2.

My RB912UAG-2HPnD (cpu: MIPS 74Kc V4.12, fw type: ar9340) was bricked by ROS update from 6.43.1 to 6.43.2:

ROS 6.42.7, fw 6.42.7: uploaded 6.43 packages, /sys reb - OK
ROS 6.43, fw 6.42.7: /sys rou up, /sys reb - OK
...a few days later...
ROS 6.43, fw 6.43: uploaded 6.43.1 packages, /sys reb - OK
ROS 6.43.1, fw 6.43: /sys rou up, /sys reb - OK
...a few days later...
ROS 6.43.1, fw 6.43.1: uploaded 6.43.2 packages, /sys reb - BRICKED

Recovered the box by Netinstall (installed 6.43.2 packages), then completed the firmware upgrade, downgraded both ROS and fw back to 6.43.1 and repeated the failed step:

ROS 6.43.2, fw 6.43.1: /sys rou up, /sys reb - OK
ROS 6.43.2, fw 6.43.2: uploaded 6.43.1 packages, /sys pack down - OK
ROS 6.43.1, fw 6.43.2: /sys rou up, /sys reb - OK
ROS 6.43.1, fw 6.43.1: uploaded 6.43.2 packages, /sys reb - BRICKED

Netinstall again, 6.43.2 packages. Another experiment:

ROS 6.43.2, fw 6.43.1: /sys rou up, /sys reb - OK
ROS 6.43.2, fw 6.43.2: uploaded 6.43.1 packages, /sys pack down - OK
(contrary to the first experiment, here I skipped firmware downgrade 6.43.2->6.43.1)
ROS 6.43.1, fw 6.43.2: uploaded 6.43.2 packages, /sys reb - OK

Thus in my case the problem occurs when upgrading ROS packages and the firmware is exacly 6.43.1.

Ondrej

CZFan · Mon Sep 24, 2018 4:21 pm

Note sure if someone has mentioned this before, if so, apologies for reposting

Current TX Power = 0dBm

board-name: hAP ac^2
model: RBD52G-5HacD2HnD
firmware-type: ipq4000L
factory-firmware: 3.43
current-firmware: 6.43.1
upgrade-firmware: 6.43.1

Current TX Power.JPG

Mon Sep 24, 2018 7:24 pm

Current TX Power = 0dBm

Current TX power readings are not supported for 802.11ac-capable wireless cards. That's a known (and documented!) limitation that has always been there.

CZFan · Mon Sep 24, 2018 7:40 pm

Current TX Power = 0dBm
Current TX power readings are not supported for 802.11ac-capable wireless cards. That's a known (and documented!) limitation that has always been there.

My post is on the 802.11b/g/n WLAN card

Can you provide link to the documentation, want to go read up a bit more

Mon Sep 24, 2018 7:57 pm

Can you provide link to the documentation

Look at the very bottom of this wiki page (in the "Winbox" section).

CZFan · Mon Sep 24, 2018 8:02 pm

Can you provide link to the documentation
Look at the very bottom of this wiki page (in the "Winbox" section).

Got it, thx.

I think it should rather be placed under headings for TX power, not right, right at the bottom of the document under some willy nilly comment about Winbox.

bennyh · Tue Sep 25, 2018 8:54 am

I have MTU problem with IPIPv6 in these and older ROS releases too. There is IPsec encrypted IPIPv6 tunnel between 3011 and 750gr3, if I change the proposal auth method from SHA1 to SHA256, the MTU is changing, but the clamp MSS option doesnt work and all TCP connection is broken (HTTP, Winbox) till I make postrouting TCP MSS changing rules, where I lower the MSS, then It semms the TCP connections ar workable again (but IPV6 stay broken, because a cant made IPv6 change MSS rules, no options to check the MSS value in IPv6 firewall, there are greyed sections at rules).

Tue Sep 25, 2018 10:10 am

Rather then doing MSS clamping you'd better fix your firewall to allow PMTUD to function properly across your tunnel...

kos · Tue Sep 25, 2018 10:26 am

Since ROS 6.43 there are entries setting ethernet speed to 100Mbps for every cooper not auto negotiated interface on every MT device. Is it normal?
.....
set [ find default-name=ether5 ] speed=100Mbps
set [ find default-name=ether6 ] speed=100Mbps
set [ find default-name=ether7 ] speed=100Mbps
.....

bennyh · Tue Sep 25, 2018 10:40 am

Rather then doing MSS clamping you'd better fix your firewall to allow PMTUD to function properly across your tunnel...

And how? There is nothing blocked between two router and two sites, ICMP goes trough freely from one site to other. What sould I do? It looks like, the PMTU discovers wrong MTU value.

saaremaa · Tue Sep 25, 2018 2:06 pm

Is there any information on correcting the error "Delegated-IPv6-Prefix" attribute for PPPoE?
viewtopic.php?f=1&t=89443&start=100#p687190
viewtopic.php?f=1&t=89443&start=100#p687516
viewtopic.php?f=1&t=89443&start=100#p687867

thg3x · Tue Sep 25, 2018 4:40 pm

Is there any information on correcting the error "Delegated-IPv6-Prefix" attribute for PPPoE?
viewtopic.php?f=1&t=89443&start=100#p687190
viewtopic.php?f=1&t=89443&start=100#p687516
viewtopic.php?f=1&t=89443&start=100#p687867

Waiting too !

mducharme · Tue Sep 25, 2018 8:22 pm

Is there any information on correcting the error "Delegated-IPv6-Prefix" attribute for PPPoE?

The problem is bigger than just the Delegated-IPv6-Prefix - from my testing, DHCPv6 prefix delegation is basically entirely broken, at least with PPP connections, whether or not RADIUS is used. Only if there is a static DHCPv6 binding will DHCPv6 prefix delegation work with PPP connections in 6.43.xx. We can't really tell if there is a problem with the Delegated-IPv6-Prefix RADIUS attribute until this issue is fixed.

mkx · Tue Sep 25, 2018 9:11 pm

Since ROS 6.43 there are entries setting ethernet speed to 100Mbps for every cooper not auto negotiated interface on every MT device. Is it normal?
.....
set [ find default-name=ether5 ] speed=100Mbps
set [ find default-name=ether6 ] speed=100Mbps
set [ find default-name=ether7 ] speed=100Mbps
.....

This was always set like this (you could verify it by checking output of /interface ethernet print). It is now shown in export because default setting starting with 6.43 is 1Gbps ... upgrade does not change settings and export shows differences from default. The value does not apply when autonegotiation is enabled... which is default as well.

BTW you can set speed to 1Gbps even if underlying interface hardware is 100Mbps only (e.g. on hAP ac lite).

bennyh · Wed Sep 26, 2018 11:46 am

Rather then doing MSS clamping you'd better fix your firewall to allow PMTUD to function properly across your tunnel...

Today I checked all my firewall rules (IPv6 and IPv4 too), I disabled some rules, that may have negative aftermaths, but these rules only touched that interfaces between them the tunnel is created on (end interfaces of 2 WWAN connection bridged trough unsafe switch in a tower). Inside the tunnel and on tunnel interfaces there is no blocking rules, all input output and forward allowed.
The problem still exists.
If I change the keying method from SHA1 to SHA256, the IPIPv6 reconnect and after thet the new TCP connections are broken, but ping works.
What next now?

Kraken2k · Wed Sep 26, 2018 12:36 pm

I found a strange behavior about bridges - might be only WinBox issue but still...

I have two bridges in my config - when I create bridge, MAC address is automatically assigned (I never use administrative MACs, or create bridges by Copy) and these are unique. But since the moment, when I assign a port to the bridge, Winbox shows the same MAC for both bridges.

in configuration, there is no sign of that addresses (not even in the whole device config export):

/interface bridge
add arp=proxy-arp comment=LAN fast-forward=no name=bridge-lan
add fast-forward=no name=bridge1

Device is RB1100AHx2 with RoS and RB firmware upgraded to 6.43.2

Wed Sep 26, 2018 12:48 pm

If I change the keying method from SHA1 to SHA256, the IPIPv6 reconnect and after thet the new TCP connections are broken, but ping works.
What next now?

Check if the MTU settings on your tunnel interfaces are correct. In case you rely on RouterOS to calculate it automatically try setting it to the correct value manually (I'm not even sure RouterOS can calculate it correctly in all possible tunneling/encapsulation scenarios).

bennyh · Wed Sep 26, 2018 2:29 pm

If I change the keying method from SHA1 to SHA256, the IPIPv6 reconnect and after thet the new TCP connections are broken, but ping works.
What next now?
Check if the MTU settings on your tunnel interfaces are correct. In case you rely on RouterOS to calculate it automatically try setting it to the correct value manually (I'm not even sure RouterOS can calculate it correctly in all possible tunneling/encapsulation scenarios).

Which values are correct for IPIPv6 MTU trough 802.11 with SHA256+AES256 IPSec? Now there is nothing set for MTU, the Actual MTU with SHA1 is 1414, with SHA256 is 1410 .

pe1chl · Wed Sep 26, 2018 2:52 pm

You can always set it lower than strictly required, e.g. 1400 or 1300

mkx · Wed Sep 26, 2018 3:12 pm

I found a strange behavior about bridges - might be only WinBox issue but still...

Can you post output of command /interface bridge export? Just to check if there's something weird.

Kraken2k · Wed Sep 26, 2018 4:04 pm

I found a strange behavior about bridges - might be only WinBox issue but still...
Can you post output of command /interface bridge export? Just to check if there's something weird.

Here is the output - bridge1 was only created to demonstrate this, and there is only one interface included atm. Yes, I'm aware that vlan filtering is inactive in this configuration - the thing is that after upgrade and removing the second bridge the vlan filtering rules (that so far worked as expected) suddenly blocked all traffic, even if removing second bridge should not definitely affect the operation of the first one:

/interface bridge
add arp=proxy-arp comment=LAN fast-forward=no name=bridge-lan
add fast-forward=no name=bridge1
/interface bridge port
add bridge=bridge-lan interface=ether2
add bridge=bridge-lan interface=ether4
add bridge=bridge-lan interface=ether5
add bridge=bridge-lan interface=ether1
add bridge=bridge-lan interface=ether6
add bridge=bridge1 interface=vlan100-remote1
add bridge=bridge-lan frame-types=admit-only-vlan-tagged interface=ether3-tst pvid=10
add bridge=bridge-lan interface=ether7 pvid=20
add bridge=bridge-lan interface=ether8 pvid=10
add bridge=bridge-lan interface=ether9 pvid=10
/interface bridge settings
set allow-fast-path=no
/interface bridge vlan
add bridge=bridge-lan comment=A tagged=ether1,ether2,ether6,ether4,ether5 vlan-ids=30
add bridge=bridge-lan comment=M tagged=ether4,ether5,ether1,ether2,ether6,ether3-tst vlan-ids=10
add bridge=bridge-lan comment=S tagged=ether6 untagged=ether7 vlan-ids=20
add bridge=bridge-lan comment=G tagged=ether4,ether5,ether2 vlan-ids=60
add bridge=bridge-lan comment=TST tagged=ether6 vlan-ids=70
add bridge=bridge-lan comment=R1 tagged=ether6-server vlan-ids=100

mkx · Wed Sep 26, 2018 4:33 pm

I was hoping to see actual configuration ... better yet, post output of /inteface bridge print, /interface bridge port print and /interface ethernet print ... it would be interesting to see where MAC of both bridges comes from.

Kraken2k · Wed Sep 26, 2018 5:58 pm

I was hoping to see actual configuration ... better yet, post output of /inteface bridge print, /interface bridge port print and /interface ethernet print ... it would be interesting to see where MAC of both bridges comes from.

Here - MACs seems to be originated from ether1 default MAC address:

/interface bridge> print
Flags: X - disabled, R - running 
 0 R ;;; LAN
     name="bridge-lan" mtu=auto actual-mtu=1500 l2mtu=1598 arp=proxy-arp arp-timeout=auto mac-address=D4:CA:6D:41:F5:CA protocol-mode=rstp fast-forward=no 
     igmp-snooping=no auto-mac=yes ageing-time=5m priority=0x8000 max-message-age=20s forward-delay=15s transmit-hold-count=6 vlan-filtering=no dhcp-snooping=no 

 1 R name="bridge1" mtu=auto actual-mtu=1500 l2mtu=1594 arp=enabled arp-timeout=auto mac-address=D4:CA:6D:41:F5:CA protocol-mode=rstp fast-forward=no igmp-snooping=no 
     auto-mac=yes ageing-time=5m priority=0x8000 max-message-age=20s forward-delay=15s transmit-hold-count=6 vlan-filtering=no dhcp-snooping=no 

/interface bridge port print
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload 
 #     INTERFACE                                              BRIDGE                                              HW  PVID PRIORITY  PATH-COST INTERNAL-PATH-COST    HORIZON
 0   H ether2                                                 bridge-lan                                          yes    1     0x80         10                 10       none
 1   H ether4                                                 bridge-lan                                          yes    1     0x80         10                 10       none
 2   H ether5                                                 bridge-lan                                          yes    1     0x80         10                 10       none
 3   H ether1                                                 bridge-lan                                          yes    1     0x80         10                 10       none
 4   H ether6                                                 bridge-lan                                          yes    1     0x80         10                 10       none
 5     vlan100-remote1                                        bridge1                                                    1     0x80         10                 10       none
 6   H ether3                                                 bridge-lan                                          yes   30     0x80         10                 10       none
 7   H ether7                                                 bridge-lan                                          yes   20     0x80         10                 10       none
 8   H ether8                                                 bridge-lan                                          yes   10     0x80         10                 10       none
 9   H ether9                                                 bridge-lan                                          yes   10     0x80         10                 10       none

/interface ethernet print
Flags: X - disabled, R - running, S - slave 
 #    NAME                                                             MTU MAC-ADDRESS       ARP             SWITCH                                                         
 0 RS ;;;  
      ether1                                                          1500 D4:CA:6D:41:F5:CA enabled         switch2                                                        
 1 RS ;;; 
      ether2                                                          1500 D4:CA:6D:41:F5:CB enabled         switch2                                                        
 2 RS ;;; 
      ether3                                                          1500 D4:CA:6D:41:F5:CC enabled         switch2                                                        
 3 RS ;;; 
      ether4                                                          1500 D4:CA:6D:41:F5:CD enabled         switch2                                                        
 4 RS ;;; 
      ether5                                                          1500 D4:CA:6D:41:F5:CE enabled         switch2                                                        
 5 RS ;;; 
      ether6                                                          1500 D4:CA:6D:41:F5:CF proxy-arp       switch1                                                        
 6 RS ;;; 
      ether7                                                          1500 D4:CA:6D:41:F5:D0 enabled         switch1                                                        
 7 RS ;;;
      ether8                                                          1500 D4:CA:6D:41:F5:D1 enabled         switch1                                                        
 8 RS ;;;
      ether9                                                          1500 D4:CA:6D:41:F5:D2 enabled         switch1                                                        
 9 X  ether10                                                         1500 D4:CA:6D:41:F5:D3 enabled         switch1                                                        
10 R  ;;; WAN
      ether11-wan                                                     1500 D4:CA:6D:41:F5:D4 enabled        
11 X  ether12                                                         1500 D4:CA:6D:41:F5:D5 enabled        
12 X  ether13                                                         1500 D4:CA:6D:41:F5:D6 enabled

Kraken2k · Wed Sep 26, 2018 6:30 pm

I was hoping to see actual configuration ... better yet, post output of /inteface bridge print, /interface bridge port print and /interface ethernet print ... it would be interesting to see where MAC of both bridges comes from.

It seems that bridge gets it's MAC automatically from the first port connected to it - dynamically changing this whenever the config change is made.... okay, tl;dr; probably my mistake with configuration.

I think I see the problem: routing vs. bridging configuration:

/interface vlan> print
Flags: X - disabled, R - running 
 #   NAME                                     MTU ARP             VLAN-ID INTERFACE                                 
(output omitted)
 7 R ;;; R1
     vlan100-remote1                         1500 enabled             100 bridge-lan

router interface vlan100-remote1 has been defined on bridge-lan in router configuration, but later added to bridge1 which caused strange behavior (including strange traffic flow over the LAN).

So "MAC flow" was ether1 -> bridge-lan -> vlan100-remote1 -> bridge1

*sigh* I need some rest.

Wed Sep 26, 2018 7:46 pm

It seems that bridge gets it's MAC automatically from the first port connected to it - dynamically changing this whenever the config change is made....

This is actually a documented behavior...

2jarek · Wed Sep 26, 2018 7:49 pm

Again in6.43.2 Nv2 frame priority qos works very poorly for dynamic downlink. For fixes downlink or sync master works fine.

Kraken2k · Wed Sep 26, 2018 8:59 pm

It seems that bridge gets it's MAC automatically from the first port connected to it - dynamically changing this whenever the config change is made....
This is actually a documented behavior...

Yes, it is... I just had no idea, how two bridges managed to get the same MAC dynamically. Now I know - my mistake, case closed.

arneh00 · Wed Sep 26, 2018 9:28 pm

Hello every one I just update my microtik os and i can not reach from outside to my internal network, actually when I trace my internal network address from outsite it comes till my internet ip address which is set on microtik but doesnt reach my local network, can any one help please.

ziegenberg · Wed Sep 26, 2018 9:47 pm

Hello every one I just update my microtik os and i can not reach from outside to my internal network, actually when I trace my internal network address from outsite it comes till my internet ip address which is set on microtik but doesnt reach my local network, can any one help please.

Do you have an public IPv4 address for your internal network?

arneh00 · Thu Sep 27, 2018 7:21 am

My internal network ip rage is 192.168.1.x , I dont know what you mean by public IPV4 address

sindy · Thu Sep 27, 2018 8:52 am

Did it work before upgrade to 6.43.2? If not, create a new topic and export your configuration there; if it did, create a new topic with a configuration export anyway and place a link to it here. Accessing the (private) address range which you use on LAN via the Internet is normally only possible by means of VPN, so something important must be missing in your description.

bennyh · Thu Sep 27, 2018 8:59 am

You can always set it lower than strictly required, e.g. 1400 or 1300

Ok, it seems work with 1400 (I tried with Actual MTU 1410 too but TCP failure trough tunnel), if I set this value at booth ends, but with SHA1 such thing didnt need, it looked like actual MTU worked right without MTU settings.

pe1chl · Thu Sep 27, 2018 9:07 am

Well, when you think the default values are not good enough for you it always could mean you need to study the matter to
know the result of changing encryption lengths or hash methods. I happily run everything at the default SHA1/AES128 and
I am not too worried that the theoretical weaknesses will actually be exploited by someone...

bennyh · Thu Sep 27, 2018 9:59 am

Well, when you think the default values are not good enough for you it always could mean you need to study the matter to
know the result of changing encryption lengths or hash methods. I happily run everything at the default SHA1/AES128 and
I am not too worried that the theoretical weaknesses will actually be exploited by someone...

For SHA256: A clever latin guy said once in the far past: Si vis pacem, para bellum, and Google said, SHA1 is breakable (but expensive), so If the HW engine can accelerate SHA256, why we dont use?
The ROS is changing the actual MTU if I change the method, but it semms there is some sh*t in pancake, as we say it. Ok I am not a professionel in tunnelling and crypting techniques, but If a Mikrotik document doesnt write other (please link it for me if exists), It should work, but it doesnt. Thats it, should be fix.

Thu Sep 27, 2018 12:14 pm

The ROS is changing the actual MTU if I change the method, ... , but If a Mikrotik document doesnt write other (please link it for me if exists), It should work, but it doesnt.

The IPIP wiki page says the default is 1500. Nothing is said about MTU being automatically/dynamically adjusted, so I assume no automatic adjustment ever happens. Though I'd still expect it to work happily (though not fully efficiently) even with the default MTU of 1500, unless you set dont-fragment interface property to yes.

pe1chl · Thu Sep 27, 2018 12:44 pm

The tunnel interfaces have a manually adjustable MTU that may default to 1500, but once they are installed and up they have an "actual MTU" which is automatically set to 1500 minus the tunnel overhead for that type of tunnel (sometimes a bit lower: when the header actually has a variable size it is set according to the maximal size of that header, even when it really cannot increase to that size with the functionality that RouterOS offers).
So when you create an IPIP tunnel and don't set the MTU, it will set an actual MTU of 1480 (correct).

However, this calculation apparently fails when IPsec is configured with nondefault hash/encrypt selection. So the "overhead of IPsec" was likely only calculated for the default case.
Note that it fails as well when the outer packets are routed through an interface that does not have MTU 1500 (e.g. PPPoE).
There is apparently no dynamic adjustment of the "actual MTU" based on MTU of the outgoing route, or returned ICMP "size exceeded" messages.
So in such cases you need to manually set a lower MTU on the tunnel interface.

andronovDmitriy · Fri Sep 28, 2018 3:57 am

Problem firmware 6.43 - 6.43.2.
Multiple gre with ipsec unreachable with new dynamic peer.
Because router os no distinction is made between peers with different
local addresses to one remout address.

I was able to start gre from the second local address only manually create peer and set passive mode.

sindy · Fri Sep 28, 2018 11:46 am

Problem firmware 6.43 - 6.43.2.
Multiple gre with ipsec unreachable with new dynamic peer.
Because router os no distinction is made between peers with different local addresses to one remout address.

Dmitriy, are you 100% sure that it did work different before 6.43? If yes, send your observations to support@mikrotik.com together with a supout.rif file; if not, create a separate topic in General section of the forum because in such case this one would not be the right topic to discuss it.

kelner · Fri Sep 28, 2018 2:18 pm

On v.6.43.[12] RADIUS authentication at login does not work on my routers. It worked well on v.6.42 though. Does anybody has such problem too?

Fri Sep 28, 2018 2:19 pm

search.php?keywords=radius+6.43

kelner · Fri Sep 28, 2018 2:50 pm

search.php?keywords=radius+6.43

Thank you!
Adding "mschap" into freeradius' config file radiusd.conf looks like the solution.

authorize {
files
mschap
}

authenticate {
mschap
}

mducharme · Fri Sep 28, 2018 11:41 pm

It has now been nearly three weeks since 6.43 was released and DHCPv6 PD server over PPP is still completely broken, preventing all PPP clients from getting IPv6. Is a fix coming soon? It is a rather critical issue.

jasonx · Sat Sep 29, 2018 3:54 pm

the problem with the ipv6 dhcp server continues, in bindings does not work in version 6.43.2

sophitus · Sun Sep 30, 2018 2:01 pm

My hap ac has still memory leak and crashes even in 6.43.2 not really stable

kernel failure in previous boot
out of memory condition was detected

mducharme · Mon Oct 01, 2018 2:46 am

My hap ac has still memory leak and crashes even in 6.43.2 not really stable

kernel failure in previous boot
out of memory condition was detected

I also have instabilities with my hap AC, crashing every week, although I wasn't graphing memory usage before so I can't be sure there is a leak on mine. I've just set up the graphing to try to see.

sophitus · Mon Oct 01, 2018 3:00 pm

My hap ac has still memory leak and crashes even in 6.43.2 not really stable

kernel failure in previous boot
out of memory condition was detected
I also have instabilities with my hap AC, crashing every week, although I wasn't graphing memory usage before so I can't be sure there is a leak on mine. I've just set up the graphing to try to see.

Reverted to 6.42.7 and no related crashes anymore, with 6.43.2 I had daily out of memory crashes....

Vovanys · Mon Oct 01, 2018 11:28 pm

hAP ac
After update to 6.43.2 (stable)
system,error,critical router was rebooted without proper shutdown by watchdog timer
This happened several times already.
Before this year no reboots

dziku2 · Wed Oct 03, 2018 9:44 pm

On hAP ac2 is similar problem. Unexpected reboots every 2h to 48h. I sent description of problem to Mikrotik support.

mkx · Wed Oct 03, 2018 9:52 pm

My experience on hAP ac2: very unstable, plenty of watchdog reboots (most of them due to ping timeouts, pinged address is linux server on LAN).
For me instability is regression from 6.42.9.

mducharme · Thu Oct 04, 2018 5:14 am

My hap ac has still memory leak and crashes even in 6.43.2 not really stable

kernel failure in previous boot
out of memory condition was detected
I also have instabilities with my hap AC, crashing every week, although I wasn't graphing memory usage before so I can't be sure there is a leak on mine. I've just set up the graphing to try to see.

Update: I do not seem to have a memory leak, graphing the memory usage over the past few days has shown no changes, but my device is still crashing about once a week since the new versions.

grawerpl · Thu Oct 04, 2018 1:20 pm

After upgrade can't make to work EoIP over IPSec (IPIP over IPSec works but not without issue) and not working IPSec witch older firmware. What is even more disturbing it shows that established tunnel but no traffic pass and that same with EoIP over IPsec. Configuration was restored from backup, and i try everything but still nothing helps.
Ooo and another thing is that every change in ipsec is done, it not reset tunnel i must reset it manual :/

Davis · Fri Oct 05, 2018 1:30 am

On hAP ac2 is similar problem. Unexpected reboots every 2h to 48h. I sent description of problem to Mikrotik support.

I have the same issue - one of my hAP ac2 is rebooting from time to time (looks like it usually reboots within 24 hours and then works properly till I reboot it manually - however this most likely is pure coincidence). My hAP ac2 also stuck/crashed without rebooting once (it resumed working after unplugging+replugging power).
For me the issue started after upgrade from 6.43.1 to 6.43.2. Router was working on 6.43.1 for around 48 hours without a single reboot. Then router was upgraded to 6.43.2 and after around 6 hours it rebooted for the first time.
Resource graphing is enabled on the router and memory usage was always below 17% (so memory leak should NOT be the cause of reboot, at least a memory leak that grows longer than 5 minutes).

Has MikroTik support replied to you?

sophitus · Fri Oct 05, 2018 9:57 am

As it looks like I have again mem leak reboots on hap ac with RouterOS 6.42.9. Just before reboot IPSEC failure show up in logs. 6.42.7 seemed to be ok, but 6.42.9 is again bad even on bugfix!

mkx · Fri Oct 05, 2018 7:09 pm

My experience on hAP ac2: very unstable, plenty of watchdog reboots (most of them due to ping timeouts, pinged address is linux server on LAN).
For me instability is regression from 6.42.9.

I take my words back. Instability is not a regression from 6.42.9, my hAP ac2 was not completely stable while running 6.42.7 (but much more stable than any of 6.43.x). Two days ago I downgraded to 6.42.9 and so far it's stable.

Some statistics:

while running 6.43 for 7d21h it rebooted 13 times due to "watchdog cannot ping address W.X.Y.Z, reboting". So it had average uptime of 14.5 hours.
while running 6.43.1 for 15d4h it rebooted 48 times, so it had average uptime of 7.6 hours
while running 6.42.9 for 1d21h it never rebooted (current uptime 1d21h16m57s)

Every time I installed another version of ROS I also upgraded (or downgraded) firmware. Next I'll try to upgrade only ROS to determine if source of instability is ROS or firmware.

N.b.: my hAP ac2 doesn't seem to suffer of memory leaks, memory usage graph shows more or less steady usage of less that 1/4 of available RAM.

dziku2 · Fri Oct 05, 2018 8:43 pm

On hAP ac2 is similar problem. Unexpected reboots every 2h to 48h. I sent description of problem to Mikrotik support.
I have the same issue - one of my hAP ac2 is rebooting from time to time (looks like it usually reboots within 24 hours and then works properly till I reboot it manually - however this most likely is pure coincidence). My hAP ac2 also stuck/crashed without rebooting once (it resumed working after unplugging+replugging power).
For me the issue started after upgrade from 6.43.1 to 6.43.2. Router was working on 6.43.1 for around 48 hours without a single reboot. Then router was upgraded to 6.43.2 and after around 6 hours it rebooted for the first time.

Has MikroTik support replied to you?

It's the reply from Mikrotik support:

Right now I do not see where is the issue.
Try to turn of watchdog timer:
"/system watchdog set watchdog-timer=no"
And after device freeze, reboot or powercycle it and then manually create new supout.rif file. Send it to us.

Cha0s · Fri Oct 05, 2018 10:53 pm

After upgrading to 6.43.2 from 6.42.7 you can no longer have multiple IPsec peers to the same destination IP but with different source addresses.

Screenshot_17.png

This worked fine on 6.42.7.

What's the reasoning behind this restriction?
I need multiple peers to the same destination but using different gateways (source addresses).

Please revert this change.

sophitus · Fri Oct 05, 2018 11:02 pm

Appearently there is a memory leak since changelog 6.44beta17 (2018-Oct-04 09:42) states:

"*) bridge - fixed possible memory leak when VLAN filtering is used;"

I had VLAN filtering turned on... on my hap ac

The ones who monitored stable memory usage, did you have VLAN filtering on?
6.42.7 is still the best release for me so far and not 6.42.9.

mducharme · Fri Oct 05, 2018 11:32 pm

Appearently there is a memory leak since changelog 6.44beta17 (2018-Oct-04 09:42) states:

"*) bridge - fixed possible memory leak when VLAN filtering is used;"

I had VLAN filtering turned on... on my hap ac

The ones who monitored stable memory usage, did you have VLAN filtering on?
6.42.7 is still the best release for me so far and not 6.42.9.

I have stable memory usage on my hAP AC and no VLAN filtering, but unexplained reboots approximately once a week.

mkx · Sat Oct 06, 2018 11:14 am

As I noted memory usage on my hAP ac2 is stable and I don't have VLAN filtering enabled (I'm dealing with VLANs on switch chip).

Sat Oct 06, 2018 1:41 pm

After upgrading to 6.43.2 from 6.42.7 you can no longer have multiple IPsec peers to the same destination IP but with different source addresses.

This regression is said to be fixed in 6.44beta14. Please check the change log in the post here. And I'd expect this kind fix to be merged to 6.42.x later as well.

Cha0s · Sat Oct 06, 2018 1:56 pm

After upgrading to 6.43.2 from 6.42.7 you can no longer have multiple IPsec peers to the same destination IP but with different source addresses.

This regression is said to be fixed in 6.44beta14. Please check the change log in the post here. And I'd expect this kind fix to be merged to 6.42.x later as well.

Thanks. I totally missed that entry in the changelog.

narian · Mon Oct 08, 2018 2:42 pm

Just upgraded RB951Ui-2nD from 6.42.7 to 6.43.2 and it's bricked. Netinstall does not see it.
I've upgraded it from winbox system -> packages -> download and install.

What could be a reason and is there any way to ressurect bricked device?

draguzet · Mon Oct 08, 2018 10:13 pm

Just upgraded RB951Ui-2nD from 6.42.7 to 6.43.2 and it's bricked. Netinstall does not see it.
I've upgraded it from winbox system -> packages -> download and install.

What could be a reason and is there any way to ressurect bricked device?

Same here, repeated on 4 devices

, copy paste .npk file, reboot...device DEAD, it make beep beep, but is not live, no winbox, no IP access, no wifi powered on ??
Something are bad with 6.43.2 ? Mikrotik ?

mkx · Mon Oct 08, 2018 10:32 pm

My experience on hAP ac2: very unstable, plenty of watchdog reboots (most of them due to ping timeouts, pinged address is linux server on LAN).
For me instability is regression from 6.42.9.
I take my words back. Instability is not a regression from 6.42.9, my hAP ac2 was not completely stable while running 6.42.7 (but much more stable than any of 6.43.x). Two days ago I downgraded to 6.42.9 and so far it's stable.

Some statistics:
while running 6.43 for 7d21h it rebooted 13 times due to "watchdog cannot ping address W.X.Y.Z, reboting". So it had average uptime of 14.5 hours.

while running 6.43.1 for 15d4h it rebooted 48 times, so it had average uptime of 7.6 hours

while running 6.42.9 for 1d21h it never rebooted (current uptime 1d21h16m57s)

Every time I installed another version of ROS I also upgraded (or downgraded) firmware. Next I'll try to upgrade only ROS to determine if source of instability is ROS or firmware.

N.b.: my hAP ac2 doesn't seem to suffer of memory leaks, memory usage graph shows more or less steady usage of less that 1/4 of available RAM.

So I upgraded ROS to 6.43.2 while leaving firmware at 6.42.9 ... instability came back, in 2d10h it rebooted 8 times with average uptime of 7.3 hours. Memory usage (as charted by graphing tool) never raised above 40MB (out of 240MB), so this clearly is not the reason for reboots.

I hope MT will improve on stability of 6.43 branch ... or launch better (and more stable) 6.44 soon.

draguzet · Mon Oct 08, 2018 10:50 pm

Just upgraded RB951Ui-2nD from 6.42.7 to 6.43.2 and it's bricked. Netinstall does not see it.
I've upgraded it from winbox system -> packages -> download and install.

What could be a reason and is there any way to ressurect bricked device?

Narian, what is the behavior of bricked device ? I have sveral with same problem.

1. After upgrade to 6.43.2 device are unreachable, boot up properly but not working.
2. I try to reset on default, and is passed, but same problem
3. Wifi are powered on with default SSID, after I try to connect to wifi stop working
4. LAN led are green even I disconnect LAN cable from that port
5. Netinstall not working

FiREWiRE · Tue Oct 09, 2018 1:27 am

I've just upgraded my good old RB750G from 6.42.7 to 6.43.2 using check for updates and then download and install. The front LEDs of the router went out, as they usually do when it reboots, but they never came back. Winbox (latest version) couldn't connect to the router, no DHCP, no internet, nothing, the router was stuck. I've waited for about 5 minutes and decided to disconnect and reconnect the power cord. The router came back to life. I've checked the package list and version 6.43.2 was installed.

I've then upgraded the firmware using /system routerboard upgrade
After the firmware update a reboot is required so I've used system reboot and again the router was stuck.

I've waited a couple minutes and did the same disconnect and reconnect of the power cord to fix it.

There is a serious problem happening when rebooting the router using 6.43.2
I'm wondering if this has anything to do with it:

What's new in 6.43.2 (2018-Sep-18 12:12):
Changes in this release:
*) routerboot - fixed RouterOS booting on devices with particular NAND memory (introduced in v6.43);

UpRunTech · Tue Oct 09, 2018 1:34 am

Seeing as 6.44 will be a while can you please put any wireless patches from 6.44RC into the 6.43 branch? I have had CAPAC and HAPAC units stop registering clients on 6.43.2 until they were rebooted even though the interface was running.

*) wireless - improved stability for 802.11ac;

dasiu · Wed Oct 10, 2018 2:40 pm

On mipsbe devices with AR8227 switch chipset (100 Mbps 5-port routers like hAP, hAP ac lite, hEX lite, hEX PoE lite, RB951Ui-2Hnd, OmniTik 5) it seems you can damage the routerboard after upgrading it to 6.43.2 and using no-default settings...

Anyone experienced physical Ethernet port problems after upgrade to 6.43.2? Port not linking or port showing false link without any cable connected (and looping traffic)?

Happened to me few days ago and to my friend yesterday:
Me: RB951Ui-2HnD. After upgrade - ports 2,3 stopped working. First they were just off (not reacting to the cable), then they started showing link (one - 10 Mbps, other one - 100 Mbps). Then port ether5 also stopped working (no reaction to link, showing inactive all the time). Additionally - I can use ether1, but when I add ether1 to the bridge (even if it's the only port in the bridge and regardless of hw-offload on or off) I have packet losses on the port.
My friend - 2 hAP ac lite devices. After upgrade - few Ethernet ports are just down (not showing link with cable connected), while others work (you can log in, etc.) with the same config.

The same architecture, the same chipset (AR8227), the same software version and problem after upgrade, both of us using "no-defaults" reset. Different devices with different configs on different continents. Is it possible, that the upgrade "destroyed" something physically? Or is it really just that strange coincidence only 2 of us had?

draguzet · Wed Oct 10, 2018 3:20 pm

On mipsbe devices with AR8227 switch chipset (100 Mbps 5-port routers like hAP, hAP ac lite, hEX lite, hEX PoE lite, RB951Ui-2Hnd, OmniTik 5) it seems you can damage the routerboard after upgrading it to 6.43.2 and using no-default settings...

Anyone experienced physical Ethernet port problems after upgrade to 6.43.2? Port not linking or port showing false link without any cable connected (and looping traffic)?

Same situation, described below:

1. After upgrade to 6.43.2 device are unreachable, boot up properly but not working.
2. I try to reset on default, and is passed, but same problem
3. Wifi are powered on with default SSID, after I try to connect to wifi stop working
4. LAN led are green even I disconnect LAN cable from that port
5. Netinstall not working

dasiu · Wed Oct 10, 2018 3:35 pm

Same situation, described below:

1. After upgrade to 6.43.2 device are unreachable, boot up properly but not working.
2. I try to reset on default, and is passed, but same problem
3. Wifi are powered on with default SSID, after I try to connect to wifi stop working
4. LAN led are green even I disconnect LAN cable from that port
5. Netinstall not working

Thank you, draguzet!
I reported it, Ticket#2018101022006114.
Can you, please, also share if you did firmware (RouterBoot) upgrade on it (System -> Routerboard -> Upgrade)? Or did it stay on older firmware? Also - what is the device model?
BTW - wifi is available, but "not working", the same for me. Reason is - the wifi is in the same bridge as the faulty ports, and is getting a broadcast storm (the ports are doing loop), and after connecting to wifi I'm getting the MNDP broadcast packets multiplied thousands times.
BTW2 - Netinstall not working also for me...

draguzet · Wed Oct 10, 2018 4:54 pm

Same situation, described below:

1. After upgrade to 6.43.2 device are unreachable, boot up properly but not working.
2. I try to reset on default, and is passed, but same problem
3. Wifi are powered on with default SSID, after I try to connect to wifi stop working
4. LAN led are green even I disconnect LAN cable from that port
5. Netinstall not working
Thank you, draguzet!
I reported it, Ticket#2018101022006114.
Can you, please, also share if you did firmware (RouterBoot) upgrade on it (System -> Routerboard -> Upgrade)? Or did it stay on older firmware? Also - what is the device model?
BTW - wifi is available, but "not working", the same for me. Reason is - the wifi is in the same bridge as the faulty ports, and is getting a broadcast storm (the ports are doing loop), and after connecting to wifi I'm getting the MNDP broadcast packets multiplied thousands times.
BTW2 - Netinstall not working also for me...

It is on old Firmware, because first boot are not successful and I did not have a way to upgrade firmware (Routerboard - Upgrade).
Device models with problems are: RB951Ui-2HnD , RBDynaDishG-5HacDr3, RB921GS-5HPacD-19S, and for now we stop to upgrade !
I have successful Netinstall (on DynaDish for now) on following way:

1) Power your device off;
2) Power device on;
3) Press and hold the reset button (hold about 1m and relese reset button).
4) Device are detected on Netinstall, and DO NOT install 6.43.2 because same problem are present again !

owsugde · Thu Oct 11, 2018 1:51 pm

Changes in this release:

*) routerboot - fixed RouterOS booting on devices with particular NAND memory (introduced in v6.43);

I suspect this fix to be incomplete, to say the least. Several of my wAP ac's in the field have become quite unstable, especially on reboots. Not sure if by .43.x or specifically .43.2 though.

schadom · Thu Oct 11, 2018 5:03 pm

We encountered an issue with the /routing bgp advertisements print detail where ... command which seems to crash/reboot our CCR1009-7G-1C-1S+s running on 6.43.1. We have two BGP full feeds with each approx. 720k IPv4 and 58k IPv6 routes, Cymru feed with 105k bogon prefixes and we redistribute a full feed to a single customer. Free Memory is at 840/1968MB, CPU usage average at 12%.

Generally stability of the BGP implementation and routing-related commands seems to have gotten much worse following the 6.43 release. Peering sessions terminate randomly, CMDs like /ip route print sporadically return false double results for the same dynamic route with same origin/path or even fail entirely, causing the terminal to freeze. With a (Cisco) peer we even encountered "AFI invalid address family" errors on the peers-side recently which all of a sudden disappeared again without any changes on the MT- nor Cisco-side.

Before opening a support ticket with MT, is anyone else seeing this (or similar) behaviour recently?

Thu Oct 11, 2018 5:55 pm

schadom - Please send supout file and problem description to support@mikrotik.com. Please provide precise command that you use in order to filter print command output.

ssbaksa · Fri Oct 12, 2018 11:07 am

I've just upgraded my good old RB750G from 6.42.7 to 6.43.2 using check for updates and then download and install. The front LEDs of the router went out, as they usually do when it reboots, but they never came back. Winbox (latest version) couldn't connect to the router, no DHCP, no internet, nothing, the router was stuck. I've waited for about 5 minutes and decided to disconnect and reconnect the power cord. The router came back to life. I've checked the package list and version 6.43.2 was installed.
----snip-----

What's new in 6.43.2 (2018-Sep-18 12:12):
Changes in this release:
*) routerboot - fixed RouterOS booting on devices with particular NAND memory (introduced in v6.43);

The same here. My RB750GL is gone. Bricked. LED is blinking as it should but Netinstall never gets anything from RB750GL.
That's third time in 7 years of working with various MT's but this time I just can't do a thing.

Any sugestion?

Br

Sasa

draguzet · Fri Oct 12, 2018 11:26 am

The same here. My RB750GL is gone. Bricked. LED is blinking as it should but Netinstall never gets anything from RB750GL.
That's third time in 7 years of working with various MT's but this time I just can't do a thing.
Any sugestion?

Try this:
1) Power your device off;
2) Power device on;
3) Press and hold the reset button (hold about 1m and relese reset button).
4) After board appears in Netinstall install version lower than 6.43.x !! (try different waiting time while holding reset button, 1 minute, 2 minute...)

I'm really strange when the Mikrotik will remove the 6.43.2 version and declare it unstable, since obviously the different boards are falling after the upgrade!

kris62 · Sun Oct 14, 2018 3:34 am

Connection between RB450GX4 and Winbox 3.18

Hi, guys: I just wanted to get help from this forum because my new device RB450GX4 has problem about connection to Winbox 3.18.
I need to close winbox for several times then it can be connected to RB450GX4... Very strange.

Have you guys with similar problem as mine ?

P.S.
The firmware in my RB450GX4 is mostly updated ~ 6.43.2.

Kris from Taiwan

Chupaka · Sun Oct 14, 2018 11:19 am

Was it working good in previous versions? If not, please create separate topic with more details.

denisun · Sun Oct 14, 2018 4:38 pm

In queue export file and full backup export file has separate queue tree statements.

If i have queue tree with parent and childs then i have:
first parent statements
then queue types
and final the rest statements of tree, that childs.

/queue tree
add bucket-size=0 max-limit=4500k name=pppoe-out1-UP parent=global
add bucket-size=0 limit-at=3M max-limit=4500k name=QoS_Low-UP parent=\
    pppoe-out1-UP
....
/queue type
...
/queue tree
add bucket-size=0 limit-at=500k max-limit=4500k name=QoS_1-UP packet-mark=\
    QoS_1-UP parent=pppoe-out1-UP priority=1 queue=fifo-UP-1
.....

If i have only childs and no parents (except that global) the i have all statements together:

/queue tree
add bucket-size=0 max-limit=50M name=pppoe-out1-DW parent=global queue=\
    default
add bucket-size=0 limit-at=500k max-limit=50M name=QoS_1-DW packet-mark=\
    QoS_1-DW parent=pppoe-out1-DW priority=1 queue=pcq-DW-1
...

ssbaksa · Tue Oct 16, 2018 8:36 am

The same here. My RB750GL is gone. Bricked. LED is blinking as it should but Netinstall never gets anything from RB750GL.
That's third time in 7 years of working with various MT's but this time I just can't do a thing.
Any sugestion?
Try this:
1) Power your device off;
2) Power device on;
3) Press and hold the reset button (hold about 1m and relese reset button).
4) After board appears in Netinstall install version lower than 6.43.x !! (try different waiting time while holding reset button, 1 minute, 2 minute...)

I'm really strange when the Mikrotik will remove the 6.43.2 version and declare it unstable, since obviously the different boards are falling after the upgrade!

Done all of this. As I have few more devices for testing purpose it will wait for having some spare time to fiddle with this but it is annoying problem.
In 30 years this is my second completely bricked device. First was Buffalo router without header.

BTW, Mikrotik, are those 3 hidden spots with Rx, Tx, and GND marking real serial port or just ...

Br

Sasa

pe1chl · Tue Oct 16, 2018 11:20 am

are those 3 hidden spots with Rx, Tx, and GND marking real serial port or just ...

TTL serial. Get a TTL serial to USB converter from aliexpress or similar, and you can connect it to a PC and watch the boot procedure.
(or even flash new firmware over serial when you are patient)

DummyPLUG · Tue Oct 16, 2018 7:50 pm

are those 3 hidden spots with Rx, Tx, and GND marking real serial port or just ...
TTL serial. Get a TTL serial to USB converter from aliexpress or similar, and you can connect it to a PC and watch the boot procedure.
(or even flash new firmware over serial when you are patient)

Speak about TTL serial to USB (and many serial to USB), beware that of them are using PL2303 series chipset and some of them are using fake PL2303 chipset, the latest driver and win10 driver will refuse to work with them. If you look for a Serial to USB cable better check if can work in win10 without manually install any driver.

p.s. I have one from UGreen which work in win10.

pe1chl · Tue Oct 16, 2018 8:00 pm

beware that of them are using PL2303 series chipset and some of them are using fake PL2303 chipset, the latest driver and win10 driver will refuse to work with them. If you look for a Serial to USB cable better check if can work in win10 without manually install any driver.

Could be, I never use Windows, and in Linux they all work without problem...

DummyPLUG · Thu Oct 18, 2018 3:50 am

beware that of them are using PL2303 series chipset and some of them are using fake PL2303 chipset, the latest driver and win10 driver will refuse to work with them. If you look for a Serial to USB cable better check if can work in win10 without manually install any driver.
Could be, I never use Windows, and in Linux they all work without problem...

I have a fake PL2302 cable which damage my old wifi AP

ssbaksa · Thu Oct 18, 2018 8:02 am

are those 3 hidden spots with Rx, Tx, and GND marking real serial port or just ...
TTL serial. Get a TTL serial to USB converter from aliexpress or similar, and you can connect it to a PC and watch the boot procedure.
(or even flash new firmware over serial when you are patient)

Ah, nice suggestion but, all my laptops are Pro type and I have real serial ports on them

Serial port is not a problem on computer side. Question is, are those 3 spots on MT board real serial connections or just some
relics from past.

Br

Sasa

Thu Oct 18, 2018 9:35 am

Ah, nice suggestion but, all my laptops are Pro type and I have real serial ports on them

The key here is that TTL serial and RS232 are somewhat different beasts- they differ at least in the voltage levels (while on the protocol level they must be compatible). You can easily damage TTL serial port by directly connecting it to a standard serial port on your laptop.

emils · Thu Oct 18, 2018 10:41 am

New version 6.43.4 has been released in stable RouterOS channel:

viewtopic.php?f=21&t=140560