Almost every SUPEE I reported is at least at the state “we can reproduce in labs. gonna fix - but can’t give ETA right now. thanks”. So IMHO filing a support ticket is worth it. Commenting detailled issues in beta-release threads is kind of wasted time. I hardly doubt that any “loose” failure-description here is picked up by MT-staff at all. Maybe the issues that arise very often in the thread - maybe - but thats it.
Honestly, you just need to provide as much infos as possible so they can reproduce. “it is broken” may not help at all.
I’ve just rebooted and my configuration was wiped. I’m going back to the stable v6 channel. I do have a support ticket open (SUP-58017) for this issues, granted I raised it against 7.1RC1.
Installed 7.1rc1 on a mAP 2nD, that crashed every now and then. Upgraded to 7.1rc2, still crashing.
I did not change any queue settings.
One crash it wiped the configuration, luckily I could load the backup I did just minutes before without issues. No idea though what could have caused the wipe.
on v7.1rc2 restoring configuration from backup is not working if the backup file is password protected, same issue with restoring config files from cloud backup
In such situations you should do a /export of the full configuration and maybe also a backup, install the newer version, and restore the configuration from a local
winbox connected to the MAC address. (so you can wipe it entirely before importing the export)
Remember that importing an export does not restore users and their passwords, and certificates. So when you have them, your safer bet may be via the backup.
Must set the use IPv6 flag in the PPP Profile, also if you enabled default route in the PPPoE login, do not set it in dhcpv6-client.
IPv6 actually works but I also had many problems after migration from v6.
I’m having issues with 6to4 interface. IPv4 packets are somehow assembled (length 2922 bytes) and then rejected with ICMPv6 Packet Too Big.
The tunnel throughput is starting at 900 Mbit and then dropping quickly to no more than 20 Mbps.
It is dependent on the uplink (SFP) and fast path setting (when using switched/bridged port).
Device RB4011, 7.1beta5 to 7.1rc2. Supouts and packet captures sent to support SUP-44956 (updated March, May, August, September).
Currently this ticket is unanswered.
A possible workaround is to create a (dummy) bridge or bonding interface for the wan port (sfp).
After this the throughput is somewhere between 150 Mbps and 400 Mbps.
Any way to get fastpath working on Wireguard tunnels so we can get more performance out of it?
Fastpath works for PPPoE for example, but not for Wireguard?
I know Wireguard uses built-in kernel module, isn’t that fastpath?
Darn, I just was told by support that the backups where broken and are still broken in 6.49beta. This a BIG problem to me and I have to wait for the next version to be able to make a backup that I can use to restore. Till then it is manual importing stuff from a RSC export file if needed.