v6.42rc [release candidate] is released!

Wed Dec 27, 2017 10:50 am

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.42rc2 (2017-Dec-27 07:37):
*) dude - fixed e-mail notifications when default port is not used;
*) firewall - fixed "tls-host" firewall matcher;
*) firewall - limited maximum "address-list-timeout" value to 35w3d13h13m56s;
*) routerboot - fixed missing upgrade firmware for "ar7240" devices;
*) tile - fixed USB device speed detection after reboot;
*) traffic-flow - do not count single extra packet per each flow;

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

kamillo · Wed Dec 27, 2017 11:45 am

Admire the spirit, Christmas period and you are releasing new (RC) version. But looking at changes 4 out of 6 are fixes so this sounds more like 6.41.1 not 6.42.

Wed Dec 27, 2017 12:00 pm

kamillo - Fixes must be tested on rc tree before they are included in full version. Otherwise each and every version would be beta.

th0massin0 · Wed Dec 27, 2017 12:39 pm

Is there a chance to support boot from VirtIO-SCSI in this release of CHR?

null31 · Wed Dec 27, 2017 4:16 pm

No problem with upgrade from 6.41rc47 to 6.42rc2 on hAP ac lite and from 6.41rc66 to 6.42rc2 on CHR under VBox.

Cha0s · Wed Dec 27, 2017 5:31 pm

*) traffic-flow - do not count single extra packet per each flow;

Can you give more details about this?

irghost · Wed Dec 27, 2017 5:33 pm

*) firewall - fixed "tls-host" firewall matcher;

TLS-host does not work for me!

Thu Dec 28, 2017 7:33 am

Cha0s - Before the fix Traffic Flow, for example, instead of reporting 5 packets per flow reported 6 packets. Simply reported one packet more than flow has actually processed;
irghost - Can you provide an example of rule which you have tried out and seen that it is not working?

fenomen51 · Thu Dec 28, 2017 7:52 am

Дома hAP ac стоит, 2 часа с бубном танцев не привели к получению интернета из одноимённого отверстия с данной прошивкой, как заколдованный, не найден тебе узел и всё тут. Ну, руки у меня кривые конечно, но остальные устройства автоматом завелись, а это - нет

irghost · Thu Dec 28, 2017 10:21 am

Cha0s - Before the fix Traffic Flow, for example, instead of reporting 5 packets per flow reported 6 packets. Simply reported one packet more than flow has actually processed;
irghost - Can you provide an example of rule which you have tried out and seen that it is not working?

/ip firewall filter add action=drop chain=forward protocol=tcp tls-host=*.youtube.com

raffav · Thu Dec 28, 2017 2:14 pm

Cha0s - Before the fix Traffic Flow, for example, instead of reporting 5 packets per flow reported 6 packets. Simply reported one packet more than flow has actually processed;
irghost - Can you provide an example of rule which you have tried out and seen that it is not working?
Code: Select all
/ip firewall filter add action=drop chain=forward protocol=tcp tls-host=*.youtube.com

i never figure out how to setup that, so i will be cool to have some exemple form MT support

alexspils · Thu Dec 28, 2017 2:22 pm

*) dude - fixed e-mail notifications when default port is not used;
does it means that dude development is unfreezed?
what abount dude api?
We have strange issue:
we have device with one service but dude shows 2 services

Cha0s · Thu Dec 28, 2017 2:37 pm

Cha0s - Before the fix Traffic Flow, for example, instead of reporting 5 packets per flow reported 6 packets. Simply reported one packet more than flow has actually processed;
irghost - Can you provide an example of rule which you have tried out and seen that it is not working?
Code: Select all
/ip firewall filter add action=drop chain=forward protocol=tcp tls-host=*.youtube.com
i never figure out how to setup that, so i will be cool to have some exemple form MT support

I don't think you can use wildcards. Or to put it more correctly, I think you should use the domains defined in the certificate.
Youtube's certificate does not contain *.youtube.com

anuser · Thu Dec 28, 2017 7:24 pm

Hi, would it be possible to activate / enable / support "airtime fairness" for Atheros wireless chipsets within 6.42rc?

Thu Dec 28, 2017 9:39 pm

fenomen51 - Please note that most of the users in the forum do not know Russian language. I recommend to send this report to support@mikrotik.com and provide confguration of your router which you had before an upgrade. We will test if we can reproduce this problem;
irghost, raffav, Cha0s - Seems that we have found an issue with new TLS matcher. We will try to fix it as soon as possible;
alexspils - Please note that this was just a single fix. More fixes will be available in future RouterOS releases, but we can not promise any ETA for them;
alexspils, anuser and everyone else - If you have suggestions or bugs reports related to RouterOS, then either create a new support topic or contact support. We will be happy to hear you out. Version topics are made to find out issues with concrete version - see the feedback about concrete version. Main idea is to help to users who want to upgrade.

AlainCasault · Thu Dec 28, 2017 11:41 pm

Cha0s - Before the fix Traffic Flow, for example, instead of reporting 5 packets per flow reported 6 packets. Simply reported one packet more than flow has actually processed;
irghost - Can you provide an example of rule which you have tried out and seen that it is not working?
Code: Select all
/ip firewall filter add action=drop chain=forward protocol=tcp tls-host=*.youtube.com
i never figure out how to setup that, so i will be cool to have some exemple form MT support

I think every new function SHOULD have some examples on proper usage.

Best regards and happy holidays!

irghost · Fri Dec 29, 2017 2:24 pm

irghost, raffav, Cha0s - Seems that we have found an issue with new TLS matcher. We will try to fix it as soon as possible;

add some documents

bajodel · Mon Jan 01, 2018 4:11 am

add some documents

+1 .. We know documentation takes time, but the rc features cannot be really well tested w/o at least basic suggestions

SimonK · Tue Jan 02, 2018 1:22 pm

@strods why isnt wiki thedude changelog not updated?

msatter · Tue Jan 02, 2018 3:13 pm

There is a backlog of items in the changelogs to be documented in the WiKi and when you look at the Hairpin Nat page it is 7 years old and there has been a change in RouterOS (local port incl. WanIP) that comes in handy for many users of RouterOS.

However there was today change in the IPSEC page which now has an clear table of which equipment is supporting which encryption and makes it all very clear and easy to understand.

Wed Jan 03, 2018 2:35 pm

Version 6.42rc5 has been released.

Changes since previous release:
*) bridge - fixed bridge related settings conversation during upgrade from pre-v6.41 bridge implementation (introduced v6.41);
*) bridge - properly update "actual-mtu" after MTU value changes (introduced v6.41);
*) capsman - improved CAPsMAN responsiveness on systems with large amount of CAP interfaces;
*) detnet - additional work on "detect-internet" implementation;
*) detnet - fixed "detect-internet" feature unavailability if router had too long identity (introduced v6.41);
*) discovery - fixed discovery related settings conversation during upgrade from pre-v6.41 discovery implementation (introduced v6.41);
*) firewall - fixed "tls-host" firewall matcher (introduced v6.41);
*) ike1 - display error message when peer requests "mode-config" when it is not configured;
*) ike1 - fixed "aes-ctr" and "aes-gcm" encryption algorithms (introduced v6.41);
*) ike2 - improve half-open connection handling;
*) interface - improved interface configuration responsiveness;
*) log - properly report bridge interface MAC address changes;
*) poe-out - do not show "poe-out-current" on devices which can not determine it;
*) rb1100ahx4 - fixed reset button responsiveness when regular firmware is used;
*) ssh - improved key import error messages;
*) tile - added "aes-ctr" hardware acceleration support;
*) tr069-client - fixed HTTPS authentication process;
*) wireless - fixed nv2 protocol on ARM platform SXTsq devices;
*) wireless - improved wireless scan functionality for devices with multiple wireless interfaces;

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

zryny4 · Wed Jan 03, 2018 5:34 pm

I have a bootloop after upgrading my hap ac lite from rc2 to rc5...

Wed Jan 03, 2018 5:40 pm

I have a bootloop after upgrading my hap ac lite from rc2 to rc5...

What configuration you had on the hap ac lite?

zryny4 · Wed Jan 03, 2018 5:48 pm

What configuration you had on the hap ac lite?

capsman with local wifi and map lite on ether5 (poe), bridge (ether3,5 + caps interfaces), ripe atlas in ether4, uplink in ether1.

pe1chl · Wed Jan 03, 2018 5:55 pm

add some documents
+1 .. We know documentation takes time, but the rc features cannot be really well tested w/o at least basic suggestions

Yes, all changes affecting commands and parameters should be documented on the Wiki.
It is not acceptable to have to manually check all change lists when trying to figure out how to use commands.
(especially the details of parameters)

Maybe the Wiki should be split in current and release candidate branches so new features can be added in the release candidate
branch and moved over to the current branch once it has been released.
When each new feature in the release candidates is not immediately documented in the Wiki, a backlog will develop and "making the
documentation uptodate" will become an every higher mountain.

Wed Jan 03, 2018 8:40 pm

Description is included in each and every related wiki page:
tls-host (string; Default: ) - Allows to match traffic based on TLS hostname. Accepts GLOB syntax for wildcard matching. Note that matcher will not be able to match hostname if TLS handshake frame is fragmented into multiple TCP segments (packets).

pe1chl · Wed Jan 03, 2018 9:44 pm

The Wiki comment is more generic. New features are not always added to the wiki.
E.g. the option PEAP for eap-methods in the wireless security profiles has never been added to the documentation, although several threads of people waiting for this are on the forum.

raffav · Thu Jan 04, 2018 12:48 pm

Get boot loop on CRS125-24G-1S-2HnD
after upgrade to rc5

It is something related to capsman , i think
if disable cap function it stop looping

AlainCasault · Thu Jan 04, 2018 3:45 pm

add some documents
+1 .. We know documentation takes time, but the rc features cannot be really well tested w/o at least basic suggestions
Yes, all changes affecting commands and parameters should be documented on the Wiki.
It is not acceptable to have to manually check all change lists when trying to figure out how to use commands.
(especially the details of parameters)

Maybe the Wiki should be split in current and release candidate branches so new features can be added in the release candidate
branch and moved over to the current branch once it has been released.
When each new feature in the release candidates is not immediately documented in the Wiki, a backlog will develop and "making the
documentation uptodate" will become an every higher mountain.

+1!!!!

Sent from Tapatalk

Thu Jan 04, 2018 4:14 pm

Version 6.42rc6 has been released.

Changes since previous release:
*) btest - fixed TCP test accuracy when low TX/RX rates are used;
*) crs317 - improved transmit performance between 10G and 1G ports;
*) dhcpv6-client - added possibility to specify options (CLI only);
*) snmp - added w60g support;
*) wireless - fixed device becoming unresponsive (introduced in v6.42rc5);

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

marcin21 · Thu Jan 04, 2018 7:30 pm

!) wireless - new driver with initial support for 160 and 80+80 MHz channel width;

where to find this feature ?
what hardware is supported to test 160mhz channel width?

mszru · Thu Jan 04, 2018 10:03 pm

!) wireless - new driver with initial support for 160 and 80+80 MHz channel width;
where to find this feature ?
what hardware is supported to test 160mhz channel width?

This new driver is needed to take advantage of 802.11ac Wave 2 wireless devices which MikroTik does not have currently (if I am not mistaken). Please follow the link viewtopic.php?f=21&t=123936&p=626003&hilit=160#p626003 with a brief discussion.

You may also want to read the FAQ for more details on Wave 2:

Wave 2, a superset of Wave 1, requires new hardware in both access points and client devices to support the additional 802.11ac capabilities such as MU-MIMO, channel widths up to 160 MHz, and the potential for a fourth spatial stream.

marcin21 · Thu Jan 04, 2018 10:21 pm

I've found that QCA9888 is 80+80mhz capable
https://www.qualcomm.com/products/qca9888

seems that Omnitik AC has one, or am I mistaken?

Thu Jan 04, 2018 10:55 pm

Please note that this topic is made in order to resolve software issues introduced in 6.42rc versions before version becomes 6.42.

If you have questions about version which is not 6.42rc, then write to support@mikrotik.com, create a new topic in forum or write into already existing topic made for concrete version.

Fri Jan 05, 2018 4:32 am

This new driver is needed to take advantage of 802.11ac Wave 2 wireless devices which MikroTik does not have currently (if I am not mistaken).

The SXTsq AC is 802.11ac Wave2. As is the un-announced cAP AC which has passed FCC testing.

I expect to see a bunch more Mikrotik products be given the ARM+802.11ac Wave2 makeover in the coming months.

anuser · Fri Jan 05, 2018 3:05 pm

The SXTsq AC is 802.11ac Wave2.

