Somewhat unbelievably... while 7.13.5 took 14,4 MB of space in hap ac2 - 7.14 has seem to got smaller as used space indicates now 14,3 MB (that with legacy wireless package).Also note that upgrading beyond 7.12.1 can cause issues on ARM devices with "16MB flash", especially for devices that actually have only 15.3MB flash.
So be extra careful when upgrading such a device (e.g. hAP ac2), especially when you cannot easily netinstall it (remote location).
What device this is?What causes this message regarding a backup-routerboot upgrade? Screenshot from 2024-02-29 09-48-58.png
Since 7.14 there is a lot more verbose logging w.r.t. Wireguard in general, not only BTH.Hi,
I have the following wireguard bth info in the log on a hap ax lite LTE 6 and an RB 5009. With version 7.13
was everything OK. A new configuration of Wiregurad BTH does not bring any changes.
But if you ask me, there should also be an 'off' switch for this logging ... haven't found it yet.*) wireguard - optimised and improved WireGuard service logging;
But everything works.19:36:54 script,warning USB device count: 2 >> 3 .id=*1;device=1-0;name=xHCI Host Controller;speed=480;vendor=Linux 5.6.3 xhci-hcd;.id=*2;device=2-0;name=xHCI Host Controller;speed=5000;vendor=
Linux 5.6.3 xhci-hcd;.id=*3;device=1-1;name=FG621 Module;speed=480;vendor=Fibocom
19:37:16 script,warning LTE inteface count: 0 >> 1
In Logging, select info, then add wireguard to it, then add the negative sign to wireguard.I'm getting endless messages 'Handshake for peer did not complete after 5 seconds, retrying (try 2)' in log.
Can you elaborate please ? I don't seem to get it right.In Logging, select info, then add wireguard to it, then add the negative sign to wireguard.
On hapAC2 with wifi-qcom-ac i have 164KiB left. That is very bad :( but it works for now.Old wireless package got smaller but how it is with wifi-qcom-ac? Anyone knows if it is possible to upgrade to 7.14 and how much flash space will be left free afterwards?
I'm getting endless messages 'Handshake for peer did not complete after 5 seconds, retrying (try 2)' in log.
Thx, It worked nicely.System/Logging and open, for example, "info" topic. Add "!wireguard" to it. All info logs, except WireGuard, will be logged now.
*) system - expose "lo" and "vrf" interfaces;
Same problem here. I lost all ethernet devices on one of our CHR after upgrading to 7.14. Provider is running virtualizorAll ethernet interfaces on the CHR machine on the VDSINA hosting are missing. I checked the installation process twice, the ethernet is always lost. I installed 7.13.5, the ethernet is back.
Simple answer yes. RC are not ment for production, do upgrade.I'd like to know, is v7.14rc4 testing and v7.14 stable the same release, except maybe changing the version number and channel? Should I upgrade from v7.14rc4 to this?
sorry, RB960PGS (hEX PoE) r2.What device this is?What causes this message regarding a backup-routerboot upgrade? Screenshot from 2024-02-29 09-48-58.png
Can confirm this, the bug was introduced with 7.14rc2 and is still there. I opened a support ticket for that. They asked me to create and download a supout.rif file. You may create it, but you cannot download it without ethernet interfaces. So that didn't really help. Will wait for a better idea. Guest tools are also no longer recognized, so that must have been substantial changes between 7.14rc1 and the releases after that. Unfortunately I couldn't find anything in the release notes, that would help for a better understanding of that problem.All ethernet interfaces on the CHR machine on the VDSINA hosting are missing. I checked the installation process twice, the ethernet is always lost. I installed 7.13.5, the ethernet is back.
On 7.14 wifi clients can connect to 2.4ghz SSID but DHCP runs into a timeout (and even with static IP no communication possible). Once wifi 5ghz is online (after initial DFS), clients can connect to 5ghz and get IP instantly. But nothing suspicious in the logs.*) bridge - improved protocol-mode STP and RSTP functionality;
*) arm - improved system stability when using microSD on RB1100Dx4;
It seems the issue is that even when the interface of the VPN is added to the VRF via ip->VRF list, the wireguard VPN interface isn't dynamically added to the VRF it was assigned when IP route assignments come up. 7.13.5 It works and behaves as expected, but in this case all wireguard interfaces so matter if they're added to a different VRF or not are dynamically assigned to the main vrf.I noticed that on two L009's I have that VRF's quit working. I had a VRF for a Wireguard VPN service and after upgrade it doesn't seem to function anymore. Downgraded back to 7.13.5 and its back to working normally.
But now on 7.14 the read speed is awful on microSD slot.I can confirm this is fixed on RB1100AHx4 as well.Code: Select all*) arm - improved system stability when using microSD on RB1100Dx4;
On 7.13.5 I had ping losses and reboots when formatting and writing a big file to the microSD slot via Winbox.
On 7.14 I was able to successfully write a file larger than 400 MB.
Thank you!
Why did you upgrade a remote location, just some hour after a new release?HOW to get it working back on remote location!???
Those changes are only in the new 7.14 version, but you have the old one. So you don't yet have the smaller package size. You must upgrade using Netinstall. From then on you will no longer have the issues.*) package - reduced package size for SMIPS
I still cannot ugrade hAP Lite from 7.13 to 7.14 (7.6MiB required, 7.5MiB free, although it's only few kilobytes that are actually missing).
Manual upgrade also won't pass, missing those few kb to upload wireless package.
What is it good for? The lo interface?*) system - expose "lo" and "vrf" interfaces;
Best explanation I could find around here:What is it good for? The lo interface?
The SSID is "jupiter" for both wifis. When I only enable 2.4ghz iface, clients connect but receive no IP address (stuck at "obtaining IP address..."). Reproducible on several devices.On 7.14 wifi clients can connect to 2.4ghz SSID but DHCP runs into a timeout (and even with static IP no communication possible). Once wifi 5ghz is online (after initial DFS), clients can connect to 5ghz and get IP instantly. But nothing suspicious in the logs.*) bridge - improved protocol-mode STP and RSTP functionality;
Then I switched "protocol-mode=rstp" to "protocol-mode=none" on default bridge. Suddenly DHCP and everything else started working on 2ghz as well.
Thank you, it works. Considering how bizarre it works, I'm curious about the reason for enabling this rule by default.In Logging, select info, then add wireguard to it, then add the negative sign to wireguard.
Defaults are not applied by updates. Once you have made a setting it will be saved and restored at reboot, you need to change it to 30 seconds yourself when you want that. New installations will get the new default.*) firewall - increased default "udp-timeout" value from 10s to 30s;
It wasn't applied after the update to v17.14.
Well, I would call it quite irresponsible to install a freshly released 7.xx version at a remote location within a day after release, especially when the same issue was already reported in the release topic...Warning!
CCR2004-pcie doesn't come back after upgrade. it's crazy what You do at mikrotik, to release fw *STABLE* that bricks cloud core unit.
looks like boot-loop.
Defaults are not applied by updates. Once you have made a setting it will be saved and restored at reboot, you need to change it to 30 seconds yourself when you want that. New installations will get the new default.
Have you bothered to actually read the page from the link provided?What causes this message regarding a backup-routerboot upgrade? Screenshot from 2024-02-29 09-48-58.png
edit: Device is RB960PGS (hEX PoE) r2.
It was 7.13 on mine (with 7.8 firmware).Which version you had on CCR2004-1G-2XS-PCIe, before you did update to 7.14 ?
I have Neighbor Discovery enabled on all interfaces, and weird errors stopped appearing for me when I disabled keep-alive on passive peersRegarding "wireguard, debug: Sending handshake initiation to peer (0.0.0.0:0)" on passive peers.
This is just pure speculation and I might be completely wrong; but after some troubleshooting it seems that MNDP might trigger passive WireGuard peers to attempt to establish a connection despite the absence of an endpoint address, hence why the dest-addr is set to 0.0.0.0:0.
You mean, you have a VM and you don't test upgrades by making a copy of your VM before upgrading the router in production? %)I too had an issue with CHR ethernet adapters disappearing after updating from 7.13.5 to 7.14 on a production server times two. 7.14 is supposed to be stable realease? I was prepared with a week old snapshot and suddenly my adapters reappeared.
That has nothing to do with the VPS provider, I have the same problem running a selfhosted xcp-ng installation which worked without any problems since 2 two years until the release of 7.14rc2. You can reproduce the issue easily as follows.@fragtion
Could you please clarify if your VPS provider has made any updates?
7.14 cannot be considered stable, at least not for the CHR image. I have the same issue with all ethernet interfaces disappearing after updating to 7.14rc2 or newer. I did a rollback to 7.14rc1 in my testing environment. In production I still run 7.13.5.I too had an issue with CHR ethernet adapters disappearing after updating from 7.13.5 to 7.14 on a production server times two. 7.14 is supposed to be stable realease? I was prepared with a week old snapshot and suddenly my adapters reappeared.
its distant but not yet on production. frankly speaking it's because I've got problem on it with tagged VLAN, and according to changelogWhy did you upgrade a remote location, just some hour after a new release?HOW to get it working back on remote location!???
You should wait 14 days, read the forum, and then you maybe should upgrade.
Also if its a remote location, you should have an equal local device to test it on first.
7.13.5 as I have on hosting x86.Which version you had on CCR2004-1G-2XS-PCIe, before you did update to 7.14 ?
Downgrading to 7.13.5 fixes the issue also on SSID "jupiter. But still I don't know what causes this. I would suspect RSTP changes - but how can I pin that out?The SSID is "jupiter" for both wifis. When I only enable 2.4ghz iface, clients connect but receive no IP address (stuck at "obtaining IP address..."). Reproducible on several devices.
On 7.14 wifi clients can connect to 2.4ghz SSID but DHCP runs into a timeout (and even with static IP no communication possible). Once wifi 5ghz is online (after initial DFS), clients can connect to 5ghz and get IP instantly. But nothing suspicious in the logs.
Then I switched "protocol-mode=rstp" to "protocol-mode=none" on default bridge. Suddenly DHCP and everything else started working on 2ghz as well.
Then I change the SSID to "jupiter2". Suddenly all clients connect to AP and can obtain an IP.
Now I am completely clueless.
After upgrading to 7.14 again - the issue is gone!!! Magic. Pretty speechless.Downgrading to 7.13.5 fixes the issue also on SSID "jupiter. But still I don't know what causes this. I would suspect RSTP changes - but how can I pin that out?
The SSID is "jupiter" for both wifis. When I only enable 2.4ghz iface, clients connect but receive no IP address (stuck at "obtaining IP address..."). Reproducible on several devices.
Then I change the SSID to "jupiter2". Suddenly all clients connect to AP and can obtain an IP.
Now I am completely clueless.
Still not BQL for RouterOS? I still see poor bufferbloat/CPU usage issues under stress testing. Come on MikroTik, just add BQL support already.*) defconf - use "fq_codel" queue as default interface queue for wired ports on LTE devices;
Then make it, or simply allow official ONIE support on your hardware, we'll flash any OS of choice and get over RouterOS.We can't "Add stuff", we can only "Make stuff"
yesAWS sent me a notification that there is a new ROS Image available, does this mean updates will work now without the Instance type t3 -> t2 -> t3 limbo when freshly deployed?
https://aws.amazon.com/marketplace/pp/p ... gn6js6av54
--Michael
On the all routers (from various vendors) I ever configured you can configure as many loopback interfaces you want, attach them to vrfs and use for various things i.e. iBGP. It does not seem to be case there. and What is a VRF interfaceBest explanation I could find around here:What is it good for? The lo interface?
viewtopic.php?p=943761#p943761
A bit lazy, aren't we ?...and What is a VRF interface
In large organisation with lots of routers (and switches) its normal to set IP on loop back interface so they are more easy to handle.Thank you...until now I did not need it but I have to see it now. It would be better to fix Netwatch/sending notification than add new interface for nothing...
Some kind of mechanism to import/export routes from one vrf to another within same router --> Thanks!RouterOS version 7.14 have been released in the "v7 stable" channel!
What's new in 7.14 (2024-Feb-29 09:10):
Are you in love with Mikrotik hardware so much? So there is a thing by Mikrotik you can't complain about? WowThen make it, or simply allow official ONIE support on your hardware, we'll flash any OS of choice and get over RouterOS.We can't "Add stuff", we can only "Make stuff"
I don't know, but maybe you can tell us a little about your environment. That could help microtik narrow down the problem.Upgraded 10 CHRs without issue... what I did wrong? :-)
I don't have detailed HV information, I'm only a client. I only know that some VMs are run on ProxMox (7.3-6, 7.4-17, 7.4-16, 8.1.4) but have no idea about server or NIC models.tell us a little about your environment
It never is. A new default doesn't overwrite something already set up. This is done on purpose, because the old value worked, and there is a chance the new value will mess with some weird user config.*) firewall - increased default "udp-timeout" value from 10s to 30s;
It wasn't applied after the update to v17.14.
Thanks, that's quite a bit. Do you use any special functions within your CHR routers? How many interfaces do you have connected to them? Can you print the output of the /system/resources/pci section to the thread so we can see what resources are in the VM.I don't have detailed HV information, I'm only a client. I only know that some VMs are run on ProxMox (7.3-6, 7.4-17, 7.4-16, 8.1.4) but have no idea about server or NIC models.tell us a little about your environment
These logs should be in a debug and not an info level.The comment from w0lt was correct. In order to disable specific topic logs, go to System/Logging and open, for example, "info" topic. Add "!wireguard" to it. All info logs, except WireGuard, will be logged now.
Yes, these are new logs, nothing changed in the WireGuard behavior. Same actions simply were not logged before.
What notifications and I don't understand if it's sending or not.Thank you...until now I did not need it but I have to see it now. It would be better to fix Netwatch/sending notification than add new interface for nothing...
OK what hypervisor? Worked fine on Hyper-V.I too had an issue with CHR ethernet adapters disappearing after updating from 7.13.5 to 7.14 on a production server times two. 7.14 is supposed to be stable realease? I was prepared with a week old snapshot and suddenly my adapters reappeared.
/system/resource/pci/print
Columns: DEVICE, VENDOR, NAME, IRQ
# DEVICE VENDOR NAME IRQ
0 00:00.0 Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (AGP disabled) (rev: 3) 0
1 00:07.0 Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev: 1) 0
2 00:07.1 Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev: 1) 0
3 00:07.3 Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev: 2) 0
4 00:08.0 Microsoft Corporation Hyper-V virtual VGA (rev: 0) 11
Thanks, that's quite a bit. Do you use any special functions within your CHR routers? How many interfaces do you have connected to them? Can you print the output of the /system/resources/pci section to the thread so we can see what resources are in the VM.
Columns: DEVICE, VENDOR, NAME
# DEVICE VENDOR NAME
0 00:00.0 Intel Corporation 440FX - 82441FX PMC [Natoma] (rev: 2)
1 00:01.0 Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] (rev: 0)
2 00:01.1 Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] (rev: 0)
3 00:01.2 Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev: 1)
4 00:01.3 Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev: 3)
5 00:02.0 unknown unknown (rev: 2)
6 00:03.0 Red Hat, Inc. Virtio memory balloon (rev: 0)
7 00:05.0 Red Hat, Inc. QEMU PCI-PCI bridge (rev: 0)
8 00:0a.0 Red Hat, Inc. Virtio block device (rev: 0)
9 00:12.0 Red Hat, Inc. Virtio network device (rev: 0)
10 00:13.0 Red Hat, Inc. Virtio network device (rev: 0)
11 00:14.0 Red Hat, Inc. Virtio network device (rev: 0)
12 00:1e.0 Red Hat, Inc. QEMU PCI-PCI bridge (rev: 0)
13 00:1f.0 Red Hat, Inc. QEMU PCI-PCI bridge (rev: 0)
Columns: DEVICE, VENDOR, NAME
# DEVICE VENDOR NAME
0 00:00.0 Intel Corporation 440FX - 82441FX PMC [Natoma] (rev: 2)
1 00:01.0 Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] (rev: 0)
2 00:01.1 Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] (rev: 0)
3 00:01.2 Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev: 1)
4 00:01.3 Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev: 3)
5 00:02.0 unknown unknown (rev: 2)
6 00:03.0 Red Hat, Inc. Virtio memory balloon (rev: 0)
7 00:05.0 Red Hat, Inc. QEMU PCI-PCI bridge (rev: 0)
8 00:12.0 Red Hat, Inc. Virtio network device (rev: 0)
9 00:13.0 Red Hat, Inc. Virtio network device (rev: 0)
10 00:14.0 Red Hat, Inc. Virtio network device (rev: 0)
11 00:15.0 Red Hat, Inc. Virtio network device (rev: 0)
12 00:16.0 Red Hat, Inc. Virtio network device (rev: 0)
13 00:1e.0 Red Hat, Inc. QEMU PCI-PCI bridge (rev: 0)
14 00:1f.0 Red Hat, Inc. QEMU PCI-PCI bridge (rev: 0)
15 01:01.0 Red Hat, Inc. Virtio SCSI (rev: 0)
Columns: DEVICE, VENDOR, NAME
# DEVICE VENDOR NAME
0 00:00.0 Intel Corporation 440FX - 82441FX PMC [Natoma] (rev: 2)
1 00:01.0 Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] (rev: 0)
2 00:01.1 Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] (rev: 0)
3 00:01.2 Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev: 1)
4 00:01.3 Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev: 3)
5 00:02.0 unknown unknown (rev: 2)
6 00:03.0 Red Hat, Inc. Virtio memory balloon (rev: 0)
7 00:05.0 Red Hat, Inc. QEMU PCI-PCI bridge (rev: 0)
8 00:0a.0 Red Hat, Inc. Virtio block device (rev: 0)
9 00:12.0 Red Hat, Inc. Virtio network device (rev: 0)
10 00:13.0 Red Hat, Inc. Virtio network device (rev: 0)
11 00:14.0 Red Hat, Inc. Virtio network device (rev: 0)
12 00:1e.0 Red Hat, Inc. QEMU PCI-PCI bridge (rev: 0)
13 00:1f.0 Red Hat, Inc. QEMU PCI-PCI bridge (rev: 0)
Columns: DEVICE, VENDOR
# DEVICE VENDOR
0 00:00.0 Intel Corporation
1 00:01.0 Red Hat, Inc.
2 00:02.0 Red Hat, Inc.
3 00:02.1 Red Hat, Inc.
4 00:02.2 Red Hat, Inc.
5 00:02.3 Red Hat, Inc.
6 00:02.4 Red Hat, Inc.
7 00:1f.0 Intel Corporation
8 00:1f.2 Intel Corporation
9 00:1f.3 Intel Corporation
10 01:00.0 Red Hat, Inc.
11 02:00.0 Red Hat, Inc.
12 03:00.0 Red Hat, Inc.
13 04:00.0 Red Hat, Inc.
Columns: DEVICE, VENDOR, NAME
# DEVICE VENDOR NAME
0 00:00.0 Intel Corporation 440FX - 82441FX PMC [Natoma] (rev: 2)
1 00:01.0 Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] (rev: 0)
2 00:01.1 Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] (rev: 0)
3 00:01.2 Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev: 1)
4 00:01.3 Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev: 3)
5 00:02.0 unknown unknown (rev: 2)
6 00:03.0 Red Hat, Inc. Virtio memory balloon (rev: 0)
7 00:05.0 Red Hat, Inc. QEMU PCI-PCI bridge (rev: 0)
8 00:0a.0 Red Hat, Inc. Virtio block device (rev: 0)
9 00:12.0 Red Hat, Inc. Virtio network device (rev: 0)
10 00:1e.0 Red Hat, Inc. QEMU PCI-PCI bridge (rev: 0)
11 00:1f.0 Red Hat, Inc. QEMU PCI-PCI bridge (rev: 0)
Columns: DEVICE, VENDOR
# DEVICE VENDOR
0 00:00.0 Intel Corporation
1 00:01.0 Intel Corporation
2 00:01.1 Intel Corporation
3 00:01.2 Intel Corporation
4 00:01.3 Intel Corporation
5 00:02.0 unknown
6 00:03.0 Red Hat, Inc.
7 00:04.0 Red Hat, Inc.
8 00:05.0 Intel Corporation
9 00:06.0 Red Hat, Inc.
10 00:07.0 Red Hat, Inc.
11 00:08.0 Red Hat, Inc.
12 00:09.0 Red Hat, Inc.
13 00:0a.0 Red Hat, Inc.
14 00:0b.0 Red Hat, Inc.
Columns: DEVICE, VENDOR, NAME
# DEVICE VENDOR NAME
0 00:00.0 Intel Corporation 440FX - 82441FX PMC [Natoma] (rev: 2)
1 00:01.0 Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] (rev: 0)
2 00:01.1 Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] (rev: 0)
3 00:01.2 Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev: 1)
4 00:01.3 Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev: 3)
5 00:02.0 unknown unknown (rev: 2)
6 00:03.0 Red Hat, Inc. Virtio memory balloon (rev: 0)
7 00:05.0 Red Hat, Inc. QEMU PCI-PCI bridge (rev: 0)
8 00:12.0 Red Hat, Inc. Virtio network device (rev: 0)
9 00:13.0 Red Hat, Inc. Virtio network device (rev: 0)
10 00:1e.0 Red Hat, Inc. QEMU PCI-PCI bridge (rev: 0)
11 00:1f.0 Red Hat, Inc. QEMU PCI-PCI bridge (rev: 0)
12 01:01.0 Red Hat, Inc. Virtio SCSI (rev: 0)
Columns: DEVICE, VENDOR, NAME
# DEVICE VENDOR NAME
0 00:00.0 Intel Corporation 440FX - 82441FX PMC [Natoma] (rev: 2)
1 00:01.0 Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] (rev: 0)
2 00:01.1 Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] (rev: 0)
3 00:01.2 Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev: 1)
4 00:01.3 Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev: 3)
5 00:02.0 unknown unknown (rev: 2)
6 00:03.0 Red Hat, Inc. Virtio memory balloon (rev: 0)
7 00:05.0 Red Hat, Inc. QEMU PCI-PCI bridge (rev: 0)
8 00:0a.0 Red Hat, Inc. Virtio block device (rev: 0)
9 00:12.0 Red Hat, Inc. Virtio network device (rev: 0)
10 00:13.0 Red Hat, Inc. Virtio network device (rev: 0)
11 00:1e.0 Red Hat, Inc. QEMU PCI-PCI bridge (rev: 0)
12 00:1f.0 Red Hat, Inc. QEMU PCI-PCI bridge (rev: 0)
Columns: DEVICE, VENDOR
# DEVICE VENDOR
0 00:00.0 Intel Corporation
1 00:01.0 Intel Corporation
2 00:07.0 Intel Corporation
3 00:07.1 Intel Corporation
4 00:07.3 Intel Corporation
5 00:07.7 VMware
6 00:0f.0 VMware
7 00:11.0 VMware
8 00:15.0 VMware
9 00:15.1 VMware
10 00:15.2 VMware
11 00:15.3 VMware
12 00:15.4 VMware
13 00:15.5 VMware
14 00:15.6 VMware
15 00:15.7 VMware
16 00:16.0 VMware
17 00:16.1 VMware
18 00:16.2 VMware
19 00:16.3 VMware
20 00:16.4 VMware
21 00:16.5 VMware
22 00:16.6 VMware
23 00:16.7 VMware
24 00:17.0 VMware
25 00:17.1 VMware
26 00:17.2 VMware
27 00:17.3 VMware
28 00:17.4 VMware
29 00:17.5 VMware
30 00:17.6 VMware
31 00:17.7 VMware
32 00:18.0 VMware
33 00:18.1 VMware
34 00:18.2 VMware
35 00:18.3 VMware
36 00:18.4 VMware
37 00:18.5 VMware
38 00:18.6 VMware
39 00:18.7 VMware
40 03:00.0 VMware
41 0b:00.0 VMware
42 13:00.0 VMware
43 1b:00.0 VMware
Columns: DEVICE, VENDOR, NAME, IRQ
# DEVICE VENDOR NAME IR
0 00:00.0 Intel Corporation 440FX - 82441FX PMC [Natoma] (rev: 2) 0
1 00:01.0 Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] (rev: 0) 0
2 00:01.1 Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] (rev: 0) 0
3 00:01.2 Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev: 1) 11
4 00:01.3 Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev: 3) 9
5 00:02.0 unknown unknown (rev: 2) 0
6 00:03.0 Red Hat, Inc. Virtio network device (rev: 0) 11
7 00:04.0 Red Hat, Inc. Virtio memory balloon (rev: 0) 11
search this topic...WUS DIS????
It seems that at least one is running under VMware, the others under KVM. Another user reports that Hyper-V is working. Amazon has updated their CHR image as well, as I noted in this thread. I don't know what they are using in their cloud. I'd also appreciate more feedback from other users to see if it's limited to Xen-based VMs or if KVM and XEN both have issues with it. I'm not sure about that yet. With KVM-based installations, there seem to be working and non-functioning ones. There might be an implication to the Linux kernel of the KVM host. Let's see what feedback we get on this.Thanks, that's quite a bit. Do you use any special functions within your CHR routers? How many interfaces do you have connected to them? Can you print the output of the /system/resources/pci section to the thread so we can see what resources are in the VM.
Well, IMHO it is just a bug. When a wireguard interface is passive, and it receives "interesting traffic to send", it should just do nothing.These logs should be in a debug and not an info level.The comment from w0lt was correct. In order to disable specific topic logs, go to System/Logging and open, for example, "info" topic. Add "!wireguard" to it. All info logs, except WireGuard, will be logged now.
Yes, these are new logs, nothing changed in the WireGuard behavior. Same actions simply were not logged before.
Please explain what you mean. Logging for "debug" is disabled by default, and always has been.Some default debug filters not being applied to log entries.
I saw them for wireguard, DHCP, DNS, NTP. All silent now.
Example which wasn't there before moving from 7.14rc3 to 7.14.Please explain what you mean. Logging for "debug" is disabled by default, and always has been.
Did you create a log rule for "debug" and does it behave different now?
Please clarify if this means ONLY new 7.14 AWS T3 instance can be updated going forward.yesAWS sent me a notification that there is a new ROS Image available, does this mean updates will work now without the Instance type t3 -> t2 -> t3 limbo when freshly deployed?
https://aws.amazon.com/marketplace/pp/p ... gn6js6av54
--Michael
I just upgraded to 7.14 and got the same. Wireguard is DEADHi,
I have the following wireguard bth info in the log on a hap ax lite LTE 6 and an RB 5009. With version 7.13
was everything OK. A new configuration of Wiregurad BTH does not bring any changes.
A new wg configuration from scratch did the trick. I've deleted peer and wg interface and created new wg interface and peer, reassigned ip and set again interface in fw rulesI just upgraded to 7.14 and got the same. Wireguard is DEADHi,
I have the following wireguard bth info in the log on a hap ax lite LTE 6 and an RB 5009. With version 7.13
was everything OK. A new configuration of Wiregurad BTH does not bring any changes.
*) package - reduced "wireless" package size for ARM, ARM64, MIPSBE, MMIPS devices;
Read the first messages from this topic. It's a function, but can be disabled.my hap ac3 upgraded to 7.14 during the night.
since then a logging rule (wireguard,info) spamming the log about "Handshake for peer did not complete" for a client that doesn't connect. which is fine, but the rule is disabled, has been for a long time. I even deleted it since, but it still spams the log.
That might explain why I was not seeing this flood while I have passive Wireguard peers configured - I did not have persistent keepalive enabled on them as it did not make sense to me to have keepalive set on "responder" side (even if this kind of configuration is technically possible).Regarding the "Handshake for peer did not complete" log messages from WireGuard... I confirmed that these were coming from my passive peer entries where I had configured a persistent keepalive. The keepalive configuration was the "trigger". Removing that keepalive stopped the messages. The remote client can still have its own keepalive configured, and should if it is connecting outward and/or inward through a connection-tracking firewall, and the client-side keepalive should be sufficient to keep the connection tracking active.
It could be argued that it is a WireGuard (or MiktoTik) bug to be attempting a keepalive when no endpoint is configured and no connection exists. But removing the keepalive configuration is an easy workaround without disabling the logging of other WireGuard,info events.
Hello dude, escuse me, me too, after install my wireguard connections Dead, i use it for a simple vpn with proton service, but fail after it, are you sure for this think, the error is for the update 7.14?.I just upgraded to 7.14 and got the same. Wireguard is DEADHi,
I have the following wireguard bth info in the log on a hap ax lite LTE 6 and an RB 5009. With version 7.13
was everything OK. A new configuration of Wiregurad BTH does not bring any changes.
I have passive peers without keepalive configured and I still saw a bunch of these. They weren't incessant, but they randomly came up in clusters. I ended up filtering them in the log settings for now.That might explain why I was not seeing this flood while I have passive Wireguard peers configured - I did not have persistent keepalive enabled on them as it did not make sense to me to have keepalive set on "responder" side (even if this kind of configuration is technically possible).Regarding the "Handshake for peer did not complete" log messages from WireGuard... I confirmed that these were coming from my passive peer entries where I had configured a persistent keepalive. The keepalive configuration was the "trigger". Removing that keepalive stopped the messages. The remote client can still have its own keepalive configured, and should if it is connecting outward and/or inward through a connection-tracking firewall, and the client-side keepalive should be sufficient to keep the connection tracking active.
It could be argued that it is a WireGuard (or MiktoTik) bug to be attempting a keepalive when no endpoint is configured and no connection exists. But removing the keepalive configuration is an easy workaround without disabling the logging of other WireGuard,info events.
No, BTH worked every update until now...@gigabyte091,
Have you tried deleting BTH and recreating it?
Same here. All peers lack any persistent keepalive setting, all disabled.I have passive peers without keepalive configured and I still saw a bunch of these. They weren't incessant, but they randomly came up in clusters. I ended up filtering them in the log settings for now.
That might explain why I was not seeing this flood while I have passive Wireguard peers configured - I did not have persistent keepalive enabled on them as it did not make sense to me to have keepalive set on "responder" side (even if this kind of configuration is technically possible).
In my experience it all comes down (or goes up) with good configuration. Had to do some tweaking, enabling debug logging for wireless did provide a lot of useful information (specifically identifying the iPhone 11 having difficulties with both WPA2-PSK and WPA3-PSK enabled). If you search for SA Query on this forum you will find more information.What is going on??
I dont have a Keepalive configured, but a Gateway-Check "Ping" under routes for a few Wireguard-Peers.The keepalive configuration was the "trigger". Removing that keepalive stopped the messages.
I had to edit the "Connect Priority" thing.. It will make your WiFi vulnerable to the MacStealer'-attack.Log is flooded with SA Query timeouts. Clients have terrible experience using wifi. What is going on??
/system reset-configuration keep-users=yes run-after-reset=
I'm using same device as yours, but continued to use "wireless" package and actually gain 36KiB (500KiB -> 536KiB free) after upgrading from 7.13.5 to 7.14.Irony was lost when I migrated from wireless package to this wifi-qcom-ac*) package - reduced "wireless" package size for ARM, ARM64, MIPSBE, MMIPS devices;
Ran a wifi scan on 2.4Ghz to check the frequency and compare with between phone and laptop - chateau seized up and had to cut the power as connectivity was lost, replugged into mains again, storage went to 0 so have zero free space - have opened support ticket to find out how to clean up (what I suspect was probably a temp file in /tmp somewhere or a core dump)The gain was minimal. The default package increased ins same size as wireless package shrunk down.
Had similar issues with 7.13.x thats why I give up on new ac drivers and continue to use legacy, maybe your configuration is smaller and you are able to use ac on 7.13, but I doubt that as newer ROS releases arrives that you will able to continue to use it on this device unless some changes on ROS are made to offload storage (more packages).chateau seized up and had to cut the power as connectivity was lost, replugged into mains again, storage went to 0 so have zero free space - have opened support ticket to find out how to clean up (what I suspect was probably a temp file in /tmp somewhere or a core dump)
I fear, that since the introduction of the wireless package vs wifi-qcom-ac et al, implies that certain 16Mb storage devices with wireless are getting deprecated in favour of the newer drivers, and newer models.Had similar issues with 7.13.x thats why I give up on new ac drivers and continue to use legacy, maybe your configuration is smaller and you are able to use ac on 7.13, but I doubt that as newer ROS releases arrives that you will able to continue to use it on this device unless some changes on ROS are made to offload storage (more packages).chateau seized up and had to cut the power as connectivity was lost, replugged into mains again, storage went to 0 so have zero free space - have opened support ticket to find out how to clean up (what I suspect was probably a temp file in /tmp somewhere or a core dump)
Unfortunately they are not even doing THAT.I fear, that since the introduction of the wireless package vs wifi-qcom-ac et al, implies that certain 16Mb storage devices with wireless are getting deprecated in favour of the newer drivers, and newer models.
End result is they will get left behind with a version of v7 nd not eligible for newer upgrades. They may well stop dev efforts on the wireless package completely, its going to happen soon.
How the hell did you update hAP Lite ? I'm missing few kilobytes to be able to squeeze in ROS and wirless package.This update is full of bugs, I have to reset hAP Lite every 2 hours to reach normal speed.
Confirmed, downgraded back to 7.13.5 for now. Did you file a ticket?It seems the issue is that even when the interface of the VPN is added to the VRF via ip->VRF list, the wireguard VPN interface isn't dynamically added to the VRF it was assigned when IP route assignments come up. 7.13.5 It works and behaves as expected, but in this case all wireguard interfaces so matter if they're added to a different VRF or not are dynamically assigned to the main vrf.
This is the exact reason why Mikrotik need implement OOB (Out of Band Management - IPMI/Redfish) interface - Its subsystem that independent from main OS, where you can remotely recover/reinstall/reboot the hardware. The same as the SNMP-card in the UPS system.Warning!
CCR2004-pcie doesn't come back after upgrade. it's crazy what You do at mikrotik, to release fw *STABLE* that bricks cloud core unit.
looks like boot-loop.
HOW to get it working back on remote location!???
+1Handshake for peer did not complete after 5 seconds, retrying (try 2)
Handshake for peer did not complete after 5 seconds, retrying (try 2)
Handshake for peer did not complete after 5 seconds, retrying (try 2)
+1, the same by me
Disable wireguard logging and stop bitching.+1Handshake for peer did not complete after 5 seconds, retrying (try 2)
Handshake for peer did not complete after 5 seconds, retrying (try 2)
Handshake for peer did not complete after 5 seconds, retrying (try 2)
+1, the same by me
is very, very annoying especially with road-warrior type wireguard connections.
People will still hit the upgrade button YOLOmove this version to v8
+čit will be much MUCH better for MT to name this release v8
after all, wireless packages are radically changed, ROS does not fit anymore on old devices, many bugs, etc ...
anybody who work with relative stable 7.12.2, and blindly push update button, will be in big big trouble
so, please MT
move this version to v8
it does not seems right that this version have same V7 name with so many breaking changes
I guess, you don't need anymore work around "absense" of loopback and create bridge "Loopback" and can assign loopback address directly on the lo interface, i.e.What is it good for? The lo interface?expose "lo" interface
Mine AC2 is OK, do netinstall....Hello, after install on hap ac2 7.14 I have no free space. (with 7.13.1 it was about 2%) ; now, when I make some change and restart Mikrotik, the changes miss, even deleting unused FW rules, disabling resource gaphing and queue
MK just should separate some other packages which usually home users dont use (as. dot1X, PPP; MPLS and Radius)
This is my hap ac2 with wifi-qcom-ac and also docker package: How do you have 356 KiB with only ros and wifi-qcom-ac using netinstall?For the hAP ac2 I used netinstall. Free onboard flash space (with wifi-qcom-ac instead of wireless) is down to about 356 KiB (versus 7.13.5 at around 635 KiB).
Fingers crossed that MT can opensource their code to allow for improvements - or open up the bootloader to allow for likes of openwrt etc to be easily installed on the devices. More likely until hell freezes over :)Unfortunately they are not even doing THAT.I fear, that since the introduction of the wireless package vs wifi-qcom-ac et al, implies that certain 16Mb storage devices with wireless are getting deprecated in favour of the newer drivers, and newer models.
End result is they will get left behind with a version of v7 nd not eligible for newer upgrades. They may well stop dev efforts on the wireless package completely, its going to happen soon.
The reasonable move would be to declare 7.12.1 to be a long-term version that is supplied with security updates for a year or two, so in the meantime we can replace our 16MB ARM devices.
But no, in the event that a critical security vulnerability is found in 7.12.1 those devices immediately become useless.
I am not asking for any policy changes, only for long-term support of the 7.12.x version.Fingers crossed that MT can opensource their code to allow for improvements - or open up the bootloader to allow for likes of openwrt etc to be easily installed on the devices. More likely until hell freezes over :)
it IS disabledDisable wireguard logging and stop bitching.
+1
is very, very annoying especially with road-warrior type wireguard connections.
Apparently, my configs with NFS got migrated to nfs-sharing=yes at some point – seem to work as I didn't notice till just now. But doc do show nfs-export=yes...update Did I understand correctly that they forgot to update the documentation? The code is now like this — /disk set usb1 nfs-sharing=yes
RouterOS also supports older SMB without ROSE package - SMB with legacy protocol support.
The same problem here.All ethernet interfaces on the CHR machine on the VDSINA hosting are missing. I checked the installation process twice, the ethernet is always lost. I installed 7.13.5, the ethernet is back.
But it's not listed on: https://help.mikrotik.com/docs/display/ROS/Peripherals*) lte - added "at-chat" support for Sierra Wireless EM9293 5G modem;
That a passive peer (without endpoint) constantly tries to perform a handshake, transmitting data to nothing, just because it has a 0.0.0.0.0/0 in the allowed address, which is what is happening. This behavior is irregular, and is a bug to be fixed.Disable wireguard logging and stop bitching.+1
is very, very annoying especially with road-warrior type wireguard connections.
mAP AX in mAP Lite package, don't think so.
Thermal issues.
mAP package/size, maybe... that would be very sweet.
No, in my experience it affects eoip and ipip tunnels too.I hope it's limited to only wireguard interfaces.
Exactly, I think the same.Wireguard behavior is not the problem.
The all of a sudden excessive logging is.
This is debug and by default it should be off.
Same with dns, ntp, dhcp... I've seen it all pass by.
what kind of NIC you have ? my i350,i210/i211 on 7th gen intel working again after 7.12/7.13 bug> *) x86 - fixed VLAN tagged packet transmit for igb (introduced in v7.12);
Unfortunately this had not been fixed. My VLANs at IGB and x86 not work at all :(
That a passive peer (without endpoint) constantly tries to perform a handshake, transmitting data to nothing, just because it has a 0.0.0.0.0/0 in the allowed address, which is what is happening. This behavior is irregular, and is a bug to be fixed.
Disable wireguard logging and stop bitching.
You seem to be contradicting yourself. Which one is it?Exactly, I think the same.Wireguard behavior is not the problem.
The all of a sudden excessive logging is.
This is debug and by default it should be off.
Same with dns, ntp, dhcp... I've seen it all pass by.
Connect Priority 0/1 does not help in any way. I set it on all APs and still see those SA timeouts in the log.I had to edit the "Connect Priority" thing.. It will make your WiFi vulnerable to the MacStealer'-attack.Log is flooded with SA Query timeouts. Clients have terrible experience using wifi. What is going on??
MT screwed up the WiFi totally and the network is unuseable with this "security" feature turned on (default). And left you either with an unusable network or a vulnerable network - good job MT... viewtopic.php?t=198228#p1016424
Can you post an example?Wireguard behavior is not the problem.
The all of a sudden excessive logging is.
This is debug and by default it should be off.
Same with dns, ntp, dhcp... I've seen it all pass by.
device changed by admin
device changed by winbox-3.40/tcp-msg(winbox):admin@x.x.x.x (
/interface set ether9 disabled=no l2mtu=1596 mtu=1500 name=ether9; /interface ethernet set [ find ]
advertise=10M-baseT-half,10M-baseT-full,100M-baseT-half,100M-baseT-full,1G-baseT-half,1G-baseT-full
arp=enabled arp-timeout=auto auto-negotiation=yes combo-mode=auto disabled=no fec-mode=off l2mtu=1596
loop-protect=default loop-protect-disable-time=5m loop-protect-send-interval=5s mtu=1500
name=ether9 rx-flow-control=off sfp-rate-select=low tx-flow-control=off; /queue interface set ether9
)
I am not contradicting myself (if you had tried it you would understand). I keep insisting that it makes no sense for the passive peer without endpoint to constantly try to handshake, it's a debugging problem not a wireguard interface problem. If you don't understand it is your problem.You seem to be contradicting yourself. Which one is it?
Yes, but only log the actual change, not every single argument that /interface/set takes and the user didn't touch.I actually think that logging of changes is great! Especially when you have an external log server, you can check when something was changed and by whom.
Yet again, that behaviour described by you is not a MikroTik problem, but a WireGuard "problem", not something that MikroTik should address.I am not contradicting myself (if you had tried it you would understand). I keep insisting that it makes no sense for the passive peer without endpoint to constantly try to handshake, it's a debugging problem not a wireguard interface problem. If you don't understand it is your problem.You seem to be contradicting yourself. Which one is it?
[admin@MikroTik] > /interface/set ether9 disabled=yes
device changed by winbox-3.40/tcp-msg(winbox):admin@x.x.x.x/terminal/action:0 (/interface set ether9 disabled=yes; /interface ethernet set [ find ] disabled=yes; /queue interface set ether9)
device changed by winbox-3.40/tcp-msg(winbox):admin@x.x.x.x (/interface set ether9 disabled=yes l2mtu=1596 mtu=1500 name=ether9; /interface ethernet set [ find ] advertise=10M-baseT-half,10M-baseT-full,100M-baseT-half,100M-baseT-full,1G-baseT-half,1G-baseT-full arp=enabled arp-timeout=auto auto-negotiation=yes combo-mode=auto disabled=yes fec-mode=off l2mtu=1596 loop-protect=default loop-protect-disable-time=5m loop-protect-send-interval=5s mtu=1500 name=ether9 rx-flow-control=off sfp-rate-select=low tx-flow-control=off; /queue interface set ether9)
viewtopic.php?p=1059747#p1059747Can you post an example?Wireguard behavior is not the problem.
The all of a sudden excessive logging is.
This is debug and by default it should be off.
Same with dns, ntp, dhcp... I've seen it all pass by.
I don't see any difference (besides wireguard) on my logs with v7.14.
Please contact support and add the supout.rif file from your system.> *) x86 - fixed VLAN tagged packet transmit for igb (introduced in v7.12);
Unfortunately this had not been fixed. My VLANs at IGB and x86 not work at all :(
I have the same problem and opened a support ticket for that. Today I got the following information from the mikrotik Support: "We have managed to reproduce the issue locally in our labs and look forward to fixing it on upcoming RouterOS versions, unfortunately, I cannot provide a release date now."The same problem here.All ethernet interfaces on the CHR machine on the VDSINA hosting are missing. I checked the installation process twice, the ethernet is always lost. I installed 7.13.5, the ethernet is back.
I have several xcp-ng (XEN) servers with different host OS version running multiple CHRs.
After upgrade to 7.14 CHR can not detect any network interfaces, but in list for IRQs I can see vif0-q0-rx, vif0-q0-tx.
The latest "working" version is 7.13.5.
After rolling back to 7.13.5 and restoring from a backup, the CHR starts working normally
Can we be sure if Winbox saves/overwrites all this values or they are just "read out" to be saved in log message? If values are actually overwritten then it is possible for them to change if defaults are changed (and therefore applied?) after upgrade to newer version and that can also bring unwanted side-effects with it. If it is just related to logging then it just is misleading and confusing - but unwanted in both cases...Nope. That is what I am pointing out for years already. Winbox touches everything - now you even have the proof logged 🤣. Even can add arguments that were not there before (in the export). Dumbly saving of all form values - even if they are default values. Thats why I do not use winbox, because I dont like side effects.
That would require support in winbox ... either "winbox default config" (which would then depend on winbox version) or winbox would be able to read (and interpret) device's default config (which means building in interpreter of default config ... which winbox currently may not have, changing of settings may not depend on ability to parse and interpret random configuration lines).If values are actually overwritten then it is possible for them to change if defaults are changed ...
Well that can be debated, probably it was too much effort to keep the before-state and compare it with the after-state and log only the changed values. Would all take extra code, and we already are short on storage space.Yes, but only log the actual change, not every single argument that /interface/set takes and the user didn't touch.I actually think that logging of changes is great! Especially when you have an external log server, you can check when something was changed and by whom.
Default system logging should be made non intrusive not allowing one topic excessive logging imo. I see the point of info topic being accustomed by using !wireguard condition as wrong aproach.The comment from w0lt was correct. In order to disable specific topic logs, go to System/Logging and open, for example, "info" topic. Add "!wireguard" to it. All info logs, except WireGuard, will be logged now.
Yes, these are new logs, nothing changed in the WireGuard behavior. Same actions simply were not logged before.
Yes, that would be valuable. Sometimes it is difficult to find what the default value is for a parameter that has been changed at some time, and a separate widget near every field to "reset to default" could be nice.What IMO could be done is that winbox would be able to show defaults (if applicable) so one could apply them by hand if deemed fit.
I agree with that. This is just a log that should have been suppressed in the code (don't ever log connection attempts when the interface is configured as passive, even when there is outgoing traffic)Default system logging should be made non intrusive not allowing one topic excessive logging imo. I see the point of info topic being accustomed by using !wireguard condition as wrong aproach.
Apparently the problem is that Winbox, while it knows what has changed on each window (since each modified field becomes blue), when you hit apply, it sends EVERYTHING, instead of only the options that have changed.Well that can be debated, probably it was too much effort to keep the before-state and compare it with the after-state and log only the changed values. Would all take extra code, and we already are short on storage space.
Yes, but only log the actual change, not every single argument that /interface/set takes and the user didn't touch.
Without that, I like it that they added this logging because it provides some traceability of changes made, and alerts to changes made outside of the admin's intention.
I've installed 7.14 on multiple routers with multiple archs and I cannot confirm this behavior on any of them.viewtopic.php?p=1059747#p1059747
Can you post an example?
I don't see any difference (besides wireguard) on my logs with v7.14.
NTP, DNS, DHCP, ... all debug info now all of a sudden visible in log files.
Probably when using CLI it will also log everything when you send it everything...Apparently the problem is that Winbox, while it knows what has changed on each window (since each modified field becomes blue), when you hit apply, it sends EVERYTHING, instead of only the options that have changed.
As I said, through CLI, the new logging, is how one would expect it, so the problem is actually with winbox, instead of logging.
Well, you've reverse engineered Winbox? coolThe winbox GUI presents you with a panel with all possible settings, reads the existing values in it and then you can change them and submit the whole thing. There is no way to submit individual fields.
Can you provide the output ofviewtopic.php?p=1059747#p1059747
Can you post an example?
I don't see any difference (besides wireguard) on my logs with v7.14.
NTP, DNS, DHCP, ... all debug info now all of a sudden visible in log files.
/system/logging/print
Of course it will. That's the whole point. Log the stuff you change, not EVERYTHING. If you change 100 options, then by all means log all those 100 options.Probably when using CLI it will also log everything when you send it everything...Apparently the problem is that Winbox, while it knows what has changed on each window (since each modified field becomes blue), when you hit apply, it sends EVERYTHING, instead of only the options that have changed.
As I said, through CLI, the new logging, is how one would expect it, so the problem is actually with winbox, instead of logging.
WinBox already knows exactly which fields has been changed before you hit apply.The winbox GUI presents you with a panel with all possible settings, reads the existing values in it and then you can change them and submit the whole thing. There is no way to submit individual fields.
No ambiguity at all.So this before/after thing could be done inside winbox. But it could introduce new issues when there are two winbox sessions open at the same time (two admins) and changes are being made to the same item. As it is now, the last one wins. With the above solution, the result could be ambiguous.
Same. And it also causes a kernel panic in the host everytime it "reboots".Warning!
CCR2004-pcie doesn't come back after upgrade. it's crazy what You do at mikrotik, to release fw *STABLE* that bricks cloud core unit.
looks like boot-loop.
HOW to get it working back on remote location!???
Dumbest I've heard. Can't even imagine Cisco or Juniper putting out a stable release that bricks the product.Well, I would call it quite irresponsible to install a freshly released 7.xx version at a remote location within a day after release, especially when the same issue was already reported in the release topic...Warning!
CCR2004-pcie doesn't come back after upgrade. it's crazy what You do at mikrotik, to release fw *STABLE* that bricks cloud core unit.
looks like boot-loop.
Also, as mentioned many times before, the label "stable" refers to the stability of the release process, not to the stability of operation.
When you require stability of operation, always wait for the 7.xx.1 version and do not install it within a week of release.
But you pay 3 times the money for a comparable product. Your decision.Dumbest I've heard. Can't even imagine Cisco or Juniper putting out a stable release that bricks the product.
They can only compete in the home to small business segment and for nice special features like wireguard. For other areas they're not cheap anymore. Bought a new Cisco Nexus router/switch a month ago, 48 x 10/25Gbps + 6 40/100Gbps ports. Closest Mikrotik comes is the CRS512 which is more expensive and has less ports.But you pay 3 times the money for a comparable product. Your decision.Dumbest I've heard. Can't even imagine Cisco or Juniper putting out a stable release that bricks the product.
Came here to reply the same issue is happening to us where we have IP services in VRF.In addition to the bug reported about IPIP interfaces not working correctly with VRF, also IP service does not work fine with VRF anymore.
I have IP service www on VRF and does not respond to requests anymore, while all is fine with 7.13.5
Yes, a button/switch would be nice.The ccr2004-pcie should not even have been released with a reset button that needs you to open the server up.
sudo echo "1" > /sys/bus/pci/devices/<id>/remove
sudo echo "1" > /sys/bus/pci/rescan
lspci
That's interesting. The cheapest Switchzilla Nexus with 48 x 10/25Gbps + 6 40/100Gbps I'm aware of is more than 10'000€...Bought a new Cisco Nexus router/switch a month ago, 48 x 10/25Gbps + 6 40/100Gbps ports. Closest Mikrotik comes is the CRS512 which is more expensive and has less ports.
I have the same question.After upgrading a ccr1009 and a ccr1036 EOIP and IPIP interfaces, tho under the the ip/vrf menu did appear in the correct vrf, in reality the addresses and directly connected networks became part of the "main" vrf.
Downgrading to 7.13.5 solved the issue.
I have no fan control at all after this 7.14 update. The fan of my CRS310-1G-5S-4S+IN runs with annoying maximum speed and reports ~+-13000rpm regardless which settings i put in the health settings menu. CPU temp was 39°C and Board around 33°C with default settings for the temperature control.- changed default "fan-min-speed-percent" from 0% to 12%;
- improved fan control on CRS3xx and CCR1016-12S-1S+r2;
*) system - fixed "cpu-frequency" for CRS3xx ARM devices;
If that is true, it explains quite a lot of these "issues" we always see when new release comes out. One other thing might contribute to "breakages" as well - RouterOS does not seem to have any control over how objects can be handled i.e. you can add the bridge or any other non-physical interface and build many things around it and then you still can just delete this object outright which can leave many things in broken state - if I deal with Fortigate then I can only remove objects after all other references to it are already removed (interface is not in any firewall policies or have any other related objects attached to it).I have seen (in the past) photos of a "test lab" that they use to test new versions.
The main problem is that they test mainly with "default config" so many other configs and features are not tested...
(and they never discovered that storage is running out on 15.3MB devices because in default config it does not yet happen)
Then you probably upgraded from a quite old version. Always mention your previous version.Hi,
On my RB5009UPr+S+IN the upgrade went fine.
Only one strange thing, after reboot my active interfaces without POE devices were red, "PoE out status: short circuit"...
I think they are hoping that putting out beta and rc versions results in reports from users in the field about new problems.If that is true, it explains quite a lot of these "issues" we always see when new release comes out.I have seen (in the past) photos of a "test lab" that they use to test new versions.
The main problem is that they test mainly with "default config" so many other configs and features are not tested...
(and they never discovered that storage is running out on 15.3MB devices because in default config it does not yet happen)
That is true, but I have never encountered a situation where that lead to real problems.One other thing might contribute to "breakages" as well - RouterOS does not seem to have any control over how objects can be handled i.e. you can add the bridge or any other non-physical interface and build many things around it and then you still can just delete this object outright which can leave many things in broken state
Yes but we can not be sure about all possible side effects of these inconsistencies might have with any possible combinations of correct or incorrect base configurations anybody might have. Object with inconsistencies can be deleted but not everyone is able or interested in sanity checking for these inconsistencies - which might have a potential to introduce post-upgrade breakages. We have inherent weakness here and can not be sure what "under-the-hood" problems could possibly be introduced by that.That is true, but I have never encountered a situation where that lead to real problems.
Usually what you see is that an object that references a deleted object gets some nasty comment associated with it, it becomes non-functional, and you can still delete that object. Also, when you do an export you get a reference starting with "*".
When I make an export after lots of changes I usually check if there is any "*" in it.
All you get is a broken config, not "inherent weakness". RouterOS, as general practice, never deletes config you added. e.g. if you delete something like a VLAN, you don't want the DHCP server necessarily being removed (and that then begs question should /ip/pool linked to dhcp-server be delete too?). Often you delete some "parent" config, to only then add some replacement back & easier to rewire the "dependent" items to new parent.Object with inconsistencies can be deleted but not everyone is able or interested in sanity checking for these inconsistencies - which might have a potential to introduce post-upgrade breakages. We have inherent weakness here and can not be sure what "under-the-hood" problems could possibly be introduced by that.Also, when you do an export you get a reference starting with "*".
Can't. And ditto. If I need a loopback, I'll create one :)How do i delete loop back interface? i am not interested in
it was, is and always will be thereHow do i delete loop back interface? i am not interested in
Then you have not worked with Cisco enough. I've hit bugs which brought down both RPs/Supervisors and got them into bootloop. Don't even get me started on having to slide the line card out of chassis to access console on some Cisco boxes, which triggers spanning-tree convergence. Not something you want if that is in your core.Dumbest I've heard. Can't even imagine Cisco or Juniper putting out a stable release that bricks the product.
Well, I would call it quite irresponsible to install a freshly released 7.xx version at a remote location within a day after release, especially when the same issue was already reported in the release topic...
Also, as mentioned many times before, the label "stable" refers to the stability of the release process, not to the stability of operation.
When you require stability of operation, always wait for the 7.xx.1 version and do not install it within a week of release.
1. Stable should mean they tested it on all their products that supports upgrading to that version.
2. If the issue was mentioned for a beta version then of course it should be fixed before releasing a stable version.
3. If the problem was known and not fixed the software should not allow the upgrade.
Side note. The ccr2004-pcie should not even have been released with a reset button that needs you to open the server up.
Didn't say Cisco/Juniper don't have tons of bugs but I've never come across a "recommended release" that does not allow the product to boot after upgrade. Especially now in recent years when there's an impact/compability check etc before upgrading.Then you have not worked with Cisco enough. I've hit bugs which brought down both RPs/Supervisors and got them into bootloop. Don't even get me started on having to slide the line card out of chassis to access console on some Cisco boxes, which triggers spanning-tree convergence. Not something you want if that is in your core.
Dumbest I've heard. Can't even imagine Cisco or Juniper putting out a stable release that bricks the product.
1. Stable should mean they tested it on all their products that supports upgrading to that version.
2. If the issue was mentioned for a beta version then of course it should be fixed before releasing a stable version.
3. If the problem was known and not fixed the software should not allow the upgrade.
Side note. The ccr2004-pcie should not even have been released with a reset button that needs you to open the server up.
Ok but that is where you are going wrong. The MikroTik release tag "stable" does not make it a "recommended release".Didn't say Cisco/Juniper don't have tons of bugs but I've never come across a "recommended release" that does not allow the product to boot after upgrade. Especially now in recent years when there's an impact/compability check etc before upgrading.
If this is what Mikrotik definition of "stable" really is, please modify winbox UI on "Check For Updates" so we can have option to pick wich version that we want to install/upgrade to. Currently, winbox UI only give us option to upgrade to the latest version. Even worse for arm device, we only have version 7.X (latest) as an option.Ok but that is where you are going wrong. The MikroTik release tag "stable" does not make it a "recommended release".Didn't say Cisco/Juniper don't have tons of bugs but I've never come across a "recommended release" that does not allow the product to boot after upgrade. Especially now in recent years when there's an impact/compability check etc before upgrading.
Even "long-term" doesn't do that. You need extra research to know if a certain release is recommended for installation.
Ahhh i've just had the same thing happen :/On my CHR system on Vultr, after upgrading from version 7.13.5 to 7.14, the Ethernet card disappeared. This issue had never occurred with previous upgrades, so I didn't have a backup. I had to log in to the console to create a backup, then boot into another Linux CD to copy the backup out. I attempted to downgrade to 7.13.5, trying various methods to incorporate the 7.13.5 npk file, but during the downgrade, it showed that it didn't recognize the installation package. I then tried to install a fresh version of 7.14, but the Ethernet card still didn't appear. Eventually, I had no choice but to reinstall 7.13.5 and restore the configuration.Fortunately, I succeeded.
SOLVED in 7.15beta6That a passive peer (without endpoint) constantly tries to perform a handshake, transmitting data to nothing, just because it has a 0.0.0.0.0/0 in the allowed address, which is what is happening. This behavior is irregular, and is a bug to be fixed.
Several users have already reported that this situation was abnormal. Thanks MikroTik.*) wireguard - do not attempt to connect to peer without specified endpoint-address
On my CRS354 I went from the ancient, pre-March 2024 release of 7.13.5 all the way up to 7.14 and saw the same thing on a bunch of ports that have otherwise been working fine for months.Then you probably upgraded from a quite old version. Always mention your previous version.Only one strange thing, after reboot my active interfaces without POE devices were red, "PoE out status: short circuit"...
You can go to interfaces->ethernet and open each interface and set PoE to "off" where you do not require it.
Yes, I switched to "testing" branch first time in years. 7.13 was already tough to swallow and then 7.14. Now I go YOLO as testing branch has the fixes first. LOLThere's a new stable in the beta channel.
Well, I bought a couple of RB5009UPr+S+IN this week and they came with 7.8 and did not issue this message.On my CRS354 I went from the ancient, pre-March 2024 release of 7.13.5 all the way up to 7.14 and saw the same thing on a bunch of ports that have otherwise been working fine for months.
Then you probably upgraded from a quite old version. Always mention your previous version.
You can go to interfaces->ethernet and open each interface and set PoE to "off" where you do not require it.
cries into his 16Mb flashEvery channel feels like YOLO with MikroTik, that's why it's so exciting to manage MikroTik devices.
FYI - rebooted device, system refused to come back online as there was 0 bytes.Upgraded Chateau LTE12 to v7.14, bit shocked to see the storage size plummet from 420k approx to this.
wifi-qcom-ac and routeros?
chateau_v714.png
Irony was lost when I migrated from wireless package to this wifi-qcom-ac
*) package - reduced "wireless" package size for ARM, ARM64, MIPSBE, MMIPS devices;
I had the same issue. The public key got changed after upgrading to 7.14 and I lost remote access.In addition to the logs issue, one of a few WG peers lost its public key. The one I found when I started to investigate the loss of connection was not the same one I put there about a week ago.
I've used a Mikrotik LTE device to provide OOB management for remote sites. You can even Netinstall this way provided you have prepared this in advance and have a way to power cycle the device which can also be done remotely with the right hardware.This is the exact reason why Mikrotik need implement OOB (Out of Band Management - IPMI/Redfish) interface - Its subsystem that independent from main OS, where you can remotely recover/reinstall/reboot the hardware. The same as the SNMP-card in the UPS system.
"Netinstall" is not a solution for "off-site" recovery.
Have an RB750UP and experienced the same issue. IP stack appears to have some sort of regression, although unable to determine root cause. I was able to connect to router via winbox, but not much else was working (dhcp client or server not giving or receiving IP address).Well, the first victim RB750Gr3 runs fine with 7.14 around a week, but after today's planned reboot didn't comes up... at remote site without people
Can you check the log for the remote device?For a few days, I've been noticing freezes/crashes on one of my cAP ax. Not sure what's going on there. Log on CAPsMAN only says "disconnected abc@aa:bb:cc:dd:ee:ff, connection interrupted". Powercycling brings the device back for a couple more hours. This certainly didn't happen on 7.13.5. Any ideas?
Disabling logging isn't actually the responsible action here, as you can miss important entries, but there might not be a better interim solution. But in any case it should be temporary.Disable wireguard logging and stop bitching.
Yet it is something that Mikrotik *have* fixed in an upcoming BETA. 🤷♂️Yet again, that behaviour described by you is not a MikroTik problem, but a WireGuard "problem", not something that MikroTik should address.
What MikroTik is doing with the logs provided by WireGuard is a MikroTik problem.
You seem the be the one not understanding .. something. Sorry, probably not your fault.
Leaving it as open ended question - where did it go?
I regularly upgrade my devices, and this has been happening since the second last release. No big upgrade jump.Then you probably upgraded from a quite old version. Always mention your previous version.Hi,
On my RB5009UPr+S+IN the upgrade went fine.
Only one strange thing, after reboot my active interfaces without POE devices were red, "PoE out status: short circuit"...
You can go to interfaces->ethernet and open each interface and set PoE to "off" where you do not require it.
No graphing enabled.Leaving it as open ended question - where did it go?
Do you have graphing enabled? It may consume some permanent storage space and starts from 0 after netinstall (upgrade doesn't wipe it though).
Do you have any address lists being built up? If entries don't have timeout set, they are considered permanent and thus stored in permanent configuration database (increasing storage requirements).
I'm pretty sure there are other activities which (initially? during first few days of operation?) use up additiobal flash space.
Keeping track of storage since I updated it and it has not changed, I have the graphics active but in memoryFYI - rebooted device, system refused to come back online as there was 0 bytes.Upgraded Chateau LTE12 to v7.14, bit shocked to see the storage size plummet from 420k approx to this.
wifi-qcom-ac and routeros?
chateau_v714.png
Irony was lost when I migrated from wireless package to this wifi-qcom-ac
Ran a netinstall which cleared out the space by reformatting flash drive.
This is result
2024-03-08_19-17.png
Can someone please confirm my suspicion that when a device gets power cut off (intentionally or unintentionally) that it dumps some temporary file somewhere and does not get cleaned up.
More likely core dump which was what killed the storage space?
No cleanup due to power cut: that's possible.Can someone please confirm my suspicion that when a device gets power cut off (intentionally or unintentionally) that it dumps some temporary file somewhere and does not get cleaned up.
It seems like MikroTik is aiming to enter the brick industry. They have been increasingly producing more bricks lately.Yet another bricked hAP ac2 at the remote location while upgrading from 7.13.4.
This can be configured in system/routerboard from memory.I want to point out that after the failed update Mikrotik went into netboot mode on its own, and I didn't have to explain to my mom how long she need to hold down the Reset button =)