v6.47beta [testing] is released!

emils · Tue Dec 10, 2019 4:49 pm

Version 6.47beta8 has been released.

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.47beta8 (2019-Dec-10 10:33):

Changes in this release:

*) console - fixed "clear-history" restoring historic actions after power cycle;
*) console - removed "edit" and "set" actions from "System/History" menu;
*) crs3xx - fixed "ingress-rate" property on CRS309-1G-8S+, CRS312-4C+8XG, CRS326-24S+2Q+ devices;
*) defconf - fixed default configuration loading after fresh install (introduced in v6.46);
*) dhcpv6-client - improved error logging when when renewed address differs;
*) fetch - fixed "User-Agent" usage if provided by "http-header-field";
*) health - fixed health reporting on OmniTIK 5 PoE ac;
*) health - improved health reporting on CCR1072-1G-8S+;
*) ipsec - improved system stability when processing decrypted packet on unregistred interface;
*) l2tp - improved system stability when disconnecting many clients at once;
*) lora - improved confirmed downlink forwarding;
*) lte - do not reset modem when setting the same SIM slot on LtAP;
*) lte - fixed multiple APN reactivation after deactivation by operator;
*) lte - show SIM error when no card is present;
*) netinstall - removed "Flashfig" from Netinstall;
*) netinstall - removed "Make Floppy" from Netinstall;
*) netinstall - signed netinstall.exe with Digital Signature;
*) ppp - prioritize "remote-ipv6-prefix-pool" from PPP secret over PPP profile;
*) snmp - added "dot1qTpFdbTable" OID reporting for Q-BRIDGE-MIB;
*) snmp - fixed "dot1dBasePort" index offset for BRIDGE-MIB;
*) snmp - fixed health related OID polling (introduced in v6.46);
*) snmp - improved stability when polling MAC address related OID;
*) supout - fixed autosupout.rif file generation (introduced in v6.46);
*) w60g - use "arp" and "mtu" parameters from master interface when creating a new station;
*) winbox - added "auto-erase" option to "Tool/SMS" menu;
*) winbox - fixed "allowed-number" parameter setting invalid value in "Tool/SMS" menu;
*) winbox - show "LCD" menu only on boards that have LCD screen;
*) wireless - improved compatibility by adding default installation mode and gain for devices with integrated antennas;
*) wireless - improved compatibility for Switzerland wireless country profile to improve compliance with ETSI regulations;

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.

bnw · Tue Dec 10, 2019 4:53 pm

*) snmp - fixed health related OID polling (introduced in v6.46);

Could you elaborate please ?
Did not experience any SNMP heath issue with 6.46 yet.
Thank you !

bnw · Tue Dec 10, 2019 4:56 pm

viewtopic.php?f=2&t=116856#p741203

I opened #2019032822004818 a few months ago, many SNMP hardware OIDs are missing for the CCR1072, compared to what Winbox shows :
- Board temperature
- Board temparature 2
- Fan speed 3
- Fan speed 4
- PSU1 status (should be OID .15 (*))
- PSU2 status (should be OID .16 (*))
(*) as seen on other models such as the CRS317-1G-16S+.

We are then clearly at risk with our CCR1072-1G-8S+, not being able to monitor all their hardware components, which is a rather tricky situation for core devices.

And hope to see this in 6.47 finally !
Many thx !

emils · Tue Dec 10, 2019 5:10 pm

bnw, should affect only a few CRS devices (CRS3xx).

anuser · Tue Dec 10, 2019 10:02 pm

Will we already get MU-MIMO support within 6.47beta release?

Wed Dec 11, 2019 7:12 am

In v6.47beta there is a new menu added - "/system health gauges". You should use this for polling "Health" related data from all the RouterBOARDs.

joegoldman · Wed Dec 11, 2019 8:59 am

In v6.47beta there is a new menu added - "/system health gauges". You should use this for polling "Health" related data from all the RouterBOARDs.

Does this come with new associated MIBs / OID's? Or more for polling via API?

bnw · Wed Dec 11, 2019 9:29 am

Interesting. And if available through SNMP, will these "gauges" give the PSUs status (which are for now missing on CCR1072 as stated above) ?

ivicask · Wed Dec 11, 2019 11:22 am

When is ROMON getting fixed?I need some other fixes from new betas, but they also break ROMON..

mistry7 · Wed Dec 11, 2019 11:26 am

Will we already get MU-MIMO support within 6.47beta release?

shure on xmas, but you don't will get any year....

Wed Dec 11, 2019 12:37 pm

ivicask - Have you reported this problem to support@mikrotik.com or https://help.mikrotik.com/servicedesk/c ... on=portals ?? We are not aware of any RoMON problems;

CoMMyz · Wed Dec 11, 2019 7:09 pm

*) netinstall - removed "Flashfig" from Netinstall;

Can you please elaborate? Is this feature removed completely or just moving to a standalone executable ?

kmrue · Sat Dec 14, 2019 7:26 pm

as no UPS-bugfixing is listed I tested anyhow:
UPS still not working with APC SMT750I, SMT1000I, SMT1500I (to name just 3 models). All of them connected via their USB-port. They all get identified, but only a few parameters get transferred to the routerboard. Tested using CRS125.

Is there anything you guys @ mikrotik want me to further check out?

ivicask · Sat Dec 14, 2019 9:08 pm

ivicask - Have you reported this problem to support@mikrotik.com or https://help.mikrotik.com/servicedesk/c ... on=portals ?? We are not aware of any RoMON problems;

But some of your support confirmed it here, post #5
viewtopic.php?f=21&t=154286&p=762462#p762468

Guscht · Sun Dec 15, 2019 12:43 am

Hoped the snmp-IP-Forward MIB is fixed as well.

We get still a "no such object" error with 6.47beta8:

