v6.42.4 [current]

Tue Jun 19, 2018 11:26 am

RouterOS version 6.42.4 has been released in public "current" 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.42.4 (2018-Jun-15 14:14):

*) bridge - allow to make changes for bridge port when it is interface list;
*) bridge - fixed FastPath for bridge master interfaces (introduced in v6.42);
*) certificate - fixed "add-scep" template existence check when signing certificate;
*) chr - fixed adding MSTI entries;
*) chr - fixed boot on hosts older than Windows Server 2012 when running CHR on Hyper-V;
*) chr - fixed various network hang scenarios when running CHR on Hyper-V;
*) console - fixed script permissions if script is executed by other RouterOS service;
*) dhcpv4-server - fixed DHCP server that was stuck on invalid state;
*) health - changed "PSU-Voltage" to "PSU-State" for CRS328-4C-20S-4S+;
*) health - fixed incorrect PSU index for CRS328-4C-20S-4S+;
*) ipsec - improved reliability on IPsec hardware encryption for RB1100Dx4;
*) kidcontrol - fixed dynamically created firewall rules order;
*) led - added "dark-mode" functionality for hEX S and SXTsq 5 ac devices;
*) led - fixed CCR1016-12S-1S+ LED behaviour after Netinstall (introduced in v6.41rc58);
*) led - use routers uptime as a starting point when turning off LEDs if option was not enabled on boot;
*) ppp - fixed "hunged up" grammar to "hung up" within PPP log messages;
*) quickset - added missing wireless "channel-width" settings;
*) quickset - added support for "5ghz-a/n" band when CPE mode is used;
*) snmp - added remote CAP count OID for CAPsMAN;
*) snmp - fixed readings for CAPsMAN slave interfaces;
*) supout - added "partitions" section to supout file;
*) usb - properly detect USB 3.0 flash on RBM33G when jumper is removed;
*) userman - improved unique username generation process when adding batch of users;
*) w60g - improved RAM memoy allocation processes;
*) winbox - added missing "dscp" and "clamp-tcp-mss" settings to IPv6 tunnels;
*) winbox - allow to specify full URL in SCEP certificate signing process;
*) winbox - by default specify keepalive timeout value for tunnel type interfaces;
*) winbox - show "scep-url" for certificates;
*) winbox - show "System/Health" only on boards that have health monitoring;
*) winbox - show firmware upgrade message at the bottom of "System/RouterBOARD" menu;
*) wireless - enable all chains by default on devices without external antennas after configuration reset;
*) wireless - improved Nv2 reliability on ARM devices;

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

Donkeyrollerz · Tue Jun 19, 2018 11:37 am

Hey there, many thanks for the latest release though it looks like I am getting a 404 not found for ARM (rb3011) through your download page. I might just be a very keen bean!

pe1chl · Tue Jun 19, 2018 11:55 am

Does it fix the "lost space after upgrade" issue on CCR?
(when upgrading 6.42.1 to 6.42.3 on a CCR split into two 64MB partitions a lot of diskspace remains in-use after the upgrade and not enough space is left for another upgrade)

bennyh · Tue Jun 19, 2018 11:56 am

Hey there, many thanks for the latest release though it looks like I am getting a 404 not found for ARM (rb3011) through your download page. I might just be a very keen bean!

You can download it from the archive:
https://mikrotik.com/download/archive
(slide down to the current releases)

Tue Jun 19, 2018 12:27 pm

Donkeyrollerz - You tried to download version while it was still being released.
pe1chl - Version fixes all the problems mentioned in changelog. There are no hidden fixes.

Donkeyrollerz · Tue Jun 19, 2018 12:53 pm

Donkeyrollerz - You tried to download version while it was still being released.
pe1chl - Version fixes all the problems mentioned in changelog. There are no hidden fixes.

Thanks for that, successfully downloaded now!

nichky · Tue Jun 19, 2018 1:09 pm

do i need to upgrade the firmware every time when new version comes out?

honzam · Tue Jun 19, 2018 1:38 pm

do i need to upgrade the firmware every time when new version comes out?

Yes, it is impossible to live without it

msatter · Tue Jun 19, 2018 1:51 pm

The firmware has gotten in sync with RouterOS versions....even if nothing has changed in the firmware.

I hope one time it will be separated again and as extra information a second version number stating minimal RouterOS version.

joserudi · Tue Jun 19, 2018 1:54 pm

*) wireless - improved Nv2 reliability on ARM devices;

I'm sorry to indicate that the nv2 protocol on arm devices continues to fail. It is unstable and has packet loss. Nstreme is still the best option

nichky · Tue Jun 19, 2018 1:55 pm

The firmware has gotten in sync with RouterOS versions....even if nothing has changed in the firmware.

I hope one time it will be separated again and as extra information a second version number stating minimal RouterOS version.

brow..you doing upgrade on your firmware or NO after new version cum up. My question i more than simple.

pe1chl · Tue Jun 19, 2018 1:56 pm

Donkeyrollerz - You tried to download version while it was still being released.
pe1chl - Version fixes all the problems mentioned in changelog. There are no hidden fixes.

So how is the indicated problem going to be fixed?
Users who have installed 6.42.1-6.42.3 on CCR are effectively at a dead end.
Having to use netinstall on all those "bricked" routers is simply not acceptable!
Either a fix package or an included fix in a later release is required.
As it is now, I can no longer upgrade my two CCR that are on 6.42.1 because that disables future upgrades on them.

WirelessRudy · Tue Jun 19, 2018 5:21 pm

The firmware has gotten in sync with RouterOS versions....even if nothing has changed in the firmware.

I hope one time it will be separated again and as extra information a second version number stating minimal RouterOS version.

Can anybody make me a solution / script so after the ROS upgrade the unit either in the same reboot, or thereafter reboots again to update the fw version?
Now each and every unit has to be rebooted twice. which is a pain if you have to do big amounts....

WirelessRudy · Tue Jun 19, 2018 5:25 pm

*) wireless - improved Nv2 reliability on ARM devices;

I'm sorry to indicate that the nv2 protocol on arm devices continues to fail. It is unstable and has packet loss. Nstreme is still the best option

OH! So I'll sit and wait again.... Getting a bit frustrated over arm devices and NV2.....

icsterm · Tue Jun 19, 2018 5:58 pm

Can anybody make me a solution / script so after the ROS upgrade the unit either in the same reboot, or thereafter reboots again to update the fw version?
Now each and every unit has to be rebooted twice. which is a pain if you have to do big amounts....

here you go

:log info "Checking firmware...";
/system routerboard
:if ([get current-firmware] != [get upgrade-firmware]) do={
     :log info "Updating firmware";
     upgrade;
     #  Automatic restart
     :delay 2s
     /system reboot
     } else={
     :log info "No update."
     }

create this script then make a schedule on startup for it.

eworm · Tue Jun 19, 2018 6:05 pm