Thanks for the info. I haven´t noticed the IPQ4018 on the product page

typicalwisp · Fri Jan 05, 2018 8:56 pm

The new "/interface wireless access-list allow-signal-out-of-range" feature in 6.41 dramatically improved roaming wireless clients' connectivity. Thanks! Is it possible to add this functionality to "/caps-man access-list" as well? I am getting quite a few too-strong and too-weak disconnects on CAP managed APs:

12:32:29 caps,info XX:XX:XX:XX:XX:XX@cap6 connected 
12:32:32 caps,info XX:XX:XX:XX:XX:XX@cap6 disconnected, too strong signal 
12:32:37 caps,info XX:XX:XX:XX:XX:XX@cap6 connected 
12:32:41 caps,info XX:XX:XX:XX:XX:XX@cap6 reassociating 
12:32:41 caps,info XX:XX:XX:XX:XX:XX@cap6 connected 
12:32:53 caps,info XX:XX:XX:XX:XX:XX@cap6 disconnected, too strong signal 
12:32:56 caps,info XX:XX:XX:XX:XX:XX@cap6 connected 
12:32:59 caps,info XX:XX:XX:XX:XX:XX@cap6 disconnected, too weak signal

mistry7 · Fri Jan 05, 2018 11:23 pm

I've found that QCA9888 is 80+80mhz capable
https://www.qualcomm.com/products/qca9888

seems that Omnitik AC has one, or am I mistaken?

No Omnitik is QCA9557
And 9888 is not supportet yet!

nkourtzis · Sat Jan 06, 2018 11:57 pm

IGMP Snooping problems experienced with 6.41 and still present in 6.42rc:

- Very high traffic volume (~90Mbps) without apparent reason (VMs were not moving much data) on interfaces connecting Proxmox cluster nodes (hypervisors). During this time of high traffic, some node heartbeats were missed and nodes sporadically appeared as down, even though they were up. Just a straight bridge, no vlans. Fast forward and IGMP snooping enabled. Turning off IGMP snooping on the bridge fixed this.

- Inability of clients of vlan-tagging access points to get IP address from DHCP running on the Mikrotik, even though the VLAN and DHCP were set up correctly. The VLAN is set up in pre-6.41 style, on the bridge interface, with no vlan filtering on the bridge. Access Points are connected to the bridge ethernet ports and are tagging the traffic from clients. The DHCP server runs on the VLAN inteface. Fast forward enabled on bridge. Everything was working fine until IGMP Snooping was also enabled on the bridge. Then and after a while (not immediately), the new DHCP leases would stick in an "offered" state and logs were filled with "lease unsuccessful" messsages. Again, disabling IGMP Snooping on the bridge fixed the problem immediately.

Grickos · Tue Jan 09, 2018 1:13 am

Cap problem, easy to reproduce.
New setup, Reset Default configuration. all leave default configuration.
Set CAPsMan and CAP. The other CAPs connected to Lan are working, only the local does not work.

Firewall Filter rules block local CAP "defconf: drop all not coming from LAN."
Log:
05:42:14 firewall,info ======= input: in:(unknown 1) out:(unknown 0), proto UDP, 192.168.88.1:36345->192.168.88.1:5246, len 48
05:42:21 firewall,info ======= input: in:(unknown 1) out:(unknown 0), proto UDP, 192.168.88.1:54227->192.168.88.1:5246, len 48

If you set Filter instead of the !LAN block WAN, everything works

105547111 · Thu Jan 11, 2018 6:47 pm

IGMP Snooping problems experienced with 6.41 and still present in 6.42rc:

- Very high traffic volume (~90Mbps) without apparent reason (VMs were not moving much data) on interfaces connecting Proxmox cluster nodes (hypervisors). During this time of high traffic, some node heartbeats were missed and nodes sporadically appeared as down, even though they were up. Just a straight bridge, no vlans. Fast forward and IGMP snooping enabled. Turning off IGMP snooping on the bridge fixed this.

- Inability of clients of vlan-tagging access points to get IP address from DHCP running on the Mikrotik, even though the VLAN and DHCP were set up correctly. The VLAN is set up in pre-6.41 style, on the bridge interface, with no vlan filtering on the bridge. Access Points are connected to the bridge ethernet ports and are tagging the traffic from clients. The DHCP server runs on the VLAN inteface. Fast forward enabled on bridge. Everything was working fine until IGMP Snooping was also enabled on the bridge. Then and after a while (not immediately), the new DHCP leases would stick in an "offered" state and logs were filled with "lease unsuccessful" messsages. Again, disabling IGMP Snooping on the bridge fixed the problem immediately.

Yes - I agree totally your experience with IGMP snooping on bridges at least downstream. Main router is ccr1016, feeding 3 x downstream crs125 switches, 1 x 8 port switch, a dell centos7 server using two more CCR ethernets with VMs, DNS, FTP, etc on it as well. All off different ethers on the CCR for our LAN. A simple single bridge on the CCR with ether 1 (WAN) routed not a part of the bridge. Rest of ethers 2 to 7 are on a single bridge.

On the CCR as well as CRS, no VLANs at all simply everything is on a simple layer 2 bridge on each device. Yet after a day of enabling IGMP snooping on the CCR and the CRS-125's all my DLNA started (both wired and wireless devices) began to drop randomly stop and drop streams during playing (never ever had this) and then the DLNA devices start disappearing from the list of available DLNA servers.

I disabled IGMP snooping only on all the downstream devices, 3 x crs125, and the 3 x 951g using as wireless access points (come off the crs125 anyway), but left IGMP snooping enabled on the CCR.

As soon as I did this all the issues wen't away.

I tried then adding PIM on the CCR and CRS but as soon as IGMP snooping is on DLNA breaks. Once a device disappears from the DLNA list, disable and re-enable the ether, reboot the actual client and DLNA server, remove the ethers physically, no difference the device never shows up as a DLNA server, or the client can't see any. But its working you can https, or ftp, just the DLNA. Only a reboot of the actual crs switch resumes DLNA again until it stops.

There's definitely an issue with IGMP snooping. Over a week solid now without IGMP snooping no DLNA issues.

anuser · Thu Jan 11, 2018 9:50 pm

The new "/interface wireless access-list allow-signal-out-of-range" feature in 6.41 dramatically improved roaming wireless clients' connectivity. Thanks!

Interesting, how does this feature work at all?

typicalwisp · Thu Jan 11, 2018 10:42 pm

The new "/interface wireless access-list allow-signal-out-of-range" feature in 6.41 dramatically improved roaming wireless clients' connectivity. Thanks!
Interesting, how does this feature work at all?

Here is a lengthy discussion:
viewtopic.php?t=124884
Basically, in a wireless access-list you can specify a signal range required to establish/maintain a connection. Bugs in the client radio, bugs in the AP radio, or actual signal changes will cause a client to be disconnected from the AP when the calculated signal strength goes out of that range. This sounds good in theory, but in practice this happens for certain clients regardless of their distance to the AP (likely a bug in radio firmware.) Because the offending clients only exceed this signal range for a small number of frames at a time, the new access-list default in 6.41 is to allow a client to be out of signal range for 10 seconds before the rule is triggered.

In my experience, using a signal range of -120..120 (or not specifying a signal range at all) in the access list still results in both "too strong" and "too weak" events that disconnect clients. The "allow-signal-out-of-range" keeps these clients connected to the AP while still preventing low-signal clients from initially connecting. Unfortunately, this change didn't get implemented in caps-man when it was put into /interface wireless access-list.

biatche · Fri Jan 12, 2018 6:36 am

The new "/interface wireless access-list allow-signal-out-of-range" feature in 6.41 dramatically improved roaming wireless clients' connectivity. Thanks!
Interesting, how does this feature work at all?
Here is a lengthy discussion:
viewtopic.php?t=124884
Basically, in a wireless access-list you can specify a signal range required to establish/maintain a connection. Bugs in the client radio, bugs in the AP radio, or actual signal changes will cause a client to be disconnected from the AP when the calculated signal strength goes out of that range. This sounds good in theory, but in practice this happens for certain clients regardless of their distance to the AP (likely a bug in radio firmware.) Because the offending clients only exceed this signal range for a small number of frames at a time, the new access-list default in 6.41 is to allow a client to be out of signal range for 10 seconds before the rule is triggered.

In my experience, using a signal range of -120..120 (or not specifying a signal range at all) in the access list still results in both "too strong" and "too weak" events that disconnect clients. The "allow-signal-out-of-range" keeps these clients connected to the AP while still preventing low-signal clients from initially connecting. Unfortunately, this change didn't get implemented in caps-man when it was put into /interface wireless access-list.

If my present rule allows -80..120 and rejects -120..-81 ; what are the precise rules i want for the new option? mind pasting the lines? I suppose the involved lines should go above my present rules right?

and Dear MT, please make this possible for capsman, I've been having these connect/disconnect issues for a very very long time.. and never ever knew what the problem was.

JimmyNyholm · Fri Jan 12, 2018 5:17 pm

Version 6.42rc5 has been released.
*) bridge - properly update "actual-mtu" after MTU value changes (introduced v6.41);

Please explain.

typicalwisp · Fri Jan 12, 2018 5:56 pm

If my present rule allows -80..120 and rejects -120..-81 ; what are the precise rules i want for the new option? mind pasting the lines? I suppose the involved lines should go above my present rules right?

I think this is what the documentation should say (just guessing for min-max time):

allow-signal-out-of-range (always | time [0s..1d]; Default: 10s)
Ignore signal-range in this rule for the specified time period.

This seems to be working for me:

/interface wireless access-list
print
# For the "allow connections" rule allow 10 seconds of out-of-range signal:
set 1 allow-signal-out-of-range=10s

This may result in clients being able to connect for 10 seconds even though they are too far away. Is there a way to prevent this? These clients will take up a large portion of the AP's time/bandwidth through re-transmissions and a low symbol rate. A different solution to this problem is to throw out the "outlier" (less than -120dBm, greater than +120dBm) signal strength readings and average the signal level over a given number of "valid" frames. It adds complication when accepting a new client and creates additional memory requirements, but may result in a more desirable AP behavior. It would be really nice to be able to see the averaged signal strength for this type of rule in the debug logs... but now I'm running off the rails into "feature-request" territory. Strods, is there a better place for this discussion? I assume that the "missing from caps-man in 6.42rc" belongs here, but talking about how to use the feature should be discussed somewhere else.

WireDick · Sun Jan 14, 2018 6:12 pm

*) tile - added "aes-ctr" hardware acceleration support;

Can someone explain to me?

Sun Jan 14, 2018 6:51 pm

*) tile - added "aes-ctr" hardware acceleration support;

Can someone explain to me?

https://wiki.mikrotik.com/wiki/Manual:I ... encryption

raffav · Sun Jan 14, 2018 10:07 pm

MT Support
freq.usage and wifi snooper on RC6 is not working
it get freq monitor is not running / and ERROR not Running

interface wireless frequency-monitor wlan1 
         FREQ          USE         NF

frequency-monitor not running

 /interface wireless snooper> snoop wlan1 
CHANNEL                                                                                                                        USE        BW NET-COUNT NOISE-FLOOR STA-COUNT

not running

Mon Jan 15, 2018 3:39 pm

rc9 is released

What's new in 6.42rc9 (2018-Jan-15 09:07):

Changes since previous release:
*) bridge - fixed interface list moving in "/interface bridge port" menu;
*) bridge - fixed hw-offload disabling for Mediatek and Realtek switches when STP/RSTP configured;
*) bridge - fixed hw-offload disabling when adding a port with "horizon" set;
*) bridge - fixed repetitive port "priority" set;
*) bridge - fixed situation when packet could be sent with local MAC as dst-mac;
*) crs1xx/2xx - added BPDU value for "ingress-vlan-translation" menu "protocol" option;
*) crs3xx - hide deprecated VLAN related settings in "/interface ethernet switch port" menu;
*) dhcpv4-server - fixed framed and classless route received from RADIUS server;
*) dhcpv6-client - added info exchange support;
*) dhcpv6-client - added support for options 15 and 16;
*) dhcpv6-server - added DHCPv4 style user options;
*) ike1 - do not accept "mode-config" reply more than once;
*) ike2 - delay rekeyed peer outbound SA installation;
*) ipsec - properly update IPsec secret for IPIP/EoIP/GRE dynamic peer;
*) kidcontrol - added initial support for "/ip kid-control" feature (CLI only);
*) lte - do not add DHCP client on LTE modems that doesn't use DHCP;
*) lte - fixed DHCP client adding for MF823 modem;
*) mac-ping - fixed duplicate responses;
*) modem - added initial support for AC340U;
*) ppp - allow to override remote user PPP profile via "Mikrotik-Group";
*) ppp - changed default value of "route-distance" to 1;
*) quickset - show "G" flag for guest users;
*) radius - added warning if PPP authentication over RADIUS is enabled;
*) radius - increase allowed RADIUS server timeout to 60s;
*) snmp - allow also IPv6 on default public community;
*) snmp - fixed SNMP for W60G interfaces;
*) tile - improved stability in high throughput HW accelerated IPsec setups ("/system routerboard upgrade" required);
*) tr069-client - added "DownloadDiagnostics" and "UploadDiagnostics";
*) webfig - added support for proper default policies when adding script or scheduler job;
*) webfig - fixed bridge port sorting order by name;
*) winbox - added possibility to delete SMS from Inbox;
*) winbox - allow to open bridge host entry;
*) winbox - allow to specify "to-ports" for "action=masquerade";
*) winbox - do not show "hw" option on non-ethernet interfaces;
*) winbox - do not show VLAN related settings in switch port menu on CRS3xx boards;
*) winbox - fixed "/tool e-mail send" attachment behaviour;
*) winbox - improved stability when using trackpad scrolling in large lists;
*) wireless - fixed frequency-monitor/sniffer/snooper; (introduced in v6.42rc);
*) wireless - fixed nv2 (introduced in v6.42rc);
*) wireless - updated "Czech Republic" country 5.8 GHz frequency range;

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

