The crashes appear to be related to thoughput (so maybe a memory leak?).
We had the master in an HA pair crash and reboot 2 hours after doing the update, and then as we got into a higher volume period (a call center with a lot of SIP traffic) the restarts of the master became more frequent.
I rolled back to the previous firmware and it resolved the issue.
I was on firmware v8.0 before…
After about 7 or 8 days the Internet slows to a craw, I get lots of packet loss, and logging into the web interface of the Peplink takes forever to navigate between pages. After rebooting the device, it’s fine again (for about 7 days)
This is a brand new unit that shipped with v6.x firmware and I immediately upgraded to v8.0 cause that’s what it told me. I have only 1 WAN connection I’m throttling. Frustrating that now I can’t revert back to a stable/well-tested version???
Just upgraded to 8.0.1 now, we’ll see if it’s any better.
Model: Peplink Balance One Core
Product Code: BPL-ONE-CORE
Hardware Revision: 1
Serial Number: 192C-7253-xxxx
Given the issues being faced on firmware 8.0.1, it would suggest that the devices should not be upgraded immediately. What is the recommendation when upgrading the firmware e.g. allow for x days before upgrading?
Hello Everyone,
We have several customers already running on FW 8.0.1 GA release. We have had a diverse array of Peplink & Pepwave systems running previously 8.0.1 RC4 and every issue we have faced got successfully addressed. If anything the 8.0.1 FW has helped to highlight other problems with third-party equipment and services.
Several of our customers are, during this weekend, transitioning to the 8.0.1 GA release, the bulk of the remainder is scheduled for next weekend.
With the amount of security and performance changes from 8.0.0 to 8.0.1 (you can see these in the release notes), our customers will also be upgraded to maintain optimal security and stability on their networks.
Note: Our customers will all be using InControl2 to do the FW upgrades.
Looks like Peplink team has agreed my 6-7 day reboots are a software issue present on both 8.0 and 8.0.1. I previously was able to achieve 30+ day uptime on 7.x and would only reboot for firmware updates.
Those facing the same issue as me, it might be helpful if they have more log data? If so, you can submit a ticket and reference my existing ticket # 9090643 and post your ticket # here. It sounds like they haven’t been able to completely isolate the issue just yet and they keep taking log data.
I joyfully loaded up 8.0.1 build 1469 on to my SURF SOHO HW3. Initially my iPhone 8+ connected okay but then I started to have problems. Reviewing my notes it may have been due to setting the country code so I could access unused channels. Set to US and it connects okay. Set it to something else and the phone could see it but would not connect reliably. Back to 8.0.0 build 1429 (US) and smooth sailing.
It seems like if you connect initially with the radio set to US it can find it. Initial connections should be attempted with US and then you can change the country after the client acclimatizes? At the time of this writing the iPhone (iOS 13.1.3) has an update to iOS13.2 queued so maybe that’s the problem.
Hi. There are two reasons to correctly tell the router or WAP which country you are in: (1) so as to comply with ITU allocations and national regulations regarding frequency use, and (2) so the frequencies used by the router/WAP are coincident with those used by subscriber devices or clients (e.g., your iPhone).
Imagine a situation where you tell the router/WAP to use a channel for which your phone is incapable – by design – of using. Or, the router/WAP chooses such a channel if set on “auto.” The two will probably never connect.
A great many clients are designed to be “market specific” and will only operate on the channels authorized in that jurisdiction – period.
So, what happens when you tell your SOHO that you are, in fact, in Canada? Any joy?
I couldn’t find it either, but from re-reading the release notes it would appear as though this is managed from InControl (which we don’t use, so I can’t confirm whether or not the settings are there).
Has any consideration been given to allowing the user to bypass the required credential change?
Many Value Added Resellers will do firmware updates, license key installations, and configurations prior to sending devices to their end users. Having to set a password will be an inconvenience to these partners and the value they are adding to the channel.
Lots of current and long time Peplink users already have passwords implemented across all their deployed devices that may not fit the criteria that are now in place for the password that will require them to change all passwords when they may not wish to.
A few options that may address the need for security while still allowing for currently used or default passwords could be:
a) Instead of forcing the password to be changed, a banner could be displayed across the bottom of the dashboard similar to the remote assistance, disabled health check, beta firmware expirations etc.
b) Offer the ability to bypass changing the password. Maybe an option to either dismiss changing the password altogether, and another that would prompt again the next time a login is made.
c) Include the ability for a customer to acknowledge that their password doesn’t meet criteria for a secure password, but continue to allow any password that the user would wish to use. This way a customer
Thanks Rick-DC. Apologies to all IT professionals I am just a home user experimenting with and testing the SURF SOHO for security purposes - see post script.
The iPhone 8+ will connect to any frequency this router puts out under 8.0.0 build 1429 (surf SOHO) but not 8.0.1 build 1469. I use test gear to make sure it is compliant with EIRP and local regulations. I was only testing the new firmware and have rolled back to 8.0.0 build 1429 for smooth trouble free operation.
I think I will wait and let a few revisions come out before going any further. Even without testing the country codes to see what frequencies it covered it was having trouble connecting clients using the old configuration file. Doing a factory reset and reconfiguring from scratch seemed to correct it but I’m done for now. Good luck early adopters! I found this handy guide to the Wi-Fi channels on Wikipedia:
What I really want to know is how to configure protected management frames. I saw the option under security settings for the SSID but it would not save the settings I gave it. The iPhone 8+ is WPA3 compliant but I don’t see WPA3 as an option in the new firmware yet. Have a good one guys! Looking good!
happysurfer
ps
Per my PM there are a few Pineapples (or KALI distros) running in my neighborhood (verified with KISMET) so the PEPWAVE SURF SOHO has helped make my life easier since its so easy to reconfigure after a denial of service (DEAUTH / SSID SPOOF) attack. I tried experimenting with switching channels to unused space etc. to try and avoid these problems (skiddies/creepy landlord/ crazy neighbor/ criminals) but the 802.11abcdefg / WPA2 standard is like swiss cheese from a security standpoint / not tamper resistant. Hopefully the consortium responsible for the protocol develops something hack proof but WPA3 is already full of holes since they never consulted developers and security experts on it.
The ancient computer laws here in Canada (circa 1986 or something) are inadequate and outdated. These types of offences would mean certain jail time or actual criminal charges in other countries with nice permanent criminal records to go along with them. I have experienced over 5-10 years of deauth attacks and getting rooted until I upped my game by getting a SURF SOHO. If PEPWAVE can develop any tools to help mitigate these issues I would be eternally grateful! Disclaimer: one type of pineapple attack DOS’s the client by spoofing the SSID with a null MAC = the problem is with the client (which won’t reconnect without a new password or new network) not the AP. The SURF SOHO is so hard to hack I almost feel bad for would be attackers. Multiple isolated hidden WLAN’s have made them really have to work for it / try to listen for client PR’s. Client PR’s was resolved by turning unused clients off.
Protected management frames 802.11w came out in 2009 so I am really looking forward to it. Have a great day guys!
Since updating to firmware 8.0.1 our two 710 units keep transition from master to slave. Djisconnecting all three wans. Didn’t seems to happen on v8 and never in version 7 unless necessary.
