NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
wifidog - Clients Connected Captured in Captive Portal - SSID Captive Portal Off
Since a few days (around the 5.1 update, around the switch update to .12) we had some massive wireless problems - some systems like printers were no longer reachable.
Users reported that every now and then they get redirected to the wifidog - captive portal - however, for that SSID the captive portal is (and always was) disabled [Off].
Before the troubleshooting, we had another SSID, same settings, same VLAN, with the captive portal enabled [On]. Possible config change since the update: Band Steering, 802.11k (on the WiFi), and RSTP (on the network) was enabled.
Observations:
- Disabling the SSID with the Captive Portal on has not changed anything.
- Removing each WAC, factory reset indicidually, and re-adding has not fixed.
- Removing the SSID wigh the Captive Portal - so only one SSID with the Captive Poral Off - remained, same problem.
- System log showed some wifodog restart die to a changed IP or the like.
- The IP addresses of the Captive Portal were only WAC510 (two on the network), never the WAC505 (two on the same network).
- At this state we captured the system config from one of the WAC510 (ready to share with MrJoshW by PM).
- Further Mitigation for now: Have _again: removed the WAC510 from the network, factory reset, and re-added.
- For a few hours, there was no new issue, no more WiFi STA were captured.
Not good, somewhat disappointed. Experienced the exact same during the Insight Beta (with WAC510s only). Every hint welcome!
4 Replies
Happened today again, this time on a WAC505.
The logs show this for each access attempt:
Sun Oct 21 08:12:58 CEST 2018 hostapd: wifi1vap0: STA 40:xx:xx:xx:xx:6e IEEE 802.11: disassociated
Sun Oct 21 08:12:58 CEST 2018 hostapd: wifi1vap0: STA 40:xx:xx:xx:xx:6e IEEE 802.11: disconnected
Sun Oct 21 08:12:58 CEST 2018 wifidog[1027]: iptables command failed(1): iptables -w -t mangle -D WiFiDog_brtrunk_Outgoing -m mac --mac-source 40:xx:xx:xx:xx:6e -j MARK --or-mark 0x3
Sun Oct 21 08:12:58 CEST 2018 hostapd: wifi1vap0: STA 40:xx:xx:xx:xx:6e IEEE 802.11: Station deauthenticated due to reason code 3
Sun Oct 21 08:12:58 CEST 2018 nddmp[2586]: alarm : seqNo-[2073], level-[INFO], info-[40-xx-xx-xx-xx-6E wireless client disconnected]
Sun Oct 21 08:12:58 CEST 2018 hostapd: SSID ROAM: Tx leave update for sta 40:xx:xx:xx:xx:6eRaghuHR please investigate and fix this - dropping you another link with the WAC logs by PM It is not acceptable that valid and trusted systems (and even worse IoT devices not able to follow the wifidog portal) are locked out from the Insight and Insight Pro managed networks.
Hello,
I can open a bug with engineering about this and update Ragu with the bug ID to look further into it. Can you private message me the logs so that I can add to the engineering bug?
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
