The fq_codel type is set for wired (Ethernet, SFP) interfaces in order to reduce bufferbloat. No interface queue for LTE interface itself.
Can’t find corresponding lines in /system/default-configuration/print
/queue type add name=fq-codel-ethernet-default kind=fq-codel fq-codel-ecn=no
/queue interface set [find default-queue=only-hardware-queue] queue=fq-codel-ethernet-default
thanks!
hmm, since we already have Loopback interfaces, maybe “soon” we will also see VTI interfaces
I don’t want to get my hopes up. I’ve only been requesting VTI since 2009…
next to loopback interfaces tab, we have also vrf interfaces tab .. ?! what the heck ?
VRF HW forwarding support for CRS3xx/5xx and CCR2116/2216 incoming ?
There’s a bug in bridge where a port role is blank in CHR and hapac2 in my limited testing at least
Tell me please, what are the advantages of a “exposed lo” interface over the old way?
Tell me please, what are the advantages of a “exposed lo” interface over the old way?
One example is you don’t need to create a dummy bridge interface when terminating an EoIP tunnel at the router. Or anything that needs an IP set on a non-physical interface on the router itself. Correct me if I’m wrong.
Tell me please, what are the advantages of a “exposed lo” interface over the old way?
I seen mention that it potentially can fix issue with MPLS VPN4 security firewall bug.
After updating to v7.14beta3, I noticed that my hAP ac3 is reverting vlan-mode settings in /interface/ethernet/switch/port to vlan-mode=disabled instead of the vlan-mode=fallback that was set before. This is happening on every reboot, even after setting to vlan-mode=fallback again.
Hi and thanks for the feedback! We have reproduced the issue and will fix it in the next version.
Just notice push route is in the ovpn server setting not per secret/user basis? I hope MT would make it more flexible
Yes, openvpn in Linux is still far more flexible, with CCD and the ability to push any configuration, not only routes. Still it’s progressing quite fast on Mikrotik, so I hope it will become as complete and flexible as it’s in Linux.
Since RouterOS 7.7 we can use diffie-hellmann group 31:
*) ike2 - added support for DH Group 31 (EC25519) (CLI only);
The support is limited to ike2 / phase-1, could you please also bring this to ipsec / phase-2?
Is your crypto stack already able to support DH-32 (Curve448)? This would also be a great addition.
http://forum.mikrotik.com/t/v7-13-5-stable-is-released/171923/135 / SUP-137799
Not fixed in this build.
*) api - improved REST API stability when processing invalid requests;
This type of changes line usually involves a security or availability problem. What is the CVE ID?
Suggestion: can the 4 “FP” counters be removed from the default colums shown in winbox?
These were probably added when someone was very proud of having Fast Path, but they are not very relevant anymore.
And those who want to see them can always use the column selector to enable them again…
next to loopback interfaces tab, we have also vrf interfaces tab .. ?! what the heck ?
And both are spelled in lowercase, while other interface types have a capital first letter and VRF is spelled all-caps in other places.
That can be improved…
*) ssh - refactored SSH service internal processes;
Does this include fixes for CVE-2023-48795 - or is RouterOS already not vulnerable?
*) iot - fixed modbus partial frame reception issue;
*) iot - improved modbus Tx/Rx switching behaviour;
Upgraded KNOT working as Modbus TCP-to-RTU gateway, fingers crossed…
Still seeing some occasional timing issue when Modbus TCP requests arrive too fast after the previous one - worked around for now by adding usleep(10000) before making a new request in my application using libmodbus. Just 10ms is sufficient, when reduced to 3ms the issue occurs very rarely which seems consistent with the 3-character delay (at 9600 bps) Modbus RTU uses to detect end of frame, 1ms is clearly not sufficient. Most often this occurs when there is a write and then a read, write succeeds but the subsequent read fails as if there was RS485 bus contention when started too early.
Suggestion: can the 4 “FP” counters be removed from the default colums shown in winbox?
These were probably added when someone was very proud of having Fast Path, but they are not very relevant anymore.
And those who want to see them can always use the column selector to enable them again…
I do agree. That would be the right thing to do. I always hide them. And now I know that FP in the column name stands for FastPath
Thanks.