@netravnen, thanks for letting us know. The PTP for CCR2116 devices will be available starting from v7.16.
Well, generally that is what is referred to as “the loopback address”.
But in certain circles, certainly the users of OSPF, it is popular to refer to “the loopback address” as a unique address put on each router to have a static and unique address on each router, which is beneficial to the stability/managability of the routing protocol.
As in this case the change log entry is related to the routing, I am not at all surprised that people are confused.
Hello,
I have to say that after the update my WIFI devices connect much much much better!!! I have three cAPGi-5HaxD2HaxD
Roaming also works better now.
Devices that previously only knew 2 GHz now connect stably to 5 GHz
@ Mikrotik Support - really GREAT WORK!!!
But one device (a Samsung washer) cannot log into the WIFI network. It couldn’t do that in any of the older versions either.
Here is a log from 25 seconds:
# 2024-05-31 10:16:46 by RouterOS 7.15
# software id = UGTZ-ZKF4
#
08:50:35 wireless,info 88:57:1D:4C:9A:B1@A6-CAPax--KG-FL--2-GHz-6 connected, signal strength -47
08:50:35 dhcp,info dhcp-VLAN32 assigned 10.18.32.51 for 88:57:1D:4C:9A:B1 Samsung-Washer
08:50:35 script,info DHCP2DNS: registering static domain name Waschmaschine-Samsung-KG-Kueche.32.hnet for address 10.18.32.51 with ttl 00:05:00
08:50:35 system,info static dns entry added by script:dhcp-lease-script (*30BE3 = /ip dns static add address=10.18.32.51 comment=#DHCP disabled=no name=Waschmaschine-Samsung-KG-Kueche.32.hnet ttl=5m)
08:50:37 wireless,info 88:57:1D:4C:9A:B1@A6-CAPax--KG-FL--2-GHz-6 disconnected, connection lost, signal strength -47
08:50:40 wireless,info 88:57:1D:4C:9A:B1@A6-CAPax--KG-FL--2-GHz-6 connected, signal strength -48
08:50:40 dhcp,info dhcp-VLAN32 deassigned 10.18.32.51 for 88:57:1D:4C:9A:B1 Samsung-Washer
08:50:40 script,info DHCP2DNS: removing static domain name(s) for address 10.18.32.51
08:50:40 system,info static dns entry removed by script:dhcp-lease-script/action:5804 (/ip dns static remove *30BE3)
08:50:40 dhcp,info dhcp-VLAN32 assigned 10.18.32.51 for 88:57:1D:4C:9A:B1 Samsung-Washer
08:50:40 script,info DHCP2DNS: registering static domain name Waschmaschine-Samsung-KG-Kueche.32.hnet for address 10.18.32.51 with ttl 00:05:00
08:50:40 system,info static dns entry added by script:dhcp-lease-script (*30BE4 = /ip dns static add address=10.18.32.51 comment=#DHCP disabled=no name=Waschmaschine-Samsung-KG-Kueche.32.hnet ttl=5m)
08:50:42 wireless,info 88:57:1D:4C:9A:B1@A6-CAPax--KG-FL--2-GHz-6 disconnected, connection lost, signal strength -48
08:50:46 wireless,info 88:57:1D:4C:9A:B1@A6-CAPax--KG-FL--2-GHz-6 connected, signal strength -48
08:50:46 dhcp,info dhcp-VLAN32 deassigned 10.18.32.51 for 88:57:1D:4C:9A:B1 Samsung-Washer
08:50:46 script,info DHCP2DNS: removing static domain name(s) for address 10.18.32.51
08:50:46 system,info static dns entry removed by script:dhcp-lease-script/action:5805 (/ip dns static remove *30BE4)
08:50:46 dhcp,info dhcp-VLAN32 assigned 10.18.32.51 for 88:57:1D:4C:9A:B1 Samsung-Washer
08:50:46 script,info DHCP2DNS: registering static domain name Waschmaschine-Samsung-KG-Kueche.32.hnet for address 10.18.32.51 with ttl 00:05:00
08:50:46 system,info static dns entry added by script:dhcp-lease-script (*30BE5 = /ip dns static add address=10.18.32.51 comment=#DHCP disabled=no name=Waschmaschine-Samsung-KG-Kueche.32.hnet ttl=5m)
08:50:48 wireless,info 88:57:1D:4C:9A:B1@A6-CAPax--KG-FL--2-GHz-6 disconnected, connection lost, signal strength -47
08:50:52 wireless,info 88:57:1D:4C:9A:B1@A6-CAPax--KG-FL--2-GHz-6 connected, signal strength -47
08:50:53 dhcp,info dhcp-VLAN32 deassigned 10.18.32.51 for 88:57:1D:4C:9A:B1 Samsung-Washer
08:50:53 script,info DHCP2DNS: removing static domain name(s) for address 10.18.32.51
08:50:53 system,info static dns entry removed by script:dhcp-lease-script/action:5806 (/ip dns static remove *30BE5)
08:50:53 dhcp,info dhcp-VLAN32 assigned 10.18.32.51 for 88:57:1D:4C:9A:B1 Samsung-Washer
08:50:53 script,info DHCP2DNS: registering static domain name Waschmaschine-Samsung-KG-Kueche.32.hnet for address 10.18.32.51 with ttl 00:05:00
08:50:53 system,info static dns entry added by script:dhcp-lease-script (*30BE6 = /ip dns static add address=10.18.32.51 comment=#DHCP disabled=no name=Waschmaschine-Samsung-KG-Kueche.32.hnet ttl=5m)
08:50:55 wireless,info 88:57:1D:4C:9A:B1@A6-CAPax--KG-FL--2-GHz-6 disconnected, connection lost, signal strength -49
08:50:59 wireless,info 88:57:1D:4C:9A:B1@A6-CAPax--KG-FL--2-GHz-6 connected, signal strength -46
08:50:59 dhcp,info dhcp-VLAN32 deassigned 10.18.32.51 for 88:57:1D:4C:9A:B1 Samsung-Washer
08:50:59 script,info DHCP2DNS: removing static domain name(s) for address 10.18.32.51
08:50:59 system,info static dns entry removed by script:dhcp-lease-script/action:5807 (/ip dns static remove *30BE6)
08:50:59 dhcp,info dhcp-VLAN32 assigned 10.18.32.51 for 88:57:1D:4C:9A:B1 Samsung-Washer
08:50:59 script,info DHCP2DNS: registering static domain name Waschmaschine-Samsung-KG-Kueche.32.hnet for address 10.18.32.51 with ttl 00:05:00
08:50:59 system,info static dns entry added by script:dhcp-lease-script (*30BE7 = /ip dns static add address=10.18.32.51 comment=#DHCP disabled=no name=Waschmaschine-Samsung-KG-Kueche.32.hnet ttl=5m)
Is there anything you can do about it?
Best regards Jörg
Nice work!
But, after rebooting the router, the adlist does not load again and it stops working.
Also please specify what memory is used at the moment of adlist loading. I noticed that at the moment of booting, the number in the Sector write since reboot has been increased
In here: https://help.mikrotik.com/docs/display/ROS/User#User-Privatekeys
you say the private key supports both PEM and PKCS#8 format.
But in fact , 7.15 can only import ED25519 private key in PKCS#8 format, no PEM .
The signal range does nothing, as you allow it “ALWAYS” to be out of range. So whatever the signal range is, this rule will work…
"allow-signal-out-of-range (time period | ‘always’)
The length of time which a connected peer’s signal strength is allowed to be outside the range required by the signal-range parameter, before it is disconnected.
If the value is set to ‘always’, peer signal strength is only checked during association."
https://help.mikrotik.com/docs/display/ROS/WiFi#:~:text=allow-signal-out-of-range%20(,strength%20is%20only%20checked%20during%20association.
A similar change is needed for the “Tx Power” column, currently there are two columns with the same name which results in empty data if you reopen the WiFi window.
There are many such cases in RouterOS/Winbox! There really should be someone who walks along all property lists and weeds them out.
FWIW upgraded home capsman setup with RB5009 / AX3 / AX2 / AXLite and a separate mAP.
No problems on any of those devices.
Not even with positive signal levels 
Turn off fast roaming support… that usually fixes connection problems for old or simple devices.
You can create another SSID for only those devices and leave fast roaming on the primary network.
I observed this positive signal thing already some time ago on 7.13. http://forum.mikrotik.com/t/positive-signal-level-in-wifi-registration-table/174490/1
The Big OISD recommended list consumes ~ 31 MB of ram.
Hi,
i know this is kind of cosmetic.
Some time ago i filed SUP135576. It was closed with the answer, that this behavior will be fixed in some upcoming version. Unfortunately it seems to persist in this Version.
I think /ping and traceroute should behave like in other OSs so troubleshooting will be more straight forward. And the response is also kind of false.
Since ping can do IPv6 a AAAA should be a appropriate record.
Currently its like this:
[johann@hap1] > :put [:resolve ipv4.ipv64.net]
144.76.85.238
[johann@hap1] > :put [:resolve ipv6.ipv64.net]
2a01:4f8:192:1326::bad:c0de
[johann@hap1] > ping ipv4.ipv64.net
SEQ HOST SIZE TTL TIME STATUS
0 144.76.85.238 56 56 72ms269us
1 144.76.85.238 56 56 72ms587us
2 144.76.85.238 56 56 72ms662us
sent=3 received=3 packet-loss=0% min-rtt=72ms269us avg-rtt=72ms506us max-rtt=72ms662us
[johann@hap1] > ping 2a01:4f8:192:1326::bad:c0de
SEQ HOST SIZE TTL TIME STATUS
0 2a01:4f8:192:1326::bad:c0de 56 58 17ms516us echo reply
1 2a01:4f8:192:1326::bad:c0de 56 58 17ms93us echo reply
2 2a01:4f8:192:1326::bad:c0de 56 58 17ms252us echo reply
sent=3 received=3 packet-loss=0% min-rtt=17ms93us avg-rtt=17ms287us max-rtt=17ms516us
[johann@hap1] > ping ipv6.ipv64.net
invalid value for argument address:
invalid value of mac-address, mac address required
invalid value for argument ipv6-address
failure: dns name exists, but no appropriate record
[johann@hap1] >
Thank you very much for looking into this and the awesome work in this release.
*) smb - do not allow setting empty “comment” or “domain” properties;
Does this include fix to SUP-146116 (RB5009 crashes when accessing SMB share)?
Setting signal-range=-75..120 should solve the problem
I am surprised that people do not have that already. In the manual it says that the default range is -120..120 so I would expect that one starts from there.
However, there appears to be a (new?) bug as now, when creating a new access rule with signal level, the initial range is 0..0.
That is of course not good. It looks like this bug was introduced with the wifi-qcom drivers.
!) system - added support for AMPERE (R) and ARM64 CHR installations (new ARM64 CHR image available);
→ So ROS will run on Raspberry Pi? That would be nice
i updated some CRS-317 switches from 7.12.1 to 7.15 without problem, and enabled qos-hw-offloading just to see the counters with default configuration and all good
but
One switch which had the following ACL on interface towards provider cease to forward traffic on that interface after enabling qos-hw-offloading
/interface ethernet switch rule
add dst-mac-address=01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF new-dst-ports="" ports=sfp-8 switch=switch1
started to show sfp-8:0 discarding sfp-8:0 learning in logs
just disabling qos-hw-offloading issuing the following command solves the situation
interface/ethernet/switch/set qos-hw-offloading=no switch1
sorry i dont tried removing that ACL to test, but thats the only relevant difference in config between the switch which presented the issue and other switch
As long as your R Pi runs a hypervisor (CHRs run as virtual machines, not on bare metal).