DoH server connection error: SSL: ssl: CRL not found (6)
DoH server connection error: SSL: ssl: CRL not found (6) [ignoring repeated messages]
18:05:13 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -41
18:05:15 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -40
18:05:15 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:05:15 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:08:25 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -40
18:08:28 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -41
18:08:28 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:08:28 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:11:19 wireless,info 00:C3:0A:B7:ED:1C@cap-wifi3 disconnected, SA Query timeout, signal strength -49
18:11:20 wireless,info 00:C3:0A:B7:ED:1C@cap-wifi4 connected, signal strength -56
18:11:38 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -40
18:11:40 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -39
18:11:41 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:11:41 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:14:51 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -41
18:14:53 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -42
18:14:53 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:14:53 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:18:03 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -41
18:18:06 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -40
18:18:06 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:18:06 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:21:16 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -41
18:21:18 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -41
18:21:18 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:21:19 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:24:28 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -40
18:24:31 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -41
18:24:31 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:24:31 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:27:41 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -41
18:27:44 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -40
18:27:44 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:27:44 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:30:54 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -40
18:30:56 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -41
18:30:56 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:30:56 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:34:07 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -39
18:34:09 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -41
18:34:09 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:34:09 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:37:19 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -40
18:37:22 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -40
18:37:22 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:37:22 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:40:31 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -39
18:40:34 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -40
18:40:34 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:40:34 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:43:44 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -39
18:43:46 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -40
18:43:46 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:43:46 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:46:56 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -40
18:46:59 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -41
18:46:59 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:46:59 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:50:09 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -41
18:50:12 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -41
18:50:12 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:50:12 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:53:22 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -41
18:53:24 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -41
18:53:24 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:53:24 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:56:34 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -41
18:56:37 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -42
18:56:37 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:56:37 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:59:47 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -41
18:59:49 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -41
18:59:49 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:59:50 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
18:59:55 system,info,account user admin logged in from 10.10.88.20 via winbox
19:03:00 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -41
19:03:02 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -41
19:03:02 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:03:02 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:04:28 system,info,account user admin logged out from 10.10.88.20 via winbox
19:06:12 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -41
19:06:15 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -41
19:06:15 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:06:15 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:06:57 system,info,account user admin logged in from 10.10.88.20 via winbox
19:09:25 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -41
19:09:27 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -41
19:09:27 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:09:27 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:09:57 system,info,account user admin logged out from 10.10.88.20 via winbox
19:10:02 system,info,account user admin logged in from 10.10.88.20 via winbox
19:12:37 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -41
19:12:40 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -40
19:12:40 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:12:40 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:13:50 system,info,account user admin logged out from 10.10.88.20 via winbox
19:15:50 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -39
19:15:52 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -41
19:15:53 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:15:53 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:15:53 wireless,info 00:C3:0A:B7:ED:1C@cap-wifi4 disconnected, SA Query timeout, signal strength -53
19:15:58 wireless,info 00:C3:0A:B7:ED:1C@cap-wifi3 connected, signal strength -31
19:19:03 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -41
19:19:05 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -42
19:19:05 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:19:06 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:22:15 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -40
19:22:17 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -42
19:22:18 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:22:18 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:25:28 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -41
19:25:30 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -42
19:25:30 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:25:30 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:28:40 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -41
19:28:43 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -41
19:28:43 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:28:43 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:31:53 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -40
19:31:55 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -40
19:31:55 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:31:56 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:35:06 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -41
19:35:08 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -40
19:35:08 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:35:08 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:38:18 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -41
19:38:21 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -40
19:38:21 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:38:21 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:41:31 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -40
19:41:33 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -40
19:41:33 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:41:33 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:44:43 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -40
19:44:46 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -41
19:44:46 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:44:46 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:47:56 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -41
19:47:58 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -40
19:47:58 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:47:59 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:48:25 dhcp,info dhcp_VLAN88 deassigned 10.10.88.220 for 18:FD:74:CE:E6:83 MikroTik
19:48:25 dhcp,info dhcp_VLAN88 assigned 10.10.88.220 for 18:FD:74:CE:E6:83 MikroTik
19:51:09 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -40
19:51:11 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -40
19:51:11 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:51:11 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:54:21 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -39
19:54:24 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -40
19:54:24 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:54:24 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:54:57 wireless,info A4:55:90:89:31:A2@cap-wifi3 disconnected, connection lost, signal strength -39
19:57:34 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -40
19:57:36 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -42
19:57:36 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
19:57:36 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:00:46 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -39
20:00:49 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -40
20:00:49 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:00:49 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:01:04 wireless,info A4:55:90:89:31:A2@cap-wifi3 connected, signal strength -33
20:03:59 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -39
20:04:01 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -40
20:04:02 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:04:02 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:07:12 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -41
20:07:14 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -41
20:07:14 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:07:14 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:07:24 wireless,info A4:55:90:89:31:A2@cap-wifi3 disconnected, connection lost, signal strength -42
20:10:24 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -40
20:10:27 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -40
20:10:27 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:10:27 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:13:37 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -40
20:13:39 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -41
20:13:39 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:13:40 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:16:50 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -42
20:16:52 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -41
20:16:52 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:16:52 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:20:02 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -41
20:20:05 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -39
20:20:05 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:20:05 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:23:15 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -41
20:23:17 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -41
20:23:17 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:23:17 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:26:27 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -40
20:26:30 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -40
20:26:30 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:26:30 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:29:40 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -40
20:29:42 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -41
20:29:42 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:29:43 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:32:53 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -41
20:32:55 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -40
20:32:55 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:32:55 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:36:05 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -40
20:36:08 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -41
20:36:08 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:36:08 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:39:18 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -41
20:39:20 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -41
20:39:20 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:39:20 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:42:03 wireless,info A4:55:90:89:31:A2@cap-wifi3 connected, signal strength -35
20:42:30 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -41
20:42:33 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -41
20:42:33 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:42:33 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:42:37 wireless,info A4:55:90:89:31:A2@cap-wifi3 disconnected, connection lost, signal strength -39
20:45:43 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -41
20:45:45 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -41
20:45:46 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:45:46 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:48:21 wireless,info A4:55:90:89:31:A2@cap-wifi3 connected, signal strength -31
20:48:56 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -40
20:48:58 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -40
20:48:58 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:48:58 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:52:08 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -41
20:52:11 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -41
20:52:11 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:52:11 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:53:55 wireless,info 70:32:17:E3:AF:80@cap-wifi3 connected, signal strength -35
20:54:08 system,info,account user admin logged in from 10.10.88.9 via winbox
20:55:21 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 disconnected, SA Query timeout, signal strength -41
20:55:23 wireless,info 18:A7:F1:79:D1:4B@cap-wifi5 connected, signal strength -41
20:55:23 dhcp,info dhcp_VLAN30 deassigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
20:55:24 dhcp,info dhcp_VLAN30 assigned 10.10.30.3 for 18:A7:F1:79:D1:4B uplus-haier-ac-d14b-v0
My home setup suffers from the same issue. It also doesn't work with SSTP, which is sad.Sadly the IPSec problem mentioned here viewtopic.php?t=197095&start=300#p1014852 is still present in this version.
SA Query is a procedure for checking if a client device can be reached (and still has the agreed-on encryption key). SA Query timeouts are expected, when a client device attempts to connect to an AP after losing its previous connection due to signal fade (or some other conditions where it did not or could not inform the AP that it is disconnecting).After update to 7.11rc I started to get famous SA Query timeout every couple of minutes
Device in question is air conditioner, I didn't had any problems until update.
Hi
rc1
Cloudflare-dns.com DOH certificate no longer works.
I deleted it and imported it again, but it didn't help.
Code: Select allDoH server connection error: SSL: ssl: CRL not found (6) DoH server connection error: SSL: ssl: CRL not found (6) [ignoring repeated messages]
If you look carefully this particular device is connected only to cap-wifi5 (IoT network) and upstair AP don't broadcast that network, only downstairs AP does, other devices that you can see here are my laptop and my wife's phone, and this AC is in the same room as my donwstairs AP and both are ofcourse stationary and from the signal you can see that they are close.SA Query is a procedure for checking if a client device can be reached (and still has the agreed-on encryption key). SA Query timeouts are expected, when a client device attempts to connect to an AP after losing its previous connection due to signal fade (or some other conditions where it did not or could not inform the AP that it is disconnecting).
The AC in you logs appears to be switching back and forth between cap-wifi3 and cap-wifi5 without informing the AP that it's disconnecting before attempting a new connection. This might be because it is losing reception of the AP. Or it could be that it cannot reach some network resource it expected to reach and so it tries switching APs in a not-so-graceful way.
Which version did you upgrade from?
Not really my problem but ...Gigabyte, FToms is pointing out that your LOGS show this. So please check what is really happening.
Exactly, only few entries are for that mac address, all other entries are for 18:A7:F1:79:D1:4B, and this continued thought the night for this client.Not really my problem but ...Gigabyte, FToms is pointing out that your LOGS show this. So please check what is really happening.
I'm not sure where you see that ?
Those logs, looking at MAC 18:A7:F1:79:D1:4B, only show connection with wifi5. Nothing else.
That corresponds with the situation as explained by gigabyte.
There is only 1 entry for wifi3 or wifi4 but that's for MAC 00:C3:0A:B7:ED:1C. Irrelevant for this case, I think ?
look at IP->Cloud->BTH VPN*) bth - added "Back To Home" VPN service for ARM, ARM64, and TILE devices;
where can we see that?
Right, my bad. That MAC is in fact only connecting to cap-wifi5.If you look carefully this particular device is connected only to cap-wifi5 (IoT network)
I have DHCP lease renewal time set do 1 day. I will send supout and logs to support today.One thing I am noticing on a second look is that the delay between a connection and disconnection appears to be almost exactly 190 seconds every time. Does that perhaps correspond to DHCP leases renewal?
03:16:11 wireless,info F2:C3:26:B2:60:1C@wifi2 disconnected, SA Query timeout, signal strength -73
03:16:11 wireless,info F2:C3:26:B2:60:1C@wifi1 connected, signal strength -58
03:31:17 wireless,info F2:C3:26:B2:60:1C@wifi1 disconnected, SA Query timeout, signal strength -56
03:31:18 wireless,info F2:C3:26:B2:60:1C@wifi2 connected, signal strength -83
04:15:10 wireless,info F2:C3:26:B2:60:1C@wifi2 disconnected, SA Query timeout, signal strength -76
04:15:11 wireless,info F2:C3:26:B2:60:1C@wifi1 connected, signal strength -53
04:33:04 wireless,info F2:C3:26:B2:60:1C@wifi1 disconnected, SA Query timeout, signal strength -52
04:33:04 wireless,info F2:C3:26:B2:60:1C@wifi2 connected, signal strength -82
04:35:53 wireless,info F2:C3:26:B2:60:1C@wifi2 disconnected, SA Query timeout, signal strength -75
04:35:53 wireless,info F2:C3:26:B2:60:1C@wifi1 connected, signal strength -57
04:39:32 wireless,info F2:C3:26:B2:60:1C@wifi1 disconnected, SA Query timeout, signal strength -51
04:39:32 wireless,info F2:C3:26:B2:60:1C@wifi2 connected, signal strength -84
04:40:14 wireless,info F2:C3:26:B2:60:1C@wifi2 disconnected, SA Query timeout, signal strength -79
04:40:15 wireless,info F2:C3:26:B2:60:1C@wifi1 connected, signal strength -57
04:49:48 wireless,info F2:C3:26:B2:60:1C@wifi1 disconnected, SA Query timeout, signal strength -52
04:49:49 wireless,info F2:C3:26:B2:60:1C@wifi2 connected, signal strength -85
04:50:29 wireless,info F2:C3:26:B2:60:1C@wifi2 disconnected, SA Query timeout, signal strength -78
04:50:29 wireless,info F2:C3:26:B2:60:1C@wifi1 connected, signal strength -59
05:08:10 wireless,info F2:C3:26:B2:60:1C@wifi1 disconnected, SA Query timeout, signal strength -52
05:08:10 wireless,info F2:C3:26:B2:60:1C@wifi2 connected, signal strength -83
05:33:13 wireless,info F2:C3:26:B2:60:1C@wifi2 disconnected, SA Query timeout, signal strength -75
05:33:14 wireless,info F2:C3:26:B2:60:1C@wifi1 connected, signal strength -65
06:03:52 wireless,info F2:C3:26:B2:60:1C@wifi1 disconnected, SA Query timeout, signal strength -55
06:03:52 wireless,info F2:C3:26:B2:60:1C@wifi2 connected, signal strength -82
06:23:22 wireless,info F2:C3:26:B2:60:1C@wifi2 disconnected, SA Query timeout, signal strength -80
06:23:23 wireless,info F2:C3:26:B2:60:1C@wifi1 connected, signal strength -54
06:33:38 wireless,info F2:C3:26:B2:60:1C@wifi1 disconnected, SA Query timeout, signal strength -56
06:33:38 wireless,info F2:C3:26:B2:60:1C@wifi2 connected, signal strength -81
06:37:02 wireless,info F2:C3:26:B2:60:1C@wifi2 disconnected, SA Query timeout, signal strength -74
06:37:03 wireless,info F2:C3:26:B2:60:1C@wifi1 connected, signal strength -63
06:52:54 wireless,info F2:C3:26:B2:60:1C@wifi1 disconnected, SA Query timeout, signal strength -56
06:52:54 wireless,info F2:C3:26:B2:60:1C@wifi2 connected, signal strength -83
06:59:36 wireless,info F2:C3:26:B2:60:1C@wifi2 disconnected, SA Query timeout, signal strength -75
06:59:37 wireless,info F2:C3:26:B2:60:1C@wifi1 connected, signal strength -67
07:24:58 wireless,info F2:C3:26:B2:60:1C@wifi1 disconnected, SA Query timeout, signal strength -59
07:24:59 wireless,info F2:C3:26:B2:60:1C@wifi2 connected, signal strength -80
This is to be expected if a client device, which supports management frame protection, attempts a new connection without properly terminating the previous one.I have an SA Query timeout error when the device switches between wifi1 and wifi2 interfaces (hAP ac3). It appeared in 7.11 beta2, it was not present in 7.10.2.
yes, i wrote about it aboveHi
v7.11 rc1 has also broken Cloudflare (1.1.1.1) DoH certificate for me - I get a CRL error in the logfile and DNS resolution remains broken until I disable DoH certificate verification.
While troubleshooting, I'd also note that I cannot import CRLs, so wondering whether CRL file validation is the bit that is broken?
Regards,
Jason
But it real works at 7.8 and old versions.Yes, LE does not work currently in RouterOS on an IPv6-only network. This is not implemented yet. This particular scenario is not in any way related to the v7.11rc release.
Try with a clean winbox session. It shows up here.IP Cloud is missing from Winbox (3.39) on my OVA(x86) (7.11Rc1) Router. It show up on terminal, and in Winbox on other routers lik 750Gr3. See picutre:
.
ip-cloud.png
Try to fix the "cpu is not running at default frequency" by setting it to automatic.cube60ac pro.jpgWith the Cube 60 pro ac no improvement in stability with 7.11RC...............
Support recommended disabling CLR (/certificate/settings/set crl-use=no) and it workedHi
rc1
Cloudflare-dns.com DOH certificate no longer works.
I deleted it and imported it again, but it didn't help.
Code: Select allDoH server connection error: SSL: ssl: CRL not found (6) DoH server connection error: SSL: ssl: CRL not found (6) [ignoring repeated messages]
Thanks for the info. i will test it.Try to fix the "cpu is not running at default frequency" by setting it to automatic.cube60ac pro.jpgWith the Cube 60 pro ac no improvement in stability with 7.11RC...............
If that doesn´t help, export the config to a RSC file, factory default with no config the device and import the RSC file via terminal.
That fixed all my instabilities I had during the last several ROS updates ;-)
All my devices are rock-solid with all 7.11 versions (since 7.11Beta4):
hc_002.jpg
":convert to=hex" doesn't work with number types. I'd expect either a string with "7F" or "007F" back from below..., instead the number arg is treated as string and ASCII codes are used:*) console - added ":convert" command;
:put [:convert to=hex 127]
:put [:convert from=raw to=hex value=[:tonum 127]]
313237
It looks like this has been broken for a while, and I didn't notice. I have played around with it a bit, and it looks like I can change the MTU after the device has rebooted, but it's not setting them correctly on startup.I upgraded a RB4011iGS+5HacQ2HnD to 7.11rc1 and MTU's were no longer being applied to vlans on a bridge, they were all at 1500.
Rolling back to 7.10, the MTUs were correctly set.
Yes, I reported this a while back. I have a script that runs that disables/enables the VLAN interfaces after booting to force the configured MTU size to take effect. Without it, my OSPF links won't start due to MTU mismatch (most of my PTP links between routers have been configured with an MTU of 2000 or more to support future tagging and tunneling techniques).It looks like this has been broken for a while, and I didn't notice. I have played around with it a bit, and it looks like I can change the MTU after the device has rebooted, but it's not setting them correctly on startup.I upgraded a RB4011iGS+5HacQ2HnD to 7.11rc1 and MTU's were no longer being applied to vlans on a bridge, they were all at 1500.
Rolling back to 7.10, the MTUs were correctly set.
This is with 7.11b6, which I happened to have lying around.
https://i.imgur.com/Hitjrdz.png
This does not appear to be working. Hardware offloaded VLAN filtering on hEXr3 still breaks spanning tree, as documented in this forum thread.*) switch - fixed BPDU packet processing on MT7621, MT7531 with HW offloaded vlan-filtering;
Yes you have right about it.i thing from 7.7 and newer versions
no red color of unreachable routes
do you have any plan to fix it or no?
thank you
3Καταγραφή.jpg
put the value in quotes
":convert to=hex" doesn't work with number types. I'd expect either a string with "7F" or "007F" back from below..., instead the number arg is treated as string and ASCII codes are used:
Unfortunately, the error also occurs with the setting to default cpu frequency..............Thanks for the info. i will test it.
Try to fix the "cpu is not running at default frequency" by setting it to automatic.
If that doesn´t help, export the config to a RSC file, factory default with no config the device and import the RSC file via terminal.
That fixed all my instabilities I had during the last several ROS updates ;-)
All my devices are rock-solid with all 7.11 versions (since 7.11Beta4):
hc_002.jpg
Steve
Yup. If someone had time for =rot13.... num to hex seems pretty reasonable...Put decimal to hex function as well to reduce confusion. Decimal 127 output must be 7F not 313237.
but... if the input is "num" (decimal) then 7F is what you SHOULD get with this::convert "127" to=hex # "313237"
:convert 127 to=hex # should return "7F"... BUT assumes str + ASCII instead...
:convert 1.1.1.1 to=hex # should return "01010101" since arg :typeof = ip not "312e312e312e31"
:convert 2021:: to=hex # should return "202100000000000000000000"
Is this the fix for WiFi slave interfaces adding themselves to the appropriate VLAN? I didn't see this happen when I updated my APs and my RB5009 (CAPsMAN Wifiwave2) to 7.11.wifiwave2 - automatically add wifi interfaces to appropriate bridge VLAN when wireless clients with new VLAN IDs connect;
Here is a quote from our manual - "Converts specified value from one format to another. By default uses an automatically parsed value if the "from" format is not specified (for example, "001" becomes "1", "10.1" becomes "10.0.0.1", etc.)"Yup. If someone had time for =rot13.... num to hex seems pretty reasonable...Put decimal to hex function as well to reduce confusion. Decimal 127 output must be 7F not 313237.
Basically, :convert to=hex should be type aware. At least for input arg is typeof=num... Right now :convert only deals with strings.
So if input is a string, then yeah "127" becoming "313237" makes sense...but... if the input is "num" (decimal) then 7F is what you SHOULD get with this::convert "127" to=hex # "313237":convert 127 to=hex # should return "7F"... BUT assumes str + ASCII instead...
Arguable, perhaps not high priority, but ip and ipv6 are types, and have hex represented::convert 1.1.1.1 to=hex # should return "01010101" since arg :typeof = ip not "312e312e312e31"
:convert 2021:: to=hex # should return "202100000000000000000000"
The Wireguard interface is always in a "running" state. You can connect multiple peers to the same interface. There is no easy way to determine if the interface should be up or down.
Most likely you are looking for the Wireguard peers parameter "last-handshake".
I had the same problem, because it´s a little bit tricky.Is this the fix for WiFi slave interfaces adding themselves to the appropriate VLAN? I didn't see this happen when I updated my APs and my RB5009 (CAPsMAN Wifiwave2) to 7.11.wifiwave2 - automatically add wifi interfaces to appropriate bridge VLAN when wireless clients with new VLAN IDs connect;
On the regular old CAPsMAN and non-ax devices, the slave interfaces - in my case on VLAN 10 - automatically add themselves to the bridge VLAN (as tagged no less) as soon as the CAPsMAN provisioning is done.
*) lte - added "at-chat" support for Fibocom L850-GL modem;
failure: Modem unsupported!
failure: AT channel not responding
Is it fixed-fixed now for all platforms? You've been fixing it since February 2022.What's new in 7.11rc2 (2023-Aug-03 10:50):
*) wireguard - fixed peer IPv6 "allowed-address" usage;
What means?What's new in 7.11rc2 (2023-Aug-03 10:50):
*) ssh - fixed SSH key agreement when using ed25519 under server settings;
Yeah the num type to/from hex is common one that does come up sometimes, so be good to see that at some point.However, since "convert" does not support the "num" format at the moment, it will use the from value as "raw".
:convert from=raw to=raw 1.1
at least on rb5009 arm64 i could use again /112Is it fixed-fixed now for all platforms? You've been fixing it since February 2022.What's new in 7.11rc2 (2023-Aug-03 10:50):
*) wireguard - fixed peer IPv6 "allowed-address" usage;
https://download.mikrotik.com/routeros/ ... -arm64.npkUnfortunately, there's no way to get 7.11rc1 back from the website.
at least on rb5009 arm64 i could use again /112
Is it fixed-fixed now for all platforms? You've been fixing it since February 2022.
hope that @strods will show this post to mr Oskars K. from ticketing portal [SUP-121761]
maybe ticketing stuff will be less arrogant next time
it was stated in every 7.10 ++ forum topic that WG IPv6 with non /64 allowed address will break on certain platforms
after sending 2 .rif (7.9.2 vs 7.11) mr Oskars have very negative attitude
i saw that all old beta forum topics are erasedWe are very sorry if you felt offended in some way.
If we are going to e-mail support, why is this topic on the forum?To everyone! Please remember - this is a user forum. Report bugs to support@mikrotik.com immediately, if you are sure that the issue you have is a bug. This will get things done much faster!
Because 90% of problems are due to user ignorance, and often with the help of forum users they are fixed.If we are going to e-mail support, why is this topic on the forum?
to add to "strods" clarification ... you do have to understand, that support staff (not STUFF!!) mostly if at all has no time to sift through the user forum topics with A LOT of useless entries and poeple just complaining over stuff wich is BETA or RC and not stable by any means.i saw that all old beta forum topics are erasedWe are very sorry if you felt offended in some way.
i reported few time when v7.10 betaX started to show, that WG with IPv6 and non /64 suffix have a problem
in 7.11beta topic there was also another user with same observation, and i clearly remember that he has ticket number also
in previous posts i was clearly show configs, tracert, and errors reported by ROS when one try to use WG with non /64 on various platforms
all these post was ignored by MT staff
and then, when i had enough of ignorance, i filled the bug report with all data and RIFs to trace bug
few day of silence, then question ...
it was obvious that no one take seriously bugs reported in forum (at least 3 time, two different user) and that staff from ticketing portal is not aware of similar bug reports
so, it is annoying that we, users, help MT to debug they OS, for ex WG / IPv6, which is broken in last XX releases ( and will break again ) with different behavior on different platforms and our rewards is silence or ignorance
at least answer what i expected was: yes, we read forum posts, we are aware of problem, tnx for RIFs, will try to reproduce ...
anyway, tnx for fixing it (for now)
YESSS, please!!!!! :-)In WiFi / registration tab please add CAP identity where client are connected.
Because 90% of problems are due to user ignorance, and often with the help of forum users they are fixed.If we are going to e-mail support, why is this topic on the forum?
Then there's the 2% that users persist in reporting on the forum, instead of to support@mikrotik.com.
The remaining 8% are not problems related to any of the previous aspects.
8%
Because 90% of problems are due to user ignorance, and often with the help of forum users they are fixed.
Then there's the 2% that users persist in reporting on the forum, instead of to support@mikrotik.com.
The remaining 8% are not problems related to any of the previous aspects.
My question was rhetorical. I don't want answers to them because I know them.
I will gladly read that I am ignorant or that I should write to the support. I will gladly read anything that will help solve my problem, perhaps resulting from ignorance. So far I haven't read anything about my previous question.
I've been having this off and on with the 7.x releases. 7.9 was fine for me, 7.10.2 my Synology NAS with a ConnectX 4 card + FS SM optic has link, but DHCP/etc do not work. 7.7 was fine, I think 7.8 didn't work, etc. It's all over the map - it's become a guessing game if things will work for me with the 7.x releases and SFP+s on my CRS328. I always see notes about SFP changes in each release so I've stopped reporting the issues because every time it gets fixed, it just gets broken again. I'm going to wait for things to stabilize a bit then start reporting again if it remains broken, because right now it doesn't seem to help resolve the issue since the fixes seem to get invalidated in later releases.I've finally updated from 7.7 to 7.11rc1 & rc2, and while it looks like the openvpn problems have been fixed, I'm experiencing *lots* of sfp problems.
A lot of sfp ports flapping that didn't happened neither with 7.7 nor with 6.xx versions.
And since updating to rc2, the SFP interface with my DAC (XS+DA0001) between my CRS328 and my RB5009 doesn't go up automatically anymore. I need to connect to the CRS328 and disable/enable the sfp interface after each reboot to make it work.
It seems the BPDU processing has indeed been fixed for bridges and bridge-ports in hybrid mode via `frame-types=admit-all`. If the bridge and/or ports are set for `frame-types=admit-only-VLAN-tagged` this is still broken and will cause RSTP to refuse to forward packets, unless one of the previous workarounds is employed (Disabling RSTP, setting edge=yes, or disabling Hardware Offload)What's new in 7.11rc1 (2023-Jul-28 09:52):
*) switch - fixed BPDU packet processing on MT7621, MT7531 with HW offloaded vlan-filtering;
We are SPECIFICALLY AND DIRECTLY told to report bugs in this forum.Then there's the 2% that users persist in reporting on the forum, instead of to support@mikrotik.com.If we are going to e-mail support, why is this topic on the forum?
Yeah I kinda use these release threads to judge stability. My theory is... If you're unsure something is a bug or notice something "weird" in the release, just post. If it's critical and/or your sure it's a bug, file bug report then post...Want to report a bug, both ways?
Excellent! It will enable other colleagues to identify with your situation and perhaps help to find the cause.
EDIT: is security.connect-group + connect-priority ?*) wifiwave2 - changed default behavior for handling duplicate client MAC addresses, added settings for changing it (CLI only);
Maybe delete or unpin that post then? It's still the first one that people see.That topic is from 2019 when v7 was in beta. It is not beta anymore,. 4 years have passed. It is stable
Maybe delete or unpin that post then? It's still the first one that people see.That topic is from 2019 when v7 was in beta. It is not beta anymore,. 4 years have passed. It is stable
If people are not able to read and understand what is written....UPDATE: v7 is no longer in beta. Report bugs to support @ mikrotik . com please
That was only just added, when it was unpinned. Don't get upset because people were doing what they were told!But this is also the first line on this topic.If people are not able to read and understand what is written....UPDATE: v7 is no longer in beta. Report bugs to support @ mikrotik . com please
That topic is from 2019 when v7 was in beta. It is not beta anymore,. 4 years have passed. It is stable
IS time to create a section about "RouterOS 7" and leave "RouterOS beta and rc versions" just for... RouterOS beta and rc versions!!!RouterOS beta and rc versions
Please report all issues with RouterOS beta / rc pre-release versions.
It's not unpinned at all (now at 2023-08-07 22:11 CEST, tomorrow if is unpinned, is another thing), and if you haven't noticed it's not my fault.That was only just added, when it was unpinned. Don't get upset because people were doing what they were told!
Oh, I do apologise, it has NOT been unpinned. So, yeah, it really should be, like I suggested originally 8)It's not unpinned at all (now at 2023-08-07 22:11 CEST, tomorrow if is unpinned, is another thing), and if you haven't noticed it's not my fault.
viewforum.php?f=1
this is silly to argue over.
Can't you see that the picture is from May 6th 2022??? Not from last week...Edit: Because I thought 'maybe I *am* crazy', I had a look on the wayback machine, and it did specifically say 'don't report v7 bugs to support, report them here'
https://web.archive.org/web/20220506060 ... cd47182e4d
You cannot change comments on dynamic entries, anywhere. And, address-list entries from DNS are dynamic.SUP-121988 Regarding the issue of adding comments to dns-to-address-list
They execute in round-robin, which it's done for a while...SUP-123531 The rules of DNS static are not executed in sequential order
That's not correct. I am pretty sure you can set a comment for dynamic DHCP leases.You cannot change comments on dynamic entries, anywhere.
Likely true, I was mainly thinking of dynamic interfaces.That's not correct. I am pretty sure you can set a comment for dynamic DHCP leases.You cannot change comments on dynamic entries, anywhere.
Well, I HATE that and I refuse to use it!(OT) I like how Ubiquiti has configured their forum software to accept private uploads on the first post of a thread. This allows both the support teams to get the files they need, as well as allowing other members of the community to see that a particular issue has been reported. Others can then pile on with similar symptoms, sharing screenshots, etc.
My point is less about the means or methods, and more about the idea that the issues and feedback are exposed to both internal and external eyes in one place, in an attempt to eliminate duplicate posts and consolidate discussion about the issue(s). Certainly a more secure method of file transfer could be employed for transferring support files.Well, I HATE that and I refuse to use it!(OT) I like how Ubiquiti has configured their forum software to accept private uploads on the first post of a thread.
Normis... I have several tickets opened about pppoe crahes and bgp instability or bgp late advertisment over time.MikroTik forum is for the community. It is user-to-user discussion. No bugs should be reported here, no private files should be uploaded here. Unlike some others, we have actual support with an actual ticketing system. help.mikrotik.com/servicedesk/servicedesk/
I would not expect them to read all threads, but it would not be unreasonable to expect them monitoring the Announcements / x is released! and Feature requests (the one you started yourself) threads.Yes, if you are not sure if it's a bug and want somebody to do a sanity check - sure, forum is a good place. But please do not expect that MikroTik staff is monitoring all threads for possible bug reports. If you are sure it's a bug - report directly in our support system
https://forum.mikrotik.com/search.php?keywords=&terms=all&author=pe1chl&sc=1&sf=firstpost&sr=topics&sk=t&sd=d&st=0&ch=300&t=0&submit=Search
I don't understand what I would need to check and what you are trying to solve.@pe1chl This will show all topics you started and with this it would be easy to check
My reply to you was posting #116 and your posting was #115 and so a direct answer. Also I don't like to quote because then the pages becomes a mess. My nightmares exist of reading topics, where two users are the only ones active and they quote each other in full in every posting......WHY???I don't understand what I would need to check and what you are trying to solve.@pe1chl This will show all topics you started and with this it would be easy to check
This shows how important it is to always quote the (part of) the article you are replying to.
That topic is from 2019 when v7 was in beta. It is not beta anymore,. 4 years have passed. It is stable
@Normis...
Is time to change the section name, is ridiculous:IS time to create a section about "RouterOS 7" and leave "RouterOS beta and rc versions" just for... RouterOS beta and rc versions!!!RouterOS beta and rc versions
Please report all issues with RouterOS beta / rc pre-release versions.
The problem is not that MikroTik do not read the topics, they do. See the above reply by normis: apparently he is reading the topic.You wrote in post 115 about that if Mikrotik opens an topic then they should also check that topic for what is going on. The link I gave allows them to do that and most likely they already use it. Makes work easier and they have not to browse though the pages to find their own started topics back.
Hi, I described it here (viewtopic.php?p=1007986#p1007986) and reported to support (SUP-122789). Sadly, no solution yet. They asked to send supout.rif by the way. I think it would be helpful if you could make another report with such a file attached if you don't mind.Hello,
I have 4 DAC-SFP+ in my Mikrotik switch which are shown with a temperature of 255C. I can set the value to disable them to 256, so they are working perfectly fine. But the fans of the whole switch are running in maximum speed. The switch is in my living room, so it is really anoying.
mikrotik_overheated_sfp_dac_2023-08_#2.png
Obviosly 255C is an error, maybe -1 in an unsigned 2^8 integer. Please don't use this value for system fans or give me the opportunity to ignore the value each module one by one.
The error occured with 7.10 and unfortunately wasn't fixed in 7.11rc yet.
Also described here:
viewtopic.php?p=1017712#p1017712
Good point ... It's a ROS 7.11rc2 topic ... please do not flood it with moderation complains. Should I delete or moderate your post?....
Even the discourse of quotations, hundreds of useless posts are produced in the search, because the search also searches in the quoted text, making a mess that disorients.
I had the same problem. The connections hang, the interface drops and the addresses in ip/address turn red. Openvpn port 1194 is blocked and only normalizes when I restart the router. I went back to 7.11beta2.Hi!
Something changed from beta firmware(s) (at least 7.11beta2) to RC in relation to OpenVPN - RC version has problems with more than 170 OVPN connections ...
I reverted to 7.11beta2 and everything works great.
Luka
If it is not mentioned in the release notes, it's not yet fixed.Has this been fixed yet or is it still pending? I really need this to be fixed so I can complete an installation.
Many people, myself included, have had similar thoughts about Mikrotik software releases and other companies' releases as well. Of course this is a naive outlook which is not well matched with reality. If you just think about it a little while you realize it obviously makes no sense to work on one thing at a time. With a team of people you have multiple projects occurring simultaneously simply because you have multiple developers of different levels and skill sets and many things to get done.I think the problem here with MT they should finished one thing at a time before jumping on to another task at hand and also they should published the roadmap at least people know what to expect or not, otherwise this will be a recurring theme MT will surely delete this post anytime soon just like what they did before.
Well...The problem with MLAG is directly related to bridging and spanning-tree for which there have been a number of fixes in the past couple of releases. I'm not sure if any of those posted fixes also fix the MLAG issues or not. Just checking. Would be nice if there were some sort of actual bug tracking number for the MLAG issue that I could search (like other software/equipment manufacturers).If it is not mentioned in the release notes, it's not yet fixed.Has this been fixed yet or is it still pending? I really need this to be fixed so I can complete an installation.
Of course we have no idea about how many people are actually working in MikroTik software development, and how specialized they are on certain areas of the system.Many people, myself included, have had similar thoughts about Mikrotik software releases and other companies' releases as well. Of course this is a naive outlook which is not well matched with reality. If you just think about it a little while you realize it obviously makes no sense to work on one thing at a time. With a team of people you have multiple projects occurring simultaneously simply because you have multiple developers of different levels and skill sets and many things to get done.
Well, at this point, IS-IS is an unfilled row on a help page. I'd call that being on the "roadmap" ;)At the moment they appear to be restaffed, but still it surprises me that rather than finishing the job on the existing problems that have been caused by the routing revamp in v7, they already start on new things like IS-IS.
BFD
Features not yet supported
enabling BFD for ip route gateways
[...]
What hardware was this on? These fixes in 7.11rc3 have gotten my hEXr3s working the same as the rest of my 'tik gear, at least so far as vlan-filtering, bridging, and rstp are concerned.Out of curiosity, I've had a problem (as others have had) with MLAG. The problem was introduced in 7.7, and just prior to 7.10 being released, it was finally acknowledge as a problem with a solution pending.
*) switch - fixed BPDU packet processing on MT7621, MT7531 with HW offloaded vlan-filtering;
*) switch - improved multicast packet forwarding on MT7621;
No, it is listed as "initial support" under version 7.12.Well, at this point, IS-IS is an unfilled row on a help page. I'd call that being on the "roadmap" ;)At the moment they appear to be restaffed, but still it surprises me that rather than finishing the job on the existing problems that have been caused by the routing revamp in v7, they already start on new things like IS-IS.
I've tried different versions in the last days and it looks like it happens as you say. The behaviour changes from one version to another in my CRS328 too. I'm starting to think if this is not a mix of hardware and software issues, it's not "normal" having so many problems related with SFP and different firmware versions.I've been having this off and on with the 7.x releases. 7.9 was fine for me, 7.10.2 my Synology NAS with a ConnectX 4 card + FS SM optic has link, but DHCP/etc do not work. 7.7 was fine, I think 7.8 didn't work, etc. It's all over the map - it's become a guessing game if things will work for me with the 7.x releases and SFP+s on my CRS328. I always see notes about SFP changes in each release so I've stopped reporting the issues because every time it gets fixed, it just gets broken again. I'm going to wait for things to stabilize a bit then start reporting again if it remains broken, because right now it doesn't seem to help resolve the issue since the fixes seem to get invalidated in later releases.
Where did you read that?No, it is listed as "initial support" under version 7.12.
https://help.mikrotik.com/docs/display/ ... l+OverviewWhere did you read that?No, it is listed as "initial support" under version 7.12.
This is absolutely incorrect. Our changelogs do include all (without exceptions) changes in the source code that do affect already released products and features. Of course, sometimes we are working on a new feature in the background or support for a new product and that might in some way interfere and break already working configuration. Also, a lot of things on systems like RouterOS depend on timing, and by adding a code in one facility you might break something else.It is quite clear that fixes go into RouterOS without mention in the changelog.
If only because some thing suddenly appear "broken" without any mentioned change in that function or anything related to it.
The changelog is only a recap of the most important changes in that version, otherwise it would be too long.
(I have proposed possible improvements of the whole changelog publication system)
You know I respect you, but this time you were wrong.Good point ... It's a ROS 7.11rc2 topic ... please do not flood it with moderation complains. Should I delete or moderate your post?....
Even the discourse of quotations, hundreds of useless posts are produced in the search, because the search also searches in the quoted text, making a mess that disorients.
That is the closest /latest topic to discuss moderation: viewtopic.php?t=197356
I only wrote it once.please do not flood it with moderation complains.
On this page: https://help.mikrotik.com/docs/display/ ... l+OverviewWhere did you read that?No, it is listed as "initial support" under version 7.12.
Well, that may be the official position, but e.g. take a look on the whole DNS resolver disaster earlier this year.This is absolutely incorrect. Our changelogs do include all (without exceptions) changes in the source code that do affect already released products and features. Of course, sometimes we are working on a new feature in the background or support for a new product and that might in some way interfere and break already working configuration.It is quite clear that fixes go into RouterOS without mention in the changelog.
If only because some thing suddenly appear "broken" without any mentioned change in that function or anything related to it.
The changelog is only a recap of the most important changes in that version, otherwise it would be too long.
(I have proposed possible improvements of the whole changelog publication system)
Even if that is the case (reboot), which in my 18year experience with MikroTik, very rarely is, isn't that a bug on its own?Truth be told, most of the issues that are "yelled about" after an upgrade are actually caused by a reboot
Q: was on your device also lte1 configured as WAN and all ether ports as LAN ?Updated hap ax lite lte6 to rc3
It doesn't happen often that a reboot fixes a problem, but it can happen that a reboot results in a situation that does not occur when you make a configuration step by step, which is then built in a different sequence after reboot.Even if that is the case (reboot), which in my 18year experience with MikroTik, very rarely is, isn't that a bug on its own?Truth be told, most of the issues that are "yelled about" after an upgrade are actually caused by a reboot
By the way: is it only me, or the text for "Show from which peer route received", on the "v7.1" column is light gray over green - make it quite hard to read?On this page: https://help.mikrotik.com/docs/display/ ... l+Overview
*) lora - moved LoRa service to IoT package;
It is used to hide secrets :-)By the way: is it only me, or the text for "Show from which peer route received", on the "v7.1" column is light gray over green - make it quite hard to read?
hAP ac3 , upgrade from ROS 7.10.2 stable, to 7.11rc3 ...
failed
"can not install lora-7.11rc3: iot-7.11rc3 is not installed, but is required"
[...]
Something to do with the following change?hAP ac3 , no Lora card, but interested in the MQTT service of IOT.Code: Select all*) lora - moved LoRa service to IoT package;
You might be able to force this through by also installing IoT package from extra-packages at the same time?hAP ac3 , upgrade from ROS 7.10.2 stable, to 7.11rc3 ...
failed
"can not install lora-7.11rc3: iot-7.11rc3 is not installed, but is required"
Something to do with the following change?
hAP ac3 , no Lora card, but interested in the MQTT service of IOT.Code: Select all*) lora - moved LoRa service to IoT package;
Seems like in an upgrade bug. I read RN that going forward you use iot.npk for LoRa... but it should still handle if you already had lora.npk installed to upgrade...The update logic got confused, all of LoRa service moved to IoT package ???? or only some parts ????
I probably depends on the monitor.By the way: is it only me, or the text for "Show from which peer route received", on the "v7.1" column is light gray over green - make it quite hard to read?light_grey_over_green.pngOn this page: https://help.mikrotik.com/docs/display/ ... l+Overview
FWIW, the help docs on "Packages" and "Lora" do not reflect this...*) lora - moved LoRa service to IoT package;
FYI ...Already manually removed lora-7.10.2 and iot-7.10.2 . Upgrade to 7.11rc3 done and OK. Will add the new IOT again later. This time there normally is no LoRa package, as the change log it is now part of IOT. But there is a smaller LoRa one in the 7.11rc3 extra packages ZIP file.
The update logic got confused, all of LoRa service moved to IoT package ???? or only some parts ????
Anyway BTH in 7.11rc3 works fine! Very easy to set up. Excellent feature for my short-term holiday travel.
That´s why I asked again. If maybe something is not handled correctly by Mikrotik in the RC-version, to avoid lots of complaints when rolling out stable 7.11. I have not tested if possibly the same behaviour appears on 7.10.2. I use the RC as I have wifiwave2 and I believe the RC-version is more stable still...I had similar situation very annoying...I had teams call and suddenly my new Dell with WiFI 6 disconnected from my hap AX3 and immediately connected to the same WiFI. In log was SA Query timeout. I do not think that this is OK
As MikroTIk fan, this move is 100% approved, BTH is a nice have but pretty sure there is a looong list of things to fix/improve!Obviously BTH is not release-ready yet. And probably stabilizing BTH would take longer time than MT devs would like.
Nice move. I wait for Stable.We had three options - release BTH as is, delay 7.11 stable just due to the BTH or remove BTH. We did choose to remove BTH as we can not call it "stable" yet and move a step closer to 7.11 (stable) for those who do not care about BTH. We would like to call it a win-win. BTH will be back on 7.12, no worries.
I have a feeling that in some cases the renewal of an IPsec ike1 association kills some other associations and triggers a renewal.Minor detail, but I'd argue this was introduced in 7.11beta2 not 7.10 (SUP-122289). Thank you very much for thoroughly diagnosing and fixing the issue.
I have a feeling that in some cases the renewal of an IPsec ike1 association kills some other associations and triggers a renewal.
Did you observe that? It happens in "main" mode so it may not be related to this. What I observe is when a GRE/IPsec tunnel's IPsec is renewed, the L2TP/IPsec from the same remote peer is renewed at the same time. The local address is different for these.
Ok that is interesting, I will try to find an opportunity to upgrade the software on that router and see if it is the same issue. Thanks!In this case, a peer with aggressive mode set would continuously trigger a rekey for *all* other peers/policies (different remote addresses).
Noted that if I choose 2,4 network instead of 5 G - the SA Query Timeout is gone. My 2,4G network has WPA/WPA2 only since I have old devices not supporting WPA 3. Can this be related to WPA3 security?That´s why I asked again. If maybe something is not handled correctly by Mikrotik in the RC-version, to avoid lots of complaints when rolling out stable 7.11. I have not tested if possibly the same behaviour appears on 7.10.2. I use the RC as I have wifiwave2 and I believe the RC-version is more stable still...I had similar situation very annoying...I had teams call and suddenly my new Dell with WiFI 6 disconnected from my hap AX3 and immediately connected to the same WiFI. In log was SA Query timeout. I do not think that this is OK
use disable-pmkid=yesNoted that if I choose 2,4 network instead of 5 G - the SA Query Timeout is gone. My 2,4G network has WPA/WPA2 only since I have old devices not supporting WPA 3. Can this be related to WPA3 security?
That´s why I asked again. If maybe something is not handled correctly by Mikrotik in the RC-version, to avoid lots of complaints when rolling out stable 7.11. I have not tested if possibly the same behaviour appears on 7.10.2. I use the RC as I have wifiwave2 and I believe the RC-version is more stable still...
So are you keeping up your relay ? Or it will be offline until 7.12beta ?
What's new in 7.11rc4 (2023-Aug-11 12:57):
*) bth - removed from 7.11 for "stable" release, the development will continue in "beta" 7.12;
I have set disable pmkid since before. And now removed WPA3. Seems more stable.use disable-pmkid=yes
Noted that if I choose 2,4 network instead of 5 G - the SA Query Timeout is gone. My 2,4G network has WPA/WPA2 only since I have old devices not supporting WPA 3. Can this be related to WPA3 security?