Mon Jan 15, 2018 4:29 pm

How the kid control should work?

Mon Jan 15, 2018 4:32 pm

Jarda https://wiki.mikrotik.com/wiki/Manual:Kid-control
Current implementation is very basic. In future content filter is planned or other features.

Mon Jan 15, 2018 4:38 pm

Sorry for my stupidity, I couldn't imagine that you have already created a documentation wiki page for that. Thanks for the link, it looks promising.

parham · Mon Jan 15, 2018 6:46 pm

*) radius - increase allowed RADIUS server timeout to 60s;

Thanks, Guys.

alexcherry · Mon Jan 15, 2018 6:57 pm

I checked to override with Radius remote user PPP profile ("Mikrotik-Group" attribute) - it works fine.
This is a nice feature that some people where asking for a long time. Now we can define several profiles and set different values there, such as speed per profile, queue type, different pool and then using Radius server say where PPPoE customer belongs.

There is one important option in PPPoE profile - Parent.
The question is how to setup the parent for Simple Queue correctly ? PPPoE queue of customer has a target <pppoe-test@connect>, what should be set to the Parent target ? Remember that it should be set there before any customer connects, because parent is a static queue.

The option is to set 0.0.0.0/0, but then, we can have only one parent per router, because if I add second parent, the 0.0.0.0/0 of previous one will take the whole traffic.

Here is an example, we have two parents, Regular and Business. There are two PPP server profiles, when customer is from business - he is set to Business profile and put under Business Parent Queue.

Picture -

Why this is nice to implement - because we can add Simple Queue to parents and according to Janis presentation, it should bring better performance on CCR routers with thousands of Simple queues.

alexcherry · Mon Jan 15, 2018 8:12 pm

Ok, guys, I have found the answer on my previous question.

Final solution is not that automated as I wanted, but still better than nothing.

Instead of setting 0.0.0.0 to profiles we should do following :

1. Define different IP pool for profile. For example 192.168.101.0/24 - regular users, 192.168.250.0/24 - business users.
2. To parent I can set the range that corresponds to the pool. So, Business Parent queue Target = 192.168.250.0/24. Regular Parent Queue Target = 192.168.101.0/24.
3. I can define the speed limits for Plans inside PPP profile, or Radius can send it as Mikrotik-rate-limit attribute.
4. When PPPoE clients connect, Radius answers with "Mikrotik-Group" = business or "Mikrotik-Group" = regular and Queue is set under correct Partner.

Partner queue can have a Speed limitation - this will provide contention scenario, or Partner can be "unlimited", then Simple Queues will be just well balanced on CCR cores.

Picture :

Mon Jan 15, 2018 8:55 pm

*) dhcpv4-server - fixed framed and classless route received from RADIUS server;

What exactly was "fixed" ?

Alessio Garavano · Tue Jan 16, 2018 8:28 am

BAD WIRELESS!!!

Tested in a SXT in "station-bridge" in production connected to a Sextant in "ap-bridge" mode and was lost

tomorrow need to go physically to the tower to downgrade by ethernet... the SXT client is in Wireless-Protocol=nv2-nstreme, changed the Sextant AP to NV2 or Nstreme and no connect... In rc5 was the same and by the changelog this solve wireless problems and i take the risk... NOT SOLVED!

Chupaka · Tue Jan 16, 2018 12:48 pm

You mean, you're using RC versions on towers? Dude, you're crazy

th0massin0 · Tue Jan 16, 2018 1:57 pm

Dear Mikrotik Developers,
could you consider to support VirtIO-SCSI: ( viewtopic.php?f=15&t=124905&start=100#p626094 ), please?

msatter · Tue Jan 16, 2018 3:30 pm

I can confirm that on my 750Gr3 now the conversion from master-slave to bridge works, and that on L2TP/IPSEC now dail-on-demand/timeout is now respected.

Updated: "*) bridge - fixed hw-offload disabling for Mediatek and Realtek switches when STP/RSTP configured;"
upload speed through router is still 500 Mbit/s slower when STP/RSTP is activated on the Bridge

Alessio Garavano · Tue Jan 16, 2018 5:34 pm

BAD WIRELESS!!!

Tested in a SXT in "station-bridge" in production connected to a Sextant in "ap-bridge" mode and was lost tomorrow need to go physically to the tower to downgrade by ethernet... the SXT client is in Wireless-Protocol=nv2-nstreme, changed the Sextant AP to NV2 or Nstreme and no connect... In rc5 was the same and by the changelog this solve wireless problems and i take the risk... NOT SOLVED!

UPDATE: Nstreme work fine... i add the "Management Protection Key" of the Sextant AP to the SXT station and connect OK with Nstreme... NV2 is not working!

Tue Jan 16, 2018 5:51 pm

You should never have queue with target 0.0.0.0/0. Such queue can limit traffic for specific IP only on one direction (upload and download is limited only by download limit) because every IP goes under 0.0.0.0/0 so queue does not know which is download and which is upload. For example, traffic between x.x.x.x and y.y.y.y will be always matched by this queue under download since x.x.x.x and y.y.y.y is under 0.0.0.0/0. If you set target as x.x.x.x then queue will know that if source address is x.x.x.x, then it is upload and if x.x.x.x is destination, then it is download.

Tue Jan 16, 2018 5:57 pm

Updated: "*) bridge - fixed hw-offload disabling for Mediatek and Realtek switches when STP/RSTP configured;"
upload speed through router is still 500 Mbit/s slower when STP/RSTP is activated on the Bridge

That's as expected since hw-offloaded STP/RSTP is not supported on Realtek, Mediatek and ICPlus175D switches: https://wiki.mikrotik.com/wiki/Manual:S ... Offloading. As I understand when you enable STP/RSTP on one of these switches the hw-offload should automatically be turned off, but that didn't happen before, and now they fixed that.

idlemind · Tue Jan 16, 2018 9:33 pm

*) dhcpv6-client - added info exchange support;
*) dhcpv6-client - added support for options 15 and 16;
*) dhcpv6-server - added DHCPv4 style user options;

While it is a worthy mention and any improvement in DHCPv6 support is welcome I feel it is important to remind you that your team is sorely lacking in this area from even a residential router perspective. Look at how OpenWRT / LEDE implements DNSMASQ in LUCI for a valuable interface. We need to be allow per server instance to set the network bits used, aka VLAN11 should always be provider::/56 ending in 11 like provider11::/64, this implies nesting or parent/child functionality that is currently not allowed with your pool system. Additionally, the DHCPv6 server needs to support client address allocation before it is useful. In parallel the SLAAC implementation should not parrot the upstream DNS servers, instead the administrator should be able to set their own. If I use your SLAAC implementation it results in all of my IPv6 DNS queries, which could be a single stack area of my network, not being cached.

Grickos · Tue Jan 16, 2018 11:53 pm

I have a strange problem.
PPPoe connectivity to ISP modem.
Local devices can not connect to the web site IP address 185.58.74.135 which hosts for a larger number of sites. It can be checked which pages do not work with reverse ip (for example, https://www.ipneighbour.com)

The ROS 6.39.3 version works ok.
The Ros 6.41 and 6.42RC does not work.
Other sites work normally. I do not know if something else site does not work.

liviu2004 · Wed Jan 17, 2018 8:32 am

My site does not work either, I have a created a topic for that.

Grickos · Wed Jan 17, 2018 11:14 pm

No feedback what's wrong with pppoe.?
It's not a problem for a RC release, but a current. Especially at this point, Downgrade is not simply because of the implementation bridge.
This is the main thing about roter, website review. it is not a special possibility. Some hosting does not open, they which have about 100 websites.
My production is at 6.39.3, so it's not terrible. At work and at home in newer versions.
Tnx liviu2004 on the topic, I thought something was wrong with me.

Best regards.
Sorry for bad English

soonwai · Thu Jan 18, 2018 7:32 am

No feedback what's wrong with pppoe.?
It's not a problem for a RC release, but a current. Especially at this point, Downgrade is not simply because of the implementation bridge.
This is the main thing about roter, website review. it is not a special possibility. Some hosting does not open, they which have about 100 websites.
My production is at 6.39.3, so it's not terrible. At work and at home in newer versions.
Tnx liviu2004 on the topic, I thought something was wrong with me.

Best regards.
Sorry for bad English

I tested and have the same problem. Test done with veritas.hr 185.58.74.135. IPv4 only.
RB750Gr3 6.42rc6: Website does not load
Mobile data on my smartphone: Website loads OK

Another shared host website, rtcs.com.my, loads fine.

Chupaka · Thu Jan 18, 2018 9:02 am

6.41, sites from https://www.ipneighbour.com/#/lookup/185.58.74.135 list open normally. What error do you see?

Grickos · Thu Jan 18, 2018 5:13 pm

The list opens normally, the web pages on that list do not open. For example, the web Page pupilla.hr, boletus.hr ...
Just through the Mikrotik pppoe connection is a problem. "Status do not get off of "syn sent"
I have print logs, but the liviu2004 explained everything in his topic.
( I have a backup connection, pppoe on the router ISP, a Mikrotik connected via Lan to that router. . so the company that has to have access to one page has redirected it.)

mrz · Thu Jan 18, 2018 6:23 pm

New RC version released

What's new in 6.42rc11 (2018-Jan-18 12:42):

*) bridge - fixed IGMP Snooping after disabling/enabling bridge;
*) bridge - fixed allowed MSTI priority values;
*) certificate - do not use utf8 for SCEP challange password;
*) chr - automaticly generate new systemID on first startup;
*) crs326 - fixed possible packet leaking from CPU to switch ports;
*) dhcpv4-server - added "dns-none" option to "/ip dhcp-server network dns";
*) dhcpv6-client - implement confirm after reboot;
*) filesystem - fixed situations when "/flash" directory lost files after upgrade;
*) ipsec - fixed AES-CTR and AES-GCM support on RB1200;
*) kidcontrol - added initial support for "/ip kid-control" feature;
*) ppp - changed default value of "route-distance" to 1;
*) ppp - fixed change-mss funcionality in some specific traffic (introduced in v6.41);
*) webfig - fixed MAC address ordering;
*) webfig - fixed wireless snooper address, SSID and other column ordering;
*) winbox - added "dhcp-option-set" to DHCP server;
*) winbox - added "insert-queue-before" to DHCP server;
*) winbox - added DHCPv6 client info request type and updated statuses;
*) winbox - show Bridge Port PVID column by default;
*) wireless - fixed nv2 (introduced in v6.42rc);

soonwai · Thu Jan 18, 2018 6:43 pm

The list opens normally, the web pages on that list do not open. For example, the web Page pupilla.hr, boletus.hr ...
Just through the Mikrotik pppoe connection is a problem. "Status do not get off of "syn sent"
I have print logs, but the liviu2004 explained everything in his topic.
( I have a backup connection, pppoe on the router ISP, a Mikrotik connected via Lan to that router. . so the company that has to have access to one page has redirected it.)

It's OK now with rc11. Tried veritas.hr, pupilla.hr and boletus.hr. All loading ok.

I guess this fixed it:
*) ppp - fixed change-mss funcionality in some specific traffic (introduced in v6.41);

pe1chl · Thu Jan 18, 2018 7:19 pm

*) ppp - fixed change-mss funcionality in some specific traffic (introduced in v6.41);

