Beta Software EAP783_V1_1.1.92 Beta Firmware -- Closed
This Article Applies to: EAP783_V1 Fully Adapted to Omada SDN Controller v5.14 or above
Release Notes:
New Features/Enhancements:
1. Supports displaying Configuration Result.
2. Supports cluster deployment in Controller mode (CBC does not support).
3. Supports Radius Proxy.
4. Supports OWE.
5. Supports custom Channel Range.
6. Supports upgrading firmware through cloud in Standalone mode.
7. Supports Portal Logout.
8. Supports disabling HTTP protocol in Standalone mode.
9. Supports DHCP Option43.
10. Supports multiple Radius Servers for MAC-Based Authentication.
11. Supports configuring NAS ID with WPA-Enterprise encryption.
12. Supports DNS Queries.
13. Supports configuring Rate Limit with Portal in Controller mode.
14. Supports configuring the Device Name in Controller mode, which can be carried in LLDP/SNMP/DHCP interaction.
15. Supports viewing status information and making some simple configuration through Standalone management page when the EAP is managed by the Controller and disconnected with Controller currently.
16. Supports displaying the maximum associated clients based on the EAP model in Controller mode.
17. Supports displaying the radio bandwidth of the EAP in Controller mode.
18. Supports configuring wireless mode in Controller mode.
19. Supports statistics of Multicast/Broadcast packets.
20. Supports 1024 PPSK entries.
21. Supports 802.11 a/n mixed in 5G.
22. Supports Non-stick Roaming function.
23. Supports authentication type of EKMS and Generic Radius with Unbound MAC for PPSK with Radius.
24. Supports Multicast Filtering with IPv6 address.
25. Supports reporting default OFDMA status.
26. Supports MAC Filter with 2000 entries per MAC Group profile.
27. Support DNS adoption.
28. Supports Multicast/Broadcast Rate Limit.
29. Enhances security protection.
30. Improves stability.
31. Improves support for more SSH commands.
32. Optimizes Automatic Power Optimization function.
33. Optimizes the configuration of Beacon Interval.
34. Optimizes roaming function.
35. Optimizes logs displayed in Controller.
Bug Fixed:
1. Fixed the issue that RSSI information display error in WLAN Optimization.
2. Fixed the issue about LLDP-MED packet forwarding exception.
3. Fixed the issue that URL Filtering cannot work properly when TLS1.3 is enabled in the browser.
4. Fixed the issue that HTTPS Redirection and Pre-Authentication Access don’t take effect in some special scenarios.
5. Fixed the reboot issue of EAP when client try connecting tri-band MLO SSID.
Notes:
1. This version of firmware is applied to the Omada APP v4.17 or above.
Beta Firmware Download
Attention
Please be sure you have read the Beta Test Agreement before upgrading the Beta firmware!
EAP783_v1_1.1.92_Build_20250507(Beta)
EAP783_v1_1.1.90_Build_20250115(Beta)
Notes:
(1) The above firmware is applied to EAP783 V1.
(2) Your device’s configuration won’t be lost after upgrading.
(3) The above firmware is fully adapted to Omada SDN Controller v5.14 and above
Update Log
23th May, 2025
Provide the beta link for EAP783_1.1.92:
EAP783_v1_1.1.92_Build_20250507(Beta)
18th Mar, 2025
Update the release note.
17th Jan, 2025
Provide the download link:
EAP783_v1_1.1.90_Build_20250115(Beta)
Feedback
Any further feedback on the new firmware, please feel free to comment below or start a new thread from HERE.
To get better assistance, you may check Tips For Efficiently Reporting an Issue In The Community.
When reporting an issue, especially it's about firmware upgrade, it's suggested to include the following info:
- Management mode (Controller or Standalone)
- Device Model(s) and Hardware
- Device Firmware (previous and current)
Thank you in advance for your great cooperation and support.
Recommended Threads
Experience the Latest Omada EAP Firmware - Trial Available Here, Subscribe for Updates!
Current Available Solutions to Omada EAP Related Issues [Constantly Updated]
Get the Latest Omada SDN Controller Releases Here - Subscribe for Updates
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
> Now, however, with the 1.1.92 beta, a problem has arisen in VLAN 1 where the connections are no longer clean. Is there anything known about this? In addition to VLAN 1, the customer also uses many other VLANs in the network where there are no problems.
I can confirm that this behavior is still present in the current "stable" firmware:
EAP783 1.0_1.1.4 Build 20251030.
My setup was fairly standard:
- Default LAN on untagged VLAN 1 (so, effectively "no VLAN" for LAN/Wi-Fi clients)
- Multiple additional VLANs for things like IoT
- Routing and firewalling handled centrally, nothing exotic
The symptoms were extremely frustrating and non-obvious:
- Traffic from default VLAN 1 Wi-Fi to other VLANs was unreliable, with what looked like missing TCP ACKs / asymmetric connectivity.
- Concrete example: I could not reliably access Valetudo on a robot vacuum that lives on its own IoT VLAN, when connecting from Wi-Fi on default VLAN 1.
- The same access worked perfectly from wired LAN in the same default network, so the problem clearly sat in the EAP/VLAN handling on the wireless side, not in routing or firewall rules.
After way too much packet-tracing and trial-and-error, the only stable workaround I’ve found is:
- Stop using VLAN 1 / untagged as the "real" LAN.
- Create a dedicated "LAN" VLAN for normal devices (tagged on the trunk, access on the appropriate ports/SSIDs).
- Move all "normal" LAN clients (including the Wi-Fi SSID that used to sit on default VLAN 1) to this new non-1 VLAN.
Once I did that, inter-VLAN communication immediately became reliable again. No more broken sessions, no more partial loads, no more weird one-way traffic.
I’m shocked by how much time I’ve burned debugging because of the EAP783. The rest of the VLAN design is straightforward, and every other VLAN behaves correctly, only VLAN 1 on the EAP783 is problematic.
Is this a known regression on EAP783 (1.1.92 beta and 1.0_1.1.4 Build 20251030)?
And more importantly, is there a plan to fix VLAN 1 behavior on Wi-Fi so we don’t have to design around it by avoiding VLAN 1 entirely?
Right now, the practical advice I’d give anyone deploying EAP783 is: do not use VLAN 1 as your production LAN, put your "real" LAN on a dedicated tagged VLAN and avoid VLAN 1 wherever possible.
- Copy Link
- Report Inappropriate Content
Hi @nikisima
Thanks for the feedback. Please send a copy of your controller's config file to the ticket TKID251228355. I just created it for you.
This will help us find the reason as soon as possible. Thanks.
nikisima wrote
> Now, however, with the 1.1.92 beta, a problem has arisen in VLAN 1 where the connections are no longer clean. Is there anything known about this? In addition to VLAN 1, the customer also uses many other VLANs in the network where there are no problems.
I can confirm that this behavior is still present in the current "stable" firmware:
EAP783 1.0_1.1.4 Build 20251030.
My setup was fairly standard:
- Default LAN on untagged VLAN 1 (so, effectively "no VLAN" for LAN/Wi-Fi clients)
- Multiple additional VLANs for things like IoT
- Routing and firewalling handled centrally, nothing exotic
The symptoms were extremely frustrating and non-obvious:- Traffic from default VLAN 1 Wi-Fi to other VLANs was unreliable, with what looked like missing TCP ACKs / asymmetric connectivity.
- Concrete example: I could not reliably access Valetudo on a robot vacuum that lives on its own IoT VLAN, when connecting from Wi-Fi on default VLAN 1.
- The same access worked perfectly from wired LAN in the same default network, so the problem clearly sat in the EAP/VLAN handling on the wireless side, not in routing or firewall rules.
After way too much packet-tracing and trial-and-error, the only stable workaround I’ve found is:- Stop using VLAN 1 / untagged as the "real" LAN.
- Create a dedicated "LAN" VLAN for normal devices (tagged on the trunk, access on the appropriate ports/SSIDs).
- Move all "normal" LAN clients (including the Wi-Fi SSID that used to sit on default VLAN 1) to this new non-1 VLAN.Once I did that, inter-VLAN communication immediately became reliable again. No more broken sessions, no more partial loads, no more weird one-way traffic.
I’m shocked by how much time I’ve burned debugging because of the EAP783. The rest of the VLAN design is straightforward, and every other VLAN behaves correctly, only VLAN 1 on the EAP783 is problematic.
Is this a known regression on EAP783 (1.1.92 beta and 1.0_1.1.4 Build 20251030)?
And more importantly, is there a plan to fix VLAN 1 behavior on Wi-Fi so we don’t have to design around it by avoiding VLAN 1 entirely?
Right now, the practical advice I’d give anyone deploying EAP783 is: do not use VLAN 1 as your production LAN, put your "real" LAN on a dedicated tagged VLAN and avoid VLAN 1 wherever possible.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 4
Views: 15588
Replies: 142
Voters 2
