Firmware 8.1.0 Beta 2

We’re happy to announce that the Firmware 8.1.0 Beta 2 is now available.

Supported models:
X Series, Balance, MAX, SpeedFusion Engine, FusionHub, Surf SOHO

Download Release Notes

Download the Beta Firmware

4 Likes

Hi,
thanks for this new beta release! :slight_smile:

Question: How can I set these options via WebUI on my Balance One?

21683 [OpenVPN] Custom DNS Servers in LAN DHCP Server can now be pushed to client
22145 [AP Controller] Added support for 802.11k neighbor report base on Wireless SSIDs

Please add hd 1 dome to the list.

1 Like

Hi @Jonathan_Pitts - I’ve been informed that the HD2 Dome Firmware also works for the HD1 Dome Link > Here <

I hope this helps,

Steve

2 Likes

Can the Trans MAX (cat 18/MAX-TST-GLTE-G-T-PRM) version run this Beta software? I checked the documentation and it does not mention this version specifically and did not include recent patch fix pushed for us. I do not want to somehow brick the device.

1 Like

@MobileHopeful, are you running a special firmware (eg. 8.0.2sXXX) on your device (MAX-TST-GLTE-G-T-PRM)? Can you share the firmware version with us to cross-check?

1 Like

@WeiMing
8.0.2s122 build 4468

Let me know what else you need.

@MobileHopeful, the fixes in 8.0.2s122 should be included in firmware 8.1.0 Beta 2. You may want to give it a try and let us know the outcome. If the 8.1.0 Beta 2 doesn’t work out as it is, you can revert to current firmware via System > Reboot, then select 8.0.2s102.

1 Like

Hi, since beta 2 the WAN1 port of my balance one has problems with Link Speed negotiations with a Telekom DSL Speedport Hybrid (DSL + LTE) router. Tries several minutes until the link is established. Setting it to a fixed speed doesn’t help, as it does not establish the link, analogously. Seems like the balance is restarting the port several times until it get‘s it up running after a reboot.
No problem with the previous firmware 8.0.2.

Surf SOHO MK3. Loaded this beta (had not tried the first one). I changed one of my wireless nets from wpa2, to wpa2/wpa3, to test that out. It is worth noting that this particular network is always “hidden”. I then killed the original (wpa2) network on my laptop, and reconnected using wpa3. Later, I hibernated that laptop (Windows 10x64, fully updated), like I do each evening, but when I powered it up the next day, it did not automatically reconnect to the network, as it has always done prior to this change. Even though that is the default WiFi connection on the laptop, I now have to re-authenticate.

So… I find it hard to imagine that WPA3 standards require a re-authentication in this scenario, which leads me to wonder if something in the new Peplink code, required to support WPA3, has unintentionally broken the original functionality? Hopefully someone can check that out.

2020/06/01 update: I switched back to the same settings I was using, before the FW update, i.e. simply selecting WPA2 (only) in the SOHO, and then re-joined that (hidden) network again, from my laptop, so that my laptop configuration would also be the way it was before the upgrade. None of that helped, I still (now) have to re-join my hidden network, each day, when I power up from its hibernated state. It still “feels like” something was broken in the new code, which is causing this behavior.

@ckirch, I don’t see the reported issue from my Balance One. Below is the log. It takes 10++ seconds to connect the WAN with 8.0.2 and 8.1.0b02.

Jun 01 04:58:21 System: Started up (8.0.2s052 build 4438)
Jun 01 04:58:34 WAN: WAN 1 connected (192.168.52.85)
Jun 01 05:10:21 System: Started up (8.1.0b02 build 4906)
Jun 01 05:10:38 WAN: WAN 1 connected (192.168.52.85)

I believe the problem is related to the connectivity between Balance One and the ISP router. I suggest open ticket for us to take a closer look.

Dear @TK_Liew,
ticket is already under investigation by support. :wink:
Dear @Serenity,
I am facing connection issues with WPA2/WPA3 with new beta fw 2, Fast Transition on, Mac Filter on (deny all except…) for a SSID connected to VLAN, too. Seems to happen, too, when time scheduler turns of SSID over night (not AP!).
Support is investigating, but it is not deterministically reproducable, unfortunately.
I found turning off „fast transition“ helps, usually.