NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
WAX610 - blank admin page
Hi all,
Does anyone have any experience with a WAX610? It's my first Netgear WiFi product so I'm not sure if this is how they are meant to work or not.
I added the MAC to my DHCP server and booted up and took a good few minutes to accept the IP address (it just kept requesting it over and over) and finally when it accepted the IP I opened up the browser to access the admin page. After accepting the self-signed cert, the page is just blank. No login, no error, nothing. If I leave the blank page just sitting there then every few minutes it comes up saying my session has expired and it's redirecting me to the login, but then it's blank again.
I called Netgear support who said I have to access the admin page via WiFi before you can access it via the LAN. So I did this but no luck. I tried updating the firmware via the WiFi interface (now on 9.6.2.6) and the only change is that now the browser tab says "NETGEAR WAX6xx" instead of the hostname I'd typed in.
I checked online and there are quite a few people having a similar problem, but they got the admin page back after rebooting or doing a device reset, and I have tried both, multiple times, but no admin web page for me. Looking in the HTML page source, the page isn't blank, there's just a div id="app" tag that's supposed to get populated with DOM elements but for some reason this never happens. No errors in the browser console either.
So am I correct in that you can't locally manage these APs via the LAN interface? If so I will have to return it and try a different brand because I don't want to have to physically visit each AP and join its WiFi network in order to update the settings. And cloud-managed isn't an option for me for security reasons.
Is there some setting I have missed to make the admin web page not blank on a LAN connection, or should I get a refund and try another brand?
Malvineous wrote:
But if I access it via its FQDN (as in http://hostname.mydomain.example) then the admin page is blank.
Is this expected behaviour? Is everyone just using raw IPs instead of DNS?
Reads like you have not configured the FQDN on the LAN settings.
Crux is that they are comparing the FQDN with the referrer URL, kid of a security (or security by obscurity) feature, without any warning as you experience. Yes, I don't get warm with this ****, as it's different from any other business vendor product implementation.
7 Replies
Malvineous wrote:
So am I correct in that you can't locally manage these APs via the LAN interface?
No, of course not.
Are you making use of a strange Web browser, some security nightmare in place intercepting valid code for example?
Reconsidering you mentioned having updated the firmware, the Web UI was undoubted workable, not looking as empty as you stated before. Time to drop the browser cache probably, and force reload the page?
Below, for your reference, is the beginning of the html code from any WAX6xx - indeed, this is the generic name before the standard JavaScript does rattle in, showing the effective product name:
Yes as I said the web interface worked on a phone connected via WiFi, but I don't want to have to physically visit each AP and connect to it one by one to access the web interface, I want to access it via its IP on the LAN like I can with every other network device. I used the phone to apply the firmware update.
I'm using the latest version of Firefox which isn't that strange to me. No weird security things. The network tab in the browser console shows nothing is blocked, although the page does try to make an API call to a 'getVersion' endpoint on the device which returns with a 200 OK but contains an "Invalid request" HTML error page so no idea what's going on there. Every other management interface I access in this browser works fine, from Cisco to TP-Link. It's not a browser cache issue as I tried Shift+Reload to bypass the cache and on two different computers as well with the same result. I tried to telnet and SSH in like on other devices as I don't mind CLI config but these ports aren't open on the Netgear.
I can see in the browser console there is a <div> tag that is meant to be populated with some DOM elements but this does not happen, but as there are no errors in the browser console I cannot debug this further. I have written web interfaces professionally before and I am familiar with DOM manipulation and browser caching so it looks to me like the code is not even starting to run for some reason, otherwise it would've added more child elements to that 'app' <div> element beyond the couple that are there.
In your screenshot the key part of the web interface is just past the end of what you have shown. There is a <div id="app"> tag where you will either see tags for the UI, or there will be no tags visible. You might have to look in the DOM Inspector as depending on the browser, the 'view source' function may only show the original file before the code running on the page modified it. In this case you'll see the <div> as empty.
I've spent many hours on this now just trying to begin the set up of the device, but it looks like the firmware is completely broken, so I will probably have to return it and try for a different manufacturer with better QA on their firmware. I might expect these kinds of bugs from consumer level gear but for a product aimed at business use to not have a working admin web page - and for people to have been having the same problem for years with no fix? That's a pretty poor effort from Netgear I have to say. I think I'm at the point now where even if by some magic it can be fixed, I don't trust the product any more, especially not as other posts here say they have gotten the admin web page working but then days later it is broken again. Just makes you wonder what other corners they have cut and what other surprises are waiting for you down the track.
Just to add to this in case anyone encounters a similar issue in the future, the device also really struggles to accept an IP address off a DHCP server. Most devices on the network accept the IP after one or two requests, within a couple of seconds, but the Netgear device takes over two *minutes* of sending DHCP requests before it finally relents and accepts the IP it has been given. These are the logs from the DHCP server for a single power-up of the device, spanning over two minutes:
DHCPDISCOVER from 80:cc:9c:6b:9f:9f via bond10g DHCPOFFER on 198.18.0.3 to 80:cc:9c:6b:9f:9f via bond10g DHCPDISCOVER from 80:cc:9c:6b:9f:9f via bond10g DHCPOFFER on 198.18.0.3 to 80:cc:9c:6b:9f:9f via bond10g DHCPDISCOVER from 80:cc:9c:6b:9f:9f via bond10g DHCPOFFER on 198.18.0.3 to 80:cc:9c:6b:9f:9f via bond10g DHCPDISCOVER from 80:cc:9c:6b:9f:9f via bond10g DHCPOFFER on 198.18.0.3 to 80:cc:9c:6b:9f:9f via bond10g DHCPDISCOVER from 80:cc:9c:6b:9f:9f via bond10g DHCPOFFER on 198.18.0.3 to 80:cc:9c:6b:9f:9f via bond10g DHCPDISCOVER from 80:cc:9c:6b:9f:9f via bond10g DHCPOFFER on 198.18.0.3 to 80:cc:9c:6b:9f:9f via bond10g DHCPDISCOVER from 80:cc:9c:6b:9f:9f via bond10g DHCPOFFER on 198.18.0.3 to 80:cc:9c:6b:9f:9f via bond10g DHCPREQUEST for 198.18.0.3 (198.18.0.102) from 80:cc:9c:6b:9f:9f via bond10g DHCPACK on 198.18.0.3 to 80:cc:9c:6b:9f:9f via bond10g DHCPREQUEST for 198.18.0.3 (198.18.0.102) from 80:cc:9c:6b:9f:9f via bond10g DHCPACK on 198.18.0.3 to 80:cc:9c:6b:9f:9f via bond10g DHCPREQUEST for 198.18.0.3 (198.18.0.102) from 80:cc:9c:6b:9f:9f via bond10g DHCPACK on 198.18.0.3 to 80:cc:9c:6b:9f:9f via bond10g DHCPDISCOVER from 80:cc:9c:6b:9f:9f via bond10g DHCPOFFER on 198.18.0.3 to 80:cc:9c:6b:9f:9f via bond10g DHCPDISCOVER from 80:cc:9c:6b:9f:9f via bond10g DHCPOFFER on 198.18.0.3 to 80:cc:9c:6b:9f:9f via bond10g DHCPDISCOVER from 80:cc:9c:6b:9f:9f via bond10g DHCPOFFER on 198.18.0.3 to 80:cc:9c:6b:9f:9f via bond10g DHCPREQUEST for 198.18.0.3 (198.18.0.102) from 80:cc:9c:6b:9f:9f via bond10g DHCPACK on 198.18.0.3 to 80:cc:9c:6b:9f:9f via bond10g DHCPREQUEST for 198.18.0.3 (198.18.0.102) from 80:cc:9c:6b:9f:9f via bond10g DHCPACK on 198.18.0.3 to 80:cc:9c:6b:9f:9f via bond10g DHCPREQUEST for 198.18.0.3 (198.18.0.102) from 80:cc:9c:6b:9f:9f via bond10g DHCPACK on 198.18.0.3 to 80:cc:9c:6b:9f:9f via bond10g DHCPDISCOVER from 80:cc:9c:6b:9f:9f via bond10g DHCPOFFER on 198.18.0.3 to 80:cc:9c:6b:9f:9f via bond10g DHCPREQUEST for 198.18.0.3 (198.18.0.102) from 80:cc:9c:6b:9f:9f via bond10g DHCPACK on 198.18.0.3 to 80:cc:9c:6b:9f:9f via bond10g DHCPREQUEST for 198.18.0.3 (198.18.0.102) from 80:cc:9c:6b:9f:9f via bond10g DHCPACK on 198.18.0.3 to 80:cc:9c:6b:9f:9f via bond10g DHCPREQUEST for 198.18.0.3 (198.18.0.102) from 80:cc:9c:6b:9f:9f via bond10g DHCPACK on 198.18.0.3 to 80:cc:9c:6b:9f:9f via bond10g DHCPDISCOVER from 80:cc:9c:6b:9f:9f via bond10g DHCPOFFER on 198.18.0.3 to 80:cc:9c:6b:9f:9f via bond10g DHCPDISCOVER from 80:cc:9c:6b:9f:9f via bond10g DHCPOFFER on 198.18.0.3 to 80:cc:9c:6b:9f:9f via bond10g DHCPDISCOVER from 80:cc:9c:6b:9f:9f via bond10g DHCPOFFER on 198.18.0.3 to 80:cc:9c:6b:9f:9f via bond10g DHCPDISCOVER from 80:cc:9c:6b:9f:9f via bond10g DHCPOFFER on 198.18.0.3 to 80:cc:9c:6b:9f:9f via bond10g DHCPREQUEST for 198.18.0.3 (198.18.0.102) from 80:cc:9c:6b:9f:9f via bond10g DHCPACK on 198.18.0.3 to 80:cc:9c:6b:9f:9f via bond10g DHCPREQUEST for 198.18.0.3 from 80:cc:9c:6b:9f:9f via bond10g DHCPACK on 198.18.0.3 to 80:cc:9c:6b:9f:9f via bond10gWeirdly if I ping the device it accepts the IP after a minute or so, but then it drops it again and takes another minute before it comes back. Bizarre.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