Please give a bit more detail and/or workaround for this issue. Can it be fixed by removing change-mss in PPP and adding a change-mss firewall mangle rule?
When will 6.41.1 be released to fix it?

msatter · Thu Jan 18, 2018 8:13 pm

What could have been changed?!
RC9: *) ppp - changed default value of "route-distance" to 1;
RC11: *) ppp - changed default value of "route-distance" to 1;

Indeed it is really time to roll-out 6.41.1

mrz · Thu Jan 18, 2018 8:22 pm

*) ppp - fixed change-mss funcionality in some specific traffic (introduced in v6.41);
Please give a bit more detail and/or workaround for this issue. Can it be fixed by removing change-mss in PPP and adding a change-mss firewall mangle rule?
When will 6.41.1 be released to fix it?

Yes. You can add change mss mangle rules manually to fix the problem, you don't need to turn off setting in ppp profile.

msatter · Thu Jan 18, 2018 8:52 pm

I have now some new behaviour (RC11) when using when using /IP-firewall-Mangle-Extra-Dst. Address Type.

I used here Address Type "!-local" to exclude the local addresses even it was not on the router itself but directly connected to one port. I have now to include the complete local address range to have it working as before. I use that to decide if a address is in the local network or the WAN and now I have to filter extra on 192.168.88.0/24 to make that decision.

It is now working as in the WiKi manual so I have to do more than before.

UPDATE:

I am back and while investigating why the above did not work any more my router disappeared, not literal but from my network, and I had to restore what was not possible because it wanted a password that was not there and was not needed. [Ticket#2018011822005351]

I went back to 6.40.5, never got a stable 6.41, and build-up from that back to 6.42.RC9 and there also "local" worked again.

The crash was my fault and I was looking at /IP addresses and noticed the line "192.168.88.1/24 192.168.88.0 bridge1" and I removed the "/24" because the Network was stated.....bye bye connection and so router and up to a reset config. DON'T TRY THIS AT HOME OR WORK!!

So the workings of "local" changed in RC11 .

[Ticket#2018011822005351] has now been resolved and it was an error on my side that I missed to hit the checkbox "Don't Encrypt" that time. Potential to avoid this confusing is still there in the graphical interface so that when you miss to click you know what is going to happen.

Grickos · Thu Jan 18, 2018 9:59 pm

The list opens normally, the web pages on that list do not open. For example, the web Page pupilla.hr, boletus.hr ...
Just through the Mikrotik pppoe connection is a problem. "Status do not get off of "syn sent"
I have print logs, but the liviu2004 explained everything in his topic.
( I have a backup connection, pppoe on the router ISP, a Mikrotik connected via Lan to that router. . so the company that has to have access to one page has redirected it.)
It's OK now with rc11. Tried veritas.hr, pupilla.hr and boletus.hr. All loading ok.

I guess this fixed it:
*) ppp - fixed change-mss funcionality in some specific traffic (introduced in v6.41);

Yes, I saw that fix, everything is okay now.

Grickos · Thu Jan 18, 2018 10:22 pm

One thing has not worked on Winbox for a long time.
If you set Schedule "Start Time = Startup", Next Run shows ok. If you change your mind and put it for example "Start Time = 00:04:00" "Interval = 1d 00:00:00". "Next Run" shows some strange time.
The only way to gain proper time is to create a new Schedule or set time in Terminal. The terminal works fine.

msatter · Fri Jan 19, 2018 3:56 pm

Did anyone else noticed a change (6.42.RC11) in behaviour of the Address Type: "local" as described in posting: viewtopic.php?f=21&t=129034&start=50#p637725?

Chupaka · Fri Jan 19, 2018 4:10 pm

Did anyone else noticed a change (6.42.RC11) in behaviour of the Address Type: "local" as described in posting: viewtopic.php?f=21&t=129034&start=50#p637725?

dst-address-type=local should not catch addresses from local network. it should work just as described in docs: "local - if dst-address is assigned to one of router's interfaces"

https://wiki.mikrotik.com/wiki/Manual:I ... all/Filter

anuser · Fri Jan 19, 2018 7:39 pm

Version 6.42rc5 has been released.
:
*) capsman - improved CAPsMAN responsiveness on systems with large amount of CAP interfaces;
:

How many CAP interfaces are we talking about?

zajadacz · Sat Jan 20, 2018 12:04 am

*) kidcontrol - added initial support for "/ip kid-control" feature (CLI only);

Why are you working on a new features that are not very important for Mikrotik users (there is firewall which can do much more for experienced users) and you are not fixing existing important issues? When you will solve a problem with with wireless compatibility for low-end client devices? viewtopic.php?f=7&t=102908#p618041

biatche · Sat Jan 20, 2018 3:48 am

*) kidcontrol - added initial support for "/ip kid-control" feature (CLI only);
Why are you working on a new features that are not very important for Mikrotik users (there is firewall which can do much more for experienced users) and you are not fixing existing important issues? When you will solve a problem with with wireless compatibility for low-end client devices? viewtopic.php?f=7&t=102908#p618041

Yah I was wondering about that too. I'm sure Amazon are very much looking forward to flashing the latest RC so they can have kid control.

Could work on things like LACP with hardware offload.

and allow-signal-out-of-range for capsman............................... critically....... important.............................................

msatter · Sat Jan 20, 2018 10:58 am

Did anyone else noticed a change (6.42.RC11) in behaviour of the Address Type: "local" as described in posting: viewtopic.php?f=21&t=129034&start=50#p637725?
dst-address-type=local should not catch addresses from local network. it should work just as described in docs: "local - if dst-address is assigned to one of router's interfaces"

https://wiki.mikrotik.com/wiki/Manual:I ... all/Filter

It was not mentioned in the RC11 release notes and it good that Mikrotik fixed this because this discrepancy between the docs and reality has been present in at least 6.40 and 6.41 and up to 6.42RC9.

Chupaka · Sat Jan 20, 2018 12:41 pm

It was not mentioned in the RC11 release notes and it good that Mikrotik fixed this because this discrepancy between the docs and reality has been present in at least 6.40 and 6.41 and up to 6.42RC9.

Can't confirm on 6.41:

/ip firewall filter
add action=accept chain=output dst-address-type=local log=yes

Router pings itself (192.168.88.1/24) - packets are in log.
Router pings its neighbour (192.168.88.

- no logging. So, in 6.41 dst-address-type=local also works as expected.

msatter · Sat Jan 20, 2018 4:16 pm

It was not mentioned in the RC11 release notes and it good that Mikrotik fixed this because this discrepancy between the docs and reality has been present in at least 6.40 and 6.41 and up to 6.42RC9.
Can't confirm on 6.41:

/ip firewall filter
add action=accept chain=output dst-address-type=local log=yes
Router pings itself (192.168.88.1/24) - packets are in log.
Router pings its neighbour (192.168.88. - no logging. So, in 6.41 dst-address-type=local also works as expected.

/ip firewall mangle
add action=mark-connection chain=prerouting comment="VPN connection mark" connection-mark=no-mark \
    dst-address-type=!local dst-port=80,443 new-connection-mark=VPN1 passthrough=yes \
    per-connection-classifier=src-port:2/0 protocol=tcp src-address-list=PrivateVPN
        add action=mark-connection chain=prerouting comment="VPN connection mark" connection-mark=no-mark \
    dst-address-type=!local dst-port=80,443 new-connection-mark=VPN2 passthrough=yes \
    per-connection-classifier=src-port:2/1 protocol=tcp src-address-list=PrivateVPN

And the line above does not catch local traffic in RC9 but in RC11 it does. My computer (on the PrivateVPN list) goes to a local device with a webpage on port 80 (non HTTPS) and in RC11 it is marked as traffic that has to go through the VPN.

To make this future proof I am going to add the local network to the address list that unmarks connections that should not go through the VPN.

Update: I have now installed RC11 again and it works now correctly. All dst-address-type=local are now not more present in that part of Mangle so that won't bother me again.

Why it now works and the previous time is still an mystery to me and also why one line underneath needed extra filters to work despite they where not needed. Now it goes correctly as in the manual.

pe1chl · Sat Jan 20, 2018 7:01 pm

*) kidcontrol - added initial support for "/ip kid-control" feature (CLI only);
Why are you working on a new features that are not very important for Mikrotik users (there is firewall which can do much more for experienced users) and you are not fixing existing important issues?

I always hope (or try to fool myself?) that silly things like kid-control or "detect internet" are assignments for a trainee or graduate, and the normal staff is working on the important stuff (or maybe even on version 7!).
Indeed it would be a shame when time that would otherwise be spent on important stuff is instead wasted on these things...

mistry7 · Sat Jan 20, 2018 10:41 pm

*) kidcontrol - added initial support for "/ip kid-control" feature (CLI only);
Why are you working on a new features that are not very important for Mikrotik users (there is firewall which can do much more for experienced users) and you are not fixing existing important issues?
I always hope (or try to fool myself?) that silly things like kid-control or "detect internet" are assignments for a trainee or graduate, and the normal staff is working on the important stuff (or maybe even on version 7!).
Indeed it would be a shame when time that would otherwise be spent on important stuff is instead wasted on these things...

What you see is product focus on home router, cheap home router, not at wisp wireless anymore....
If WISP is in focus we had this features before 2016:
- Spectral scan
- GPS Sync
- working NV2 or NV3

dadoremix · Sat Jan 20, 2018 11:25 pm

Make some app
To controll 100+ mikrotik os remote
Like ubiquiti have
Dude is not that app
I can upgrade via dude
But how i can pull backup?
One click? No
Maybe with massive script, bum im not programer

msatter · Sat Jan 20, 2018 11:46 pm

I only know this APP viewtopic.php?t=98407 and not the Dude APP you mention.

Nando_lavras · Mon Jan 22, 2018 2:36 pm

Since 6.41:

- bridge - fixed hw-offload disabling when adding a port with "horizon" set;

I've tried with the last 6.42RC11 in a CRS326, when i add a port with horizon=1 this port not activate the hw-offload, this is correct? I trying to isolate all ports, all the ports have to communicate only with the uplink port, but without loosing the hw-offload.

Fernando.

anuser · Mon Jan 22, 2018 3:10 pm

Is there any difference between 6.42rc11 and 6.41 concerning wifi? Reason I ask: Today I tested with one customer and a smartphone with Android 7.0 He was standing in front of one wAP AC with 6.41. Signal was -61db. It used the 2.4Ghz band. He was able to connect and was thrown out of the access point after some seconds/minutes. According to the CAPSMAN controller, the reason was: "disconnected, too weak signal" I updated the wAP AC to 6.42rc11 and he´s now surfing without any problems since 40 minutes.

TestCRS · Mon Jan 22, 2018 5:02 pm

Please inform about your plans,
when will work LACP with hardware offload in RouterOS (on crs 317)?
Depends on your answer, we will buy your equipment or not.
Thank you.

biatche · Mon Jan 22, 2018 7:26 pm

Please inform about your plans,
when will work LACP with hardware offload in RouterOS (on crs 317)?
Depends on your answer, we will buy your equipment or not.
Thank you.

Yeah been waiting for it too, but they could be busy working on other extremely important enterprise features like kid control.

JimmyNyholm · Mon Jan 22, 2018 8:56 pm

HW LACP is must.

klaus007 · Mon Jan 22, 2018 10:37 pm

I'm also waiting for this feature!!

JimmyNyholm · Mon Jan 22, 2018 11:15 pm

HW LACP is must.

[Ticket#2018012222005306] RE: LACP HW CRS317-1G-16 [...]

JimmyNyholm · Mon Jan 22, 2018 11:17 pm

I would love VLan Translation on CRS317-1G-16S+RM as well... when can vi se that?

Tue Jan 23, 2018 9:02 am

Version 6.42rc5 has been released.
:
*) capsman - improved CAPsMAN responsiveness on systems with large amount of CAP interfaces;
:
How many CAP interfaces are we talking about?

More than 100 CAPs.

JimmyNyholm · Tue Jan 23, 2018 10:34 am