Testing OIDs...
14.12.2019 23:31:27 (98726 ms) : SNMP Datatype: ASN_UNSIGNED
Test 1.3.6.1.2.1.4.24.3.0: value=3 #
14.12.2019 23:31:28 (99944 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.1.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
14.12.2019 23:31:30 (101377 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.1.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
14.12.2019 23:31:31 (102658 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.1.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #
14.12.2019 23:31:32 (103789 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.2.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
14.12.2019 23:31:33 (104495 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.2.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
14.12.2019 23:31:33 (105034 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.2.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #
14.12.2019 23:31:35 (106269 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.3.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
14.12.2019 23:31:36 (107475 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.3.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
14.12.2019 23:31:37 (108783 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.3.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #
14.12.2019 23:31:39 (110254 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.4.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
14.12.2019 23:31:40 (111267 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.4.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
14.12.2019 23:31:40 (111839 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.4.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #
14.12.2019 23:31:41 (112396 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.5.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
14.12.2019 23:31:42 (113092 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.5.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
14.12.2019 23:31:42 (113881 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.5.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #
14.12.2019 23:31:43 (114760 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.6.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
14.12.2019 23:31:44 (115728 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.6.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
14.12.2019 23:31:45 (116158 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.6.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #
14.12.2019 23:31:45 (116616 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.7.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
14.12.2019 23:31:46 (117546 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.7.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
14.12.2019 23:31:47 (118558 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.7.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #
14.12.2019 23:31:48 (119709 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.8.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
14.12.2019 23:31:50 (121071 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.8.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
14.12.2019 23:31:51 (122398 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.8.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #
14.12.2019 23:31:52 (123440 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.10.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
14.12.2019 23:31:53 (124483 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.10.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
14.12.2019 23:31:54 (125600 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.10.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #
14.12.2019 23:31:55 (126839 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.11.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
14.12.2019 23:31:56 (127828 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.11.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
14.12.2019 23:31:58 (129141 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.11.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #
14.12.2019 23:31:58 (129730 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.12.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
14.12.2019 23:31:59 (130054 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.12.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
14.12.2019 23:31:59 (130798 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.12.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #
14.12.2019 23:32:00 (131935 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.13.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
14.12.2019 23:32:01 (132994 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.13.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
14.12.2019 23:32:03 (134092 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.13.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #
14.12.2019 23:32:04 (135693 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.14.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
14.12.2019 23:32:05 (136548 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.14.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
14.12.2019 23:32:06 (137167 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.14.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #
14.12.2019 23:32:06 (137965 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.15.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
14.12.2019 23:32:07 (138930 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.15.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
14.12.2019 23:32:09 (140092 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.15.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #
14.12.2019 23:32:10 (141385 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.16.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
14.12.2019 23:32:11 (142697 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.16.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
14.12.2019 23:32:13 (144062 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.16.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #

With 6.45.7 (or less) a good result:

Testing OIDs...
14.12.2019 23:34:53 (6895 ms) : SNMP Datatype: ASN_UNSIGNED
Test 1.3.6.1.2.1.4.24.3.0: value=3 #
14.12.2019 23:34:53 (7012 ms) : SNMP Datatype: ASN_IPADDRESS
Test 1.3.6.1.2.1.4.24.4.1.1.0.0.0.0.0.0.0.0.0.10.10.0.1: value=0.0.0.0 #
14.12.2019 23:34:53 (7128 ms) : SNMP Datatype: ASN_IPADDRESS
Test 1.3.6.1.2.1.4.24.4.1.1.10.10.0.0.255.255.252.0.0.10.10.0.70: value=10.10.0.0 #
14.12.2019 23:34:53 (7245 ms) : SNMP Datatype: ASN_IPADDRESS
Test 1.3.6.1.2.1.4.24.4.1.1.192.168.11.0.255.255.255.0.0.192.168.11.1: value=192.168.11.0 #
14.12.2019 23:34:53 (7361 ms) : SNMP Datatype: ASN_IPADDRESS
Test 1.3.6.1.2.1.4.24.4.1.2.0.0.0.0.0.0.0.0.0.10.10.0.1: value=0.0.0.0 #
14.12.2019 23:34:53 (7620 ms) : SNMP Datatype: ASN_IPADDRESS
Test 1.3.6.1.2.1.4.24.4.1.2.10.10.0.0.255.255.252.0.0.10.10.0.70: value=255.255.252.0 #
14.12.2019 23:34:54 (7937 ms) : SNMP Datatype: ASN_IPADDRESS
Test 1.3.6.1.2.1.4.24.4.1.2.192.168.11.0.255.255.255.0.0.192.168.11.1: value=255.255.255.0 #
14.12.2019 23:34:54 (8054 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.3.0.0.0.0.0.0.0.0.0.10.10.0.1: value=0 #
14.12.2019 23:34:54 (8172 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.3.10.10.0.0.255.255.252.0.0.10.10.0.70: value=0 #
14.12.2019 23:34:54 (8288 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.3.192.168.11.0.255.255.255.0.0.192.168.11.1: value=0 #
14.12.2019 23:34:54 (8447 ms) : SNMP Datatype: ASN_IPADDRESS
Test 1.3.6.1.2.1.4.24.4.1.4.0.0.0.0.0.0.0.0.0.10.10.0.1: value=10.10.0.1 #
14.12.2019 23:34:55 (8753 ms) : SNMP Datatype: ASN_IPADDRESS
Test 1.3.6.1.2.1.4.24.4.1.4.10.10.0.0.255.255.252.0.0.10.10.0.70: value=10.10.0.70 #
14.12.2019 23:34:55 (8878 ms) : SNMP Datatype: ASN_IPADDRESS
Test 1.3.6.1.2.1.4.24.4.1.4.192.168.11.0.255.255.255.0.0.192.168.11.1: value=192.168.11.1 #
14.12.2019 23:34:55 (8997 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.5.0.0.0.0.0.0.0.0.0.10.10.0.1: value=11 #
14.12.2019 23:34:55 (9161 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.5.10.10.0.0.255.255.252.0.0.10.10.0.70: value=11 #
14.12.2019 23:34:55 (9375 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.5.192.168.11.0.255.255.255.0.0.192.168.11.1: value=12 #
14.12.2019 23:34:55 (9626 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.6.0.0.0.0.0.0.0.0.0.10.10.0.1: value=4 #
14.12.2019 23:34:56 (9831 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.6.10.10.0.0.255.255.252.0.0.10.10.0.70: value=3 #
14.12.2019 23:34:56 (9979 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.6.192.168.11.0.255.255.255.0.0.192.168.11.1: value=3 #
14.12.2019 23:34:56 (10094 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.7.0.0.0.0.0.0.0.0.0.10.10.0.1: value=3 #
14.12.2019 23:34:56 (10210 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.7.10.10.0.0.255.255.252.0.0.10.10.0.70: value=2 #
14.12.2019 23:34:56 (10325 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.7.192.168.11.0.255.255.255.0.0.192.168.11.1: value=2 #
14.12.2019 23:34:56 (10581 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.8.0.0.0.0.0.0.0.0.0.10.10.0.1: value=0 #
14.12.2019 23:34:57 (10794 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.8.10.10.0.0.255.255.252.0.0.10.10.0.70: value=0 #
14.12.2019 23:34:57 (10907 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.8.192.168.11.0.255.255.255.0.0.192.168.11.1: value=0 #
14.12.2019 23:34:57 (11043 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.10.0.0.0.0.0.0.0.0.0.10.10.0.1: value=0 #
14.12.2019 23:34:57 (11156 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.10.10.10.0.0.255.255.252.0.0.10.10.0.70: value=0 #
14.12.2019 23:34:57 (11270 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.10.192.168.11.0.255.255.255.0.0.192.168.11.1: value=0 #
14.12.2019 23:34:57 (11384 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.11.0.0.0.0.0.0.0.0.0.10.10.0.1: value=1 #
14.12.2019 23:34:57 (11617 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.11.10.10.0.0.255.255.252.0.0.10.10.0.70: value=0 #
14.12.2019 23:34:58 (11814 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.11.192.168.11.0.255.255.255.0.0.192.168.11.1: value=0 #
14.12.2019 23:34:58 (11918 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.12.0.0.0.0.0.0.0.0.0.10.10.0.1: value=4294967295 #
14.12.2019 23:34:58 (12132 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.12.10.10.0.0.255.255.252.0.0.10.10.0.70: value=4294967295 #
14.12.2019 23:34:58 (12236 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.12.192.168.11.0.255.255.255.0.0.192.168.11.1: value=4294967295 #
14.12.2019 23:34:58 (12342 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.13.0.0.0.0.0.0.0.0.0.10.10.0.1: value=4294967295 #
14.12.2019 23:34:58 (12587 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.13.10.10.0.0.255.255.252.0.0.10.10.0.70: value=4294967295 #
14.12.2019 23:34:59 (12785 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.13.192.168.11.0.255.255.255.0.0.192.168.11.1: value=4294967295 #
14.12.2019 23:34:59 (12889 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.14.0.0.0.0.0.0.0.0.0.10.10.0.1: value=4294967295 #
14.12.2019 23:34:59 (12999 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.14.10.10.0.0.255.255.252.0.0.10.10.0.70: value=4294967295 #
14.12.2019 23:34:59 (13103 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.14.192.168.11.0.255.255.255.0.0.192.168.11.1: value=4294967295 #
14.12.2019 23:34:59 (13208 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.15.0.0.0.0.0.0.0.0.0.10.10.0.1: value=4294967295 #
14.12.2019 23:34:59 (13312 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.15.10.10.0.0.255.255.252.0.0.10.10.0.70: value=4294967295 #
14.12.2019 23:34:59 (13458 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.15.192.168.11.0.255.255.255.0.0.192.168.11.1: value=4294967295 #
14.12.2019 23:35:00 (13755 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.16.0.0.0.0.0.0.0.0.0.10.10.0.1: value=1 #
14.12.2019 23:35:00 (13992 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.16.10.10.0.0.255.255.252.0.0.10.10.0.70: value=1 #
14.12.2019 23:35:00 (14193 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.16.192.168.11.0.255.255.255.0.0.192.168.11.1: value=1 #

emils · Mon Dec 16, 2019 9:01 am

Guscht You need to send supout.rif file to support@mikrotik.com and brief problem description. We are currently unable to reproduce such issue.

ivicask Have you tried the 6.46 stable and 6.47 testing versions? RoMoN works for me now. Make sure both the end user and the agent is updated. If it is not working in the latest versions, please open a support ticket with supout.rif file from your routers.

Guscht · Mon Dec 16, 2019 2:28 pm

Hi,

I did this already when V6.46 was released, but I got no response from you...

Try the SNMP-Tester (https://downloads.paessler.com/tools/SN ... +5.2.3.zip) from PRTG.
The OID-LIB (IP-FORWARD.MIB) is attached.

Then simply run the OID-LIB against a RouterOS device with ROS V6.46 or greater. It will fail in the way I posted I above (SNMP Error 222).
ROS V6.45.7 (or lower) report valid data back.

hc_001.jpg

bnw · Mon Dec 16, 2019 2:54 pm

viewtopic.php?f=2&t=116856#p741203
I opened #2019032822004818 a few months ago, many SNMP hardware OIDs are missing for the CCR1072, compared to what Winbox shows

In v6.47beta there is a new menu added - "/system health gauges". You should use this for polling "Health" related data from all the RouterBOARDs.

Does this come with new associated MIBs / OID's? Or more for polling via API?

Interesting. And if available through SNMP, will these "gauges" give the PSUs status (which are for now missing on CCR1072 as stated above) ?

Good news, here is what we now have (as of 6.47b8) for the CCR1072 :

$ snmpwalk ... .1.3.6.1.4.1.14988.1.1.3
.1.3.6.1.4.1.14988.1.1.3.9.0 = STRING: "n/a"
.1.3.6.1.4.1.14988.1.1.3.11.0 = INTEGER: 370
.1.3.6.1.4.1.14988.1.1.3.12.0 = INTEGER: 435
.1.3.6.1.4.1.14988.1.1.3.14.0 = INTEGER: 1000
.1.3.6.1.4.1.14988.1.1.3.17.0 = Gauge32: 4169
.1.3.6.1.4.1.14988.1.1.3.18.0 = Gauge32: 4182
.1.3.6.1.4.1.14988.1.1.3.100.1.16 = STRING: "power-consumption"
.1.3.6.1.4.1.14988.1.1.3.100.1.17 = STRING: "cpu-temperature"
.1.3.6.1.4.1.14988.1.1.3.100.1.7001 = STRING: "fan1-speed"
.1.3.6.1.4.1.14988.1.1.3.100.1.7002 = STRING: "fan2-speed"
.1.3.6.1.4.1.14988.1.1.3.100.1.7003 = STRING: "fan3-speed"
.1.3.6.1.4.1.14988.1.1.3.100.1.7004 = STRING: "fan4-speed"
.1.3.6.1.4.1.14988.1.1.3.100.1.7101 = STRING: "board-temperature1"
.1.3.6.1.4.1.14988.1.1.3.100.1.7102 = STRING: "board-temperature2"
.1.3.6.1.4.1.14988.1.1.3.100.1.7201 = STRING: "psu1-voltage"
.1.3.6.1.4.1.14988.1.1.3.100.1.7202 = STRING: "psu2-voltage"
.1.3.6.1.4.1.14988.1.1.3.100.1.7301 = STRING: "psu1-current"
.1.3.6.1.4.1.14988.1.1.3.100.1.7302 = STRING: "psu2-current"
.1.3.6.1.4.1.14988.1.1.3.100.2.16 = Gauge32: 435
.1.3.6.1.4.1.14988.1.1.3.100.2.17 = Gauge32: 37
.1.3.6.1.4.1.14988.1.1.3.100.2.7001 = Gauge32: 4169
.1.3.6.1.4.1.14988.1.1.3.100.2.7002 = Gauge32: 4182
.1.3.6.1.4.1.14988.1.1.3.100.2.7003 = Gauge32: 4182
.1.3.6.1.4.1.14988.1.1.3.100.2.7004 = Gauge32: 4222
.1.3.6.1.4.1.14988.1.1.3.100.2.7101 = Gauge32: 25
.1.3.6.1.4.1.14988.1.1.3.100.2.7102 = Gauge32: 25
.1.3.6.1.4.1.14988.1.1.3.100.2.7201 = Gauge32: 0
.1.3.6.1.4.1.14988.1.1.3.100.2.7202 = Gauge32: 121
.1.3.6.1.4.1.14988.1.1.3.100.2.7301 = Gauge32: 0
.1.3.6.1.4.1.14988.1.1.3.100.2.7302 = Gauge32: 36
.1.3.6.1.4.1.14988.1.1.3.100.3.16 = INTEGER: 5
.1.3.6.1.4.1.14988.1.1.3.100.3.17 = INTEGER: 1
.1.3.6.1.4.1.14988.1.1.3.100.3.7001 = INTEGER: 2
.1.3.6.1.4.1.14988.1.1.3.100.3.7002 = INTEGER: 2
.1.3.6.1.4.1.14988.1.1.3.100.3.7003 = INTEGER: 2
.1.3.6.1.4.1.14988.1.1.3.100.3.7004 = INTEGER: 2
.1.3.6.1.4.1.14988.1.1.3.100.3.7101 = INTEGER: 1
.1.3.6.1.4.1.14988.1.1.3.100.3.7102 = INTEGER: 1
.1.3.6.1.4.1.14988.1.1.3.100.3.7201 = INTEGER: 3
.1.3.6.1.4.1.14988.1.1.3.100.3.7202 = INTEGER: 3
.1.3.6.1.4.1.14988.1.1.3.100.3.7301 = INTEGER: 4
.1.3.6.1.4.1.14988.1.1.3.100.3.7302 = INTEGER: 4

.1.3.6.1.4.1.14988.1.1.3.100 is the new interesting part, the gauges.

Same new gauges on a RB4011 :

$ snmpwalk ... .1.3.6.1.4.1.14988.1.1.3
.1.3.6.1.4.1.14988.1.1.3.9.0 = STRING: "n/a"
.1.3.6.1.4.1.14988.1.1.3.10.0 = INTEGER: 270
.1.3.6.1.4.1.14988.1.1.3.14.0 = INTEGER: 1400
.1.3.6.1.4.1.14988.1.1.3.100.1.13 = STRING: "voltage"
.1.3.6.1.4.1.14988.1.1.3.100.1.14 = STRING: "temperature"
.1.3.6.1.4.1.14988.1.1.3.100.2.13 = Gauge32: 238
.1.3.6.1.4.1.14988.1.1.3.100.2.14 = Gauge32: 27
.1.3.6.1.4.1.14988.1.1.3.100.3.13 = INTEGER: 3
.1.3.6.1.4.1.14988.1.1.3.100.3.14 = INTEGER: 1

We'll now be able to properly monitor CCR1072

Many thanks MikroTik for this !

bnw · Mon Dec 16, 2019 4:12 pm

One thing perhaps following my post above.
We have the PSUs' voltage and current in these new gauges.
We could then monitor PSUs checking for example that voltage >12.
Will you however add a psu-state OID ?

Could you also provide us with the new MIB containing these gauges' part please ?

Thank you again !

mducharme · Thu Dec 19, 2019 7:48 am

I am curious - how many more 6.4x versions are expected given that 7 is now in beta? Is 6.47 or 6.48 possibly the last RouterOS 6.x? Or will there be a longer period of overlap while 7.x is released and 6.x is still being developed?

ivicask · Thu Dec 19, 2019 1:18 pm

Guscht You need to send supout.rif file to support@mikrotik.com and brief problem description. We are currently unable to reproduce such issue.

ivicask Have you tried the 6.46 stable and 6.47 testing versions? RoMoN works for me now. Make sure both the end user and the agent is updated. If it is not working in the latest versions, please open a support ticket with supout.rif file from your routers.

Installed 6.47beta8 and works fine now, thanks!

Maggiore81 · Fri Dec 27, 2019 9:08 am

I am curious - how many more 6.4x versions are expected given that 7 is now in beta? Is 6.47 or 6.48 possibly the last RouterOS 6.x? Or will there be a longer period of overlap while 7.x is released and 6.x is still being developed?

Hello. You have to consider that a lot of devices are unable to support ros 7 because of flash disk limitations. I think that they should develop ros 6 for a loong time.

JohnTRIVOLTA · Mon Dec 30, 2019 10:23 am

I moved the question in ros v7.0beta4 topic !

eworm · Mon Jan 06, 2020 10:20 pm

In v6.47beta there is a new menu added - "/system health gauges". You should use this for polling "Health" related data from all the RouterBOARDs.

Just testing this...

[admin@MikroTik] /system health gauges> :put [ :typeof [ get [ find where type="V" ] value ] ]  
str
[admin@Mikrotik] /system health gauges> :put [ get [ find where type="V" ] value ]            
50.3

As RouterOS does not support decimal numbers with place (but only integer)... Any chance to change the unit (V/10 or mV) and return numeric values here?
That would simplify using the values in scripts a lot! Thanks!

emils · Mon Jan 13, 2020 3:34 pm

Version 6.47beta19 has been released.

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.47beta19 (2020-Jan-09 08:08):

MAJOR CHANGES IN v6.47:
----------------------
!) socks - added support for SOCKS5 (RFC 1928);
----------------------

Changes in this release:

!) socks - added support for SOCKS5 (RFC 1928);
*) bonding - improved slave interface MAC address handling;
*) bonding - prefer primary slave MAC address for bonding interface;
*) bridge - added logging message when a host MAC address is learned on a different bridge port;
*) chr - improved stability when changing ARP modes on e1000 type adapters;
*) console - prevent "flash" directory from being removed (introduced in v6.46);
*) console - updated copyright notice;
*) crs305 - disable optical SFP/SFP+ module Tx power after disabling SFP+ interface;
*) defconf - fixed "caps-mode" not initialized properly after resetting;
*) defconf - fixed default configuration loading on RBwAPG-60adkit (introduced in v6.46);
*) discovery - do not send CDP and LLDP packets on interfaces that does not have MAC address;
*) discovery - do not send discovery packets on inactive bonding slave interfaces;
*) discovery - do not send discovery packets on interfaces that are blocked by STP;
*) dot1x - added "radius-mac-format" parameter (CLI only);
*) health - added "gauges" submenu with SNMP OID reporting;
*) lora - added "ru-864-mid" channel plan;
*) lora - fixed packet sending when using "antenna-gain" higher than 5dB;
*) lora - improved immediate packet delivery;
*) lte - do not allow running "scan" on R11e-4G;
*) lte - fixed "band" value setting when configuration is reset on R11e-4G;
*) lte - fixed "cell-monitor" on R11e-LTE in 3G mode;
*) lte - fixed "earfcn" reporting on R11e-LTE6 in UMTS and GSM modes;
*) lte - improved all APN session activation after disconnect on R11e-LTE;
*) lte - report only valid info parameters on R11e-LTE6;
*) lte - use APN from network when blank APN used on R11e-4G;
*) ppp - fixed minor typo in "ppp-client" monitor;
*) qsfp - do not report bogus monitoring readouts on modules without DDMI support;
*) qsfp - improved module monitoring readouts for DAC and break-out cables;
*) routerboard - added "mode-button" support for RBcAP2nD;
*) sniffer - allow setting port for "streaming-server";
*) snmp - added "dot1qTpFdbTable" OID reporting for Q-BRIDGE-MIB;
*) snmp - improved OID policy checking and error reporting on "set" command;
*) supout - added "dot1x" section to supout files;
*) system - correctly handle Generic Receive Offloading (GRO) for MPLS traffic;
*) system - fixed "*.auto.rsc" file execution (introduced in v6.46);
*) system - fixed "check-installation" on PowerPC devices (introduced in v6.46);
*) traceroute - improved stability when invalid packet is received;
*) traffic-generator - improved memory handling on CHR;
*) webfig - allow skin designing without "ftp" and "sensitive" policies;
*) webfig - fixed "skins" saving to "flash" directory if it exists (introduced in v6.46);
*) winbox - automatically refresh "Packets" table when new packets are captured by "Tools/Packet Sniffer";
*) winbox - fixed "Default Route Distance" default value when creating new LTE APN;
*) winbox - removed duplicate "join-eui", "dev-eui", "counter", "chain", "size" and "payload" parameters under "Lora/Traffic";

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.

guipoletto · Mon Jan 13, 2020 4:52 pm

!) socks - added support for SOCKS5 (RFC 1928);
Well, it's january, and it's christmas again! S2

SiB · Mon Jan 13, 2020 5:25 pm

*) winbox - automatically refresh "Packets" table when new packets are captured by "Tools/Packet Sniffer";

AWESOME, So good to see this :)
The button with "Clear" and "AutoScrool" will be good addition as future request.
.
.
---------------------------------------------------------------------------------------

*) lte - fixed "cell-monitor" on R11e-LTE in 3G mode;
*) lte - fixed "earfcn" reporting on R11e-LTE6 in UMTS and GSM modes;

DY33IxHn0r.png

But still developers can easily show current PHY-CellID because it is in hex in at command response:

/log print where message~"CREG: 1"
lte,async,raw SXTR__LTE: $CREG: 1,"2b01","047ff4fb",2,"021"
# $CREG: 1,"LAC hex","CellID hex",UMTS type,"PHY-CellID hex"

In my example 021hex => 33 dec and CellLock in 3G works as:

/interface lte at-chat lte1 input="at*cell=2,2,,3030,33"

but with all detected phy-cellid from cell-monitor I cannot connect and my current 33 dec is not detected by cell-monitor.
Reported: SUP-3946
.
.
---------------------------------------------------------------------------------------
.

*) lte - report only valid info parameters on R11e-LTE6;

What this means?
.
.
---------------------------------------------------------------------------------------
Error 1) Cannot login via RoMon and WinBox (by IPv4).
Upgrade SXTR+R11e-LTE6 = not possibility to login via RoMON and WinBox by IP.
MACTelnet and WinBox via mac-address works. Logs:

16:46:50 echo: system,error,critical login failure for user marcin.przysowa from 192.168.88.253 by romon 00:00:00:00:00:01 via winbox
22:25:22 warning denied winbox/dude connect from 192.168.91.253

I type many time's the same credentials. They works via MacTelnet, not works by RoMON. I create a super easy asd user with password asd123 and still the same.
New Sniffer not see the incomming IPv4 but MAC-ADDRESS-es but in logs he report the IPv4 and tools torch see the IPv4.

winbox_v3.20_64_1dJ4785PvW.png

from PC

Wireshark_wXmDbBOpfV.png

irghost · Tue Jan 14, 2020 1:23 pm

Version 6.47beta19 has been released.

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.47beta19 (2020-Jan-09 08:08):

MAJOR CHANGES IN v6.47:
----------------------
!) socks - added support for SOCKS5 (RFC 1928);
----------------------

Changes in this release:

!) socks - added support for SOCKS5 (RFC 1928);
*) bonding - improved slave interface MAC address handling;
*) bonding - prefer primary slave MAC address for bonding interface;
*) bridge - added logging message when a host MAC address is learned on a different bridge port;
*) chr - improved stability when changing ARP modes on e1000 type adapters;
*) console - prevent "flash" directory from being removed (introduced in v6.46);
*) console - updated copyright notice;
*) crs305 - disable optical SFP/SFP+ module Tx power after disabling SFP+ interface;
*) defconf - fixed "caps-mode" not initialized properly after resetting;
*) defconf - fixed default configuration loading on RBwAPG-60adkit (introduced in v6.46);
*) discovery - do not send CDP and LLDP packets on interfaces that does not have MAC address;
*) discovery - do not send discovery packets on inactive bonding slave interfaces;
*) discovery - do not send discovery packets on interfaces that are blocked by STP;
*) dot1x - added "radius-mac-format" parameter (CLI only);
*) health - added "gauges" submenu with SNMP OID reporting;
*) lora - added "ru-864-mid" channel plan;
*) lora - fixed packet sending when using "antenna-gain" higher than 5dB;
*) lora - improved immediate packet delivery;
*) lte - do not allow running "scan" on R11e-4G;
*) lte - fixed "band" value setting when configuration is reset on R11e-4G;
*) lte - fixed "cell-monitor" on R11e-LTE in 3G mode;
*) lte - fixed "earfcn" reporting on R11e-LTE6 in UMTS and GSM modes;
*) lte - improved all APN session activation after disconnect on R11e-LTE;
*) lte - report only valid info parameters on R11e-LTE6;
*) lte - use APN from network when blank APN used on R11e-4G;
*) ppp - fixed minor typo in "ppp-client" monitor;
*) qsfp - do not report bogus monitoring readouts on modules without DDMI support;
*) qsfp - improved module monitoring readouts for DAC and break-out cables;
*) routerboard - added "mode-button" support for RBcAP2nD;
*) sniffer - allow setting port for "streaming-server";
*) snmp - added "dot1qTpFdbTable" OID reporting for Q-BRIDGE-MIB;
*) snmp - improved OID policy checking and error reporting on "set" command;
*) supout - added "dot1x" section to supout files;
*) system - correctly handle Generic Receive Offloading (GRO) for MPLS traffic;
*) system - fixed "*.auto.rsc" file execution (introduced in v6.46);
*) system - fixed "check-installation" on PowerPC devices (introduced in v6.46);
*) traceroute - improved stability when invalid packet is received;
*) traffic-generator - improved memory handling on CHR;
*) webfig - allow skin designing without "ftp" and "sensitive" policies;
*) webfig - fixed "skins" saving to "flash" directory if it exists (introduced in v6.46);
*) winbox - automatically refresh "Packets" table when new packets are captured by "Tools/Packet Sniffer";
*) winbox - fixed "Default Route Distance" default value when creating new LTE APN;
*) winbox - removed duplicate "join-eui", "dev-eui", "counter", "chain", "size" and "payload" parameters under "Lora/Traffic";

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.

