Not a quick fix, but if you do run RouterOS x86 you can change to RouterOS CHR (run on VmWare).
fq_codel and cake work brilliantly with flow control on and without a shaper. why turn it off?
I am curious as to what you mean by “without a shaper” - do you mean setting fq_codel or cake as the interface queue? MikroTik abstracts away many of the parts of tc (which I haven’t used on regular Linux, only MikroTik’s abstraction of it), and so I do not have a complete understanding of what “without a shaper” means in this context.
“/tool mac-server set allowed-interface-list=none” doesn’t disable mac telnet until reboot.
Hi All,
HTTPS within the HOTSPOT service doesn’t work anymore.
Upgraded from 6.79.2 to 7.1.1 no changes in already working Hap Lite, now I get Handshake failure.
Downgraded and it works back again.
Hotspot is an issue in general since ROS 7.
I found something weird on my RB750Gr3 running v7.1.1:
when this rule is enabled:
0 ;;; defconf: masquerade
chain=srcnat action=masquerade out-interface-list=internet ipsec-policy=out,none
my pppoe client are stable.
as soon as I disable this rule, that I don’t need, my ppp clients are disconnected after a few seconds, whith this message in the log:
terminating... - peer is not responding
If a re-enable this rule, everything goes back to normal.
forget my previous message: a script couldn’t run without this rule, then believed internet was down and disabled the lan port. my bad.
now it works back with 7.2 rc1.
Other issues with cpu and accessibility preventing me to use that version.
I had a Wireguard problem here, maybe someone can check.
I configured an external paid VPN service. To change the contry the connection output will be, I have to change the endpoint field in the Peer configuration.
The problem is that after changing the endpoint address, the RouterOS ramdomly connect to the old and to the new value.
For example, the endpoint is configured as us.samplevpn.com. I change it to de.samplevpn.com. After that, RouterOS connect to us.samplevpn.com, disconnect and connect to de.samplevpn.com, disconnect and connect to us.samplevpn.com again, and so on…
Rebooting the router after the configuration change fix the problem.
That’s how Wireguard works… If a package with valid authentication from a peer is received the current endpoint address is updated automatically. Generally this is a good think as it help for a stable connection when peers are roaming.
I guess the reboot helps as it clears your tracked connections. I would suggest to try two things here:
- Remove the old connection from tracking (/ip/firewall/connection/) or
- Update the listen port on wireguard interface
Not tested, but either of both should fix the issue.
Could someone please comment on the availability of “Dude Server” in 7.x.x versions?
Thank you,
I have 7.1.1 on RB4011 with CAPS-man - here is some bug with bridge/capsman - any change with bridge (disable port, or change mode to rstp/none) cause almost frozen routerboard, reboot required.
Simple: create bridge with eth ports, create caps-man with datapath add to bridge, then add cap.
without capsman disable/enable bridge, change rtsp etc. works normally, but with bridge/port/dynamic cap interfaces = “death”
tested on latest RC 7 build and same result, on ROS6 - no problem
This configuration was applied on reseted device with v7 - so its no relevant to upg with config from v6 to v7.
I am also having massive performance problems with the RB3011 and RouterOS v7.
Other devices like HAP-AC2 or mAP do not suffer from this.
Not to be too negative though - this is a great release with many desirable features!
Noticed same bug with same setup.
I’m sure they will add defaults for those later. They probably do not consider it to be urgent at this time, and are focusing on fixing a lot of bugs instead of dealing with minor things like this.
.
I have uploaded a VERY strong case on ‘dissapearing items on reboot’ to Mikrotik (SUP-71205). I connected to a RB2011 running 7.1.1, generated a support file, issued a reboot, and mayhen was made: after the reboot, VLAN interfaces were gone, bridge interface was gone, ovpn-client interface was gone, etherNN interfaces that had custom names were all renamed back to etherNN default names (which breaks other things, like pppoe-client that was attached to ether1-EXTERNAL and became attached to no interface after reboot). I had to go physically to that RB to fix it, as the pppoe-client interface, now attached to nowhere, couldn’t connect. While there, downgraded to 6.49.2. When locally on the box, on first access, I created a new support file and uploaded both (before and after reboot) to Mikrotik team, hope they can figure out what’s happening, as I have absolutely no doubt it’s a SEVERE bug, which can render boxes completly down and might require physical access to repair it, just like it happened to me.
Yes it is a nasty issue but it could be easy to fix, maybe it is just a database thing where a transaction is used and it is not always properly committed. It could be a single line fix.
@leonardogyn Firstly well done for catching that rare gremlin with such a precise and correct methodical approach. Could I ask what prompted you to create the supout before the reboot? It’s not like there’s a need to create supouts randomly all the time. I’m guessing something went wrong?
I’m asking because, FWIW, personally I’m not fully convinced that the config loss issue is actually triggered on a reboot. I was once having an issue with a wireguard interface (I can’t remember exactly what the issue was, but something wasn’t saving or taking effect correctly..) So I rebooted, and then afterwards the wg interface was corrupt (I think private key changed to some AAAAAAAAAAAAAAz or something) along with other missing config post-reboot. It’s like the database actually got corrupt while the router was still running, but still “appeared” fine in winbox (some kind of caching maybe?) - until reboot, then the real destruction became clear/apparent. If that’s true, then your “VERY strong case” may not actually even reveal any culprit in spite of your thorough approach, which is even more haunting as to how elusive this bug is. I hope everyone is making regular backups until a definite fix for this appears in the changelogs