HW LACP is must.
[Ticket#2018012222005306] RE: LACP HW CRS317-1G-16 [...]

Hello,

We are currently working on this feature. We hope to see it soon.

Best regards,
Arturs C.

--
MikroTik.com

Come to the MUM conferences, registration open in Cameroon, Kenya, Russia (Ekaterinburg), Russia (St. Petersburg), Europe (Berlin), Australia, New Zealand! https://mum.mikrotik.com/

Got reply from support that they are working on and trying to release soon... That feels like a message all would like to hear.....

Tue Jan 23, 2018 3:45 pm

Version 6.42rc12 has been released.

Changes since previous release:

*) bridge - fixed "mst-override" export;
*) chr - added "open-vm-tools" on VMware installations;
*) chr - added "qemu-guest-agent" on KVM installations;
*) chr - added "xe-daemon" on Xen installations;
*) chr - fixed interface naming order when adding more that 4 interfaces on VMware installations;
*) chr - fixed suspend on Xen installations;
*) chr - make additional disks visible under "/disk" on Xen installations;
*) chr - make virtio disks visible under "/disk" on KVM installations;
*) dhcpv6-server - added DHCPv4 style user options (CLI only);
*) interface - improved interface configuration responsiveness;
*) ippool - added ability to specify comment (CLI only);
*) kidcontrol - added initial support for "/ip kid-control" feature;
*) ppp - fixed change-mss functionality in some specific traffic (introduced in v6.41);
*) quickset - properly detect LTE interface on startup;
*) routerboard - added RouterBOOT "auto-upgrade" after RouterOS upgrade (extra reboot required) (CLI only);
*) snmp - added "/caps-man interface print oid";
*) snmp - improved request processing performance for wireless and CAP interfaces;
*) wireless - fixed "wds-slave" channel selection when single frequency is specified;

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 expected or after crash.

th0massin0 · Tue Jan 23, 2018 4:49 pm

Does booting from VirtIO-SCSI supported?

anuser · Tue Jan 23, 2018 5:01 pm

Version 6.42rc5 has been released.
:
*) capsman - improved CAPsMAN responsiveness on systems with large amount of CAP interfaces;
:
How many CAP interfaces are we talking about?
More than 100 CAPs.

I setup a new controller (coming from the CHR release) with an RB1100AHX4 and put new CAPs (wAP AC, HAP AC, HAP AC lite) on the controller, step by step. After nearly 3 days without any problem,
I experienced my first problems again today, i.e. the controller lost the connection to all of the CAPs concurrently.

- The RB1100AHX4 is monitored from two different probes (10s ping) within my network. There was no single loss to it. My monitoring was able pull all information with SNMP. No connection loss here.
- RouterOS version on RB1100AHX4: 6.41
- RouterOS version on CAPs: 6.42rc11
- sessions displayed on RB1100AHX4 when right before the loss: ~23000
- amount of clients connected on all CAP right before the loss: 723
- CPU load on RB1100AHX4 right before the loss: CPU1: 25%, CPU2: 38%, CPU3: 19%, CPU4: 19%
- Amount of CAPS: 46
- Amount of CAP interfaces displayed within CAPSMAN => CP Interfaces: 268 (we have multiple SSIDs on 2.4Ghz and 5Ghz)
----> That´s the critical 100 "CAP interface barrier" I assume?

All CAPs tell me within their logs: "CAP connect to MikroTik (::ffff:....) failed: timeout
The CAPSMAN controller tells me for each CAP: "caps,debug [::ffff:.....,Run,[6C:3B:6B:B7:01:95]] lost connection, keepalive timeout"

So will 6.42rc11 running on the RB1100AHX4 help?
(I had those issues as well on a the CHR version before with ~80 CAPs and it didn´t matter what CPU cores I used, going from 2 core up to 16, the controller lost its connection to the CAPs)

planetcoop · Tue Jan 23, 2018 6:53 pm

Updated my btest CHR to 6.42rc12 with legit open-vmware-tools.... So nice to suspend or gracefully shutdown a CHR.

pe1chl · Tue Jan 23, 2018 7:26 pm

*) chr - added "open-vm-tools" on VMware installations;

HOORAY!!! finally!

Cha0s · Tue Jan 23, 2018 8:18 pm

*) routerboard - added RouterBOOT "auto-upgrade" after RouterOS upgrade (extra reboot required) (CLI only);

What's the point if we have to do an extra reboot?
The whole point of a feature like this would be to update both ROS and RouterBOOT with one reboot.

mervincm · Wed Jan 24, 2018 1:26 am

Any hope outstanding for hardware LACP bonded links on CRS226? been waiting for years!

Wed Jan 24, 2018 7:41 am

As many other features, also "auto-upgrade" is only in rc state and is still work on progress.

Chupaka · Wed Jan 24, 2018 8:40 am

*) chr - make virtio disks visible under "/disk" on KVM installations;

So, is it possible now to run CHR on Google Cloud Platform?..

Wed Jan 24, 2018 10:54 am

Version 6.42rc5 has been released.
:
*) capsman - improved CAPsMAN responsiveness on systems with large amount of CAP interfaces;
:
How many CAP interfaces are we talking about?
More than 100 CAPs.
I setup a new controller (coming from the CHR release) with an RB1100AHX4 and put new CAPs (wAP AC, HAP AC, HAP AC lite) on the controller, step by step. After nearly 3 days without any problem,
I experienced my first problems again today, i.e. the controller lost the connection to all of the CAPs concurrently.

- The RB1100AHX4 is monitored from two different probes (10s ping) within my network. There was no single loss to it. My monitoring was able pull all information with SNMP. No connection loss here.
- RouterOS version on RB1100AHX4: 6.41
- RouterOS version on CAPs: 6.42rc11
- sessions displayed on RB1100AHX4 when right before the loss: ~23000
- amount of clients connected on all CAP right before the loss: 723
- CPU load on RB1100AHX4 right before the loss: CPU1: 25%, CPU2: 38%, CPU3: 19%, CPU4: 19%
- Amount of CAPS: 46
- Amount of CAP interfaces displayed within CAPSMAN => CP Interfaces: 268 (we have multiple SSIDs on 2.4Ghz and 5Ghz)
----> That´s the critical 100 "CAP interface barrier" I assume?

All CAPs tell me within their logs: "CAP connect to MikroTik (::ffff:....) failed: timeout
The CAPSMAN controller tells me for each CAP: "caps,debug [::ffff:.....,Run,[6C:3B:6B:B7:01:95]] lost connection, keepalive timeout"

So will 6.42rc11 running on the RB1100AHX4 help?
(I had those issues as well on a the CHR version before with ~80 CAPs and it didn´t matter what CPU cores I used, going from 2 core up to 16, the controller lost its connection to the CAPs)

The fix should be applied on the CAPsMAN.

Wed Jan 24, 2018 3:10 pm

Version 6.42rc14 has been released.

Changes since previous release:

*) bridge - fixed ARP option changing on bridge (introduced v6.41);
*) bridge - fixed VLAN filtering when "use-ip-firewall" is enabled (introduced in v6.41);
*) certificate - added PKCS#10 version check;
*) certificate - dropped DES support and added AES instead for SCEP;
*) certificate - dropped MD5 support and require SHA1 as minimum for SCEP;
*) certificate - fixed PKCS#10 version;
*) netinstall - improved LTE package description;
*) ovpn - fixed resource leak on systems with high CPU usage;
*) ppp - added initial support for NETGEAR AC340U and ZyXEL WAH1604;
*) rb433/rb450 - fixed port flapping on bridged Ethernet interfaces if hw-offload is enabled (introduced in v6.41);
*) routerboard - added RouterBOOT "auto-upgrade" after RouterOS upgrade (extra reboot required) (CLI only);
*) userman - added support for ARM and MMIPS platforms;
*) wireless - improved packet processing on ARM platform devices;
*) wireless - improved wireless scan functionality for devices with multiple wireless interfaces;

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 expected or after crash.

Note: if SCEP and CAPsMAN is used, make sure to upgrade clients first, only then upgrade server side. Otherwise after server upgrade old clients will not be able to get certificates.

dasvos · Wed Jan 24, 2018 3:22 pm

Userman for ARM? Thank you Mikrotik.

Sent from my WAS-LX1 using Tapatalk

evince · Wed Jan 24, 2018 6:24 pm

irghost, raffav, Cha0s - Seems that we have found an issue with new TLS matcher. We will try to fix it as soon as possible;

v6.42rc14, and still not working

Wed Jan 24, 2018 8:04 pm

evince - Have you opened support ticket regarding this issue? We have not received any more complaints that this option would not work and have not experienced any more issues with it in our lab.

MartijnVdS · Wed Jan 24, 2018 10:02 pm

Note: if SCEP and CAPsMAN is used, make sure to upgrade clients first, only then upgrade server side. Otherwise after server upgrade old clients will not be able to get certificates.

Does the basic "request a certificate" option in CAPsMAN use SCEP? Or does that use something else?

mistry7 · Wed Jan 24, 2018 10:03 pm

*) userman - added support for ARM and MMIPS platforms;

a miracle after 3 years

biatche · Wed Jan 24, 2018 11:35 pm

The new "/interface wireless access-list allow-signal-out-of-range" feature in 6.41 dramatically improved roaming wireless clients' connectivity. Thanks! Is it possible to add this functionality to "/caps-man access-list" as well? I am getting quite a few too-strong and too-weak disconnects on CAP managed APs:
Code: Select all
12:32:29 caps,info XX:XX:XX:XX:XX:XX@cap6 connected 
12:32:32 caps,info XX:XX:XX:XX:XX:XX@cap6 disconnected, too strong signal 
12:32:37 caps,info XX:XX:XX:XX:XX:XX@cap6 connected 
12:32:41 caps,info XX:XX:XX:XX:XX:XX@cap6 reassociating 
12:32:41 caps,info XX:XX:XX:XX:XX:XX@cap6 connected 
12:32:53 caps,info XX:XX:XX:XX:XX:XX@cap6 disconnected, too strong signal 
12:32:56 caps,info XX:XX:XX:XX:XX:XX@cap6 connected 
12:32:59 caps,info XX:XX:XX:XX:XX:XX@cap6 disconnected, too weak signal

i emailed support and they said they don't plan on adding this feature for capsman. so they find this important for wireless but not capsman. very 'logical' right?

huntah · Thu Jan 25, 2018 12:26 am

I am very glad Mikrotk is working on Certificates. I dont use SCEP but rather more and more popular LetsEncypt (hotstpot, SSTP and IKEv2 VPN !).
I would be great if Mikrotik could implement something like acme.sh . I have used this guide https://www.ollegustafsson.com/en/letsencrypt-routeros/
to automate renew, upload and install the certificates but its quite a hassle.
Wouldn't it be great if we could just have someting like this:

/system certificates add type=LE hostname=remote.mikrotik.com challenge=DNS-manual services=SSL hotspot=profile1 ipsec-peer="name of the peer"

MK would create an ACME challenge and we would put it simply in our DNS:
Domain: '_acme-challenge.remote.mikrotik.com'
TXT value: 'ddasdLAoGgAtZYSGIodasudsw4fdsNhvCNd1qnu0cdmnE'

For me this means:
1.No need for dedicated linux machine:
2. No need to SSH RSA login
3. No need for scheduled task to import any new certs

I think that for majority of us it would be enough ACME DNS manual challange.

Just a suggestion because you are in the middle of Certificate updates

I know this is not exatcly related to 6.42RC but I think it is on the point what would many of us need!

td32 · Thu Jan 25, 2018 12:36 am

*) userman - added support for ARM and MMIPS platforms;

a miracle after 3 years

what a news...
so next step: support EAP

dmingo · Thu Jan 25, 2018 2:08 am

Hello:
For Mk support.
Very low performance in nv2 (10Mbps), 802.11 (> 100Mbps) ok
Bandwidht Test (TCP) Mk Link PtP 2.1Km Model: LHG5 ac arm(IPQ4019)
Regards.

typicalwisp · Thu Jan 25, 2018 2:19 am

The new "/interface wireless access-list allow-signal-out-of-range" feature in 6.41 dramatically improved roaming wireless clients' connectivity.
i emailed support and they said they don't plan on adding this feature for capsman. so they find this important for wireless but not capsman. very 'logical' right?

Hopefully, there was a misunderstanding. I suppose they could fix the bugs related to signal strength calculations instead of adding allow-signal-out-of-range. Obviously, I don't have clients connecting at above 120dBm (1,000 Mega Watt) even though we regularly see disconnects for "too strong signal."

These bugs make caps-man virtually useless for 802.11 clients. Modern OS wireless drivers often auto-reconnect, but older ones stay disconnected when the AP sends a de-auth frame. This is fine when the clients go out of range, but my customers have multiple devices less than 6 meters from an access point disconnecting and reconnecting because of "too strong/weak signal." In the logs I copied it was the same non-moving device for all the log entries.

I assume that Mikrotik is working on something to mitigate the signal issue in access-list. I'm not picky about how it gets fixed. If there is anything I can do to speed this along, please let me know.

biatche · Thu Jan 25, 2018 3:38 am

The new "/interface wireless access-list allow-signal-out-of-range" feature in 6.41 dramatically improved roaming wireless clients' connectivity.
i emailed support and they said they don't plan on adding this feature for capsman. so they find this important for wireless but not capsman. very 'logical' right?