Socks5 with radius auth? maybe?

Tue Jan 14, 2020 3:18 pm

@irqhost: why do you quoute whole post? Isn't it enough just to ask a question in this thread?

Jotne · Tue Jan 14, 2020 8:47 pm

Many does not see det big red post button at the bottom of the page

Guscht · Thu Jan 16, 2020 1:09 pm

Just for your information, the SNMP-IP-Forward is still broken (with V6.47beta19):

Testing OIDs...
16.01.2020 12:01:28 (1401 ms) : SNMP Datatype: ASN_UNSIGNED
Test 1.3.6.1.2.1.4.24.3.0: value=3 #
16.01.2020 12:01:28 (1433 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.1.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
16.01.2020 12:01:28 (1467 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.1.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
16.01.2020 12:01:28 (1503 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.1.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #
16.01.2020 12:01:28 (1532 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.2.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
16.01.2020 12:01:28 (1560 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.2.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
16.01.2020 12:01:28 (1587 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.2.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (1617 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.3.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (1649 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.3.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (1680 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.3.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (1710 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.4.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (1740 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.4.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (1764 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.4.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (1791 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.5.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (1818 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.5.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (1851 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.5.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (1880 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.6.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (1906 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.6.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (1930 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.6.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (1958 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.7.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (1981 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.7.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (2008 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.7.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (2033 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.8.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (2062 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.8.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (2086 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.8.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (2112 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.10.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (2137 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.10.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (2166 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.10.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (2213 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.11.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (2233 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.11.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (2257 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.11.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (2284 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.12.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (2308 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.12.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (2332 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.12.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (2357 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.13.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (2379 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.13.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (2405 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.13.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (2426 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.14.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (2449 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.14.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (2474 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.14.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (2495 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.15.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (2524 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.15.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (2543 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.15.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (2565 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.16.0.0.0.0.0.0.0.0.0.10.10.0.1: value=No such object (SNMP error # 222) #
16.01.2020 12:01:29 (2589 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.16.10.10.0.0.255.255.252.0.0.10.10.0.70: value=No such object (SNMP error # 222) #
16.01.2020 12:01:30 (2614 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHOBJECT
Test 1.3.6.1.2.1.4.24.4.1.16.192.168.11.0.255.255.255.0.0.192.168.11.1: value=No such object (SNMP error # 222) #

And here are the expected result after downgrading (with V6.44.6):

Testing OIDs...
16.01.2020 12:06:09 (1173 ms) : SNMP Datatype: ASN_UNSIGNED
Test 1.3.6.1.2.1.4.24.3.0: value=3 #
16.01.2020 12:06:09 (1200 ms) : SNMP Datatype: ASN_IPADDRESS
Test 1.3.6.1.2.1.4.24.4.1.1.0.0.0.0.0.0.0.0.0.10.10.0.1: value=0.0.0.0 #
16.01.2020 12:06:09 (1226 ms) : SNMP Datatype: ASN_IPADDRESS
Test 1.3.6.1.2.1.4.24.4.1.1.10.10.0.0.255.255.252.0.0.10.10.0.70: value=10.10.0.0 #
16.01.2020 12:06:09 (1255 ms) : SNMP Datatype: ASN_IPADDRESS
Test 1.3.6.1.2.1.4.24.4.1.1.192.168.11.0.255.255.255.0.0.192.168.11.1: value=192.168.11.0 #
16.01.2020 12:06:09 (1283 ms) : SNMP Datatype: ASN_IPADDRESS
Test 1.3.6.1.2.1.4.24.4.1.2.0.0.0.0.0.0.0.0.0.10.10.0.1: value=0.0.0.0 #
16.01.2020 12:06:09 (1304 ms) : SNMP Datatype: ASN_IPADDRESS
Test 1.3.6.1.2.1.4.24.4.1.2.10.10.0.0.255.255.252.0.0.10.10.0.70: value=255.255.252.0 #
16.01.2020 12:06:09 (1328 ms) : SNMP Datatype: ASN_IPADDRESS
Test 1.3.6.1.2.1.4.24.4.1.2.192.168.11.0.255.255.255.0.0.192.168.11.1: value=255.255.255.0 #
16.01.2020 12:06:09 (1354 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.3.0.0.0.0.0.0.0.0.0.10.10.0.1: value=0 #
16.01.2020 12:06:09 (1383 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.3.10.10.0.0.255.255.252.0.0.10.10.0.70: value=0 #
16.01.2020 12:06:09 (1405 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.3.192.168.11.0.255.255.255.0.0.192.168.11.1: value=0 #
16.01.2020 12:06:09 (1430 ms) : SNMP Datatype: ASN_IPADDRESS
Test 1.3.6.1.2.1.4.24.4.1.4.0.0.0.0.0.0.0.0.0.10.10.0.1: value=10.10.0.1 #
16.01.2020 12:06:09 (1453 ms) : SNMP Datatype: ASN_IPADDRESS
Test 1.3.6.1.2.1.4.24.4.1.4.10.10.0.0.255.255.252.0.0.10.10.0.70: value=10.10.0.70 #
16.01.2020 12:06:09 (1480 ms) : SNMP Datatype: ASN_IPADDRESS
Test 1.3.6.1.2.1.4.24.4.1.4.192.168.11.0.255.255.255.0.0.192.168.11.1: value=192.168.11.1 #
16.01.2020 12:06:09 (1504 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.5.0.0.0.0.0.0.0.0.0.10.10.0.1: value=11 #
16.01.2020 12:06:09 (1529 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.5.10.10.0.0.255.255.252.0.0.10.10.0.70: value=11 #
16.01.2020 12:06:09 (1554 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.5.192.168.11.0.255.255.255.0.0.192.168.11.1: value=12 #
16.01.2020 12:06:09 (1581 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.6.0.0.0.0.0.0.0.0.0.10.10.0.1: value=4 #
16.01.2020 12:06:09 (1601 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.6.10.10.0.0.255.255.252.0.0.10.10.0.70: value=3 #
16.01.2020 12:06:09 (1624 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.6.192.168.11.0.255.255.255.0.0.192.168.11.1: value=3 #
16.01.2020 12:06:09 (1648 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.7.0.0.0.0.0.0.0.0.0.10.10.0.1: value=3 #
16.01.2020 12:06:09 (1670 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.7.10.10.0.0.255.255.252.0.0.10.10.0.70: value=2 #
16.01.2020 12:06:09 (1697 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.7.192.168.11.0.255.255.255.0.0.192.168.11.1: value=2 #
16.01.2020 12:06:09 (1717 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.8.0.0.0.0.0.0.0.0.0.10.10.0.1: value=0 #
16.01.2020 12:06:09 (1740 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.8.10.10.0.0.255.255.252.0.0.10.10.0.70: value=0 #
16.01.2020 12:06:09 (1763 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.8.192.168.11.0.255.255.255.0.0.192.168.11.1: value=0 #
16.01.2020 12:06:09 (1785 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.10.0.0.0.0.0.0.0.0.0.10.10.0.1: value=0 #
16.01.2020 12:06:09 (1812 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.10.10.10.0.0.255.255.252.0.0.10.10.0.70: value=0 #
16.01.2020 12:06:09 (1835 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.10.192.168.11.0.255.255.255.0.0.192.168.11.1: value=0 #
16.01.2020 12:06:09 (1857 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.11.0.0.0.0.0.0.0.0.0.10.10.0.1: value=1 #
16.01.2020 12:06:09 (1879 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.11.10.10.0.0.255.255.252.0.0.10.10.0.70: value=0 #
16.01.2020 12:06:09 (1900 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.11.192.168.11.0.255.255.255.0.0.192.168.11.1: value=0 #
16.01.2020 12:06:10 (1927 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.12.0.0.0.0.0.0.0.0.0.10.10.0.1: value=4294967295 #
16.01.2020 12:06:10 (1951 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.12.10.10.0.0.255.255.252.0.0.10.10.0.70: value=4294967295 #
16.01.2020 12:06:10 (1974 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.12.192.168.11.0.255.255.255.0.0.192.168.11.1: value=4294967295 #
16.01.2020 12:06:10 (1997 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.13.0.0.0.0.0.0.0.0.0.10.10.0.1: value=4294967295 #
16.01.2020 12:06:10 (2017 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.13.10.10.0.0.255.255.252.0.0.10.10.0.70: value=4294967295 #
16.01.2020 12:06:10 (2044 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.13.192.168.11.0.255.255.255.0.0.192.168.11.1: value=4294967295 #
16.01.2020 12:06:10 (2068 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.14.0.0.0.0.0.0.0.0.0.10.10.0.1: value=4294967295 #
16.01.2020 12:06:10 (2091 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.14.10.10.0.0.255.255.252.0.0.10.10.0.70: value=4294967295 #
16.01.2020 12:06:10 (2115 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.14.192.168.11.0.255.255.255.0.0.192.168.11.1: value=4294967295 #
16.01.2020 12:06:10 (2138 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.15.0.0.0.0.0.0.0.0.0.10.10.0.1: value=4294967295 #
16.01.2020 12:06:10 (2190 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.15.10.10.0.0.255.255.252.0.0.10.10.0.70: value=4294967295 #
16.01.2020 12:06:10 (2210 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.15.192.168.11.0.255.255.255.0.0.192.168.11.1: value=4294967295 #
16.01.2020 12:06:10 (2239 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.16.0.0.0.0.0.0.0.0.0.10.10.0.1: value=1 #
16.01.2020 12:06:10 (2261 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.16.10.10.0.0.255.255.252.0.0.10.10.0.70: value=1 #
16.01.2020 12:06:10 (2285 ms) : SNMP Datatype: ASN_INTEGER
Test 1.3.6.1.2.1.4.24.4.1.16.192.168.11.0.255.255.255.0.0.192.168.11.1: value=1 #

I have already sent you supout-files. But I've never got an answer from you...
My wish, please fix this problem, It was introduces with V6.46.

emils · Thu Jan 16, 2020 1:39 pm

Please provide the ticket number starting with "SUP-". We are unable to reproduce the issue.

Michel · Thu Jan 16, 2020 7:22 pm

Try to update my RB4011 from routeros-arm-6.46.2.npk + user-manager-6.46.2-arm.npk = Error IPSEC can no longer login, downgrade back to 6.46.2

kmrue · Mon Jan 27, 2020 7:35 pm

as no UPS-bugfixing is listed I tested anyhow:
UPS still not working with APC SMT750I, SMT1000I, SMT1500I (to name just 3 models). All of them connected via their USB-port. They all get identified, but only a few parameters get transferred to the routerboard. Tested using CRS125.

Is there anything you guys @ mikrotik want me to further check out?

Anyone @Mikrotik working on that bug?

bnw · Tue Jan 28, 2020 1:14 am

One thing perhaps following my post above.
We have the PSUs' voltage and current in these new gauges.
We could then monitor PSUs checking for example that voltage >12.
Will you however add a psu-state OID ?

Same thing finally for the FANs.
On some devices, FAN speed always remains at a high level, making FAN monitoring based on their speed rather easy.
Though, on some other devices, FAN speed sometimes falls to 0 RPM, then increases to some thousands, then falls again to 0...
Making FAN speed monitoring on such devices rather impossible.

Could you then also add a fan-state OID among the new health gauges ?

Many thanks !

buset1974 · Sat Feb 08, 2020 5:52 pm

anyone can explain what exactly improve on this

*) system - correctly handle Generic Receive Offloading (GRO) for MPLS traffic;

i 'am having ping rapid random timeout on vpls, hope the improvement can fix the problem.

thx

emils · Mon Feb 10, 2020 4:11 pm

Version 6.47beta32 has been released.

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.47beta32 (2020-Feb-10 11:45):

Important note!!!

- The Dude server must be updated to monitor v6.47beta30+ RouterOS type devices.
- The Dude client must be manually upgraded after upgrading The Dude server.
- Make sure LTE APN Profile name does not match any of the DHCP server's names if LTE passthrough is used.

MAJOR CHANGES IN v6.47:
----------------------
!) socks - added support for SOCKS5 (RFC 1928);
----------------------

Changes in this release:

*) arm - improved watchdog and kernel panic reporting in log after reboots on RB3011 and IPQ4018/IPQ4019 devices ("/system routerboard upgrade" required);
*) branding - allow forcing configuration script as default configuration (new branding packet required);
*) branding - fixed "company-url" and "router-default-name" survival after system upgrade;
*) branding - fixed WEB HTML page survival after system upgrade;
*) certificate - fixed certificate verification when flushing CRL's;
*) crs3xx - correctly remove switch rules on CRS317-1G-16S+ and CRS309-1G-8S+ devices;
*) crs3xx - fixed QSFP+ interface linking for CRS326-24S+2Q+ device (introduced in v6.47beta19);
*) crs3xx - improved switch host table updating;
*) defconf - added welcome note with common first steps for new users;
*) defconf - fixed default configuration initialization if power loss occurred during the process;
*) defconf - fixed "no-defaults=yes" applying default configuration (introduced in v6.47beta);
*) disk - improved recently created file survival after reboots;
*) dns - use only servers received from IKEv2 server when present;
*) dot1x - added hex value support for RADIUS switch rules;
*) dot1x - added range "dst-port" support for RADIUS switch rules;
*) dot1x - added support for lower case "mac-auth" RADIUS formats;
*) dot1x - fixed dynamically created switch rule removal when client disconnects;
*) dot1x - fixed port blocking when interface changes state from disabled to enabled;
*) dot1x - fixed "reject-vlan-id" value range;
*) dot1x - improved debug logging output to "dot1x" topic;
*) dot1x - improved value validation for dynamically created switch rules;
*) dude - updated The Dude to use new style authentication method;
*) ike1 - added support for "UNITY_DEF_DOMAIN" and "UNITY_SPLITDNS_NAME" payload attributes;
*) ike2 - added support for "INTERNAL_DNS_DOMAIN" payload attribute;
*) ike2 - fixed DHCP Inform package handling when received on PPPoE interface;
*) ipsec - added "split-dns" parameter support for mode configuration (CLI only);
*) ipsec - fixed minor spelling mistake in logs;
*) ipsec - improved IPsec service stability when receiving bogus packets;
*) lte - added interface name prefix for logging events;
*) lte - added "phy-cellid" value support for LTE-US;
*) lte - added support for multiple passthrough APN configuration;
*) lte - do not allow using empty APN Profile names;
*) lte - show "phy-cellid" value only in LTE mode;
*) quickset - removed "LTE band" setting from Quick Set;
*) quickset - show "Antenna Gain" setting on devices without built-in antennas;
*) quickset - use "station-wds" mode when connecting to AP with RouterOS flag;
*) routing - improved IGMP-Proxy service stability when receiving bogus packets;
*) snmp - fixed "routeros-version" value returning from registration table;
*) snmp - fixed UPS battery voltage value scaling;
*) supout - improved UPS information reporting;
*) telnet - improved telnet compatibility with other client implementations;
*) tr069-client - removed warning log message when not using HTTPS;
*) traffic-flow - added "postDestinationMacAddress" parameter support for IPFIX and Netflow v9;
*) upgrade - fixed space handling in package file names;
*) ups - improved compatibility with APC Smart UPS 1000 and 1500;
*) user-manager - fixed signup enabling (introduced in v6.46);
*) w60g - improved stability after multiple disconnections;
*) webfig - added default configuration confirmation window to WebFig;
*) webfig - do not show WebFig menu when opening 'Check For Updates' in Quick Set;
*) winbox - added support for inline bar graphs for LTE signal values;
*) winbox - completely removed old style authentication method;
*) winbox - fixed "invalid" flag presence under "System/Certificates/CRL" menu;
*) wireless - improved compatibility for "ETSI" wireless country profile;
*) www - added "tls-version" parameter in "IP->Services" menu (CLI only);

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.

bpwl · Mon Feb 10, 2020 6:32 pm

What's new in 6.47beta32 (2020-Feb-10 11:45):

Why did you remove the "antenna gain" line in Winbox for wireless???? To fix the ETSI not imposing the minimum. ????

Well I knew ETSI regulatory domain forgot to check the minimal antenna gain. Countries did impose the minimal gain.

As setting TX power is difficult with the few left over options, the method explained in this forum several times is to increase the antenna gain, to reduce the transmit power.
"All rates fixed" is no good as the radio cannot follow for the higher MCS encodings. And "manual" and "card rates" is not allowed.
The only other oprion is not to set the country ("no_country_set") and go fully manual." What an improvement! Forget regulations, you are on your own now!"

Why did you remove the "antenna gain" line in Winbox ???? To fix the ETSI not imposing the minimum.? It was the only practical way to reduce the TX power, not to heat up the radio, and always be legal

Znevna · Mon Feb 10, 2020 11:14 pm

It's probably just a missed bug, you can still set the antenna gain from terminal. There's no mention of it beeing removed in the changelog, no need to panic like that.
It's under testing branch for a reason. Hold your horses.
I'm happy that this got fixed: *) ike2 - fixed DHCP Inform package handling when received on PPPoE interface;
BTW, shouldn't that be packet instead of package?

marekm · Mon Feb 10, 2020 11:55 pm

As for "all rates fixed", I'd like to see an additional mode setting where TX power for all rates is equal to the lowest value (for the highest rate) but set automatically (without need to specify any value). Why?
While it's OK to distort the transmitted signal a little more at QPSK compared to 64QAM (or 256QAM for AC) and it will still be received correctly, any distortion (no matter what modulation is used) will increase noise outside the proper channel width. Perhaps it still fits the wide spectral mask, but we are more noisy than usually needed.
So this setting woud be effectively "be nice to nearby devices on adjacent channels". You still gain RX sensitivity at lower modulations, but TX power would remain constant for less distortion.

bpwl · Tue Feb 11, 2020 12:49 am

@Znevna: I know it's test track only. But once a developper sets for a solution (no antenna gain check needed anymore) , they may stick to that.

It's a pain now to set the country, if you don't fill in the antenna gain before entering APPLY.,
Set the gain via "terminal" to a low value, and then let somebody set the country via WinBox or Webfig.

Same with the choice for the SXTsq ac 5, to only allow "outdoor" frequencies. I want to use it indoor ... but are limited to outdoor frequencies.
We know that the "outdoor" setting exists because it is more restrictive than "indoors". (You are not allowed to disturb the ether outdoors.)

Extrems · Tue Feb 11, 2020 1:12 am

*) dns - use only servers received from IKEv2 server when present;

This might sound strange, but I need to not use the servers received.

SiB · Tue Feb 11, 2020 2:39 am

@emils

Version 6.47beta32
*) winbox - added support for inline bar graphs for LTE signal values;

Where are that inline bar graphs? I cannot found it. This will be a new feature?

Then please fix the LED display who give us info in WinBox about modem-signal-treshold=-93 who in only CLI give info that WinBox give fake information, CLI:

Ci6fF9RgSS.png

rooted · Tue Feb 11, 2020 4:52 am

Shouldn't that be "threshold"?

raffav · Tue Feb 11, 2020 9:23 am

I had to netinstall my cap ac when I applied this version, lost completely access to it just user id and power led was on
After that caps and capsman don't act normally
I woke up today my 2g were down
I had to reboot twice one i got a msg telling that regulatory domain mismatch in cap (since when in capsman mode its care about setting in wireless interface?)
After changing to match
Interface did not come up as manager although the 5 g was showing managed by capsman was not working.. I had to reboot for 2 time

Sent from my Moto Z3 Play using Tapatalk

msatter · Tue Feb 11, 2020 12:25 pm

Any chance that dynamic DNS servers in IKEv2 can be deactivated? I have a long list to which not should be connected (NordVPN). Putting a ICMP reject (output) on it helps a bit but rather I have them ignored if the user wants that. Like as it possible in L2TP/IPSEC.

Update:

GRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR

Updated my inner router also from 6.46beta68 to this beta and the DNS completely stopped working. It refuses to use my local DNS Server and only wants to use the dynamic DNS Servers. I can only block that by putting in filter the following rule:

add action=reject chain=output comment="Rejecting request made by the router itself, if not to the local DNS server" dst-address=!192.168.88.2 dst-port=53 log-prefix="DNS unreach" protocol=udp reject-with=icmp-admin-prohibited src-address=192.168.88.1

I had to revert to the previous beta to be able to post here.

*) dns - use only servers received from IKEv2 server when present;

Is this the cause that using NordVPN is not working anymore in this Beta if using a local DNS?

msatter · Tue Feb 11, 2020 4:38 pm

It is no fun looking at and being forced to use that list of dynamic servers while not wanting to use them. I want to use my Pihole at 192.168.88.2

DNSdyn.JPG

eworm · Thu Feb 13, 2020 4:42 pm

*) dns - use only servers received from IKEv2 server when present;

IMHO that's a bad change. I have an open wifi network for guests, client traffic is routed via IKEv2 provider. I do not necessarily trust this provider - I just want to hide my public IP address for unknown clients.
Traffic from known clients and router itself goes via ISP, the same should be true for DNS traffic.

I understand the idea for that change, but sending all DNS traffic to a VPN provider without the data itself does not improve the privacy or security situation. More the contrary.

Any chance to have a setting for IKEv2 peer (or mode-config or whatever...) named "use-dns" with three valid values: yes, no and exclusively?

kmrue · Thu Feb 13, 2020 6:09 pm

The release notes on 6.47beta32 states
*) ups - improved compatibility with APC Smart UPS 1000 and 1500;

However I can not confirm on that one. There seems to be absolutely no change in behaviour compared to the previous beta.

Tab General:
all fine (to my understanding, those are internal anyhow and not UPS-protocol dependant=
Alarm Setting: does not have any effect even if set to immediate

Tab Model:
Model: Fine and complete
Version: no information
Serial Number: Fine
Manufacture Date: Fine
Nominal Battery Voltage: No Information

Tab Status:
Transfer Case: no information
Run Time Left: FINE
Offline After: FINE
Battery Charge: FINE
Battery voltage: no information
Line Voltage: no information
Output Voltage: no information
Load: no information
Temperature: no information
Frequency: no information

ON Line Checkbox: Fine
On Battery Checkbox: no information
All other Checkboxes: not tested

Tests performed on a SMART UPS 1000 FW UPS 09.4 / ID=18
and with a Smart-UPS 1500 FW:COM 02.1 / UPS.05.I

both with same readings. AFAIR this new beta version - which was supposed to be IMPROVED - does not make any change at all to the previous beta.

Furthermore: UPS only gets identified upon boot (so somehow the syncing of the UPS to the RB does not seem to be easy)

Once more my offer @mikrotik that I am willing to test even intermediate versions of the UPS-npk

msatter · Thu Feb 13, 2020 6:12 pm

I like to add to make to naming more clear like "Use Peer DNS" as it is used else where in ROS.

By exclusively do you mean that the dynamic DNS is resolving only for that link? Not going into the pool of Dynamic DNS servers under IP-DNS.

osc86 · Thu Feb 13, 2020 6:22 pm

Please give us the option, to not use any dynamic servers at all, no matter what the source is.
I don't want to use any kind of dynamic dns servers, for obvious reasons.
Who is using the dns servers the vpn/isp provides anyway..

msatter · Thu Feb 13, 2020 6:59 pm

Using the dnsservers from the VPN providers is wished for and so you avoid leaking DNS data.

However if you have your own server you want to 'leak' to your own server. This is for advanced users and the default setting should be, using the dynamic servers.

ingus16 · Sun Feb 16, 2020 6:06 pm

6.47 beta 32
dns - use only servers received from IKEv2 server when present;

With this "fix" no i am not able to use local pihole +dnscrypt server because ike ipsec receive their vpn dns servers and mikrotik use only ike dns servers even despite dstnat override rule

Xymox · Sun Feb 16, 2020 6:44 pm

*) bonding - improved slave interface MAC address handling;
*) bonding - prefer primary slave MAC address for bonding interface;

Hmmmmm... Im seeing a weird issue with 6.47

I have a LAG Bonded interface to my cable modem. 802.3ad . Yes the cable modem supports this. This works perfect on 6.46 It strangely fails on the beta. Im running DHCP-Client and NAT and using firewall rules that use rules based on a interface list item WAN which is the bonded interface.

Im not smart enough to troubleshoot what goes wrong, but, when I upgrade firmware on the CCR to 47 I loose connection to the outside world. I don't see where its getting lost either. Im not smart enough to follow a packet thru the router to isolate where it gets lost.

DHCP-Client is talking to the cable modem and does get a IP.

I can regain the connection by removing the bonded interface and putting it back.

Because there was a change to bonding behavior in 6.47 I thought I should report this weird issue I am seeing. Should I send a support email ?

I have 6.46.3 and the beta on partitions and can swap around easily. So I copy 6.46.3 and save config to a partition, activate that partition, upgrade firmware on it to 6.47x, and it 100% fails every time. Swap back to 6.46.3 works fine. Swap back to 6.47x and remove/readd bonding interface and it works..

I might also be seeing the issue come back over time even after I get it working. I am monitoring that.

This fixes the issue after upgrade:

/interface bonding remove Modem1;
/interface bonding add name=Modem1 mode=802.3ad slaves=ether7,ether8 transmit-hash-policy=layer-3-and-4;
/ip dhcp-client set 0 interface=Modem1;
/interface list member add interface=Modem1 list=WAN;

Rudolfs · Mon Feb 17, 2020 1:01 pm

What's new in 6.47beta32 (2020-Feb-10 11:45):

Why did you remove the "antenna gain" line in Winbox for wireless???? To fix the ETSI not imposing the minimum. ????

Well I knew ETSI regulatory domain forgot to check the minimal antenna gain. Countries did impose the minimal gain.

As setting TX power is difficult with the few left over options, the method explained in this forum several times is to increase the antenna gain, to reduce the transmit power.
"All rates fixed" is no good as the radio cannot follow for the higher MCS encodings. And "manual" and "card rates" is not allowed.
The only other oprion is not to set the country ("no_country_set") and go fully manual." What an improvement! Forget regulations, you are on your own now!"

Why did you remove the "antenna gain" line in Winbox ???? To fix the ETSI not imposing the minimum.? It was the only practical way to reduce the TX power, not to heat up the radio, and always be legal

Hello,
This line was removed from Winbox GUI only for wireless devices with built-in antennas, due to the fact that changing this setting did not affect the performance in any way. Please note that RouterOS CLI shows all of the available options (not only the ones that can be used on the router). For example, if you type band=<tab> on router with 2 GHz wireless, you will be able to see also 5 GHz bands.

bpwl · Mon Feb 17, 2020 3:50 pm

What's new in 6.47beta32 (2020-Feb-10 11:45):

Why did you remove the "antenna gain" line in Winbox for wireless???? To fix the ETSI not imposing the minimum. ????

Well I knew ETSI regulatory domain forgot to check the minimal antenna gain. Countries did impose the minimal gain.

As setting TX power is difficult with the few left over options, the method explained in this forum several times is to increase the antenna gain, to reduce the transmit power.
"All rates fixed" is no good as the radio cannot follow for the higher MCS encodings. And "manual" and "card rates" is not allowed.
The only other oprion is not to set the country ("no_country_set") and go fully manual." What an improvement! Forget regulations, you are on your own now!"

Why did you remove the "antenna gain" line in Winbox ???? To fix the ETSI not imposing the minimum.? It was the only practical way to reduce the TX power, not to heat up the radio, and always be legal
Hello,
This line was removed from Winbox GUI only for wireless devices with built-in antennas, due to the fact that changing this setting did not affect the performance in any way. Please note that RouterOS CLI shows all of the available options (not only the ones that can be used on the router). For example, if you type band=<tab> on router with 2 GHz wireless, you will be able to see also 5 GHz bands.

Can you please tell us then how to reduce the TX power, like all experts in Wifi give as advice, on those devices using the GUI. Most settings don't work at all or you will cut off things that you didn't want (e.g. all fixed). Changing the antenna gain was many times reported on this forum as the easiest , safest and the better method, to be some defined value below the legal and the device technical limits. I'm one of the persons that repeated this solution to others.
For other explicit methods you have to look up the data-sheets to know what the device limlits are.
Of course you can go to the CLI. You can always go to the CLI for non-trivial, special, expert and exceptional settings. And we are "blind" anyway , as the "current TX powers" is not filled in. Or should we use the CLI for that as well???

w32pamela · Mon Feb 17, 2020 5:17 pm

*) quickset - use "station-wds" mode when connecting to AP with RouterOS flag;

Thank you for eliminating the automatic change to wireless mode = "station-wds" when an AP is identified as a routerboard device.

r00t · Mon Feb 17, 2020 5:49 pm

Setting frequency mode to regulatory-domain should not prevent you from changing TX power down (using tx power mode card rates and tx power value), regulatory domain setting should only limit maximum tx power. This is on AR92xx radio, so others may vary...

WeWiNet · Mon Feb 17, 2020 7:13 pm

Of course you can go to the CLI. You can always go to the CLI for non-trivial, special, expert and exceptional settings. And we are "blind" anyway , as the "current TX powers" is not filled in. Or should we use the CLI for that as well???

Use this command to see actual TX Power of YOUR_WIFI_IF (i also can't understand why this is not in Winbox shown!!!):

/interface wireless info allowed-channels YOUR_WIFI_IF

channels: 5500/20-Ceee/ac/DP(23dBm),5505/20-Ceee/ac/DP(23dBm),5510/20-Ceee/ac/DP(23dBm),
5515/20-Ceee/ac/DP(23dBm),5520/20-Ceee/ac/DP(23dBm),5525/20-Ceee/ac/DP(23dBm),
5530/20-Ceee/ac/DP(23dBm),5535/20-Ceee/ac/DP(23dBm),5540/20-Ceee/ac/DP(23dBm),
5545/20-Ceee/ac/DP(23dBm),5550/20-Ceee/ac/DP(23dBm),5555/20-Ceee/ac/DP(23dBm),
5560/20-Ceee/ac/DP(23dBm),5565/20-Ceee/ac/DP(23dBm),5570/20-Ceee/ac/DP(23dBm),
5575/20-Ceee/ac/DP(23dBm),5580/20-Ceee/ac/DP(23dBm),5585/20-Ceee/ac/DP(23dBm),
5590/20-Ceee/ac/DP(23dBm),5595/20-Ceee/ac/DP(23dBm),5600/20-Ceee/ac/DP(23dBm),
5605/20-Ceee/ac/DP(23dBm),5610/20-Ceee/ac/DP(23dBm),5615/20-Ceee/ac/DP(23dBm),
5620/20-Ceee/ac/DP(23dBm),5625/20-Ceee/ac/DP(23dBm),5630/20-Ceee/ac/DP(23dBm),
5635/20-Ceee/ac/DP(23dBm),5640/20-Ceee/ac/DP(23dBm)

bpwl · Mon Feb 17, 2020 9:32 pm

Yep. Confusing for me .... having the information what RouterOS actually is setting would help. (I understand this "ac" chip cannot be queried)
Just checked wAP ac with 6.46.3 (downgraded from 6.47 beta)

GAIN=3 / regulatory-domain= ETSI

[admin@MktwAPac] /interface wireless info> allowed-channels
interface: wlan2
channels: 5500/20-Ce/ac/DP(24dBm),5505/20-Ce/ac/DP(24dBm),5510/20-Ce/ac/DP(24dBm),5515/20-Ce/ac/DP(24dBm),5520/20-Ce/ac/DP(24dBm),5525/20-Ce/ac/DP(24dBm),
... ...
5650/20-Ce/ac/DP(24dBm),5655/20-Ce/ac/DP(24dBm),5660/20-Ce/ac/DP(24dBm),5665/20-Ce/ac/DP(24dBm),5670/20-Ce/ac/DP(24dBm),5675/20-Ce/ac/DP(24dBm),
5680/20-Ce/ac/DP(24dBm)

Does it match ? There are 3 radios but "ac" shows total power. Seems OK.

[admin@MktwAPac] /interface wireless info> country-info etsi
ranges: 2402-2482/b,g,gn20,gn40(20dBm)
5170-5250/a,an20,an40,ac20,ac40,ac80,ac160,ac80+80(23dBm)/passive,indoor
5170-5330/a,an20,an40,ac20,ac40,ac80,ac160,ac80+80(20dBm)/dfs,passive,indoor
5250-5330/a,an20,an40,ac20,ac40,ac80,ac160,ac80+80(20dBm)/dfs,passive,indoor
5490-5710/a,an20,an40,ac20,ac40,ac80,ac160,ac80+80(27dBm)/dfs,passive
5190-5310/a-turbo(20dBm)/dfs
5180-5300/a-turbo(20dBm)/dfs
5520-5680/a-turbo(27dBm)/dfs,passive
5510-5670/a-turbo(27dBm)/dfs,passive
902-927/b,g,g-turbo,gn20,gn40(30dBm)

[admin@MktwAPac] /interface wireless info> hw-info
interface: wlan2
ranges: 4920-6100/5/a,an20,an40,ac20,ac40,ac80
tx-chains: 0,1,2
rx-chains: 0,1,2
extra-info: pciinfo:0x0, cid:0, gain:2

Now with TX power set on "all rates fixed" 10 dBm. No change in this list however. Did ROS set it, or did it ignore the user setting ?

[admin@MktwAPac] /interface wireless info> allowed-channels
interface: wlan2
channels: 5500/20-Ce/ac/DP(24dBm),5505/20-Ce/ac/DP(24dBm),5510/20-Ce/ac/DP(24dBm),5515/20-Ce/ac/DP(24dBm),5520/20-Ce/ac/DP(24dBm),5525/20-Ce/ac/DP(24dBm),
... ...
5650/20-Ce/ac/DP(24dBm),5655/20-Ce/ac/DP(24dBm),5660/20-Ce/ac/DP(24dBm),5665/20-Ce/ac/DP(24dBm),5670/20-Ce/ac/DP(24dBm),5675/20-Ce/ac/DP(24dBm),
5680/20-Ce/ac/DP(24dBm)

Changing GAIN to 2 dBi , gives updated values for the channels. (even when "all rates fixed" is still at 10 dBm)

[admin@MktwAPac] /interface wireless info> allowed-channels
interface: wlan2
channels: 5500/20-Ce/ac/DP(25dBm),5505/20-Ce/ac/DP(25dBm),5510/20-Ce/ac/DP(25dBm),5515/20-Ce/ac/DP(25dBm),5520/20-Ce/ac/DP(25dBm),5525/20-Ce/ac/DP(25dBm),
... ...
5650/20-Ce/ac/DP(25dBm),5655/20-Ce/ac/DP(25dBm),5660/20-Ce/ac/DP(25dBm),5665/20-Ce/ac/DP(25dBm),5670/20-Ce/ac/DP(25dBm),5675/20-Ce/ac/DP(25dBm),
5680/20-Ce/ac/DP(25dBm)

And then you have that other dimension: the encoding power limits of the device

5 GHz Transmit (dBm) Receive Sensitivity
6MBit/s 25 -96
54MBit/s 25 -81
MCS0 25 -96
MCS7 24 -77
MCS9 23 -72

So it seems to be a double limit set: channel power (by regulation) and rate power of the card, or a fixed value override of the rate power.
How are they applied? Just 2 separate checks?
Antenna gain is that only for the channel power, or also for the rate power ?

emils · Tue Feb 18, 2020 10:39 am

Version 6.47beta35 has been released.

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.47beta35 (2020-Feb-17 13:56):

Important note!!!

- The Dude server must be updated to monitor v6.47beta30+ RouterOS type devices.
- The Dude client must be manually upgraded after upgrading The Dude server.
- Make sure LTE APN Profile name does not match any of the DHCP server's names if LTE passthrough is used.

MAJOR CHANGES IN v6.47:
----------------------
!) socks - added support for SOCKS5 (RFC 1928);
----------------------

Changes in this release:

!) socks - added support for SOCKS5 (RFC 1928);
*) chr - fixed graceful shutdown execution on Hyper-V (introduced in v6.46);
*) crs3xx - fixed frame forwarding after disabling/enabling bridge hardware offloading for CRS354-48G-4S+2Q+ device;
*) crs3xx - improved SFP+ DAC cable initialization for CRS326-24S+2Q+ device;
*) dns - added support for exclusive dynamic DNS server usage from IPsec;
*) health - fixed maximum SFP temperature reading under '/system health' menu;
*) ipsec - added "use-responder-dns" parameter support (CLI only);
*) ssh - added support for RSA keys with SHA256 hash (RFC8332);
*) supout - improved PoE-out information reporting;
*) system - improved system stability when receiving/sending TCP traffic on multicore devices;
*) traffic-flow - added "postDestinationMacAddress" parameter support for IPFIX and Netflow v9;
*) webfig - updated icon design;
*) winbox - updated icon design;
*) wireless - allow using "russia4" regulatory domain on RU locked devices;

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.

eworm · Tue Feb 18, 2020 10:41 am

*) ssh - added support for RSA keys with SHA256 hash (RFC8332);

Ha, that was fast. Thanks!
Will give it a try now.

eworm · Tue Feb 18, 2020 10:52 am

*) ssh - added support for RSA keys with SHA256 hash (RFC8332);
Ha, that was fast. Thanks!
Will give it a try now.

Looks like this breaks public key authentication. If I remove ssh-rsa from host key algorithms I am prompted for a password.
Password login succeeds (if always-allow-password-login is enabled).

eworm · Tue Feb 18, 2020 10:56 am

*) dns - added support for exclusive dynamic DNS server usage from IPsec;

This is configurable now? Where to find this setting?

eworm · Tue Feb 18, 2020 11:04 am

*) dns - added support for exclusive dynamic DNS server usage from IPsec;
This is configurable now? Where to find this setting?

Found it!

/ ip ipsec mode-config set use-responder-dns=no [ find ... ]

This setting takes exclusively, no and yes.

Thanks a lot!

msatter · Tue Feb 18, 2020 11:28 am

*) ipsec - added "use-responder-dns" parameter support (CLI only);

Thanks for implementing this and it was a looooooong wait before it became reality.

Update: I used the example given by eworm and removed the "..." do all configs in one go. The default setting is "exclusively".

/ ip ipsec mode-config set use-responder-dns=no [ find ]

I have to get used to the new icons used and it is a improvement in my eyes.

Maybe make the blue of jump, fasttrack a bit brighter. Mark routing is green and mark connection is blue and I rather see that the green is changed to not green. Green and red have a signal function. For drop and accept that is fine using red and green.

alibloke · Tue Feb 18, 2020 1:40 pm

*) webfig - updated icon design;
*) winbox - updated icon design;

