And this brings back the topic of transparency. Such massive issue should be proactively communicated once detected.
We look like fools (at best) in front of customers. Peplink means reliability on the WAN, this is the opposite of it.
Anyone can make a mistake, we can handle that if informed before customer’s production is impacted. We were looking everywhere for an issue…
Same for the LAN extra latency introduced by the internal switch 
I am not aware of this issue. What is happening?
an issue on the internal switch creates some loops and latency goes through the roof. Very hard to detect for us as only the LAN users are impacted.
Should be solved now.
This was another issue we saw with QOS enabled. After a random amount of time we had several sites report that latency was awful for them accessing the internet. We would test from the device to the internet and see no issue but if we pinged anything on the LAN the latency would be anywhere from 50-2000ms with packet loss.
We deployed 50 devices and saw it on almost all of them, removed QOS and rebooted and the issue hasn’t recurred. The special build we tested with for the random crash seemed to fix the crash but the 2 sites we tested with had the latency issue recur. We have since disabled QOS and have not seen the issue since.
Re creating this though is difficult as it took a couple of week to appear on one site and nearly a month on the other.
Update:
Peplink sent me a firmware (8.5.1s095 build 5810) that addresses the issues with the WAN2 interface.
I deployed this firmware 10 days ago, and it looks like the WAN2 issues have been solved.
I am just waiting for the QoS fixes. I will post an update once I receive the new firmware that addresses QoS specific issues.
Cheers!