Hopefully, there was a misunderstanding. I suppose they could fix the bugs related to signal strength calculations instead of adding allow-signal-out-of-range. Obviously, I don't have clients connecting at above 120dBm (1,000 Mega Watt) even though we regularly see disconnects for "too strong signal."

These bugs make caps-man virtually useless for 802.11 clients. Modern OS wireless drivers often auto-reconnect, but older ones stay disconnected when the AP sends a de-auth frame. This is fine when the clients go out of range, but my customers have multiple devices less than 6 meters from an access point disconnecting and reconnecting because of "too strong/weak signal." In the logs I copied it was the same non-moving device for all the log entries.

I assume that Mikrotik is working on something to mitigate the signal issue in access-list. I'm not picky about how it gets fixed. If there is anything I can do to speed this along, please let me know.

in our email conversation, they mentioned they want logs. maybe you could provide that. although i have a huge complaint about logs. it doesnt mention signal strength. i wish they'd consider linux type logs instead of windows type logs. logs should have useful detailed information and not just "signal too strong/weak"

jondavy · Thu Jan 25, 2018 4:13 am

PPPoE server does not work on VLAN interfaces when cpe (customer) is of another brand that is not mikrotik

typicalwisp · Thu Jan 25, 2018 5:31 am

Here is the config from one controller:

/caps-man access-list
# Main rule to allow strong clients to have a high-speed connection
add action=accept ap-tx-limit=40000000 client-tx-limit=10000000 interface=all signal-range=-80..120
# Rule to prevent clients on the fringe from using 100% of the radio bandwidth
add action=accept ap-tx-limit=500000 client-tx-limit=500000 interface=all signal-range=-87..-80
add action=accept ap-tx-limit=200000 client-tx-limit=200000 interface=all signal-range=-120..-88
# Catch-all rule to test if there is a bug in signal-range matching code
add action=accept ap-tx-limit=100000 client-tx-limit=100000 interface=all signal-range=-120..120
# Catch-all rule to see if a rule without signal-range still checks the signal... it does
add action=accept ap-tx-limit=100000 client-tx-limit=100000 interface=all

Recent logs... I am pretty sure there aren't any client devices capable of 1 GigaWatt.

jan/24 17:49:06 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal 
jan/24 17:49:14 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal 
jan/24 17:49:25 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal 
jan/24 17:50:02 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal 
jan/24 17:51:53 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal 
jan/24 17:53:58 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal 
jan/24 17:58:45 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal 
jan/24 17:59:52 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal 
jan/24 18:00:09 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal 
jan/24 18:11:29 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal 
jan/24 18:12:31 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal 
jan/24 18:28:02 caps,info EC:88:92:XX:XX:F1@cap20 disconnected, too strong signal 
jan/24 18:28:10 caps,info EC:88:92:XX:XX:F1@cap21 disconnected, too strong signal 
jan/24 18:33:27 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal 
jan/24 18:43:38 caps,info D0:22:BE:XX:XX:30@cap21 disconnected, too strong signal 
jan/24 18:43:54 caps,info D0:22:BE:XX:XX:30@cap21 disconnected, too strong signal 
jan/24 18:43:57 caps,info 90:68:C3:XX:XX:4A@cap12 disconnected, too strong signal 
jan/24 18:55:41 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal 
jan/24 18:57:32 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal 
jan/24 19:06:20 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal 
jan/24 19:06:24 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal 
jan/24 19:38:43 caps,info F8:62:14:XX:XX:60@cap20 disconnected, too strong signal 
jan/24 19:46:13 caps,info E4:58:E7:XX:XX:D0@cap10 disconnected, too strong signal 
jan/24 19:47:10 caps,info 30:10:B3:XX:XX:60@cap12 disconnected, too strong signal 
jan/24 19:55:38 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal 
jan/24 20:01:54 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal 
jan/24 20:13:45 caps,info F8:62:14:XX:XX:60@cap20 disconnected, too strong signal 
jan/24 20:19:08 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal 
jan/24 20:23:30 caps,info B8:E8:56:XX:XX:72@cap20 disconnected, too strong signal 
jan/24 20:23:34 caps,info B8:E8:56:XX:XX:72@cap20 disconnected, too strong signal 
jan/24 20:39:54 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal 
jan/24 20:48:49 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal 
jan/24 20:59:44 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal 
jan/24 21:01:40 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal 
jan/24 21:15:12 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal

djtechwork · Thu Jan 25, 2018 9:33 am

Version 6.42rc14 has been released.

Just tested on RB750GR-3. Works fine, except the usermanager. Unable to access it via web browser...

Thu Jan 25, 2018 10:08 am

djtechwork - You installed latest rc version and User Manager package, can access "/tool user-manager" from CLI, but can not open it on WEB browser (x.x.x.x/userman)? If this is correct, then please generate supout file on your router and send it to support@mikrotik.com.

djtechwork · Thu Jan 25, 2018 10:18 am

djtechwork - You installed latest rc version and User Manager package, can access "/tool user-manager" from CLI, but can not open it on WEB browser (x.x.x.x/userman)? If this is correct, then please generate supout file on your router and send it to support@mikrotik.com.

OK. Thank you..

evince · Thu Jan 25, 2018 11:21 am

evince - Have you opened support ticket regarding this issue? We have not received any more complaints that this option would not work and have not experienced any more issues with it in our lab.

Hello Strods, i'll open a ticket right now, thank you.

Thu Jan 25, 2018 12:31 pm

User Manager issue must be resolved within next rc release. Thank you for your report. Issue was fixed based on your report.

Good example why you should write to support not only report it in forum

sindy · Thu Jan 25, 2018 12:48 pm

Good example why you should write to support not only report it in forum

Well, from https://mikrotik.com/support:

If you have bought a RouterOS license or a RouterBOARD product, limited support service might be provided by e-mail for 30 days after the purchase by support@mikrotik.com. Contact your distributor for help and support, if device is not purchased from MikroTik directly.

This does not exactly encourage people to send anything to support@mikrotik.com unless they fulfil the formal requirement or are audacious or desperate enough to try

Thu Jan 25, 2018 12:52 pm

MikroTik is manufacturer and wholesaler. All the assistance in particular projects as well as regional sales are provided through our distributors and consultants. They all have knowledgeable specialists in their companies who can suggest you the most suitable equipment to use and help with the configuration / installation.

If there is an actual issue with software and/or hardware, then such problems can be resolved only through support@mikrotik.com. None of users in forum, consultants or distributors will not be able to fix issues in RouterOS.

sindy · Thu Jan 25, 2018 1:22 pm

If there is an actual issue with software and/or hardware, then such problems can be resolved only through support@mikrotik.com. None of users in forum, consultants or distributors will not be able to fix issues in RouterOS.

If only the PM was working so that I could have sent my previous post to you directly rather than spamming the topic... I perfectly understand that the support team cannot deal with elementary questions of every end user, but to tell a misconfiguration from a bug or even a deliberate limitation (see userman and support of Radius fields required to support EAP) is sometimes not easy even for experienced specialists, so don't be surprised that not everyone dares to send what he believes to be a bug to support unless encouraged to do so by someone at the forum.

Chupaka · Thu Jan 25, 2018 3:18 pm

If only the PM was working so that I could have sent my previous post to you directly rather than spamming the topic...

That's why PMs are disabled

support@mikrotik.com is his PM

msatter · Thu Jan 25, 2018 3:40 pm

If only the PM was working so that I could have sent my previous post to you directly rather than spamming the topic...
That's why PMs are disabled support@mikrotik.com is his PM

That looks to me a bit selfish because all others have also no private messaging abilities.

kometchtech · Fri Jan 26, 2018 3:12 am

Hello everyone,

Regarding CRS317, when updating from ROS6.42rc12 to ROS6.42rc14, it stopped with 'jumping to kernel code' and it can not be started.
Before I mention, CRS317 in my environment has not succeeded in updating packages from system -> package so far.

I have already told this about Mikrotik support, but at the moment it is not possible to recover by netinstall(6.41 and 6.42rc14) as well.

For a while, it may be better to look at the situation with CRS317.

Best regards.

biatche · Fri Jan 26, 2018 10:25 am

Here is the config from one controller:

/caps-man access-list
# Main rule to allow strong clients to have a high-speed connection
add action=accept ap-tx-limit=40000000 client-tx-limit=10000000 interface=all signal-range=-80..120
# Rule to prevent clients on the fringe from using 100% of the radio bandwidth
add action=accept ap-tx-limit=500000 client-tx-limit=500000 interface=all signal-range=-87..-80
add action=accept ap-tx-limit=200000 client-tx-limit=200000 interface=all signal-range=-120..-88
# Catch-all rule to test if there is a bug in signal-range matching code
add action=accept ap-tx-limit=100000 client-tx-limit=100000 interface=all signal-range=-120..120
# Catch-all rule to see if a rule without signal-range still checks the signal... it does
add action=accept ap-tx-limit=100000 client-tx-limit=100000 interface=all

Recent logs... I am pretty sure there aren't any client devices capable of 1 GigaWatt.

jan/24 17:49:06 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal 
jan/24 17:49:14 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal 
jan/24 17:49:25 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal 
jan/24 17:50:02 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal 
jan/24 17:51:53 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal 
jan/24 17:53:58 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal 
jan/24 17:58:45 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal 
jan/24 17:59:52 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal 
jan/24 18:00:09 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal 
jan/24 18:11:29 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal 
jan/24 18:12:31 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal 
jan/24 18:28:02 caps,info EC:88:92:XX:XX:F1@cap20 disconnected, too strong signal 
jan/24 18:28:10 caps,info EC:88:92:XX:XX:F1@cap21 disconnected, too strong signal 
jan/24 18:33:27 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal 
jan/24 18:43:38 caps,info D0:22:BE:XX:XX:30@cap21 disconnected, too strong signal 
jan/24 18:43:54 caps,info D0:22:BE:XX:XX:30@cap21 disconnected, too strong signal 
jan/24 18:43:57 caps,info 90:68:C3:XX:XX:4A@cap12 disconnected, too strong signal 
jan/24 18:55:41 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal 
jan/24 18:57:32 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal 
jan/24 19:06:20 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal 
jan/24 19:06:24 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal 
jan/24 19:38:43 caps,info F8:62:14:XX:XX:60@cap20 disconnected, too strong signal 
jan/24 19:46:13 caps,info E4:58:E7:XX:XX:D0@cap10 disconnected, too strong signal 
jan/24 19:47:10 caps,info 30:10:B3:XX:XX:60@cap12 disconnected, too strong signal 
jan/24 19:55:38 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal 
jan/24 20:01:54 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal 
jan/24 20:13:45 caps,info F8:62:14:XX:XX:60@cap20 disconnected, too strong signal 
jan/24 20:19:08 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal 
jan/24 20:23:30 caps,info B8:E8:56:XX:XX:72@cap20 disconnected, too strong signal 
jan/24 20:23:34 caps,info B8:E8:56:XX:XX:72@cap20 disconnected, too strong signal 
jan/24 20:39:54 caps,info 5C:CF:7F:XX:XX:11@cap17 disconnected, too strong signal 
jan/24 20:48:49 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal 
jan/24 20:59:44 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal 
jan/24 21:01:40 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal 
jan/24 21:15:12 caps,info 5C:CF:7F:XX:XX:56@cap17 disconnected, too strong signal

well... in our email conversation, they finally said they would add this to their list..... didn't sound as if they were gonna add it immediately.

maybe you could email support@mikrotik.com and persuade them why its necessary and that they should have it added to 6.42.

Fri Jan 26, 2018 12:28 pm

Version 6.42rc15 has been released.

Changes since previous release:

*) dhcpv4-server - added "dns-none" option to "/ip dhcp-server network dns";
*) dhcpv6 - make sure that time is set before restoring bindings;
*) dhcpv6-client - added possibility to specify options;
*) dhcpv6-server - added DHCPv4 style user options;
*) fetch - added "output" option for all modes in order to return result to file, variable or ignore it;
*) ippool - added ability to specify comment;
*) radius - added warning if PPP authentication over RADIUS is enabled;
*) routerboard - added RouterBOOT "auto-upgrade" after RouterOS upgrade (extra reboot required);
*) sfp - improved SFP module compatibility;
*) userman - added support for ARM and MMIPS platform;
*) webfig - do not show "hw" option on non-ethernet interfaces;
*) winbox - added "crl-store" setting to certficate settings;
*) winbox - fixed typo from "UPtime" to "Uptime";
*) winbox - fixed Winbox closing when viewing graph which does not contain any data;

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 expected or after crash.

evince · Fri Jan 26, 2018 2:32 pm