The old icons probably did need a refresh, but the new extra bland icons are....bland:

rooted · Tue Feb 18, 2020 2:07 pm

With 6.47beta35 on the hAP ac² I can no longer login using the MikroTik Android application, it force closes. I tried on two different phones with the same result, tried clearing data on the app and it still force closes.

msatter · Tue Feb 18, 2020 2:40 pm

Confirmed theat the Android client is reverting to it's login screen. Clear cache did not change that.

jlp16400 · Tue Feb 18, 2020 3:15 pm

Hi,

Yes, With 6.47beta35 on the RB3011 uias, I can no longer login using the MikroTik Android application...

Chupaka · Tue Feb 18, 2020 3:43 pm

can no longer login using the MikroTik Android application...

I bet the reason is connected with "The Dude server must be updated to monitor v6.47beta30+ RouterOS type devices."

nkourtzis · Tue Feb 18, 2020 5:00 pm

*) system - improved system stability when receiving/sending TCP traffic on multicore devices;

Can you please explain this a bit? Any example use cases? Does it also affect the forwarding CPU spikes and lost packets on ARM when The Dude is running?

r00t · Tue Feb 18, 2020 5:29 pm

Not a fan of a new icons style. Reducing amount of colors and making them all blueish and more flat is IMHO step in a wrong direction.
Now 15 icons out of 26 are looking very similar at a first glance. It would be better to have more accented colors so icons are more unique on a first glance...
Icons should help you identify menu item quickly and uniquely without having to read the text next to it, it's not just some GUI "decoration" without purpose...