Can anybody make me a solution / script so after the ROS upgrade the unit either in the same reboot, or thereafter reboots again to update the fw version?
Now each and every unit has to be rebooted twice. which is a pain if you have to do big amounts....
here you go
Code: Select all
:log info "Checking firmware...";
/system routerboard
:if ([get current-firmware] != [get upgrade-firmware]) do={
     :log info "Updating firmware";
     upgrade;
     #  Automatic restart
     :delay 2s
     /system reboot
     } else={
     :log info "No update."
     }
create this script then make a schedule on startup for it.

Don't do that! It can result in a boot loop!

icsterm · Tue Jun 19, 2018 6:14 pm

It's tested & working just fine on 2 ROS devices I own.
It's not my script but I find it usefull.

The only bootloop possible is one caused by the new bootloader not being properly written. Which didn't happen to me on 30-40 RC updates.

If bootloop happens, just netinstall the router again and make sure to have backups available. I backup my router configs daily using another script that sends the backup config files over email.

Bad day = netinstall + restore backup.

It's probably less than 1% chance to get a bootloop, though.

WirelessRudy · Tue Jun 19, 2018 6:23 pm

Don't do that! It can result in a boot loop!

Well, I am not of yesterday. I have to try it first. I made some scripts myself in the past but just as script that I'd copy and paste in a terminal window when we upgrade units.
But sometimes on the new cpu's the scripts are processed so fast some setting that in a 'step by step' try out work fine in a 'one script' just don't perform. Then I tried to build in more delay times and we tried this, then that. And next time there is a new ROS the bloody script language is changed again and nothing works anymore.... (I usually use ROS upgrades to keep record which units have had other configuration changes as well. After 12 years of working with MT we still learn new things each time which makes us to change the general OS setting of all the CPE's..

So yeah, I am going to try something like this on a unit on my desk first... then another unit, and another, before in the field....

I just don't understand why both the OS and the fw can't be upgraded in one go....

R1CH · Tue Jun 19, 2018 7:13 pm

I'm also not a fan of the labeling of firmware by RouterOS version. Previously, after updating RouterOS, I could easily see if firmware was outdated and choose to do a 2nd reboot. Now it always appears outdated, even if there were no changes between versions.

icsterm · Tue Jun 19, 2018 8:52 pm

Just script it just be the new Mikrotik slogan

pe1chl · Tue Jun 19, 2018 8:57 pm

I have suggested improvement in other topics but it appears they are not interested.
It is probably best to just set System->Routerboard->settings "auto upgrade" to enabled and then just ignore anything about firmware version.
Usually the changes (if any) are not important and they will become active at your next reboot anyway.

macsrwe · Wed Jun 20, 2018 1:42 am

The only bootloop possible is one caused by the new bootloader not being properly written. Which didn't happen to me on 30-40 RC updates.

MikroTik put out a release about six months ago where the "new available firmware" field always showed up as blank. Boot loop.

I use a more cautious approach in which the "reboot" line is replaced with a line that enables a scheduler entry timed to go off in the wee hours. That line kicks off a script that disables the scheduler entry, then reboots. That way, if there is a boot loop, at least it's a day long.

mt99 · Wed Jun 20, 2018 2:17 am

I upgraded an RB750GL, a 3011, a CRS226, and a RB951G-2HnD from 6.41.4 to 6.42.4 with no issues.

However, after the upgrade I noticed that the two routers with DNS servers (one for internal, one for my guest network) were no longer resolving. This wasn't an issue before the upgrade. I did see them receiving UDP 53 packets. After checking IP > DNS to see if anything had obviously changed and toggling "allow remote requests" on and off with no help, I activated a backup partition with 6.41.4 on both devices and rebooted. DNS is working again. Has anyone else seen this problem?

elpamyelhsa · Wed Jun 20, 2018 4:59 am

For the last few versions I've been having IPSec issues, Looks like a missing default group that is causing it

Notice no * flag exist on the default group

[admin@PRIMARY-ROUTER] /ip ipsec policy group> print
Flags: * - default 
 #   NAME                                                                                                         
 0   group2                                                                                                       
 1   group1                                                                                                       
 2   default

This causes problems with L2TP generating a dynamic Peer that gets a "Policy Template Group: Unknown" that gives a "failed to pre-process ph2 packet"

Wed Jun 20, 2018 6:55 am

joserudi, WirelessRudy - These fixes has nothing to do with Nv2 performance. In some cases ARM routers were rebooting themselves while runnning Nv2 links. Now we have introduced fixes that help in such cases.
pe1chl - Unfortunately I can not give you any ETA for any of fixes in RouterOS. When it will be fixed in rc versions, then fix will be backported to current/bugfix versions if possible.
WirelessRudy - You can not do that within the same reboot.
icsterm - Auto upgrade feature under RouterBOARD settings does the same thing automatically.
mt99 - Please send supout file from your router to support@mikrotik.com. This release does not have any DNS related fixes so it must be something else.
elpamyelhsa - We will look into this.

Everyone - As asked many times before in other topics too, please keep MikroTik announcement topics strictly related to their topic. If you have questions about, for example, RouterBOOT upgrade then either create a new discussion or contact support@mikrotik.com. We are making these topics in order to inform other users about version status and find out about new issues introduced in this release ourselves. Unrelated posts does not help to do that.

makstex · Wed Jun 20, 2018 8:09 am

Model RB1000
After update to 6.42.4 and firmware update that he worked for about 8 hours and DNS stopped responding. Switching the "Allow remote request" checkbox did not help. DNS chopped off completely. The restart has helped, but I still do not know how much it will work.

notToNew · Wed Jun 20, 2018 9:22 am

However, after the upgrade I noticed that the two routers with DNS servers (one for internal, one for my guest network) were no longer resolving. This wasn't an issue before the upgrade. I did see them receiving UDP 53 packets. After checking IP > DNS to see if anything had obviously changed and toggling "allow remote requests" on and off with no help, I activated a backup partition with 6.41.4 on both devices and rebooted. DNS is working again. Has anyone else seen this problem?

Same problem with CCR. I stay with 6.40.8 until i find a solution. Please report if you find any....

Wlad24rus · Wed Jun 20, 2018 10:19 am

How I do resolve problem with no free disc space to upgrade firmware?
I have HAP Lite with old FW, when I try to upload new pkg, - see error, "You have only 6.4mB of free space", Write error..
and new FW pkg is 7+ mBytes.. What i can delete for upgrade fitmware?

Total is 16 mbytes.. AutoUpgrade still not working - due this reason..

sch · Wed Jun 20, 2018 10:32 am

How I do resolve problem with no free disc space to upgrade firmware?
I have HAP Lite with old FW, when I try to upload new pkg, - see error, "You have only 6.4mB of free space", Write error..
and new FW pkg is 7+ mBytes.. What i can delete for upgrade fitmware?

Total is 16 mbytes.. AutoUpgrade still not working - due this reason..

You can try Netinstall. But first, run /export and save your config.

Note · Wed Jun 20, 2018 11:24 am

rb952ui-5ac2nD hap lite

ptm · Wed Jun 20, 2018 11:48 am

I upgraded an RB750GL, a 3011, a CRS226, and a RB951G-2HnD from 6.41.4 to 6.42.4 with no issues.

However, after the upgrade I noticed that the two routers with DNS servers (one for internal, one for my guest network) were no longer resolving. This wasn't an issue before the upgrade. I did see them receiving UDP 53 packets. After checking IP > DNS to see if anything had obviously changed and toggling "allow remote requests" on and off with no help, I activated a backup partition with 6.41.4 on both devices and rebooted. DNS is working again. Has anyone else seen this problem?

I have the same issue with CCR1036 and RB1100AHx2, it started after upgrading to 6.42.1 and I've checked with 6.42.2 and 6.42.3. The issue persists with some routers, I've upgraded 20, had problems with 6 of them and 2 of this 6 didn't work after downgrade them to a previous version.

eworm · Wed Jun 20, 2018 1:10 pm

icsterm - Auto upgrade feature under RouterBOARD settings does the same thing automatically.

But it does not reboot to take the changes into account. After upgrade you see a comment in export:

[admin@mikrotik] > /system routerboard print 
                ;;; Firmware upgraded successfully, please reboot for changes to take effect!
       routerboard: yes
       ...

But this is not available to scripts, no? Perhaps you should add a read-only property "pending-upgrade". A scheduled script could look like this:

:if ([/system routerboard get pending-upgrade ] = true) do={ /system reboot }

notToNew · Wed Jun 20, 2018 1:40 pm

But this is not available to scripts, no? Perhaps you should add a read-only property "pending-upgrade". A scheduled script could look like this:

Scripts can read the log! See https://wiki.mikrotik.com/wiki/Manual:S ... _log_entry

eworm · Wed Jun 20, 2018 1:54 pm

But this is not available to scripts, no? Perhaps you should add a read-only property "pending-upgrade". A scheduled script could look like this:
Scripts can read the log! See https://wiki.mikrotik.com/wiki/Manual:S ... _log_entry

Yes...

:if ([ :len [ /log find where topics=system,info,critical and message="Firmware upgraded successfully, please reboot for changes to take effect!" ] ] > 0) do={ /system reboot }

But it's pretty dumb to read the full log for something a boolean property can provide.
Additionally it is prone to errors. If I have a system which produces a lot of logs and my script is scheduled to run not too frequent this will fail. With persistent log memory this can produce boot loop.

pe1chl · Wed Jun 20, 2018 2:07 pm

But this is not available to scripts, no? Perhaps you should add a read-only property "pending-upgrade". A scheduled script could look like this:
Code: Select all
:if ([/system routerboard get pending-upgrade ] = true) do={ /system reboot }

As I wrote before, the router should do this automatically just after the automatic upgrade, before it brings up all the interfaces.
That would cause less disturbances and would be quicker.

Cha0s · Wed Jun 20, 2018 2:10 pm

rb952ui-5ac2nD hap lite

That refers to the remote side ROS version.

krafg · Wed Jun 20, 2018 4:25 pm

After upgrade, still have problems with DHCP.

Regards.

ofer · Wed Jun 20, 2018 5:00 pm

updated 3xHAP AC units everything went as planned and without issues
bridges HW offloading activated everything seems to be in order

Thanks!

Chupaka · Wed Jun 20, 2018 11:19 pm

After upgrade, still have problems with DHCP.

Regards.

What problems? I can't click your WinBox to see actual settings for some reason.

krafg · Thu Jun 21, 2018 2:05 am

After upgrade, still have problems with DHCP.

Regards.
What problems? I can't click your WinBox to see actual settings for some reason.

Randomly all computers sometimes can't get IP from DHCP server.

Regards.

DummyPLUG · Thu Jun 21, 2018 3:18 am

CCR1009, confirm DNS server stop working after about a few hours after update to 6.42.4

mt99 · Thu Jun 21, 2018 7:14 am

I upgraded an RB750GL, a 3011, a CRS226, and a RB951G-2HnD from 6.41.4 to 6.42.4 with no issues.

However, after the upgrade I noticed that the two routers with DNS servers (one for internal, one for my guest network) were no longer resolving. This wasn't an issue before the upgrade. I did see them receiving UDP 53 packets. After checking IP > DNS to see if anything had obviously changed and toggling "allow remote requests" on and off with no help, I activated a backup partition with 6.41.4 on both devices and rebooted. DNS is working again. Has anyone else seen this problem?

Opened Ticket#2018062122002481 with supouts as requested, please take a look Strods.

TmouR · Thu Jun 21, 2018 6:41 pm

I also confirm that DNS stops after a few hours on some CCR1009's

w0lt · Thu Jun 21, 2018 7:50 pm

I also confirm that DNS stops after a few hours on some CCR1009's

Sent from my ONEPLUS A5010 using Tapatalk

I had this happen on a RB800, drove me crazy till I downgraded to 6.41 then upgraded by loading files directly instead of auto-upgrade. Seems to work now.
I'm crossing my fingers, eh?

twingman · Thu Jun 21, 2018 9:24 pm

I also confirm that DNS stops after a few hours on some CCR1009's

Sent from my ONEPLUS A5010 using Tapatalk

Same issue - dns stops working after some time (random) in my two 1009 ccrs.

I have not enough space issue, too. With 2 partitions. Will be some non-netinstall solution available?

upower3 · Fri Jun 22, 2018 11:17 am

After I got my CCR1009 upgraded to 6.42.4 (both ROS and f/w) remote API login become invalid. My scripts can not log in at all, and on device I can see "login failure for user <my-user> from <my-ip>" messages in log.

I have a dedicated user to allow API requests on my device, it is of group named "api" I created to narrow its rights. This worked for years, until last night I had the upgrade installed.

Over the years before, the api group has only the following rights enabled: api, read, write. As I did my tests afterwards, I found I need to add extra right winbox to allow old scripts to connect.

I use "RouterOS PHP API class v1.6" php library from http://wiki.mikrotik.com/wiki/API_PHP_class so I think this should be fixed to have old scripts still work.

pe1chl · Fri Jun 22, 2018 11:58 am

I have seen that error report in the 6.43rc topic as well. It looks like some erroneous fix was backported into the current version.
It is a bit unfortunate that MikroTik does not track the release annoucement topics closely and instead relies on everything being reported to their mail address...
(maybe this particular issue wasn't reported there)

Pudel · Fri Jun 22, 2018 3:10 pm

Amazing update. I can't login to RB951. Wrong password/login from Winbox and Webfig
Dear Mikrotik, I suggest to hire really good programmers.

EDIT:

SSH works. Very funny

Edit2:
Downgraded from ssh. It's very funny because after downgrade password back to changed a few days ago...
In Polish "hokus pokus, czary mary"

Fri Jun 22, 2018 3:14 pm

upower3, pe1chl - API problem will be fixed in next version.

rfabriciop · Fri Jun 22, 2018 6:57 pm

buenas tardes este firmware lo instale en 3 equipos rb750gl pero los mismos dejaron de funcionar, se reinicia constantemnete y los leds encienden y apagan a cada momento no los puedo recuperar ni con netinstall, tienen alguna solucion para este problema me quedaron 3 equipos como pisapapeles.

zyzelis · Fri Jun 22, 2018 7:35 pm

deleted

WirelessRudy · Fri Jun 22, 2018 8:33 pm

buenas tardes este firmware lo instale en 3 equipos rb750gl pero los mismos dejaron de funcionar, se reinicia constantemnete y los leds encienden y apagan a cada momento no los puedo recuperar ni con netinstall, tienen alguna solucion para este problema me quedaron 3 equipos como pisapapeles.

I don't think the Mikrotik guys understand Spanish nor will most of the forum members. I believe there is a Spanish forum somewhere too...

But I'll translate:
"Good afternoon this firmware is installed on 3 devices rb750gl but these don't work after anymore, they are rebooting all the time and the LEDs are going on and off continuously. I cant' get the units back , not even with netinstall. Do you have any solution for this problem because I now have 3 units that are useless (well, I am not translating "pisapapeles".. )"

zyzelis · Fri Jun 22, 2018 9:22 pm

deleted

pe1chl · Fri Jun 22, 2018 10:55 pm

Usually when people claim their devices cannot be recovered by netinstall, it is because this is their first experience with netinstall.
Netinstall requires some proficiency to use, and trying it for the first time will usually fail, no matter if the router is in a reboot loop or perfectly fine.
Only when you have experience with netinstall and you have used it before to re-install routers, and it now fails on some other routers, you can claim that it "cannot be fixed using netinstall".

Sat Jun 23, 2018 2:55 am

That's the point. More than that, doing the netinstall looks always a bit different from the device behavior point of view, especially if it is different model in every case.

Switching off the antivirus, firewall, other interfaces, manual ip configuration, running netinstall as admin and holding the button pressed until one see the device in netinstall application are the most important success factors. The rest is a bit of alchemy mixed with woodoo.

After dozens and dozens netinstalled devices I never know what will be the problem with the next one.

DummyPLUG · Sat Jun 23, 2018 6:07 am

after update to 6.42.4 DHCP server cannot assign IP to some of our IP cam (mostly Foscam) randomly with this message: dhcp,warning dhcp1 offering lease 192.168.xxx.xxx for 44:2C:05:xx:xx:xx without success, never have the same problem with 6.42.3

nathz08 · Sat Jun 23, 2018 6:30 am

How to fix this?
I update my MT RB1100AHx2 to latest version 6.42.4 after this may hotspot config doesn't work, its login page doesn't display and those on ip bindings doesn't work as well

hope for your rapid response. thanks.

zyzelis · Sat Jun 23, 2018 8:11 am

deleted

ecylcje · Sat Jun 23, 2018 10:08 pm

Hi,

Just to say regarding this point:

joserudi, WirelessRudy - These fixes has nothing to do with Nv2 performance. In some cases ARM routers were rebooting themselves while runnning Nv2 links. Now we have introduced fixes that help in such cases.

My SXTsq 5 ac (6.42.4 (stable)) using a PTP Nv2 connection is still rebooting occasionally. Previously it was rebooting once a day or more (at one point every hour), but now it seems to stay up for 3 to 4 days before it reboots. The Nv2 connection is also very stable now, and only the reboots causes a drop.

Any room for further improvements to stability?

Thanks,

Chris

Iviks · Sat Jun 23, 2018 11:29 pm

Hi all there! I was always fan of Mikrotik! was proud of having such a great network company in Latvia...
till some months ago...
It's seems people from UBNT started to work in Mikrotik.... for the last year....
Why it just started to suck... different configurations for different rb models in vlans,... are You kidding? cant't rewrite config in common syntax?
sorry for my mistakes... just try to not use f words...

nothing really new nor in hardware nor in software... is theis the begginning of the end?

please reply! or delete this post, if u dont care!

in this case i will send all 150 + routers and 400+ client and wifi antennas as a donation back to You!

mducharme · Sun Jun 24, 2018 1:15 am

Why it just started to suck... different configurations for different rb models in vlans,... are You kidding? cant't rewrite config in common syntax?

The VLAN configuration is the same for all models. MikroTik completely changed (improved) the VLAN configuration in 6.41 for all devices. It is not MikroTik's fault if you have some routers running versions before 6.41 and some running later versions.

EDIT: Above, I assumed that Iviks was referring to software VLAN config, and not hardware, since hardware VLAN config (and its often confusing relationship with software VLAN config) has been problematic for a long time instead of just a new issue.

huntah · Sun Jun 24, 2018 9:55 am

Why it just started to suck... different configurations for different rb models in vlans,... are You kidding? cant't rewrite config in common syntax?
The VLAN configuration is the same for all models. MikroTik completely changed (improved) the VLAN configuration in 6.41 for all devices. It is not MikroTik's fault if you have some routers running versions before 6.41 and some running later versions.

You must be kidding... CRS1xxx vs CRS328..
Some you have to do in new bridge configuriration some left in Switch Chip. Others you can completly made in bridge menu and retain HWoffload.
So don't mislead people. Iviks has a valid point regarding VLAN config. It is not the same for all models if you want HW offload and I am certain this is what he means.

But on the point of this topic:
Can anyone confirm that there is no Switch menu on 6.42.4 for hAPac2? if you config it via cli it works.

WirelessRudy · Sun Jun 24, 2018 12:16 pm

The VLAN configuration is the same for all models. MikroTik completely changed (improved) the VLAN configuration in 6.41 for all devices. It is not MikroTik's fault if you have some routers running versions before 6.41 and some running later versions.

This is pertinent NOT true! arm models with 6.41 are not working properly with PPPoE. Everytime we take a new arm unit (SXT-sq, LHG, DISC) we can set it up with same config as we use for some 800 other routers but we have to upgrade to 6.42.x just to make internet traffic for the client happening!
Everything else works, even the antena has internet access but any traffic coming in on the PPPE-client interface on wlan is not passing to LAN port. Just a simple upgrade to 6.42.3 of .4 makes it to work again.....

But ok, since we are now on 6.42.4 and that works for all devices so far (on the use we have) we are not sending to support because we solved the problem ourselves. But what Iviks was writing was true! There were some months we couldn't even use our new batch of arm devices or we had to put a rc version on. There was no PPPoE support for a while but at the same time normal mipsbe etc devices with clone configs had no issue.....

mducharme · Sun Jun 24, 2018 8:14 pm

Some you have to do in new bridge configuriration some left in Switch Chip. Others you can completly made in bridge menu and retain HWoffload.
So don't mislead people. Iviks has a valid point regarding VLAN config. It is not the same for all models if you want HW offload and I am certain this is what he means.

I assumed he must not be talking about HW offload. He said "it just started to suck", meaning he was talking about a recent change. VLAN config has always been a PITA with hw-offload, and the 'switch' menu has always been different for different device models, so the fact that this was always awkward did not jibe with his statement that it "just started to suck", and by this line of reasoning he must not have been referring to the switch menu. Except for MikroTik switches where you don't necessarily need VLAN interfaces, you've always had to set up VLANs in two places instead of one if you need hw-offload and it was easy to get two packets received for every packet sent and other weirdness like that if you didn't know exactly what you were doing. If he is talking about new things, he must mean the VLAN config under "bridge". The VLAN config was always so much of a problem with hw-offload that we just did them in software (except for switches and other such cases where we badly needed hardware acceleration).

To my knowledge, the content of the "bridge" menu is the same in all models. That is what I meant, nothing about the 'switch' menu. I assumed when I was answering he must be talking about the bridge menu, not the 'switch' menu, and that he found the bridge menu was different on some devices than others. The bridge menu should only be different on devices that are running different RouterOS versions, so I assumed if he finds the bridge menu to have different contents on different devices it must be due to different RouterOS versions on those devices.

Also, I would assume the goal is to eventually remove the 'switch' menu from all devices by integrating this functionality into the bridge, but that would take time due to different functionality with different switch chips in different devices etc. It is probably too much to expect MikroTik to integrate all of that so soon after the new bridge is developed, and the new bridge code hasn't been around for that long. I have been advising people on 6.41+ to ignore the 'switch' menu completely unless they really need something there.

mducharme · Sun Jun 24, 2018 8:55 pm

This is pertinent NOT true! arm models with 6.41 are not working properly with PPPoE.

I wasn't saying anything about other issues with 6.41. My reply was only regarding the VLAN config in the bridge menu, which was changed in 6.41, and nowhere did I say that 6.41 was bug free in all regards. I have no doubt that there were bugs, and to be on the safe side, we have been remaining for several months at versions below 6.41 on production devices without careful testing to make sure everything worked. The new bridge is a big change, and big changes always have a high risk of new bugs...

cwade · Sun Jun 24, 2018 10:50 pm

I just encountered a problem with upgrading a RB850Gx2 to version 6.42.4. After the upgrade, Winbox will no longer complete connecting to the RB850Gx2. The main window opens, and a few subwindows start to populate, and then the Winbox connection hangs up, and eventually times out. The appearance is similar to what I’ve encountered in the past when there were MTU size differences that seem to cause Winbox to choke when handling large packets. However, in this case, there should not be any MTU size inconsistencies.

Note that I did upgrade my Winbox client to 3.15. I’ve also rebooted the RB850Gx2 several times, and I did perform the firmware upgrade/reboot operation as well, though this does not appear to have been necessary.

I am able to access this RB850Gx2 via SSH and the console without any problems.

Prior to the upgrade to 6.42.4, I had been on 6.42.3 with this RB850Gx2. I was not having problems accessing this router via Winbox.

Is anyone else having a problem like this?

mducharme · Sun Jun 24, 2018 10:58 pm

I just encountered a problem with upgrading a RB850Gx2 to version 6.42.4. After the upgrade, Winbox will no longer complete connecting to the RB850Gx2. The main window opens, and a few subwindows start to populate, and then the Winbox connection hangs up, and eventually times out. The appearance is similar to what I’ve encountered in the past when there were MTU size differences that seem to cause Winbox to choke when handling large packets. However, in this case, there should not be any MTU size inconsistencies.

Haven't seen this myself except in the case that you mention (MTU size differences) which is related to use of MAC winbox. Are you connecting to winbox with IP?

Are you sure it isn't an MTU issue? I've seen issues before with bridge auto MTU not adjusting properly when adding a port, resulting in a bridge IP MTU that is higher than it should be. Disabling and re-enabling the bridge or rebooting the device triggers the bridge to recalculate the correct MTU to use based on the ports that are attached and then it works. I haven't been able to reproduce this issue consistently.

cwade · Sun Jun 24, 2018 11:37 pm

I just encountered a problem with upgrading a RB850Gx2 to version 6.42.4. After the upgrade, Winbox will no longer complete connecting to the RB850Gx2. The main window opens, and a few subwindows start to populate, and then the Winbox connection hangs up, and eventually times out. The appearance is similar to what I’ve encountered in the past when there were MTU size differences that seem to cause Winbox to choke when handling large packets. However, in this case, there should not be any MTU size inconsistencies.
Haven't seen this myself except in the case that you mention (MTU size differences) which is related to use of MAC winbox. Are you connecting to winbox with IP?

Are you sure it isn't an MTU issue? I've seen issues before with bridge auto MTU not adjusting properly when adding a port, resulting in a bridge IP MTU that is higher than it should be. Disabling and re-enabling the bridge or rebooting the device triggers the bridge to recalculate the correct MTU to use based on the ports that are attached and then it works. I haven't been able to reproduce this issue consistently.

I appreciate your suggestions, however this particular router has all interfaces and bridges left at default MTU sizes (i.e., actual mtu = 1500). I just scanned all interface specifications on this RB850Gx2, and every Ethernet, VLAN, and bridge is set for an MTU of 1500 (for Layer 3 protocols). I’m familiar with the MTU problems affecting Winbox because I do have lots of MikroTik routers of various stripes configured to use non-standard MTU sizes. My impression is that Winbox has issues with packet fragmentation. However, this RB850Gx2 should have been easy, since all MTU settings were left at default.

I posted this problem on this thread since it appears to be related to upgrading from 6.42.3 to 6.42.4 (or possibly the upgrade to Winbox 3.15). I changed nothing else, and I had no problem with Winbox until I performed the upgrade. Also, other routers I’ve upgraded to 6.42.4 (mostly X86 variants) have not had problems. One possibility is that this is related to the PPC processor family.

mducharme · Mon Jun 25, 2018 12:09 am

One possibility is that this is related to the PPC processor family.

I can confirm that 6.42.4 on RB1100AHx2 (PPC) does not have this issue with Winbox disconnects.

I think I may have misremembered the MTU issue that I had - L2 MTU of the bridge had 65535 like a bridge with no ports, even though it had a bunch of ports (IP MTU was set to 1500 everywhere). One symptom of this issue was broken DHCP. Disabling and re-enabling the bridge changed the L2MTU to change from 65535 to 1580 (the L2 MTU of the ports) and then DHCP started to work. If this is not your issue then it doesn't matter but I have encountered this before, and it sometimes happens on a reboot after a RouterOS upgrade.

OldSwitchConfigLiker · Mon Jun 25, 2018 7:25 am

This is pertinent NOT true! arm models with 6.41 are not working properly with PPPoE.
I wasn't saying anything about other issues with 6.41. My reply was only regarding the VLAN config in the bridge menu, which was changed in 6.41, and nowhere did I say that 6.41 was bug free in all regards. I have no doubt that there were bugs, and to be on the safe side, we have been remaining for several months at versions below 6.41 on production devices without careful testing to make sure everything worked. The new bridge is a big change, and big changes always have a high risk of new bugs...

I must agree with Iviks statement. I too was a great follower of MT for quite some time, and implemented many of these at customers sites. So much so that for a long time I even didn't need a forum account, but could figure it out by myself with my favorite search engine.
But recently I have seen time and time again that MT implements changes that do not allow for fallback, and are so fundamental that every somewhat more complex config is impacted. The most significant I think (but certainly not the only one) is the omission of masterports, in combination with the switchconfig.

Sure, I understand that the old method was complex, and specific for every device. But it allowed for some very neat configs that optimally uses the hardware. Which we are now missing.
So I certainly understand that MT wants to make something that always works on every of their devices.

But my point is that many of those devices that are already deployed and running with the old-type configs (in my case mostly with Masterports and switchconfig), are at some point hit by a OS-vulnerability that needs a newer RoS version to fix it, and therein is no more Masterports (or switchconfig) available. The autoconvert does not give a working setup. Manual reprogramming is needed, including sometimes reapproval or recertification.
This is a cost that one cannot just present to the customer, just because there was a security update.
So in short what we need is some kind of fallback! We need CONTINUITY!!

Eg. a way to import the old config with some hidden option to allow old configs to load without conversion, but with old options still in.
Or a proper LTSB like option, maintained over let's say 5 years or so. (so the continuation of 6.40.bugfix way-way-way beyond 6.40.8 )

Another example was Netwatch. There is no override for it. Even if there are no lower-privileged users available to misuse the function. Scripts based on that now need to be rewritten.

Masterports and switchconfig was in my case reason enough to ring the alarm-bell last year, even before it became "current" in 6.41. I created a forumuser (hence the name) and formulated what I perceived as a pending issue. But response on forum was nearly nonexistent, just one question for me to give an example by a user, and an explanation by a MT-tech that everything is "now possible" in a bridge. Apparently nobody cared... or understood the fundamental implications...
So I figured "I'll give bridges a try, maybe it will become better in time". And I did. But bridges hardly became better on vlans. And by now, I stopped upgrading to 6.41 and beyond.

But in the mean time, apparently MT realized that switchconfig cannot (yet) be missed, and re-added it to for instance on hap-ac2.

For me personally, without Masterports, I need to spend too many hours per device at the customers end to reprogram the config to a working one. So I'll remain in bugfix-hell 6.40.xxx as long as possible, and if I have to advise the customer on an upgrade, I probably will have to advise against MT. Simply because (currently) MT is no longer a viable option for continuity.
And thát is what is a PITY imho. As routerboard is really a great concept.

My examples are of course just indicative of the larger problem.
But please MT, give us something stable and safe to fall back on..... come on....
Not everyone is constantly playing around with their config. Not everyone want a new feature every week.. Some of us just need a stable system that can be kept safe with updates and/or bugfixes.
And... don't just remove functionality, that can cripple a config. That's just bad business.

This is a much wider issue than whether or not bridge is better than masterports, or if a user might misuse the netwatch function to execute something he normally cannot do.
It seems thinking ahead and grasping the consequences of such "improvements" is just not high on the MT priority-list anymore

Ps. another incomprehensible MT-strategy lately is the structurally shrinking of the flash-size. Was a few years ago 64MB pretty much standard on even the lowest end devices, now even the higher end devices only come with only 16MB. (I know, 16MB NOR serial flash is much smaller and cheaper than 64Mb parallel NAND). But situation now it's so bad that you cannot even install all packages anymore on an arm device with 16MB (for testing, certification and/or evaluation). You first have to remove one, to install another.
And even more important, twin partitions for ROS-failover, what many of us like to do, is not even an option anymore.
Why is this possible on an el- cheapo 750GL, but not on a much more expensive but newer hap-ac?? Makes no sense at all. And certainly not good for continuity.
Don't shrink... but make bigger... Software (Ros) is generally also growing over time between versions... Makes no sense to shrink the medium where it should reside on....

bda · Mon Jun 25, 2018 8:33 am

Does it fix the "lost space after upgrade" issue on CCR?
(when upgrading 6.42.1 to 6.42.3 on a CCR split into two 64MB partitions a lot of diskspace remains in-use after the upgrade and not enough space is left for another upgrade)

Hi.
We have identical problem on all CCR-routers... I opend a ticket...

eddieb · Mon Jun 25, 2018 9:45 am

All this complaining about how thing used to be has nothing to do with this release, please stay on topic !

I updated all my devices to this current release, no problems seen so far.
(RB2011/RB1100/RB962/CRS125/CHR)

mducharme · Mon Jun 25, 2018 10:04 am

In the WISP environment that I work at, we have no MikroTik switches, we are running 6.40.8 on everything. We gave up on hardware acceleration long ago because we didn't really need it for our bandwidth levels and it makes configuration much too difficult for most people, so we got by with just the software bridge config for VLANs. With most people I have talked to, they never even set up the switch chip for VLANs except for CRS switches where the config was well documented. For all of those people (and for us), these changes suddenly mean that they (and we) can take advantage of hardware offload that previously went unused. There are probably a number of users who replaced MikroTik with something else because they either didn't know about the switch chip config with master/slave and just thought that MikroTik's switching was poor performing (and I know from seeing people posting on the forum that some in fact thought this) or they knew about the switch chip VLAN config and master/slave but found it too confusing and found it easier to replace it with another vendor instead of try to figure it out.

I can't tell you how many times that we would hire on a new tech with Cisco certification, very often CCNP or even CCIE, and they would usually understand everything in RouterOS without needing special explanation except the bizarre way (in 6.40 and earlier) of setting up VLANs on bridges, which these otherwise smart people would get very confused by. I cannot count the number of times that I had to draw up a whiteboard diagram so that the tech would understand the difference between a VLAN interface *on* a bridge vs. a VLAN interface that is connected to a bridge (i.e. acting as a port of a bridge). In comparison, the new means of configuration is much simpler for people to understand. Before these bridge changes, VLANs with bridges were harder to set up on RouterOS than probably any other platform and were set up in a strange way; now it is a normal way and I pretty much don't have to explain it, people get it right away. Once the switch menu functionality is completely integrated and the menu disappears, the rest of the complexity will be gone, and I hope they keep moving in this direction. Although I sympathize with those that have to make a few changes to the config after the upgrade so that things still work as they did before - maybe MikroTik can improve the conversion routine a bit to minimize this work? In the case of the WISP that I work for, the changes introduced in 6.41+ will not require that we make changes to the config, however, it is in our best interest to do so since it will remove three or four bridges from our config that we will no longer need due to these new features. For us, a simpler setup means fewer mistakes which means fewer customer issues, ultimately increasing customer satisfaction, even if it means we have to do a bit of extra work to get there.

I also think it is not realistic for MikroTik to maintain two different code bases for "continuity" for a long period (ex. your suggested 5 years of updates for the old 6.40.x codebase) all to save 10 minutes of reconfiguration time (if that) on a customer's router. If they intend to make a change every few versions with the same level of impact of the bridge change, that becomes more problematic, and then I would begin to complain seriously about continuity. However when they announced this change, I assumed it was an anomalous event, and did not represent a new trend of changing things that would break existing setups on a regular basis.

jhonykat · Mon Jun 25, 2018 10:25 am

I cannot access to router via API(PHP) after updated.
Return back to BugFix only v.6.40.8 => Worked.

pe1chl · Mon Jun 25, 2018 10:54 am

In the case of the WISP that I work for, the changes introduced in 6.41+ will not require that we make changes to the config, however, it is in our best interest to do so since it will remove three or four bridges from our config that we will no longer need due to these new features. For us, a simpler setup means fewer mistakes which means fewer customer issues, ultimately increasing customer satisfaction, even if it means we have to do a bit of extra work to get there.

I am using VLAN config in our network and as a test I migrated my own home router from a config where the VLANs were done in switch config, with each VLAN connected to a separate bridge, to a new-style config with a single bridge with all the VLAN filtering and no VLAN config in the switch menu. No spanning tree or other advanced features.
Although the two configs are completely equivalent, I have lost the hardware acceleration. I don't understand why that has to be, as on other routers where no VLANs were in use on the switch the hardware acceleration was retained during conversion to bridge setup (without VLAN filtering). IMHO it should be possible to have hardware accelerated VLAN bridging as the switch chips are clearly capable of doing it. This should have priority to implement, in fact it should have been included before the new bridge config went in to "current".

The new config isn't much clearer either. I agree with you that the switch config for VLAN is tricky to get right at first (because it is so different from the usual switch VLAN setup) but once you get the hang of it, it is easy. With bridge VLAN filtering there is similar possibility for goof-ups that ruin your day (like not including the bridge itself as a tagged member when you want to connect the CPU to the VLAN for routing). So I doubt that there will be that many fewer mistakes.

mducharme · Mon Jun 25, 2018 11:01 am

IMHO it should be possible to have hardware accelerated VLAN bridging as the switch chips are clearly capable of doing it. This should have priority to implement, in fact it should have been included before the new bridge config went in to "current".

I agree completely. It is highly problematic that with some models you cannot do bridge VLAN filtering at all without making hardware offload impossible. This should be more consistent between models, and I hope they are prioritizing that. Also, bridge options should ideally be clearly marked with whether an option is supported for hardware offload or not on a specific model, so that people will know what they have to do to get hardware offload without the guesswork (kind of like the way the hardware accelerated ipsec options are marked with the "(H)").

Chupaka · Mon Jun 25, 2018 11:44 am

I cannot access to router via API(PHP) after updated.
Return back to BugFix only v.6.40.8 => Worked.

The problem is in 6.42.4 user needs also 'winbox' permission to login via API. Should be fixed in next version, now you can just add that permission.

OldSwitchConfigLiker · Mon Jun 25, 2018 5:06 pm

mducharme:
You are just emphasizing my point now... apparently MT is now more involved in dumbing down Ros than providing a technically better and stable OS.
By removing code supporting previous features normal upgrade process is blocked, and therefore continuity is lost.
Therefore RB also LOST its validity as a serious professional networking equipment provider with proper support. (which is weird since MT is expanding in exactly that direction too)

Codebase should have stayed IN at least until all issues were resolved and old and new functionality was on par. (and maybe even then... leaving it in for backwards compatibility).
Instead, MT chose to prematurely remove it, and at the same time, MT shrinks Flash size, which likely contributes to the need for codebase removal.
And remember, it's not just switchmenu and masterports, but there are more recent examples.

I agree that one method that works for all MT devices is the nicest. I fully support the intention. But don't just ditch the old methods too.
And if you want a simple router to set up, buy a Sweex or Sitecom.... Ros is for people who invest in knowledge of how it works.
Even with new features, novices to RoS need to dig in first or get hopelessly stuck in sub-par configs... or worse.

Simplicity in itself is not a virtue. It's just an excuse.

OldSwitchConfigLiker · Mon Jun 25, 2018 5:10 pm

eddieb:
I agree that this may not be the most appropriate place, as it is not a 6.42.4 specific issue. But if you make a separate thread for it, apparently MT and community don't care to look to serious fundamental issues. This also have been proven on this forum time and time again. General threads are apparently the only ones that have sufficient reader-base to trigger a proper discussion.
Without proper discussion, understandably MT looses interest too.

So to all that are offended by Iviks statement and my response (and other responses btw), I'm truly sorry for that.
It was just the "one too many". I sense that this is an issue more and more long-term RB users are frustrated with in spite of there affinity to the great RoS. Especially now that recently it seems to happen so often. It is not just reminiscing how great things were, but trying to point out a serious fundamental issue in order to make RoS an even better RoS. And as such, in an somewhat twisted way, the release thread of a new version (like this 6.42.4 thread) might actually even be the right place for it.
I would be happy to continue in separate thread if discussion is seriously done there. And including MT, where MT is not just digging-in and defending there current strategy without the obvious customer sensitivities they have recently been ignoring in pursuit of there own goals.

bda · Mon Jun 25, 2018 5:29 pm

Hello,

Sorry for disturbing. But loss of hdd space appears on upgrading to 6.41.2, and gone worse with upgrade to 6.41.4.
In 64 Mb partitions (2x64), only 10-15% free space left after upgrade...

Dear developers. Please help. Ticket number #2018062222003568

kobuki · Mon Jun 25, 2018 7:48 pm

RB2011 upgrade from 6.34.2.

- VLANs are not converted
- new bridge is not created but interface master-slave relations removed
- after removing all VLANs to re-create the configuration manually using a new bridge, 2 bridges are automagically created somehow (RB2011 has 2 switch groups) and interfaces added
- switch VLAN config is not touched, it's still there in the switch menu

The switch menu shouldn't be there, should it? Thankfully at least the router works now with the original switch VLAN config and the VLAN interfaces I added to the bridge.

EDIT: additionally, the sfp1 interface disappeared. We don't have a module in it, but it's nowhere to be found, not even in command line. It was there with the interfaces in 6.34.2.

mducharme · Mon Jun 25, 2018 8:25 pm

The switch menu shouldn't be there, should it? Thankfully at least it works now with the original switch VLAN config and the VLAN interfaces I added to the bridge.

EDIT: additionally, the sfp1 interface disappeared. We don't have a module in it, but it's nowhere to be found, not even in command line. It was there with the interfaces in 6.34.2.

The switch menu should be there because they have not yet made all of the switch options work with hardware offload besides simple bridge ports (to replace the master/slave setting). On most models they have not yet made the bridge VLAN config work with hardware offload, so VLANs still need to be configured the old way if you need hardware offload. In our case (a WISP) we don't need hardware offload because we are not bridging more than 100Mbps so we configure everything using the new means even though it means hardware offload will be disabled.

However, the sfp1 interface should not have disappeared. Does rebooting the device again make it come back? Upgrade the RouterBOOT firmware as well just in case.

kobuki · Mon Jun 25, 2018 8:29 pm

@mducharme: in the meantime I've "found" the VLAN filtering option (I was in a kind of hurry to bring things back online), so I'll start testing it on the RB2011. I've modified my original post, removing the false info. So it might become possible to use the bridge config and ditch the old switch config even on this model. We'll see.

No, I rebooted to update the firmware, too, and the sfp1 interface didn't appear.

EDIT: I checked the "VLAN filtering" option. The router immediately created dynamic VLAN configuration on the bridge, based on the current switch config, and disabled HW accel on the ports. Oh well. I don't really need HW acceleration there, though, as it's a gateway, but I'm pretty much pissed that now I need to configure the same thing at 2 places... Now I left it as is, using switch config and HW accel.

mducharme · Mon Jun 25, 2018 8:35 pm

@mducharme: in the meantime I've "found" the VLAN filtering option (I was in a kind of hurry to bring things back online), so I'll start testing it on the RB2011. I've modified my original post, removing the false info. So it might become possible to use the bridge config and ditch the old switch config even on this model. We'll see.

No, I rebooted to update the firmware, too, and the sfp1 interface didn't appear.

I know with the RB3011 if spanning tree is enabled then hardware offload gets turned off, that might be the case for the 2011 as well but I'm not sure. Keep that in mind as you are experimenting with the config.

Try a cold boot of the device with complete power off for 30 seconds and power back on. If sfp interface does not reappear I would probably contact MikroTik support.

mducharme · Mon Jun 25, 2018 8:37 pm

EDIT: I checked the "VLAN filtering" option. The router immediately created dynamic VLAN configuration on the bridge, based on the current switch config, and disabled HW accel on the ports. Oh well. I don't really need HW acceleration there, though, as it's a gateway, but I'm pretty much pissed that now I need to configure the same thing at 2 places... Now I left it as is, using switch config and HW accel.

If you don't need HW acceleration then you don't need to configure the VLANs in the switch menu (so you don't need it in two places), you can remove that config (set the switch config back to factory default and ignore the VLAN tab) and use only bridge VLAN filtering. You might get the HW acceleration back automatically at a future date when they add HW offload support for bridge VLANs with that model.

kobuki · Mon Jun 25, 2018 8:42 pm

@mducharme: thanks for the heads-up about STP. I might switch to standard bridge config later, for now it works so I'll just let it be. I need remote hands to power-cycle, so maybe tomorrow. Luckily the SFP cage is vacant.

jmay · Mon Jun 25, 2018 11:04 pm

I'm having a strange problem since I think the update before 6.2.4 and still with 6.2.4.

I have a wireless bridge from my house to 2 out buildings using a wAPac as an 802.11 ap to feed them. Randomly both SM's will drop off the ap at the exact same time and will not attempt to reconnect until I shut wireless off at the AP and then back on. This happens on 2.4 and 5ghz. Any ideas?

I've had this setup for a very long time and no issues until recently.

ppereira · Mon Jun 25, 2018 11:45 pm

I cannot access to router via API(PHP) after updated.
Return back to BugFix only v.6.40.8 => Worked.
The problem is in 6.42.4 user needs also 'winbox' permission to login via API. Should be fixed in next version, now you can just add that permission.

Hi Chupaka, could you explain better how to give this permission?
My only issue is that, if i could fix it i will not realize a downgrade.

Best Regards

Xymox · Tue Jun 26, 2018 3:55 am

Donkeyrollerz - You tried to download version while it was still being released.
pe1chl - Version fixes all the problems mentioned in changelog. There are no hidden fixes.

So no... So this might be a dangerous update for some people as it might use up more disc space and then they will not be able to update or downgrade and will be forced to Netinstall.

I tested the upgrade on a CCr1036 where I have plenty of HD space so if something goes wrong I wont get shut out. Indeed this update consumed 14MB of additional space. Pre 6.42 updates did not consume much more space like that. So something still seems wrong to me.

The 6.43RC's tho have been going fine for me even tho nothing has been mentioned in the changelogs. No additional space consumed so far in those.

pe1chl · Tue Jun 26, 2018 10:27 am

So no... So this might be a dangerous update for some people as it might use up more disc space and then they will not be able to update or downgrade and will be forced to Netinstall.

I tested the upgrade on a CCr1036 where I have plenty of HD space so if something goes wrong I wont get shut out. Indeed this update consumed 14MB of additional space. Pre 6.42 updates did not consume much more space like that. So something still seems wrong to me.

That is why my two CCRs are effectively locked at 6.42.1 until MikroTik sort this out... which every .x release I hope they have done, but until now hey seem to rate this serious
issue low-priority

Remember, this occured using "current" versions! When I install an RC and get something like this, I expect to have to netinstall. But when I install current versions I expect them:
1 - to be tested to not have such errors
2 - in case something still goes wrong, to fix it in the next release and/or to ship a "fix" package for the affected release.

But now it has not been fixed in 2 "current" releases..... bad!

upower3 · Tue Jun 26, 2018 11:04 am

I cannot access to router via API(PHP) after updated.
Return back to BugFix only v.6.40.8 => Worked.
The problem is in 6.42.4 user needs also 'winbox' permission to login via API. Should be fixed in next version, now you can just add that permission.

I reported this a page before, funny that no one read the topic.

ecylcje · Tue Jun 26, 2018 1:15 pm

Update (NV2 - ARM reboot issue):

jun/23/2018 08:24:20 system,error,critical router was rebooted without proper shutdown
jun/26/2018 09:06:28 system,error,critical router was rebooted without proper shutdown

After 3 days my SXT SQ ac running a PTP nv2 link crashed. It seems very regular ; every 3 days the router crashes and complete reboots. This is the second crash now on 6.42.4, the first one was after 3 (approx) as well.

Chris

bugtoodd · Tue Jun 26, 2018 2:24 pm

Hi everbody,
On 6.42.4:
- OSPF adjacency will randomly drop (tested on a CCR1016-12S-1S+ with 89 neighbors on different interfaces). If we go back to 6.42.3 the issue is not present anymore.
- Mean RAM usage on 6.42.4 is about 180mbytes more that 6.42.3 (tested on CCR1016-12S-1S+)
- After upgrade, RPS is enabled on CCRs (/resources irq rps enable) while it should be disabled by default. If we perform a factory reset it is disabled.

Anybody else is seeing this?

I already opened a ticket with support (TT 2018062522004007)

Thanks,
Daniel

Wed Jun 27, 2018 12:04 pm

Version v6.42.5 has been released in current channel:

viewtopic.php?f=21&t=136171

Who is online