Version 6.42rc15 has been released.

Changes since previous release:

*) routerboard - added RouterBOOT "auto-upgrade" after RouterOS upgrade (extra reboot required);

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 expected or after crash.

Hello Strods, can you exlain this feature please?

eriitguy · Fri Jan 26, 2018 2:42 pm

Version 6.42rc15 has been released.

Changes since previous release:

*) routerboard - added RouterBOOT "auto-upgrade" after RouterOS upgrade (extra reboot required);

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 expected or after crash.
Hello Strods, can you exlain this feature please?

RouterBOOT "auto-upgrade"!

Thank you!

huntah · Fri Jan 26, 2018 6:36 pm

*) sfp - improved SFP module compatibility;

That this means thaht the following SFP modules are working:
viewtopic.php?f=17&t=120190&p=591082&hi ... 02#p591082

If yes will there be an update for SwOS also?

irghost · Sat Jan 27, 2018 9:36 am

Version 6.42rc15 has been released.

Changes since previous release:

*) dhcpv4-server - added "dns-none" option to "/ip dhcp-server network dns";
*) dhcpv6 - make sure that time is set before restoring bindings;
*) dhcpv6-client - added possibility to specify options;
*) dhcpv6-server - added DHCPv4 style user options;
*) fetch - added "output" option for all modes in order to return result to file, variable or ignore it;
*) ippool - added ability to specify comment;
*) radius - added warning if PPP authentication over RADIUS is enabled;
*) routerboard - added RouterBOOT "auto-upgrade" after RouterOS upgrade (extra reboot required);
*) sfp - improved SFP module compatibility;
*) userman - added support for ARM and MMIPS platform;
*) webfig - do not show "hw" option on non-ethernet interfaces;
*) winbox - added "crl-store" setting to certficate settings;
*) winbox - fixed typo from "UPtime" to "Uptime";
*) winbox - fixed Winbox closing when viewing graph which does not contain any data;

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 expected or after crash.

/ip dhcp-client add dhcp-options=hostname,clientid disabled=no interface=ether1

DHCP-client just return after reboot
on vmware template 6.42 rc15

frank333 · Sat Jan 27, 2018 11:30 pm

implementing a new type of queue such cake or fq_codel would be a great addition, what do you think?
Metarouter for arm?

pe1chl · Sun Jan 28, 2018 12:26 pm

implementing a new type of queue such cake or fq_codel would be a great addition, what do you think?
Metarouter for arm?

From the Codel Wiki:
CoDel - in order to run well at line rate - requires the Linux 3.3 Byte Queue Limits . It has proven too hard to backport BQL to Linux 3.2 or earlier (an attempt for 3.2 exists, but no driver support), so you will need to upgrade to Linux 3.5 or later, and have a driver that supports BQL (only about 24 as of the present writing).

There you have your answer. You will have to wait for RouterOS V7 at least.

frank333 · Sun Jan 28, 2018 12:44 pm

From the Codel Wiki:
CoDel - in order to run well at line rate - requires the Linux 3.3 Byte Queue Limits . It has proven too hard to backport BQL to Linux 3.2 or earlier (an attempt for 3.2 exists, but no driver support), so you will need to upgrade to Linux 3.5 or later, and have a driver that supports BQL (only about 24 as of the present writing).

There you have your answer. You will have to wait for RouterOS V7 at least.

ROS7 will be ready in a year I think.

Instead metarouter for ARM devices do you know when it could be ready?

hawk · Mon Jan 29, 2018 9:50 am

I have the problem with MSTP. I configured everything but the machine not see the root path cost and designated bridge. Not calculate costs in MSTP.(CRS317)

Chupaka · Mon Jan 29, 2018 12:54 pm

ROS7 will be ready in a year I think.

I think the same. For the last few years

frank333 · Mon Jan 29, 2018 5:16 pm

ROS7 will be ready in a year I think.

I think the same. For the last few years

Is it like saying that there is no hope?
And yet ARM devices are very good in my opinion;would be a real shame.

evince · Tue Jan 30, 2018 9:47 am

irghost, raffav, Cha0s - Seems that we have found an issue with new TLS matcher. We will try to fix it as soon as possible;
v6.42rc14, and still not working

Ok it is working, it was a problem of configuration.

Tue Jan 30, 2018 10:21 am

ROS7 will be ready in a year I think.

I think the same. For the last few years

5 years and counting for me

I am not exaggerating when I say my hair has turned gray in the time it has taken for v7 to be released...

hapi · Tue Jan 30, 2018 3:47 pm

Add flow control status to ethernet status in winbox. thx

metricmoose · Tue Jan 30, 2018 7:47 pm

Version 6.42rc15 has been released.

*) fetch - added "output" option for all modes in order to return result to file, variable or ignore it;

I have been trying to test the ability to store downloaded data in a variable, though I haven't had any luck yet.

[admin@Mikrotik] > /tool fetch https://api.ipify.org/ output=user 
      status: finished
  downloaded: 0KiBC-z pause]
       total: 0KiB
    duration: 0s
        data: [My IP Address was here]

I can see the data showing up, which is great. Though I can't seem to store that in a variable, I'm used to using "get" in other cases with Mikrotik scripting, but that doesn't seem to be available here. I'm fairly new to Mikrotik scripting, so I hope I'm not missing anything obvious.

null31 · Wed Jan 31, 2018 3:02 am

Hi.
I noted that PVID field has the value 65 as default when add a port to a bridge under the Winbox.
Under terminal is ok, set the value 1 to that field.

Unit RB951Ui-2HnD
ROS 6.42rc15
Winbox 3.11 under wine 3.0 on Arch Linux

mducharme · Wed Jan 31, 2018 7:37 pm

Hi.
I noted that PVID field has the value 65 as default when add a port to a bridge under the Winbox.
Under terminal is ok, set the value 1 to that field.

Confirmed, I see the same thing on rc12

JimmyNyholm · Thu Feb 01, 2018 12:22 pm

that pvid could be seen in 41rc's aswell if you set something it goes away though

gumbi2400 · Thu Feb 01, 2018 5:00 pm

I think I found an odd bug.

I recently set up an L2TP/IPSEC VPN connection to an external provider (ipvanish). I noticed that the connection when connecting directly from my local computer I get about 98% of my max internet speed (330Mbps). Setting up this same connection on my rb750gr3 and connecting through there I get no more than 1.5Mbps.

I initially assumed I set up something wrong and went through everything I could think of. Eventually I turned on the packet sniffer to see if I could see anything odd. I ran the speed test again, and I got 98Mbps, not as good as a full blown computer but not bad! When disabling the packet sniffer speed drops back down to 1.5.

In Summary: When using L2TP/IPSEC VPN enabling the packet sniffer increases speed dramatically.

Please let me know if additional information is needed.

pe1chl · Thu Feb 01, 2018 5:05 pm

You need to turn off fastpath and fasttrack in that case.

mrz · Thu Feb 01, 2018 5:06 pm

Make sure that packets are not catched by fasttrack. If packet is fasttracked it will not be seen by ipsec policy and you get packet loss/slow tunnels.

gumbi2400 · Thu Feb 01, 2018 5:29 pm

Ah not a bug after all. My apologies! I feel a bit silly as I thought I already disabled that. Thanks!

pe1chl · Thu Feb 01, 2018 6:02 pm

Please please please do some work on IPv6!
E.g. following priorities from this posting: viewtopic.php?f=2&t=123302

Things I really need, the sooner the better:
- route marking and multi route tables using marks as in IPv4
(via ipv6 firewall mangle and/or ipv6 route rule)
- configurable IPv6 nameservers in DHCPv6 and RA, or at least the option to publish the router's own
address as nameserver instead of the configured external DNS servers

Fri Feb 02, 2018 11:03 am

Version 6.42rc18 has been released.

Changes since previous release:

*) bridge - show "hw" flags only on Ethernet interfaces and interface lists;
*) crs3xx - added switch port "storm-rate" limiting options;
*) kidcontrol - added initial support for "/ip kid-control" feature;
*) lte - fixed AT communication with modem (introduced in v6.42rc12);
*) switch - hide "ingress-rate" and "egress-rate" for non-crs3xx switches;
*) tile - improved stability in high throughput HW accelerated IPsec setups ("/system routerboard upgrade" required);
*) upgrade - improved RouterOS upgrade process and restrict upgrade from RouterOS older than v5.16;
*) webfig - fixed backup loading from Webfig on RouterBOARD running default configuration;
*) winbox - allow to comment new object without committing it;
*) wireless - fixed incompatibility with macOS clients;
*) wireless - fixed wireless protocol mode restrictions if lock package is installed and has limits for it;

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 expected or after crash.

pe1chl · Fri Feb 02, 2018 12:13 pm

*) winbox - allow to comment new object without committing it;

Great!
Another potential improvement in this area: allow to set comment on an object without causing any reconfiguration or state-change on it.
(in some cases the configured object goes down-up when you change the comment!)

Chupaka · Fri Feb 02, 2018 12:19 pm

(in some cases the configured object goes down-up when you change the comment!)

Please report exact cases. They fix it

Fri Feb 02, 2018 12:20 pm

pe1chl - Seems that you misunderstood the fix. Assume that you add firewall rule, specify different parameters and do not press "Ok" button yet. Now you press "Comment" button and specify comment. When you press "Ok" on comment form, then in the past whole rule was added to firewall. Now "Ok" button on comment accepts only comment - it does not create a new rule right away.

pe1chl · Fri Feb 02, 2018 2:06 pm

(in some cases the configured object goes down-up when you change the comment!)
Please report exact cases. They fix it

I think it is easier for them to find all cases where this is handled incorrectly than for me trying to hunt them down and potentially miss some.
It looks like it really happens *everywhere*, however not in all cases there is an observable impact on operations.
(like a connection being dropped and re-established, or similar)

pe1chl · Fri Feb 02, 2018 2:09 pm

pe1chl - Seems that you misunderstood the fix. Assume that you add firewall rule, specify different parameters and do not press "Ok" button yet. Now you press "Comment" button and specify comment. When you press "Ok" on comment form, then in the past whole rule was added to firewall. Now "Ok" button on comment accepts only comment - it does not create a new rule right away.

I understand that and I think it is great, because in the past I have sometimes gone wrong with that, e.g. because it stored something that was not configured correctly yet after doing a COPY, and I wanted to reset the comment as one of the first steps. In fact, it would be better when the comment is just a separate TAB on the object, like in Webfig.

However, what I mean is when using the yellow icon to only change the comment on an existing object, it should just change the comment and not do anything else with the object.

drbunsen · Fri Feb 02, 2018 2:28 pm

I've updated a crs317 from rc6 to rc18 and now the fan is kicking in regularly. It seems it's trying to keep the cpu temperature below 40C as this is the point when it stops again.
There's nothing in the changelog about it and before that I've even seen cpu temperatures of almost 50C without the fan starting. Has this been changed?

At living room temperatures and idling the fan now iterates between running 30 seconds and being 1-2 minutes off. A little bit annoying and I guess also not the best running conditions for the fans on log term. Especially as it was totally quiet before and not remarkably hotter with like around 44C.

Fri Feb 02, 2018 2:47 pm

Version 6.42rc20 has been released.

Changes since previous release:

*) upgrade - improved RouterOS upgrade process and restrict upgrade from RouterOS older than v5.16;

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 expected or after crash.

drbunsen · Fri Feb 02, 2018 4:10 pm

I've updated a crs317 from rc6 to rc18 and now the fan is kicking in regularly. It seems it's trying to keep the cpu temperature below 40C as this is the point when it stops again.
There's nothing in the changelog about it and before that I've even seen cpu temperatures of almost 50C without the fan starting. Has this been changed?

At living room temperatures and idling the fan now iterates between running 30 seconds and being 1-2 minutes off. A little bit annoying and I guess also not the best running conditions for the fans on log term. Especially as it was totally quiet before and not remarkably hotter with like around 44C.

OK, that was too annoying and I've installed 6.41.1 stable now. Fan stays off with cpu at 42C.
Mikrotik you might want to look into this. Oviously there was some sort of change and as it's not in the changelog I assume it's not intended?

armandfumal · Fri Feb 02, 2018 9:16 pm

*) chr - added "open-vm-tools" on VMware installations;

tested. at least !!!

thanks

Just missing BGP routing in multicore cpu....need this please !!!!

Fri Feb 02, 2018 11:27 pm

Just missing BGP routing in multicore cpu....need this please !!!!

Please see viewtopic.php?f=3&t=129649#p638204

jmi2 · Mon Feb 05, 2018 12:19 pm