zapata · Tue Feb 18, 2020 8:15 pm

Damn, I should have checked the forum before installing 6.47beta35. I can no longer login via ssh (key/password).

The device is HAP AC2.

eworm · Tue Feb 18, 2020 8:52 pm

Damn, I should have checked the forum before installing 6.47beta35. I can no longer login via ssh (key/password). I cannot test winbox because it is disabled. But I assume it would fail too. The device is HAP AC2.

What SSH client do you use? Try to disable host key algorithm rsa-sha2-256 for now.

For OpenSSH something like:

ssh -oHostKeyAlgorithms=-rsa-sha2-256 admin@mikrotik

zapata · Tue Feb 18, 2020 9:16 pm

Yes, I use OpenSSH (8.2p1) and "ssh -oHostKeyAlgorithms=ssh-rsa" works. Thanks a lot, eworm!

sola969 · Wed Feb 19, 2020 12:19 am

The new icon is really ugly.

sola969 · Wed Feb 19, 2020 12:23 am

winbox 3.21 scale and fonts are also ugly.

icsterm · Wed Feb 19, 2020 12:58 pm

Latest TIK app indeed doesn't work with the latest ROS beta, constantly crashes after 'downloading plugins'. Using a hAP ac2.

Also, we need the old way of displaying fonts, on smallest zoom on a 1080p monitor with 100% DPI scapping there is a lot of wasted space in the rows. We need a flag to enable the old display method.

Wed Feb 19, 2020 1:05 pm

Yes, there is a known issue with latest MikroTik smartphone app on Android. We are working on it.
iOS works fine.

Neovr · Thu Feb 20, 2020 8:54 pm

-w60g - improved stability after multiple disconnections;
no... no stability ...
i tested on 3 links ... many disconnects every day ...
randomly, after disconect trafic not bridged ...

msatter · Mon Feb 24, 2020 9:19 pm

Yes, there is a known issue with latest MikroTik smartphone app on Android. We are working on it.
iOS works fine.

With the new 1.3.11 version in the store, the issue is resolved. Thanks fixing the Android version so it works again with 6.47 Beta.

Znevna · Tue Feb 25, 2020 2:04 pm

I don't know when this was introduced but, I now have to issue ":ip ipsec installed-sa flush" after my WAN (PPPoE) goes down and back up.
If I don't IPv4 routing is broken for some reason, no packets go over WAN (packets that don't match any policies).
I only have local subnets in policies, so that can't be the reason.
Easy to reproduce: setup an ike2 client, leave a ping to 8.8.8.8 open (or anything that doesn't match the policies installed) , reconnect pppoe-client and see how 8.8.8.8 sits in timeout until you issue a flush to installed-sa.

rooted · Tue Feb 25, 2020 6:56 pm

With the new 1.3.11 version in the store, the issue is resolved. Thanks fixing the Android version so it works again with 6.47 Beta.

Actually it introduced more issues (on Android 9 anyway), when you try to change certain drop down options they won't pop-up when in portrait and won't show up in landscape.

@normis Could you have a look at this?

osc86 · Tue Feb 25, 2020 7:38 pm

yeah.. if everyone could stop posting images that are way to big, that'd be great.

I didn't complain about the post itself, but why do all the images have to be in 1000x1000+ px?

rooted · Tue Feb 25, 2020 7:47 pm

Removed

bpwl · Thu Feb 27, 2020 12:40 pm

One reason why the "antenna gain" should be left in the wireless advanced setting in the GUI, for devices with built in antennas. It is a better way to manage the TX power.

See from minute 36 till 41; https://www.youtube.com/watch?v=pmtB3LlwquA (MUM EU 2015 What you see is not always what you get)

And while this post handles GUI fields, the "Bridge mode" is missing for "virtual wireless" interfaces. So the bridge can be turned off in the GUI for wireless 'AP bridge' , but not for the subsequent SSID's in de virtual WLAN's. Oh yes, for those you could use the CLI also.

rpingar · Thu Feb 27, 2020 4:04 pm

on latest beta 6.47.beta35 there is an issue on CCR when there is more then one IP on an bonding interface, it is not able to get the arp for both ips from the other side of the ethernet interface

valnuke · Fri Feb 28, 2020 10:46 pm

Hi,

can you bring back the old icons please?

I don't want to offend any designer, but the new ones are bad...
at least add an option to upload some old_icon_set file!

look at the difference yourself, is this an improvement?
especially the addresses and routes icons (on the right) are terrible!

MDE · Sat Feb 29, 2020 9:08 am

Hi,

can you bring back the old icons please?

I don't want to offend any designer, but the new ones are bad...
at least add an option to update some old_icon_set file!

look at the difference yourself, is this an improvement?
especially the addresses and routes icons (on the right) are terrible!

Agreed. New icon set is horrendous

Sent from my VTR-L29 using Tapatalk

SiB · Sun Mar 01, 2020 3:32 am

Agreed. New icon set is horrendous

Those new are just UGLY, one color type.

irghost · Sun Mar 01, 2020 3:07 pm

Radius authentication for Socks5
and something like Parent proxy Option

Paternot · Sun Mar 01, 2020 4:10 pm

Agreed. New icon set is horrendous
Those new are just UGLY, one color type.

Yes! Bring our colors back! It is much easier to find something on a glance when it is different from its neighbors...

theprojectgroup · Sun Mar 01, 2020 7:03 pm

*) ssh - added support for RSA keys with SHA256 hash (RFC8332);
Ha, that was fast. Thanks!
Will give it a try now.
Looks like this breaks public key authentication. If I remove ssh-rsa from host key algorithms I am prompted for a password.
Password login succeeds (if always-allow-password-login is enabled).

Same here, can't use Royal TSX Secure Gateway with ssh keys anymore:

Screenshot 2020-03-01 at 18.02.51.png

eworm · Sun Mar 01, 2020 8:43 pm

Same here, can't use Royal TSX Secure Gateway with ssh keys anymore:

This is fixed with 6.46.4 stable, so I guess it will be ok with next beta.

