ECW526
v1.8.87
[Issue Fixed]
Improves the Fast Roaming performance when there are thousands of MyPSK user in the network.
Resolved the issue where selecting too many channels in the 6G Auto Channel list caused the AP to fail to configure.
v1.8.86
[Issues Fixed]
Fix the issue that AP will trigger error evil twin alarms of AirGuard function.
v1.8.85
[New Features]
Increased MyPSK entry to 5,000 to support larger MDU/Domitory environment.
Supports sub-option codes within DHCP Option 43, enabling EnGenius APs to identify the correct Access Controller (AC) in mixed environments with multiple AP and AC brands.
Support client traffic logs when SSID is set is set to NAT mode, providing more information for trouble shooting.
Supports Configuration Rollback function, allowing the device to automatically rollback to the last stable configuration if a misconfiguration causes a loss of Cloud connection.
Increase 802.11 RTS/CTS disable option to reduce signaling overhead and latency. This improves data transmission efficiency in environments with strong signals and minimal interference, such as those using directional antennas.
v1.8.84
[Issues Fixed]
Resolved mDNS loop issue. When there are multiple AP in a network with multiple SSID and mDNS Forwarding enabled, power cycle one of the AP may causes network unstable.
v1.8.83
[Issues Fixed]
Enhance the gateway detection mechanism in Bridge Mode to solve the problem that captive portal clients could not correctly redirect to gateway.
Solve the issue that LSP can still access when Local Web Pages was disabled.
Fix the problem that AP goes offline when the third octet of gateway (GW) subnet mask is less than 255(e.g., GW IP 192.168.1.1, mask 255.255.254.0).
Fix the issue that TX Bytes and RX Bytes statistics in the disconnection log always show 0.
Fix AP cannot send 802.11v post-association packets properly when band steering is enabled.
v1.8.82
Support EnGenius fast-handover algorithm 2.0
Remove dropbear chacha20-poly1305@openssh.com encryption due to security concern.
Fix the issue that clients may get disconnected after editing ACL rules.
Add country code for Japan.
v1.8.81
Add support for SAMLv2 (Security Assertion Markup Language version 2) in Captive portal with Azure-AD.
Support HTTPS-Only for local device page.
Support WPA2-PSK[AES] + WPA-PSK[TKIP] encryption mode.
Speed up the LED turn-off time when the user disables the LED Light function.
Appendix for v1.x.81
Add support for SAMLv2 in Captive portal with Azure-AD
A captive portal is a web page that users must interact with to gain network access, often seen in public Wi-Fi networks. This update introduces support for SAMLv2 (Security Assertion Markup Language version 2), a prominent protocol used for exchanging authentication and authorization data between identity providers and service providers.
(a) What is SAMLv2?
SAMLv2 is an XML-based open standard for secure exchange of authentication and authorization data. It enables Single Sign-On (SSO), allowing users to authenticate once and gain access to multiple applications without re-entering credentials. In the context of Azure AD, SAMLv2 facilitates secure communication between Azure AD (the identity provider) and various services (service providers) users want to access.
(b) Implications of This Update
Enhanced Authentication: Users can now authenticate through Azure AD when accessing a network via a captive portal. This means that organizations leveraging Azure AD for identity management can extend its use to captive portals, ensuring a consistent and secure authentication process.
Single Sign-On (SSO): With SAMLv2, users benefit from SSO capabilities. They log in once with their Azure AD credentials and gain seamless access to multiple services and applications without the need to re-authenticate, improving user experience and productivity.
Increased Security: SAMLv2 enhances security by enabling strong authentication and reducing password fatigue. It ensures that authentication tokens are securely transmitted and managed, protecting user credentials from potential attacks.
(c) Practical Applications
Organizations can now implement SAMLv2-based captive portals, allowing users to connect to networks using their Azure AD credentials. This integration streamlines access management and bolsters security, making it especially beneficial for enterprises with a high reliance on Azure AD for identity services.
In summary, the support for SAMLv2 in Azure-AD captive portals facilitates a more secure, efficient, and user-friendly authentication process, aligning with modern enterprise needs for robust identity and access management.
Support HTTPS-Only for local device page
To address security concerns, we have introduced an HTTPS-only switch that allows users to control access to the Local Service Page (LSP). This feature is essential for enhancing the security of local device management by ensuring that all communications are encrypted.
(a) Importance of HTTPS for Security
HTTPS (Hypertext Transfer Protocol Secure) is an extension of HTTP and is widely used to secure data transmission over the internet. When enabled, HTTPS ensures that all data exchanged between the user's browser and the local device page is encrypted. This encryption is crucial for several reasons:
Data Privacy: HTTPS uses TLS (Transport Layer Security) to encrypt the data, making it unreadable to any third party that might intercept the communication. This protects sensitive information such as login credentials and configuration settings from being exposed.
Data Integrity: Encryption also ensures that the data transferred has not been altered during transmission. It prevents tampering and ensures that the information received by the user is exactly what the server sent.
Authentication: HTTPS verifies the identity of the local device page, ensuring that users are connecting to the correct page and not a malicious site impersonating it. This helps prevent man-in-the-middle attacks where an attacker might intercept and alter communications between the user and the device.
User Trust: Users are more likely to trust and engage with local device pages that employ HTTPS, as indicated by the padlock icon in the browser's address bar. This visual assurance helps build confidence in the security of the connection.
(b) Implementation and Control
By introducing an HTTPS-only switch, we empower users to enforce this level of security. Users can easily enable this switch to ensure that all access to the Local Service Page is through HTTPS. This change mitigates risks associated with unencrypted HTTP connections, such as eavesdropping and data breaches.
In summary, the HTTPS-only feature significantly enhances the security of local device pages by ensuring encrypted, authentic, and tamper-proof communication, thereby protecting user data and fostering trust.
v1.8.75
This f/w version is for the first release.
Last updated