Under Feature Improvement, Reference 21609 says “Added WPA3 Support”. I tested 8.1 beta 4 on a Surf SOHO HW2 and when creating a new SSID the UI has not changed from firmware 7.1.2 or 8.0.2.
Should there be a visible UI change?
Is WPA3 only on the MK3 version of the Surf SOHO?
Thanks.
2 Likes
@Michael234, you are right, the WPA3 only on the MK3 version of the Surf SOHO. The Release Notes will be updated to reflect the supported model(s). Thanks for the catch. 
2 Likes
Initially got this firmware last week to fix an issue with a br1 mini not connecting with a MVNO sim (hologram) that worked on 8.0.0. After uploading 8.1 all it does is reboot into the old 8.0.0. Haven’t heard back from Peplink Team in several days.
Suggestion: Post your ticket number here.
**X *** Model with 8 Port GbE doesn’t support POE when the Ethernet is set to WAN. POE works on LAN.
1 Like
Hello @sitloongs,
Reporting a new bug with the Custom Service Forwarding in relation to this post
In your example, you show having multiple entries of the same port number across multiple VLANs, though this is not working as can be seen by the error message “Duplicated rule for this TCP port”.
Peplink Balance Two, Firmware 8.1.0b04 build 4919
Happy to Help,
Marcus
The above should be the WebUI bug.
For time being you can use the custom “Source Network” Selection to forward NTP request to the NTP server.
I will comment the potential WebUI bug in the forum post below as well so that everyone is aware on the issue.
2 Likes
Hello,
Can you explain exactly how the PLMN functionnality is implemented? It might be one of the greatest improvements on cellular connectevity management for a while 
I see now:
Cellular 1 health check failed, restrict network to lower priority PLMN - 20620
Does it mean that the router will itself reorganise the list of PLMN configured? Can this list be super long and redefine roaming order for any country/operator in the world?
Thanks for the clarification
2 Likes
The PLMN function just a list to allow you to define the priority for the carrier that you would like the cellular module to connect. It support SIM SLOT fail-over as well when the defined PLMN failed to connect.
Do you have more info for the above ? Why you need to define a long list for PLMN ?
1 Like
Because it would be super cool to define for all countries in the world how roaming should behave. And if we could specify 3G/4G that would be even cooler.
Roaming cards from the same operator will connect on the same network. Using this I can spread my cards on different networks. With 3G/4G, I could even say that I prefer any operator in 4G than the regular ones in 3G. Today with current LTE/3G selection it is only 4G or auto. But “only 4G” can cause issues in the field if there is only 3G available.
1 Like
You are correct.
1 Like
hmm … Don’t think the PLMN priority will be the best feature used to redefined the global roaming behavior for the SIM cards. The reason being is that the more PLMN list that you defined it may delayed the cellular connection or fail-over to lower priority PLMN .
Can you please file a feature request for your use case and let Engineering team to consider the feasibility ? I would think your request maybe involve other integration like geolocation/others to apply the PLMN priority to the device dynamically but that may need Engineering team to review on that.
For the 4G/3G restriction, do you think you can have the following setup ?
Cellular SIM Slot A (PLMN 1, PLMN2, PLMN3) - LTE only connection
Cellular SIM Slot B (PLMN 1, PLMN2, PLMN3 - 3G Only connection.
SIM Slots connection fail-over should able to help you to limit the 4G and 3G carrier. Do you think it will help for the use case ?
1 Like
Let me suggest that Status → “Event Log” be changed to “Event Logs” (plural) as there are now two logs.
@jmlapido, you can opt for the additional data plan from the Online Store. More details could be found in the post (highlighted below).
1 Like
FYI: I see this often in the Event Log with 8.1 beta 4 at system startup:
Dec 31 19:00:54 MAC address conflict: Received an ARP packet claiming to be from our MAC address 00:1A:DD:00:28:00, but with an unknown IP (192.168.1.99)
Beta4 running on a SOHO HW2 connected to a SOHO MK3. WAN of beta4 into LAN of the MK3. 192.168.1.99 is LAN side IP of the MK3 on the untagged LAN.
Again, just an FYI. I am not saying it is a problem. I don’t understand the message.
Suspect this is the issue that you reported previously that suppose related to the SOHO MAC address issue using your config. Suppose it should be fix for firmware 8.1.0. Do allow me to further narrow down the issue with you using the ticket 20010240.
1 Like
Not sure if this is the right place for this but I got DHCP response issues on 8.1.0 beta 4 with the Balance 310x. I downgraded back to 8.0.2.
This relates to
21994 [DHCP] Fixed an issue where the DHCP server may not
reply to DHCP discovery or requests in rare situations
All Models
This doesn’t seem to be fixed.
UI feels slow in the beta compared to 8.0.2