theprojectgroup · Sun Mar 01, 2020 10:02 pm

Same here, can't use Royal TSX Secure Gateway with ssh keys anymore:
This is fixed with 6.46.4 stable, so I guess it will be ok with next beta.

I am on 6.46.4 stable. I came from 6.46.1. now i have the issue. I am on confused.

eworm · Sun Mar 01, 2020 11:15 pm

Same here, can't use Royal TSX Secure Gateway with ssh keys anymore:
This is fixed with 6.46.4 stable, so I guess it will be ok with next beta.
I am on 6.46.4 stable. I came from 6.46.1. now i have the issue. I am on confused.

With openssh and RouterOS 6.46.4 everything works fine, even if I disable host key algorithm ssh-rsa, which forces rsa-sha2-256.
Possibly your issue is related, but not the same.

You should report in correct thread (for 6.46.4) or contact Mikrotik directly.

Cha0s · Mon Mar 02, 2020 9:18 pm

Agreed. New icon set is horrendous
Those new are just UGLY, one color type.
Yes! Bring our colors back! It is much easier to find something on a glance when it is different from its neighbors...

+1

guipoletto · Wed Mar 11, 2020 8:24 pm

The colors are important, for at-a-glance finding things.
But also, the depth provided by the old shading/3d effect. The plain colors are horrible.

kmrue · Sat Mar 14, 2020 11:57 am

Sorry for bothering: Are there any plans to get the UPS-connection via USB-port working properly with APC devices? The current (part-)implementation is not of much help.

wuffzack · Fri Mar 20, 2020 3:51 am

I tested 6.47beta35 on my CRS354-48G-4S+2Q+RM switch.

I noticed, that the CPU temperature went much higher than before (>85 degrees Celsius).
CPU load was shown low in Winbox (< 10%)

I downgraded to 6.46.4 stable, and the CPU stayed hot.

After a power cycle, the CPU temperature dropped to normal levels (70 degrees Celsius).

This seems to be a weird bug with this device.

emils · Fri Mar 20, 2020 11:57 am

Version 6.47beta49 has been released.

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.47beta49 (2020-Mar-20 07:08):

Important note!!!

- The Dude server must be updated to monitor v6.46.4 and v6.47beta30+ RouterOS type devices.
- The Dude client must be manually upgraded after upgrading The Dude server.
- Make sure LTE APN Profile name does not match any of the DHCP server's names if LTE passthrough is used.
- The Dude requires "winbox" policy instead of "dude" to monitor v6.46.4 and v6.47beta30+ RouterOS type devices.

MAJOR CHANGES IN v6.47:
----------------------
!) dns - added client side support for DNS over HTTPS (DoH) (RFC8484);
!) socks - added support for SOCKS5 (RFC 1928);
!) socks - added support for SOCKS5 (RFC 1928);
!) user - enable "winbox" policy for groups with "dude" policy;
----------------------

Changes in this release:

!) dns - added client side support for DNS over HTTPS (DoH) (RFC8484);
!) socks - added support for SOCKS5 (RFC 1928);
!) user - enable "winbox" policy for groups with "dude" policy;
*) branding - fixed identity setting from branding package;
*) branding - properly use HTML files for Hotspot (introduced in v6.47beta);
*) bridge - added warning message when port is dynamically added to entry with VLAN range (CLI only);
*) bridge - correctly remove disabled MSTI;
*) bridge - improved hardware offloading enabling/disabling;
*) capsman - fixed "certificate" parameter updating on CAP;
*) certificate - disabled CRL usage by default;
*) certificate - do not use SSL for first CRL update;
*) chr - added support for file system quiescing;
*) crs3xx - do not change bridge host ID's when updating host table (introduced in v6.47beta32);
*) crs3xx - fixed interface statistics for CRS354-48G-4S+2Q+ and CRS354-48P-4S+2Q+ devices;
*) crs3xx - fixed traffic forwarding after disabling/enabling bridge hardware offloading for CRS354-48G-4S+2Q+ and CRS354-48P-4S+2Q+ devices;
*) dhcpv4 - added end option (255) validation for both server and client;
*) dhcpv4-client - improved stability when changing client while still receiving advertisements;
*) dhcpv6-server - fixed MAC address retrieving from DUID when timestamp is present;
*) dude - fixed connection to other RouterOS type devices through The Dude agents (introduced in v6.46.4);
*) filesystem - fixed NAND memory going into read-only mode or becoming unstable over time;
*) hotspot - updated splash page design ('/ip hotspot reset-html' required);
*) ike1 - added error message when specifying "my-id" for XAuth Identity;
*) ike1 - improved stability when performing policy lookup on non-existant peer;
*) ipsec - control CRL validation with global "use-crl" setting;
*) ipsec - do full certificate validation for identities with explicit certificate;
*) lcd - fixed LCD service becoming unavailable on devices without LCD screen;
*) led - added "dark-mode" functionality for CRS105-5S-FB;
*) led - fixed minor typo in LED warning message;
*) lora - added IPv6 support for LoRa packet forwarder;
*) lora - added value limits for "freq-off" parameter;
*) lora - properly update source address for packets when routing table is changed;
*) lte - added support for NEOWAY N720;
*) lte - fixed "allow-roaming" setting when using LTE network mode on R11e-LTE;
*) lte - made "mac-address" parameter read-only;
*) ppp - added support for ZTE MF90;
*) ppp - fixed minor typo when running "info" command;
*) proxy - increased minimal free RAM that can not be used for proxy services;
*) quickset - do not show "SINR" field in Quick Set when there is no data;
*) quickset - removed "EARFCN" field from Quick Set;
*) route - improved system stability after reboot with large amount of VLAN interfaces with PPPoE servers attached;
*) sniffer - fixed minor typo in "host" menu;
*) snmp - changed "upsEstimatedMinutesRemaining" reported value from seconds to minutes;
*) ssh - fixed SHA256 user authentication algorithm checking (introduced in v6.46.4);
*) supout - added "gps" section to supout files;
*) switch - made "auto" the default value for "vlan-id" parameter when creating a new static host entry;
*) system - improved driver loading speed on startup;
*) system - improved system stability when forwarding traffic from switch chip to CPU (introduced in v6.43);
*) traffic-generator - improved statistics reporting;
*) w60g - fixed link status logging;
*) w60g - improved rate selection in low traffic conditions;
*) winbox - added "Options" parameter support for DHCPv6 client and server;
*) winbox - added "Rate" parameter for switch ACL rules;
*) winbox - added 160Mhz extension channel support for CAPsMAN;
*) winbox - added comment support for "Switch->VLAN" menu;
*) winbox - added support for "Tools->WoL" menu;
*) winbox - aligned all "IP->Traffic Flow->IPFIX" check boxes in single line (WinBox v3.22 required);
*) winbox - allow setting "20/40/80/160Mhz-eeeeeeCe" channel under "Channel Width" parameter;
*) winbox - allow setting "Primary" parameter for "balance-tlb" bonding interfaces;
*) winbox - do not show "Revision" parameter under "System/RouterBOARD" menu on devices that have only one revision;
*) winbox - fixed "ARP" parameter inheritance from "CAPs Configuration" configuration;
*) winbox - fixed "BGP Origin" value display under "IPv6->Routes" menu;
*) winbox - fixed "Bands" parameter display for LTE interfaces;
*) winbox - fixed "DSCP" parameter value setting;
*) winbox - fixed "Data Rate" checkbox alignment (WinBox v3.22 required);
*) winbox - fixed "Frequency" and "Secondary Frequency" parameter inheritance from "CAPs Channel" configuration;
*) winbox - fixed "Passthr. MAC Address" parameter display "LTE APNs" menu;
*) winbox - fixed "Switch" menu on CRS354-48P-4S+2Q+;
*) winbox - fixed "dst-port" unsetting in "IP->Hotspot->Walled Garden" menu;
*) winbox - fixed automatic "IPv6->Firewall->Address List" table update;
*) winbox - fixed bonding type interface support for "Switch->Host" table;
*) winbox - made "none" the default value for "Security Profile" parameter when creating a new "Wirelees->Connect list" entry;
*) winbox - made "yes" the default value for "Inject Summary LSAs" parameter when creating a new NSSA or STUB area;
*) winbox - properly show "Hw. Offload Group" value for each interface under "Bridge->Ports" menu;
*) winbox - renamed "Memory used" to "HDD used" for HDD type under "Tools->Graphing->Resource Graphs";
*) winbox - renamed "Routerboard" to "RouterBOARD" under "System/RouterBOARD" menu;
*) winbox - show "Hardware Offload" parameter for bonding interfaces;
*) winbox - show "System/RouterBOARD/Mode Button" on devices that have such feature;
*) winbox - updated icon design;
*) wireless - added "U-NII-2" support for hAP ac2 and RBwAPGR series devices;
*) wireless - enabled unicast flood for DHCP traffic on ARM architecture access points;
*) wireless - fixed default "antenna-gain" setting on SXT 2 and LtAP series devices;
*) wireless - updated "indonesia4" regulatory domain information;

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.

ErfanDL · Fri Mar 20, 2020 12:31 pm

WoW big changes thanks.

anthonws · Fri Mar 20, 2020 12:36 pm

DoH?!?!?! AMAZING! Thank you so much for listening to your community!

msatter · Fri Mar 20, 2020 12:40 pm

DoH is a nightmare and I don't understand why it is supported by Mikrotik.

ErfanDL · Fri Mar 20, 2020 12:51 pm

DoH is a nightmare and I don't understand why it is supported by Mikrotik.

Why ?

Chupaka · Fri Mar 20, 2020 12:58 pm

Wow, now we have two socks

ErfanDL · Fri Mar 20, 2020 1:03 pm

OK the DOH is not working with my DNS DOH server !

Capture.PNG

emils · Fri Mar 20, 2020 1:20 pm

Try setting https://10.5.51.5 as the server.

SiB · Fri Mar 20, 2020 1:21 pm

SXTR brick after upgrade, first reboot. No RoMON. No L2 Neighbors discovery. No MAC ping. I wait to 5 minutes.
Cold boot - power off and power on.

PS. Please set the notification like before, at all bottom site of window:

System > Reboot and...

SXTR brick after upgrade, first reboot. No RoMON. No L2 Neighbors discovery. No MAC ping. I wait to 5 minutes.
Cold boot - power off and power on.

Package lte is now: option with old fw. version. LTE r11e-lte6 works.

Tools > WoL :)

This should be additional RM entry in DHCP Leases (Send WoL)

as-value in lte at-chat !!! Awesome, it's help with write scripts, perfect

ErfanDL · Fri Mar 20, 2020 1:32 pm

Try setting https://10.5.51.5 as the server.

thanks for reply now it's verified but could not resolve any dns name

msatter · Fri Mar 20, 2020 2:20 pm

DoH is a nightmare and I don't understand why it is supported by Mikrotik.
Why ?

DoH is weapon and not a tool. You should use that in countries that are not respecting freedoms or if ISP that manipulate DNS resolves.

I see that it not well implemented because a IP address can be used instead of only domainnames. DoH is more complicated, to be implemented swiftly in a free afternoon.

The normal DNS needs to prime the DoH so implementation needs two fields to be truhly safe.
Manually provide the IPaddress of the DoH server and the domain.tld of yhe DoH server server to vetify and use TLS.

Really!?!?

msatter · Fri Mar 20, 2020 2:21 pm

Try setting https://10.5.51.5 as the server.

You can ingnore verify but then how do you know you are talking to the correct DNS server? DoH need TLS and so a verify.

Now Mikrotik can do DoH what about DoT which is a real advancement.

msatter · Fri Mar 20, 2020 2:22 pm

Try setting https://10.5.51.5 as the server.
thanks for reply now it's verified but could not resolve any dns name

How can it verify only by a IP address?

Rader · Fri Mar 20, 2020 2:44 pm

!) dns - added client side support for DNS over HTTPS (DoH) (RFC8484);

OMG! I don't belive it! )

eworm · Fri Mar 20, 2020 2:55 pm

Try setting https://10.5.51.5 as the server.
thanks for reply now it's verified but could not resolve any dns name
How can it verify only by a IP address?

Certificates can have subject alternative name with ip address.

emils · Fri Mar 20, 2020 3:09 pm

Enable DNS logs, it should provide all necessary information for troubleshooting. I tested the DoH implementation with various publicly available servers and could not find any issues. If there are any, please let us know.

/system logging add topics=dns

ErfanDL · Fri Mar 20, 2020 3:32 pm

Enable DNS logs, it should provide all necessary information for troubleshooting. I tested the DoH implementation with various publicly available servers and could not find any issues. If there are any, please let us know.
Code: Select all
/system logging add topics=dns

tested with public DoH server but nothing

doh.PNG

CoUL · Fri Mar 20, 2020 3:42 pm

Thank you guys so much for fixing Dude. It can be seen that there was a lot of work. But for 2 years now there has been a problem (viewtopic.php?t=153562) with updating the AP, which does not have the main package of systems but several separate packages including wireless. When updating such devices, the dude writes that some packages are not available. Please pray fix it!

eworm · Fri Mar 20, 2020 3:50 pm

Enable DNS logs, it should provide all necessary information for troubleshooting. I tested the DoH implementation with various publicly available servers and could not find any issues. If there are any, please let us know.
Code: Select all
/system logging add topics=dns
tested with public DoH server but nothing

doh.PNG

Possibly the system does not know the name for "dns.nextdns.io"? Chicken and Egg problem...

Fri Mar 20, 2020 3:51 pm

@ErfanDL, it looks like you still need a "conventional" DNS server for bootstrapping...

eworm · Fri Mar 20, 2020 3:54 pm

You could try "https://1.1.1.1/dns-query" - Cloudflare managed to get the the ip address into the certificate.

emils · Fri Mar 20, 2020 3:54 pm

As others are saying. The router does not know what dns.nextdns.io is. Add at least a single regular DNS server which will be used for DoH servers name resolving. Adding a static DNS entry should also suffice.

eworm · Fri Mar 20, 2020 3:56 pm

You could try "https://1.1.1.1/dns-query" - Cloudflare managed to get the the ip address into the certificate.

Same for quad-nine:

https://9.9.9.9/dns-query (secured)
https://9.9.9.10/dns-query (unsecured)

emils · Fri Mar 20, 2020 3:59 pm

And before anyone asks, for "Verify DoH Certificate" to work you obviously have to import the root certificate in the Certificate store of your router.

eworm · Fri Mar 20, 2020 3:59 pm

As others are saying. The router does not know what dns.nextdns.io is. Add at least a single regular DNS server which will be used for DoH servers name resolving. Adding a static DNS entry should also suffice.

Are DoH servers prioritized? When does it fall back to regular dns servers?

Oh, and is it possible to specify more than one DoH server for redundancy?

mfr476 · Fri Mar 20, 2020 4:00 pm

When will we have wave 2 and spectral scan?

ErfanDL · Fri Mar 20, 2020 4:07 pm

You could try "https://1.1.1.1/dns-query" - Cloudflare managed to get the the ip address into the certificate.

yeah it's worked without Verify DoH Certificate

and where can we get cloudflare certificate file to importing in router ?

eworm · Fri Mar 20, 2020 4:10 pm

You could try "https://1.1.1.1/dns-query" - Cloudflare managed to get the the ip address into the certificate.
yeah it's worked without Verify DoH Certificate

and where can we get cloudflare certificate file to importing in router ?

If you trust my repository get it here: https://git.eworm.de/cgit/routeros-scri ... r%20CA.pem

Otherwise search for "DigiCert ECC Secure Server CA".

ErfanDL · Fri Mar 20, 2020 4:23 pm

You could try "https://1.1.1.1/dns-query" - Cloudflare managed to get the the ip address into the certificate.
yeah it's worked without Verify DoH Certificate

and where can we get cloudflare certificate file to importing in router ?
If you trust my repository get it here: https://git.eworm.de/cgit/routeros-scri ... r%20CA.pem

