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 boo...
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.
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 bond10g
Weirdly 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.
Ok, I made a little progress. It turns out if I access the AP via its IP address (as in https://1.2.3.4) then I get the admin page working. 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?
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.
Ohh that did fix the problem! I've never had to enter that into a device before to get it to work! Definitely a firmware bug because it doesn't even come up with an error, just a completely blank page. Weirdly when I put in the FQDN a popup came up saying "invalid IP address" and then the UI buttons stopped working, but after reloading the page it had saved the FQDN and immediately accessing the admin web page by https://fqdn worked. Of course accessing it via https://hostname still gives a blank page, you have to include the domain as well. What a terrible design!
So how can I get that set automatically from the DHCP server? I'm already passing "host-name" and "domain-name" options, do I have to pass another option as well? It will be annoying having to remember to log in and update the FQDN if the AP is ever moved to a different location and it picks up a new IP address and hostname.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
