We are pleased to announce that Firmware 8.6.0 is now generally available for production environments.
You can download the firmware from the Firmware Download Page or upgrade directly via InControl Firmware Management.
We are pleased to announce that Firmware 8.6.0 is now generally available for production environments.
You can download the firmware from the Firmware Download Page or upgrade directly via InControl Firmware Management.
GPS location is still not in Incontrol. Ok on router dashboard and gpx file is ok too. But nothing in Incontrol. Tested RC on BR2 and GA on B20X.
Is Wireguard Remote User Access supported on FusionHub? Any limitations?
Was unable to upgrade to 8.6.0 on a MAX Transit Duo Pro.
Received an error on the firmware page “Error: Invalid Storage”.
I submitted Ticket #26071204 for this one.
–
Separately from the above specific device issue… Other device upgrades (different models) also failed several times before being successful… Sometimes I had to reboot the device before the firmware update would succeed.
Thank you!
Matt
What were the other models that you had failures with?
Hi @MichaelG ,
Once I took a closer look, I should clarify my above message - it looks like I have two devices that won’t upgrade to the 8.6 firmware and turns out they are both MAX Transit Duo Pros (experiencing the same “Invalid Storage” error).
The other model I had some difficulty with was a MAX BR2 Pro 5G - but it was a synergized device which might have been a factor in the upgrade experience.
All other models have gone without issue (SDX Pro, MBX Mini, 310X, B One – all good!).
Lost WAN (PHY) connection (Starlink) after upgrade from 8.5.4 to 8.6.0
Reverted back to 8.5.4 and issue persists “No cable detected”
Starlink was “Standing by” in priority 2 at the moment of the upgrade
It was working no changes on cabling.
Any advise?
Thank you for this release I have been waiting for the GA announcement with patients.
Hello,
There is an Important Notice in the release notes for 8.6.0 :
The following models must be upgraded to Firmware 8.5.4 before upgrading to Firmware 8.6.0:
BR: BR1 Pro (CAT-20), BR1 Pro 5G, BR2 Pro
Dome, Transit, B One: All
However, when I click “Check Firmware Upgrade” on a BR2 Pro currently running Firmware 8.2.1, the Web Admin interface directly offers Firmware 8.6.0 as the available upgrade. Could this cause issues?
Hi,
I just tested this on a B One 5G HW2 (Same platform as BR2 Pro 5G) and the device did not came online via the WAN port.
Device was still reachable locally via the WebGUI. Rebooted back to the previous 8.5.0 firmware and device came online again.
Not sure if I was just lucky with being able to go into the local WebGUI, I don’t recommend trying this out.
If you have the devices in the Peplink InControl2 system I would recommend to have a firmware policy groupe wide to upgrade automatically to 8.5.4 and mark the box upgrade only, so any devices that have 8.6.0 or higher in the future will not be downgraded.
Hope this helps. ![]()
@JoeyJanssen I am interested on this. Can you help to download Diagnostic Report when the problem occurs in 8.6.0? Then reboot it back to the previous firmware, turn on RA, and open ticket for us to check?
Thanks.
We seems found a showstopper bug for Chinese users, after we upgrade to 8.6.0, some of users Wechat unable to log in.
All other apps working well but just Wechat showing no internet, we have tested downgrade to 8.5.4 and then Wechat start to work.
Hi Ricardo,
Please create a ticket for support team to review the Balance.
Thank you.
Do someone have problems with users trying to authenticate via RADIUS (EAP-TLS) against a RADIUS SERVER through a Peplink tunnel couldn’t get in after upgrading from 8.5.4 to 8.6.0
Captures on the RADIUS server showed the EAP-TLS handshake getting stuck and restarting over and over, never making it to Access-Accept.
After digging into it, the issue traces back to IP fragmentation of the RADIUS packet that carries the server’s TLS certificate — it doesn’t fit in one UDP datagram and gets fragmented, and something along the path wasn’t handling that correctly.
Downgrading the Peplink from 8.6.0 to 8.5.4 fixed it.
We have a Pep VPN network with multiple locations. Home office has an Asterisk server for SIP phones. The devices and prior firmware are:
B310X home office firmware 8.5.4
Balance One Core firmware 8.5.4
B One firmware 8.5.4
B One firmware 8.5.0
BPL 310 5G firmware 8.4.1
Fusion Hub firmware 8.5.1s
I received the 8.6 firmware announcement. I don’t usually update immediately after firmware is released to see if anyone complains. Not taking my own advice I updated all devices except for the older Balance One that apparently is not eligilble for 8.6. The update went smoothly. All the VPN links are green. No problem accessing the Fusion Hub server which uses https and SSH.
The next morning I began to get complaints from the remote sites that their phones did not work. The devices showed registered but there was no audio. Thats port 5060 UDP. There was no problem at the home site, only the remotes. The only thing the remote sites have in common is the VPN. Connectivity was good but could it be the update?
I rolled back one of the remote sites to the 8.5x firmware. Phones came alive. As I did that to each site the problem went away. The site with the older Balance One also had the problem but cleared up when I rolled back the B310X at the home office where the Asterisk server is located.
There appears to be a problem with 8.6 for SIP through Pep VPN that was not an issue with prior firmware.
Still no GPS location updates in Incontrol dashboard ? Location displayed is the last known.
It has been confirmed with the peplink support (Ticket # 26081099) that there is an issue where, during EAP-TLS authentication, the client’s certificate exceeds the UDP datagram size and gets fragmented; the RADIUS server does not recognize this fragmentation and prevents the connection (in my case, WPA2-Enterprise Wi-Fi). If the system is downgraded to version 8.5.4, the fragmentation issue no longer occurs, and the client can connect to the Wi-Fi.
So if you have this kind of auth via speedfusion tunnels upgrading to 8.6.0 will fail
I believe this is the same issue I reported with random SIP registration failures after core routers upgraded to 8.6.0. Odd thing is we would have only some phones at some locations fail. as in 10-15 remote locations out of 2,000 and at each failed location 2 to 4 out of their 4 or 5 IP phones would fail to register.
I had the same issue with RADIUS Auth, rolled back FW to 8.5.4 and back and working