Otherwise search for "DigiCert ECC Secure Server CA".

thanks. I download it from your link

Sob · Fri Mar 20, 2020 5:21 pm

You can save certificates from web browser. Open https url, view used certificates, select the root one, export it, copy file to router, import it, ... and tadaaa, success! And it's safe, because browser already verified it, you're not downloading it from any possibly untrusted third party (I swear it's nothing against helpful worms

).

irghost · Fri Mar 20, 2020 5:45 pm

parent proxy? For socks5
please

Sob · Fri Mar 20, 2020 6:19 pm

parent proxy? For socks5

I think you should open dedicated thread about possible SOCKS improvements. I can think about some myself, but this thread is not the right place for it.

volkirik · Fri Mar 20, 2020 7:21 pm

Works fine for 5 minutes and then Makes router unstable by %40-50 CPU usage (ssl process). And also I get lots of errors with or without "Verify certificate";

doh.png

I imported cloudflare's root CA successfully, and started to get other type of errors as follows;

doh2.png

Florian · Fri Mar 20, 2020 8:50 pm

As others are saying. The router does not know what dns.nextdns.io is. Add at least a single regular DNS server which will be used for DoH servers name resolving. Adding a static DNS entry should also suffice.
Are DoH servers prioritized? When does it fall back to regular dns servers?

Oh, and is it possible to specify more than one DoH server for redundancy?

Would be nice.

But kudos for supporting DoH, very big step

Florian · Fri Mar 20, 2020 8:52 pm

Seems there are some errors with DoH, I've this sometime in the logs : DoH max queue size reached, dropping query

eworm · Fri Mar 20, 2020 9:59 pm

My test device was set up to use crl, but to not download crl:

/ certificate settings crl-download=no crl-use=yes

That results in flooding the log:

dns,error DoH connection error: SSL: handshake failed: unable to get certificate CRL (6)

aboiles · Fri Mar 20, 2020 10:26 pm

For CloudFlare DoH.
If exporting from chrome, export Cryptographic Message Syntax (p7b) and make sure to check the Include all certificates in the certification path.
When you import the cert int RouterOS you should have 3 entries.
DigiCert Global Root CA
DigiCert ECC Secure Server CA
cloudflare-dns.com

Would be nice if we could specify ipv6 address
Major KUDOS for getting this implemented.

Chupaka · Fri Mar 20, 2020 10:29 pm

Would be nice if we could specify ipv6 address

What's the problem?

aboiles · Fri Mar 20, 2020 10:37 pm

Changing to a ipv6 address breaks the DoH.
https://[2606:4700:4700::1111]/dns-query
Mar/20/2020 13:33:33 dns,error DoH connection error: resolving error
Mar/20/2020 13:33:35 dns,error DoH connection error: resolving error
Mar/20/2020 13:33:37 dns,error DoH connection error: resolving error

eworm · Fri Mar 20, 2020 10:42 pm

When you import the cert int RouterOS you should have 3 entries.
DigiCert Global Root CA
DigiCert ECC Secure Server CA
cloudflare-dns.com

Last one is server certificate and not required in certificate store.

aboiles · Fri Mar 20, 2020 10:45 pm

Without the last one I was getting intermittent errors, with it I don't

Sob · Fri Mar 20, 2020 10:50 pm

It's enough to have "DigiCert Global Root CA", server sends both own and intermediate certificate.

And IPv6 doesn't seem to be there at all. Numeric address doesn't work. And it didn't help either, when I tried to fool it with:

/ip dns static
add address=2606:4700:4700::1111 name=one.one.one.one
/ip dns ... use-doh-server=https://one.one.one.one/dns-query verify-doh-cert=yes

According to log it tries to resolve only A record.

Edit: Although my attempt with one.one.one.one would fail anyway, because even though the hostname resolves to 1.1.1.1, DoH doesn't seem to be there.

DenisPDA · Fri Mar 20, 2020 11:24 pm

Work https://cloudflare-dns.com/dns-query

DoH_MT.JPG

DoH_MT_check.JPG

chrome_doh.JPG

Cert CA

Check_Cloud.JPG

Check_Doh.JPG

check_dns2.JPG

Everything works
Mikrotik Thank you so much

minks · Sat Mar 21, 2020 9:00 am

@ALL
Only 2 cert are needed
1s for Google
2nd for CloudFlare

/ip dns
set use-doh-server=https://dns.google/dns-query verify-doh-cert=yes
/ip dns static
add address=8.8.8.8 name=dns.google
add address=8.8.4.4 name=dns.google
add address=1.1.1.1 name=cloudflare-dns.com
add address=1.0.0.1 name=cloudflare-dns.com

.

DOH.png

Based on:
https://developers.google.com/speed/public-dns/docs/doh
https://developers.cloudflare.com/1.1.1 ... red-proxy/

volkirik · Sat Mar 21, 2020 3:28 pm

Seems there are some errors with DoH, I've this sometime in the logs : DoH max queue size reached, dropping query

@Florian : same here. couldnt get it to work stable.

msatter · Sat Mar 21, 2020 4:06 pm

How DoH works. Pssssst I like to go to the Pornhub can you give me the IP address. Here you go says Google, of you are. Google making a note the IP xxx.xxx.xxx.xxx went to the pornhub on that day and time and it is already the 6543 time. Lets ask pornhub what is the preference of IP xxx.xxx.xxx.xxx and show advertising on others sites visited by that IP.

You can replace Google by Cloudflare and it's all put in a BIG database. But but they say we don't keep track of what you ask for....an other big firm that did not sell/intentional leak your info by inserting bugs, is Facebook and it told also that they were safe.

volkirik · Sat Mar 21, 2020 4:22 pm

How DoH works. Pssssst I like to go to the Pornhub can you give me the IP address. Here you go says Google, of you are. Google making a note the IP xxx.xxx.xxx.xxx went to the pornhub on that day and time and it is already the 6543 time. Lets ask pornhub what is the preference of IP xxx.xxx.xxx.xxx and show advertising on others sites visited by that IP.

You can replace Google by Cloudflare and it's all put in a BIG database. But but they say we don't keep track of what you ask for....an other big firm that did not sell/intentional leak your info by inserting bugs, is Facebook and it told also that they were safe.

If you want fully secure internet access, you should setup your own POPs, gateways, recursive servers and get your own AS number and peer with the world yourself.

Of course it should cost you million dollars. Even big networks use IP transit, so content networks and transit providers may see and sell everything. There is only one way around: building your own!

Paid providers, VPN providers, and of course Google! they all collect statistics and they may sell anytime! There is nothing to prevent them selling our data anonymously.

Florian · Sat Mar 21, 2020 5:57 pm

Seems there are some errors with DoH, I've this sometime in the logs : DoH max queue size reached, dropping query
@Florian : same here. couldnt get it to work stable.

Despite the "max queue size reached", it's working well (I'm using opendns doh servers) here.

anthonws · Sat Mar 21, 2020 6:14 pm

I'm now constantly getting "DoH connection error: Idle timeout - connecting"...

It was working just a while ago...

aboiles · Sun Mar 22, 2020 5:55 pm

Seeing DoH intermittent errors every few hours.
DoH is still working though, does anyone know if these errors are normal for DoH (using cloudflare).

Mar/22/2020 05:05:53 dns,error DoH connection error: Idle timeout - waiting data
Mar/22/2020 05:06:02 dns,error DoH not OK HTTP response: 504:

CoUL · Mon Mar 23, 2020 7:43 am

Dude does not work properly. Constant reconnection of elements, improperly removed graphics due to ROS functions, (jumping indicators several times) sticking server Dude, which prevents him from accessing through winbox. Unable to update AP with separate packages. The most important thing is to ignore these problems. The new features are cool, but with them so many bugs in the bullshit feature. I would like you to be on the site of admins who run thousands of MikRotik without a Dude. It is better to close the Dude project already and do not make fun of him and us.

Jotne · Tue Mar 24, 2020 8:19 pm

Yes, running DoH in my home network.

I do have a 750Gv3 that I do not like to upgrade more then needed, so here is how I did it.

1. Run a RouterOS 6.47beta latest on a VmWare.
2. Set the "https://1.1.1.1/dns-query" on the DNS setting on the VmWare RouterOS.
3. Select Allow Remote Request on the RouterOS
4. On my 750Gv3 set static DNS to point to VmWare Router OS
This it. Works fine

No more can my ISP sniff my DNS request.

eworm · Wed Mar 25, 2020 12:53 am

IMHO the DoH logs have too high severity. I've configured my devices to forward error logs via e-mail. Now I get...

... on boot, probably because I have ipsec peers with dns name in address:

dns,error: DoH connection error: Network is unreachable

... and every now and then:

dns,error: DoH connection error: Idle timeout - connecting

... and...

dns,error: DoH connection error: SSL: handshake timed out (6)

aboiles · Wed Mar 25, 2020 1:56 am

I was receiving way too may errors.
Also the connections slowed way down when the router was reporting:
dns,error DoH max queue size reached, dropping query

I removed my DoH configurations, back to normal.

volkirik · Wed Mar 25, 2020 7:02 am

I was receiving way too may errors.
Also the connections slowed way down when the router was reporting:
dns,error DoH max queue size reached, dropping query

I removed my DoH configurations, back to normal.

same here.. made me sick 2 days.. need more stable version..

Jotne · Wed Mar 25, 2020 1:03 pm

DoH is a nightmare and I don't understand why it is supported by Mikrotik.

After HTTS become standard, your ISP did not anymore see what you was surfing on, but up until DoH or other solution are in place, then they can always look at your DNS request on port 53. They will not see what your read, but what site you are viseting and they can point the DNS request to any server they like. Even if you set 8.8.8.8, they can intercept this and change it to 1.1.1.1 with a port 53 redirect.
With DoH the can not see DNS traffic anymore. Nor can they redirect it.

msatter · Wed Mar 25, 2020 1:46 pm

DoH is a nightmare and I don't understand why it is supported by Mikrotik.
After HTTS become standard, your ISP did not anymore see what you was surfing on, but up until DoH or other solution are in place, then they can always look at your DNS request on port 53. They will not see what your read, but what site you are viseting and they can point the DNS request to any server they like. Even if you set 8.8.8.8, they can intercept this and change it to 1.1.1.1 with a port 53 redirect.
With DoH the can not see DNS traffic anymore. Nor can they redirect it.

The ISP can still see where to you are surfing to because that is still in plain sight for everyone, despite using HTTPS. DoH also shows the sites name your are asking on for your resolves and only a few DoH providers can hide that already.

It is a FALSE assumption, that your traffic (metadata) is invisible when using HTTPS or/and DoH.

RedirectingHTTPS is not possible due that the certificate is then not correct anymore.

As I wrote earlier DoH is a weapon and with all weapons you have to use them with care.

Redirection is bad but not bad if a bad organisation is doing that. I have a Android tablet from Huawei and have lists of blocking to keep my private thing private. DoH will make this much more difficult.

DNS requests are redirected from 8.8.8.8 to my own Pi-hole and those are made by Google despite my Pi-hole is the standard DNS. I loose my rights on my bought device beause DoH is not being able to redirect. So now those connections out are dropped in the firewall.

Cha0s · Wed Mar 25, 2020 2:30 pm

It is a FALSE assumption, that your traffic (metadata) is invisible when using HTTPS or/and DoH.

When TLS 1.3 becomes mainstream, it will no longer be an assumption.
Right now even using TLS, the ISP can see the domain you are visiting.
After TLS 1.3 that will no longer be possible and the L3-L4 "metadata" that it can collect is useless.

For example you visit a website that it is hosted in cloudflare.
Great, the ISP will see that you initiated a connection to a CF IP on port 443. And?
That IP may host hundreds of websites. It is pretty much impossible to infer anything useful other than you visited a server that is managed by CF.
On the same IP there may be a kittens site and a neonazi site. The ISP won't know which one you visited (only CF - of course).

msatter · Wed Mar 25, 2020 2:46 pm

It is a FALSE assumption, that your traffic (metadata) is invisible when using HTTPS or/and DoH.
When TLS 1.3 becomes mainstream, it will no longer be an assumption.
Right now even using TLS, the ISP can see the domain you are visiting.
After TLS 1.3 that will no longer be possible and the L3-L4 "metadata" that it can collect is useless.

For example you visit a website that it is hosted in cloudflare.
Great, the ISP will see that you initiated a connection to a CF IP on port 443. And?
That IP may host hundreds of websites. It is pretty much impossible to infer anything useful other than you visited a server that is managed by CF.
On the same IP there may be a kittens site and a neonazi site. The ISP won't know which one you visited (only CF - of course).

That what you wrote is still in the future. At the moment using DoH is futile if you want to have privacy. Secondly you are dealing with the biggest privacy enemies, having you DoH connecting to Google and Cloudflare.

In the land of the blind, the one with one seeing eye becomes King.

Cha0s · Wed Mar 25, 2020 5:14 pm

That what you wrote is still in the future.

All major web servers support TLS 1.3 already. Browsers too. It is NOT in the future. It's already being rolled out. It has started since 2018.

At the moment using DoH is futile if you want to have privacy.

I remember back in the non SSL/TLS days, people saying the same thing. SSL is futile if you want security/privacy because "reasons". Well... scripta manent. Guess who wishes they hadn't posted those silly comments...

Secondly you are dealing with the biggest privacy enemies, having you DoH connecting to Google and Cloudflare.

You do understand that DoH is not some Google proprietary protocol but an open standard (RFC 8484), right?
It's like saying that using HTTP amounts to dealing with "the biggest privacy enemies" because google services run on HTTP. That statement is ridiculous.
The same way everyone can use HTTP on their own servers, they can also use DoH. It's not limited to Google or CF.

Spreading FUD about something you obviously don't seem to understand very well, is not productive.

msatter · Wed Mar 25, 2020 5:38 pm

You can make the most secure connections and traffic ever but when it ends up with Google etc. then why bother to secure it. You're the product.

SSL was never sold in those day to be a secure connection, it was and still is seen as being a trustworthy site in the general public view. Today we should do away with having the general public seeing the TLS connection status because it should be always a secure connection.

I have in the URL bar of my Waterfox browser show what the TLS level is of the site I visit and Mikrotik is still on TLS version 1.2. To me if Mikrotik was serious on DNS security then they would also made DoT available. That is better replacement for plain DNS.

I don't use either and I just use QNAME minimization (plain DNS to several authoritative servers) through a VPN. I only reach out to Google or Cloudflare if I have to visit a server in their network.

Edit:

For DoH, ESNI will hide the SNI of the server you are going to use. Then if you IP address you are going to that server. Then you share that domain name, even in TLS 1.3 because the server needs to know which certificate to use.

No FUD!

Wed Mar 25, 2020 6:43 pm

All major web servers support TLS 1.3 already. Browsers too. It is NOT in the future. It's already being rolled out. It has started since 2018.

You keep talking about TLS 1.3 whereas you really mean ESNI. TLS 1.3 is a requirement for ESNI, but not the other way round. Enabling ESNI for a particular web-site is not only about using a web server that supports that, in fact that's a pretty involving process, and I don't believe that that will happen for a significant number of domains any time soon.

You do understand that DoH is not some Google proprietary protocol but an open standard (RFC 8484), right?
It's like saying that using HTTP amounts to dealing with "the biggest privacy enemies" because google services run on HTTP. That statement is ridiculous.

It's not about protocol, it's about services using that protocol. That's about who you trust more- your ISP or someone running public DoH server like Google or Cloudflare. You are free to chose, but in either case it has little to do with the privacy.

SiB · Wed Mar 25, 2020 11:20 pm

At ROS 6.47beta49 I press Download in "Check For Updates" and in loop see that:

qcRwlwoD1m.gif

To stop this loop I do:
/system package update cancel

DNS works normal, without DoH, just simple 1.1.1.1,9.9.9.9

msatter · Wed Mar 25, 2020 11:27 pm

At ROS 6.47beta49 I press Download in "Check For Updates" and in loop see that:
qcRwlwoD1m.gif
To stop this loop I do:
/system package update cancel

