Archer AX300E - Red lights, but everything works fine.
This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
I have an Archer AXE300 that has been running for several weeks, but after a reboot, the red lights stay illuminated on the top of the unit. When I log into the UI, there is a red exclamation point on the Internet icon.
I'm not sure what's going on, but the Internet is working fine through the unit, my wireless clients are working fine, and even if I plug a PC directly into one of the LAN ports, it still works fine. Also, if I use the diagnostics page and ping an internet address (by IP), it works fine.
The unit is in AP mode, not router mode so my options are pretty limited. However, the lights were blue until this last reboot.
Any ideas?
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
I figured out what the problem was and wanted to post the solution in case anyone else comes across the same issue.
My Archer is in Access-Point mode which means my configuration options are pretty limited (laughably limited). One of the configurations I can't set is the DNS server. For some reason, that is only available in routed mode (at least under this version of firmware).
It appears the way the Archer determines whether or not it has Internet access is by resolving a series of Internet domains:
- n-devs-gw.tplinkcloud
- n-deventry-gw.tplinkcloud
- tp-link
- live
- yahoo
- ebay
- bing
- netflix
- amazon
- wikipedia
(yes, I did verify these were indeed from the Archer and not from my network)
Since you cannot specify a DNS server, the Archer defaults to attempting the name resolution using it's default gateway as a DNS forwarder. In my case, the default gateway does not (or ever did) have DNS services on it, so it simply dropped the request. That's OK though, it appears the developers thought of this because if the DNS resolution fails, it then attempts some creative tricks using mDNS on 224.0.0.251. Specifically it does some PTR queries to try and discover the network and find the DNS server. < I did support this, and this explains why it was working all this time.
A few days ago, I changed out a switch (a core switch that the AP wasn't even connected to) and I did not configure IGMP on the new one, and I also removed multicast routing on my internal gateway. Because of that, mDNS was doomed to fail the next time the TP-Link needed it. However, I'm guessing the access point cached the original DNS responses because this little side-effect didn't make an appearance until I rebooted it days later.
Once I knew what it was trying to do, it wasn't difficult to come up with a solution. In my case, I didn't want to re-enable multicast routing on that VLAN, so I just added a DNS proxy on the gateway that will forward DNS requests to right servers. This meant the access point could now use the gateway as a DNS server, and almost immediately, the lights on the top went back to blue.
This whole thing could have been avoided if I was able to specify a DNS server from the beginning. I know that WiFi-7 is around the corner, so I hope the Archer team is still investing time in us legacy people that are stuck in the 6E technologies. This firmware still needs quite a bit of work (dare I say enhancements), so I'm keeping my fingers crossed that they don't forget about us.
- Copy Link
- Report Inappropriate Content
I figured out what the problem was and wanted to post the solution in case anyone else comes across the same issue.
My Archer is in Access-Point mode which means my configuration options are pretty limited (laughably limited). One of the configurations I can't set is the DNS server. For some reason, that is only available in routed mode (at least under this version of firmware).
It appears the way the Archer determines whether or not it has Internet access is by resolving a series of Internet domains:
- n-devs-gw.tplinkcloud
- n-deventry-gw.tplinkcloud
- tp-link
- live
- yahoo
- ebay
- bing
- netflix
- amazon
- wikipedia
(yes, I did verify these were indeed from the Archer and not from my network)
Since you cannot specify a DNS server, the Archer defaults to attempting the name resolution using it's default gateway as a DNS forwarder. In my case, the default gateway does not (or ever did) have DNS services on it, so it simply dropped the request. That's OK though, it appears the developers thought of this because if the DNS resolution fails, it then attempts some creative tricks using mDNS on 224.0.0.251. Specifically it does some PTR queries to try and discover the network and find the DNS server. < I did support this, and this explains why it was working all this time.
A few days ago, I changed out a switch (a core switch that the AP wasn't even connected to) and I did not configure IGMP on the new one, and I also removed multicast routing on my internal gateway. Because of that, mDNS was doomed to fail the next time the TP-Link needed it. However, I'm guessing the access point cached the original DNS responses because this little side-effect didn't make an appearance until I rebooted it days later.
Once I knew what it was trying to do, it wasn't difficult to come up with a solution. In my case, I didn't want to re-enable multicast routing on that VLAN, so I just added a DNS proxy on the gateway that will forward DNS requests to right servers. This meant the access point could now use the gateway as a DNS server, and almost immediately, the lights on the top went back to blue.
This whole thing could have been avoided if I was able to specify a DNS server from the beginning. I know that WiFi-7 is around the corner, so I hope the Archer team is still investing time in us legacy people that are stuck in the 6E technologies. This firmware still needs quite a bit of work (dare I say enhancements), so I'm keeping my fingers crossed that they don't forget about us.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 317
Replies: 1
Voters 0
No one has voted for it yet.