short version: With this routerOS version, if there is single client with older card like CM9, then all other clients got no change to communicate without issues.
Simply if such client is connected to AP, then mobile and notebook have horrible connectivity and LG TV and hama radio got disconnected always after few seconds.

long version: Starting with 6.37 (actually already before, if previous FWs like 6.36.4 were switched to use wireless-rep) in combination with old HW like CM9, R52 on client side, wireless channel becomes useless for all (other clients of same AP and also clients of other APs on same channel). Same issue is still there with 6.42rc20.

details:
Starting with 6.37 (and already in previous release, if wireless-rep was enabled), also with 6.40.5 and 6.42rc20 i observed below described issue, when old hardware like CM0, r52 and few others were used. I did test always with boards RB433, but i guess it's wireless issue, as it depends on wireless package used. There is no issue if HW r5nH or r52nM is used.
Issue exists in both G-only and A-only mode.

My setup was indoor:
- mikrotik AP bridge
- mikrotik client1
- mikrotik client2
Tested with fixed data rate and fixed power.

1) Each client works fine, if it's alone on AP.
2) In moment, when 2nd client with CM9 and FW 6.37(.3) or newer (or with wireless-rep package) connects, then for others: CCQ is going down, latencies up (even to hundreds on empty links), loss occurs, or client gets disconnected after few seconds (e.g. LG TV, hama radio, mikrotik with r52nM. But e.g. CM9 client survices with loss (Actually both clients have loss, if both a on version 6.37+). Note: 2nd client is not doing any traffic on AP (expect for neighbours discovery and similar, simply only few packets per second).
3) I also tried to setup 2 APs on same channel and connect 1 CM9 client per AP. If clients were on 6.36.4, it all worked fine, even throughput like 10-15mbit on each AP while sharing channel was possible. However, once i updated one client to affected version (tried with 6.40.5 or 6.42rc20), in moment CM9 connected to one AP, problem occured with client on another AP.
4) I wasn't able to reproduce the issue if using only R5nH / R52nM cards in my test setup. Tested with 6.40.5 and all worked fine.

First i spent one night trying to figure out what went wrong with AP or TV ... then i realized it's enough to turn off mikrotik client with CM9, which was updated to latest version, to get my TV, radio and laptop working fine (e.g. with CM9 client turned on speedtest to internet was 0.5mbit, without CM9 client it was 25mbit)
Then I did tests only between 3-4 mikrotik devices (As described) with client on versions 3.30, 4.17, 5.26, 6.0, 6.29.1, 6.33.3, 6.35.4, 6.36.4, where all was fine
and with 6.36.4 with wireless-rep, 6.37.3, 6.38.5, 6.38.7, 6.39.3, 6.40.5, 6.42rc20 where it was causing described problems.

I also did tests for AP side, so far my outcome is, that AP side has not this issue, e.g. works well if AP is with CM9 and 6.40.5. That means, all clients (cm9, r52nM, r5nH) of this AP are working fine (unless that CM9 client is on affected version of routeros).

For configuration: routerOs was fresh after reset, only IP and wifi configured. For wifi i tried with wpa2 aes and also without security. Also tried to disable roaming (if routerOS allowed it).

For me it looks like that with affected versions CM9 / r52 are constantly sending something to the air, which prevents others to communicate.

raffav · Mon Feb 05, 2018 4:55 pm

Hello
can someone give me a example how to use TLS-host i tryed to use facebook youtube, allot of site no one worked

Chupaka · Tue Feb 06, 2018 7:23 am

can someone give me a example how to use TLS-host i tryed to use facebook youtube, allot of site no one worked

/ip firewall filter
add action=passthrough chain=forward dst-port=443 protocol=tcp tls-host=*.facebook.com

At least I put that rule before Fasttrack rule - and it caught my connection to facebook

anuser · Tue Feb 06, 2018 7:58 am

*) wireless - fixed incompatibility with macOS clients;

What problems exist with macOS clients? Which OS X versions are affected? ( I'm running 6.41 on all CAPs and have no issues being reported by OS X clients...)

Tue Feb 06, 2018 10:44 am

*) wireless - fixed incompatibility with macOS clients;
What problems exist with macOS clients? Which OS X versions are affected? ( I'm running 6.41 on all CAPs and have no issues being reported by OS X clients...)

If you were setting priorities for the WMM then sometimes the macOS clients didn't accept packets with some priorities.

frank333 · Tue Feb 06, 2018 12:59 pm

in Bandwidth_Test you might have a box to save the ip of test servers without recompile it all the time?

hawk · Tue Feb 06, 2018 2:53 pm

I have the problem with MSTP. I configured everything but the machine not see the root path cost and designated bridge. Not calculate costs in MSTP.(CRS317)

frank333 · Thu Feb 08, 2018 1:11 am

Tip for developers, so that you do not enter the possibility of a percentage value instead of max-limits in the queue tree?

Chupaka · Thu Feb 08, 2018 3:00 am

Percentage of what?

frank333 · Thu Feb 08, 2018 11:36 am

Percentage of what?

I meant to say that, instead of entering the max limit value you could assume a fixed value in percentage or at choice.
Of course, ROS should read the bandwidth instantly or after a set time.
(e. g. 10% bandwidth istantly / 1.10=max-limit)

sindy · Thu Feb 08, 2018 11:43 am

Percentage of what?
I meant to say that, instead of entering the max limit value you could assume a fixed value in percentage (e. g. 10%) or at choice.
Of course, ROS should read the bandwidth instantly or after a set time.

Again, percentage of what? Interface speed? Some queues are not related to any particular interface.

Thu Feb 08, 2018 12:02 pm

Version 6.42rc23 has been released.

Changes since previous release:

*) console - fixed "idpr-cmtp" protocol by changing its value from 39 to 38 (CLI only);
*) crs3xx - added initial hw-offload support for 802.3ad and balance-xor bonding
*) disk - fixed disk related processes becoming unresponsive after unplugging used disk;
*) kidcontrol - added initial support for "/ip kid-control" feature;
*) ppp - do not lose "/ppp profile" script configuration after other profile parameters are edited;
*) routerboard - properly report warnings under "/system routerboard" menu;
*) sniffer - fixed situation when "/tool sniffer packet" returned packets in incorrect order;
*) snmp - added w60g support;
*) upgrade - improved RouterOS upgrade process and restrict upgrade from RouterOS older than v5.16;
*) w60g - fixed "/interface w60g reset-configuration";
*) winbox - changed default bridge port PVID value to 1;
*) wireless - added initial support for "nstreme-plus";
*) wireless - improved compatibility with specific wireless AC standard clients;

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 expected or after crash.

kometchtech · Thu Feb 08, 2018 12:24 pm

Version 6.42rc23 has been released.

Changes since previous release:

*) console - fixed "idpr-cmtp" protocol by changing its value from 39 to 38 (CLI only);
*) crs3xx - added initial hw-offload support for 802.3ad and balance-xor bonding
*) disk - fixed disk related processes becoming unresponsive after unplugging used disk;
*) kidcontrol - added initial support for "/ip kid-control" feature;
*) ppp - do not lose "/ppp profile" script configuration after other profile parameters are edited;
*) routerboard - properly report warnings under "/system routerboard" menu;
*) sniffer - fixed situation when "/tool sniffer packet" returned packets in incorrect order;
*) snmp - added w60g support;
*) upgrade - improved RouterOS upgrade process and restrict upgrade from RouterOS older than v5.16;
*) w60g - fixed "/interface w60g reset-configuration";
*) winbox - changed default bridge port PVID value to 1;
*) wireless - added initial support for "nstreme-plus";
*) wireless - improved compatibility with specific wireless AC standard clients;

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 expected or after crash.

Hi all,

When rc23 was applied, Interface was no longer recognized by OS on the following Routerboard.

- CCR1009-8G-1S-1S+

This was a segmentation fault.

- RB850Gx2

I think that it is better to stop being applied if possible.

Best regards.

frank333 · Thu Feb 08, 2018 12:33 pm

Percentage of what?
I meant to say that, instead of entering the max limit value you could assume a fixed value in percentage (e. g. 10%) or at choice.
Of course, ROS should read the bandwidth instantly or after a set time.
Again, percentage of what? Interface speed? Some queues are not related to any particular interface.

I thought that in the queue-tree they were divided only into main and parents. I am a beginner.

carnivean · Thu Feb 08, 2018 12:37 pm

nstreme-plus ? What is it ?

chrryd · Thu Feb 08, 2018 12:44 pm

Version 6.42rc23 has been released.

Changes since previous release:

*) crs3xx - added initial hw-offload support for 802.3ad and balance-xor bonding

Oh! Do we finally get 802.3ad link aggregation in HW on routeros - I've been waiting for that for a long time

Any documentation on how to set that up?

eworm · Thu Feb 08, 2018 12:50 pm

This broke my CHR installation, though I am not sure if 6.42rc23 is involved at all. The system was running 6.42rc20. I booted it and tried to update, the system told me there is not enough free space. After reboot it hangs at "Loading system with initrd".

mistry7 · Thu Feb 08, 2018 1:00 pm

nstreme-plus ? What is it ?

thats my question too

morf · Thu Feb 08, 2018 1:10 pm

nstreme-plus ? What is it ?
thats my question too

+

pietroscherer · Thu Feb 08, 2018 1:48 pm

nstreme-plus ? What is it ?

+ 32984920

UMarcus · Thu Feb 08, 2018 2:01 pm

*) wireless - improved compatibility with specific wireless AC standard clients;

What does 'improve compatibility' mean ? Also speed related ?

th0massin0 · Thu Feb 08, 2018 2:25 pm

May I ask about boot from VirtIO-SCSI (in CHR) in this release?

null31 · Thu Feb 08, 2018 2:39 pm

This broke my CHR installation, though I am not sure if 6.42rc23 is involved at all. The system was running 6.42rc20. I booted it and tried to update, the system told me there is not enough free space. After reboot it hangs at "Loading system with initrd".

Same here, except by the message about free space.
Upgrade from 6.42rc20 to 6.42rc23, after reboot, CHR is broken.
Detects one interface only and with mac-address filled with zero.

Linux live and scp to get the supout.rif.

Image from CHR cli: https://i.imgur.com/kfKnjjF.png

I sent a ticket to MikroTik support. [Ticket#2018020822005224]

zryny4 · Thu Feb 08, 2018 2:45 pm

After upgrade from rc20 to rc23, I cannot login to router via http: "ERROR: Not Found", ssh -- ok, login not default admin.

doush · Thu Feb 08, 2018 2:47 pm

what is nstreme-plus ?

Thu Feb 08, 2018 3:00 pm

Main part of upgrade process happens on old version.

For example, rc21 -> rc23. If upgrade fails, then it is caused by rc21 version. As you can see in changelog we are still working on upgrade improvements. At the moment latest fixes are included in rc23. You can test upgrade improvements only when upgrade from rc23 to, for example, rc24 will be available.

In future, if you experience problems with upgrade, then remember to mention from which precise RouterOS version and to which you made an upgrade.

eworm · Thu Feb 08, 2018 3:04 pm

Main part of upgrade process happens on old version.

For example, rc21 -> rc23. If upgrade fails, then it is caused by rc21 version. As you can see in changelog we are still working on upgrade improvements. At the moment latest fixes are included in rc23. You can test upgrade improvements only when upgrade from rc23 to, for example, rc24 will be available.

Sure. But with "not enough free space available" the system should cancel upgrade and stay with old version, no?
Are you interested in the broken image?

null31 · Thu Feb 08, 2018 3:43 pm

For example, rc21 -> rc23. If upgrade fails, then it is caused by rc21 version. As you can see in changelog we are still working on upgrade improvements. At the moment latest fixes are included in rc23. You can test upgrade improvements only when upgrade from rc23 to, for example, rc24 will be available.

Well...
I tried boot-up a VDI, VMDK and Ova (imported to vbox) from CHR 6.42rc23, all of them show the same message.
Message: https://i.imgur.com/3rs5CPZ.png

Now, I booted-up a VDI from CHR 6.41.1 with IP address, one DNS and one default route. I upgrade to 6.42rc23, no problems after upgrade, but was over a minimal config to access internet and nothing more.

Edit after rc24: Even the VDI of CHR 6.42rc24 show the above message about Missing OS...
Print from CHR 6.42rc24: https://i.imgur.com/Dlg9NSm.png

I feel this release (rc23/24) like a lulz from development team.

Thu Feb 08, 2018 4:01 pm

Version 6.42rc24 has been released.

Changes since previous release:

*) crs3xx - added initial hw-offload support for 802.3ad and balance-xor bonding
*) export - fixed "/system routerboard mode-button" compact export;
*) firewall - fixed "tls-host" firewall feature (introduced v6.41);

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 expected or after crash.t