This is done on purpose so you don't install it automatically/by accident. To go to 7.x has to be a manual process.

pe1chl · Thu Mar 26, 2020 1:50 pm

Is there any chance of improvements of the local DNS resolver as discussed in another topic? (I mean: to add more record types for static entries, etc)

pe1chl · Thu Mar 26, 2020 1:52 pm

Please add extra parameter "regexp" (including NOT operator) to "/system logging" rules so you can specify a regexp on the logged message to be (not) matched before the specified action is taken.
Often there are many messages with exactly the same topics but widely different purpose, and some of the topics are quite verbose so one would want to see (or suppress) certain messages.

CosmosNetwork · Fri Mar 27, 2020 1:43 pm

DoH configuration example. Cacert.pem is CA certificates extracted from Mozilla.

/ip dns set servers=1.1.1.1,1.0.0.1
/system ntp client set enabled=yes server-dns-names=time.cloudflare.com
/tool fetch url=https://curl.haxx.se/ca/cacert.pem
/certificate import file-name=cacert.pem passphrase=""
/ip dns set use-doh-server=https://1.1.1.1/dns-query verify-doh-cert=yes
/ip dns set servers=""

upd.

/system clock set date=jan/01/2020
/certificate import file-name=cacert.pem passphrase=""
/ip dns set use-doh-server=https://1.1.1.1/dns-query verify-doh-cert=yes

kenyloveg · Sun Mar 29, 2020 10:29 am

DoH is a nightmare and I don't understand why it is supported by Mikrotik.
After HTTS become standard, your ISP did not anymore see what you was surfing on, but up until DoH or other solution are in place, then they can always look at your DNS request on port 53. They will not see what your read, but what site you are viseting and they can point the DNS request to any server they like. Even if you set 8.8.8.8, they can intercept this and change it to 1.1.1.1 with a port 53 redirect.
With DoH the can not see DNS traffic anymore. Nor can they redirect it.

Yes, this is the exact situation happening here. (west korea)
Even i can mangle foreign ip cidr to go through VPN connection, I still can't access google/youtube/facebook etc...

Anastasia · Tue Mar 31, 2020 4:08 pm

new feature:
dns - added client side support for DNS over HTTPS (DoH) (RFC8484);

I did not install this version because it is beta. say this new feature means that the mikrotik itself can connect over the secure https Protocol to the DNS server and find out the IP. Does this mean that for the client? Please explain.

mkx · Tue Mar 31, 2020 6:17 pm

new feature:
dns - added client side support for DNS over HTTPS (DoH) (RFC8484);
I did not install this version because it is beta. say this new feature means that the mikrotik itself can connect over the secure https Protocol to the DNS server and find out the IP. Does this mean that for the client? Please explain.

This means that ROS as a client can connect to DoH servers. ROS can not serve as DoH server. If you configured your LAN clients to use ROS as caching DNS server via traditional DNS protocol (port 53 etc.), this means that also LAN clients are protected from snoping and spoofing (unless that's done by ROS device or within LAN).

LAN clients, however, can use internet DoH servers unless they are blocked by ROS firewall (not likely) and this part did not change.

MarkoB · Tue Mar 31, 2020 6:48 pm

Why DNS server does not use root servers when no static servers specified?

Sob · Tue Mar 31, 2020 7:39 pm

@MarkoB: Because for that you'd need full recursive resolver and RouterOS doesn't have it.

santyx32 · Thu Apr 02, 2020 5:37 pm

If you use another DoH provider that ain't Google/Cloudflare you can enable Verify DoH Certificate after importing the two root certificates of the endpoint URL, I use cleanbrowsing so I opened https://doh.cleanbrowsing.org/doh/security-filter/ in Firefox and opened the certificate tab.

certs.png

You need to download those two certs in PEM format and import them to your router (drag&drop to files)

import.PNG

After that you can use DoH without problems.

emils · Fri Apr 03, 2020 1:52 pm

Version 6.47beta53 has been released.

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.47beta53 (2020-Apr-03 09:39):

Important note!!!

- The Dude server must be updated to monitor v6.46.4 and v6.47beta30+ RouterOS type devices.
- The Dude client must be manually upgraded after upgrading The Dude server.
- Make sure LTE APN Profile name does not match any of the DHCP server's names if LTE passthrough is used.
- The Dude requires "winbox" policy instead of "dude" to monitor v6.46.4 and v6.47beta30+ RouterOS type devices.

MAJOR CHANGES IN v6.47:
----------------------
!) dns - added client side support for DNS over HTTPS (DoH) (RFC8484);
!) socks - added support for SOCKS5 (RFC 1928);
!) user - enable "winbox" policy for groups with "dude" policy;
----------------------

Changes in this release:

!) socks - added support for SOCKS5 (RFC 1928);
*) branding - do not ask to confirm configuration applied from branding package;
*) certificate - added "skid" and "akid" values for detailed print;
*) certificate - allow dynamic CRL removal;
*) console - prevent incorrect type interfaces appearing in command hints;
*) crs3xx - fixed QSFP interface linking after removing/inserting QSFP module (introduced in v6.47beta49);
*) dhcpv4-server - disallow zero lease-time setting;
*) filesystem - fixed NAND memory going into read-only mode or becoming unstable over time;
*) ike1 - improved policy lookup with specific protocol;
*) ike1 - rekey phase 1 rekeying as responder for Windows initiators;
*) ipsec - improved system stability when handling fragmented packets;
*) kidcontrol - ignore IPv6 multicast MAC addresses;
*) lora - added IPv6 support for LoRa packet forwarder;
*) lora - added UTC timestamp for RX events in "rxpk" json;
*) lte - added support for Huawei K5161 modem;
*) lte - fixed IP type selection from APN on RBSXTLTE3-7;
*) snmp - fixed multiple LTE interface OID reporting;
*) system - improved kernel panic reporting in logs after reboot;
*) wireless - added "russia 6ghz" regulatory domain information;
*) wireless - added "skip-dfs-channels" parameter;
*) wireless - updated "bangladesh" regulatory domain information;
*) wireless - updated "russia4" regulatory domain information;

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.

emils · Fri Apr 03, 2020 2:01 pm

Anyone that got DoH configured properly and running into stability issues, please send us a supout.rif file which is generated as soon as possible after the error has occurred with DNS debug logs enabled (topics=dns,!packet).

eworm · Fri Apr 03, 2020 2:02 pm

*) certificate - added "skid" and "akid" values for detailed print;

This looks like SHA1 key ids. Can you give more details?

skid = signing key id?

emils · Fri Apr 03, 2020 2:35 pm

Authority Key Identifier (AKID) and Subject Key Identifier (SKID)

https://tools.ietf.org/html/rfc5280#section-4.2.1.1

latifolia · Fri Apr 03, 2020 7:17 pm

I got confused a bit please elaborate to me..

If I set the RouterOS to act as DoH client to a server (Google/Cloudflare), how do they know the first time to address of google/cloudflare without first querying via regular DNS server?

Also, is there any specific CPU spec for this DoH support because I believe the CPU usage will spike and things will get slow on any HAP users.

Thank you

eworm · Sat Apr 04, 2020 12:49 am

I got confused a bit please elaborate to me..

If I set the RouterOS to act as DoH client to a server (Google/Cloudflare), how do they know the first time to address of google/cloudflare without first querying via regular DNS server?

Two ways to solve this:

configure a regular DNS server
use an url with ip address

See posts above for details.

Also, is there any specific CPU spec for this DoH support because I believe the CPU usage will spike and things will get slow on any HAP users.

This is very little extra load for the CPU... You can ignore that and there is no issue for the user.

anas94c · Sun Apr 05, 2020 8:48 am

Bonding 802.3ad Problem :

after i upgrade to this version the Bonding 802.3ad not working ( or stop about 30s ) i have not change anything and it's work without any problem in stable version

TimurA · Sun Apr 05, 2020 11:12 am

Bonding 802.3ad Problem :

after i upgrade to this version the Bonding 802.3ad not working ( or stop about 30s ) i have not change anything and it's work without any problem in stable version

no problem with 802.3ad on RB4011

rpingar · Sun Apr 05, 2020 11:19 am

Bonding 802.3ad Problem :

after i upgrade to this version the Bonding 802.3ad not working ( or stop about 30s ) i have not change anything and it's work without any problem in stable version

seemes there are issue about arp and bonding interface on tilera platforma and a lot of routes.... I notifiend it in a previous posta but they still didn't manage to fix it.

Ros

volkirik · Sun Apr 05, 2020 3:46 pm

You could try "https://1.1.1.1/dns-query" - Cloudflare managed to get the the ip address into the certificate.

thanks

abiv · Sun Apr 05, 2020 6:28 pm

So is antenna gain added back now?

volkirik · Mon Apr 06, 2020 4:03 am

So is antenna gain added back now?

yes

emils · Mon Apr 06, 2020 11:28 am

Version 6.47beta54 has been released.

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.47beta54 (2020-Apr-06 06:32):

Important note!!!

- The Dude server must be updated to monitor v6.46.4 and v6.47beta30+ RouterOS type devices.
- The Dude client must be manually upgraded after upgrading The Dude server.
- Make sure LTE APN Profile name does not match any of the DHCP server's names if LTE passthrough is used.
- The Dude requires "winbox" policy instead of "dude" to monitor v6.46.4 and v6.47beta30+ RouterOS type devices.

MAJOR CHANGES IN v6.47:
----------------------
!) dns - added client side support for DNS over HTTPS (DoH) (RFC8484);
!) socks - added support for SOCKS5 (RFC 1928);
!) user - enable "winbox" policy for groups with "dude" policy;
----------------------

Changes in this release:

*) wireless - improved 5GHz interface stability on RB4011iGS+5HacQ2HnD and Audience;
*) wireless - improved system stability on hAP ac^2;

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.

tpedko · Mon Apr 06, 2020 11:47 pm

5G stopped working at all on 4011

Reinis · Tue Apr 07, 2020 6:39 am

5G stopped working at all on 4011

please contact support@mikrotik.com and provide supout.rif generated from your device after the "5G has stopped working"
How to generate supout.rif can be found here: https://wiki.mikrotik.com/wiki/Manual:S ... utput_File

Resolution: russia4 profile now includes wider range frequencies and by default can lock into frequency that most client devices does not support. Please make sure that you're allowed to use and comply all regulations within such frequencies before enabling wireless interface!

anuser · Tue Apr 07, 2020 1:44 pm

Version 6.47beta54 has been released.
[...]
What's new in 6.47beta54 (2020-Apr-06 06:32):
[...]
Changes in this release:

*) wireless - improved 5GHz interface stability on RB4011iGS+5HacQ2HnD and Audience;
*) wireless - improved system stability on hAP ac^2;.

You haven´t already integrated MU-MIMO capable drivers in this release, haven´t you?

obukhov · Tue Apr 07, 2020 3:18 pm

Damn, I should have checked the forum before installing 6.47beta35. I can no longer login via ssh (key/password). The device is HAP AC2.

Got the same issue ( RouterBOARD 962UiGS-5HacT2HnT) . Had to roll back to stable 6.46.4

anas94c · Tue Apr 07, 2020 6:47 pm

Bonding 802.3ad Problem :

after i upgrade to this version the Bonding 802.3ad not working ( or stop about 30s ) i have not change anything and it's work without any problem in stable version
seemes there are issue about arp and bonding interface on tilera platforma and a lot of routes.... I notifiend it in a previous posta but they still didn't manage to fix it.

Ros

I think they need more Report about this

doneware · Wed Apr 08, 2020 1:01 pm

*) wireless - improved system stability on hAP ac^2;

i'm wondering whether these enhancements also apply to the 'sister-devices' like cAP-ac.

Wed Apr 08, 2020 3:20 pm

@Xymox, rpingar, anas94c - regarding the LACP, it does look like an ARP entry never gets completed when the ARP reply is received on a certain slave port. We will try to fix this in the coming RouterOS testing releases, thanks for sharing the details. In the meantime, you could try to change the bonding mode to balance-xor (or static LAG) as this mode did not show the same behavior.

rpingar · Wed Apr 08, 2020 3:34 pm

@Xymox, rpingar, anas94c - regarding the LACP, it does look like an ARP entry never gets completed when the ARP reply is received on a certain slave port. We will try to fix this in the coming RouterOS testing releases, thanks for sharing the details. In the meantime, you could try to change the bonding mode to balance-xor (or static LAG) as this mode did not show the same behavior.

not possible to test form me because i do lacp to l2 switch and it too risky to use an untested lacp.
I will test for sure the beta that is going to fix it.

regards
Ros

dacapo · Fri Apr 10, 2020 9:50 am

I found a memory leak (or cleaning error) in the DNS (hEX v6.47beta53/54), after flushing the cache it is not reset to aprox. 17KiB, but grows until the device reboots, in this example 358KiB. Accordingly, it does not clean normally during working and only grows.

msatter · Fri Apr 10, 2020 12:56 pm

I found a memory leak (or cleaning error) in the DNS (hEX v6.47beta53/54), after flushing the cache it is not reset to aprox. 17KiB, but grows until the device reboots, in this example 358KiB. Accordingly, it does not clean normally during working and only grows.

I have not found this and do you use dynamic and/or DOH servers?


print;
              dynamic-servers: 
               use-doh-server: 
              verify-doh-cert: no
        allow-remote-requests: yes
          max-udp-packet-size: 512
         query-server-timeout: 5s
          query-total-timeout: 10s
       max-concurrent-queries: 3
  max-concurrent-tcp-sessions: 3
                   cache-size: 1024KiB
                cache-max-ttl: 1d
                   cache-used: 75KiB

cache flush; print;
              dynamic-servers: 
               use-doh-server: 
              verify-doh-cert: no
        allow-remote-requests: yes
          max-udp-packet-size: 512
         query-server-timeout: 5s
          query-total-timeout: 10s
       max-concurrent-queries: 3
  max-concurrent-tcp-sessions: 3
                   cache-size: 1024KiB
                cache-max-ttl: 1d
                   cache-used: 65KiB

dacapo · Fri Apr 10, 2020 1:06 pm

I found a memory leak (or cleaning error) in the DNS (hEX v6.47beta53/54), after flushing the cache it is not reset to aprox. 17KiB, but grows until the device reboots, in this example 358KiB. Accordingly, it does not clean normally during working and only grows.

I have not found this and do you use dynamic and/or DOH servers?


print;
              dynamic-servers: 
               use-doh-server: 
              verify-doh-cert: no
        allow-remote-requests: yes
          max-udp-packet-size: 512
         query-server-timeout: 5s
          query-total-timeout: 10s
       max-concurrent-queries: 3
  max-concurrent-tcp-sessions: 3
                   cache-size: 1024KiB
                cache-max-ttl: 1d
                   cache-used: 75KiB

cache flush; print;
              dynamic-servers: 
               use-doh-server: 
              verify-doh-cert: no
        allow-remote-requests: yes
          max-udp-packet-size: 512
         query-server-timeout: 5s
          query-total-timeout: 10s
       max-concurrent-queries: 3
  max-concurrent-tcp-sessions: 3
                   cache-size: 1024KiB
                cache-max-ttl: 1d
                   cache-used: 65KiB

DOH server only (this did not happen in beta 49):

/ip dns
set use-doh-server=https://dns.google/dns-query verify-doh-cert=yes
/ip dns static
add address=8.8.8.8 name=dns.google
add address=8.8.4.4 name=dns.google

msatter · Fri Apr 10, 2020 2:38 pm

viewtopic.php?f=21&t=154662&p=784984#p780798

Enable logging and look for strange things.

pe1chl · Fri Apr 10, 2020 4:42 pm

The "Cache used not decreasing when cache flushed" problem occurs without any DoH servers.
But I have not seen a crash due to that, and it should be mentioned that in the example the Cache used is still way below the Cache Size value.
So it should not cause a memory overusage, unless you have very little memory and still have configured a large cache size.
Is this a hAP mini router?