I am setting up a mesh with my access points and am also moving to using the integrated AP Controller in my Balance 1. I guess my threshold for manually configuring access points is somewhere between 3 and 5. I recently added two new AP One AX access points and figured I would use the Mini ACs that were replaced as non-wired APs to extend range out to my hot tub and garage/theater room.
When the non-wired APs are connected via mesh to other APs - I am unable to navigate directly to their administration site by IP address. I kept thinking that they were not attached to the mesh because the website failed to load. I am however able to manage them through the controller and can get to the administration site THROUGH the AP Controller. The little square icon with an arrow coming out at an angle in the AP list that has the tooltip “Access AP Web Admin” seems to be the only way to fully manage the settings not available in the controller config section. Is this on purpose? It only seems to impact the APs that are connected through mesh. All hard-wired APs can be accessed through the controller link AND direct URL navigation.
When I try to navigate to https://192.168.1.4 - I get the redirect, but then the browser stalls out and the page never loads. I can tell that I hit the redirect because the URL changes to https://192.168.1.4/cgi-bin/setup.cgi?option=first_page&mode=config. Eventually safari times out and gives a generic error page. Is this a feature or a bug?
The second part of my post is regarding channel scanning. I thought the point of scanning channels of neighboring access points was to prevent two APs from broadcasting on the same channels. Out of 5 APs, 3 of them chose the same 5Ghz channel and two chose the same 2.4Ghz channel. I ended up manually setting different channels, but I would have thought that the APs would have auto-learned a good range of channels. To be fair, I have more wifi than I have area or users. I have some weak coverage areas that I am trying to get a better signal (so I have the APs relatively close to the wired ones – about 40-50 feet). Since they are so close, I was very surprised to see them choose the same channels.
Also, with the “global” scan time configuration from the AP Controller – what prevents the APs from all scanning/changing at the same time. Seems to me that they should stagger this operation to avoid all choosing the same channel. Maybe the scanning is tied to the deployment method (ASAP, one at a time, or groups)?
Thanks for all the hard work on all of these great updates rolling out!
For the first part, the AP WebAdmin access should behave the same in both ethernet and Wi-Fi Mesh connection. It should be accessible directly through IP address or via AP Controller “Access AP Web Admin” button.
“Access AP Web Admin” button is available if the AP is not a Remote AP, please check
whether the AP can lease DHCP from AP Controller’s LAN network, and
whether there are any IP addresses/Domain name in AP WebAdmin’s “Controller Management Settings”.
For the “generic error” after the redirection issue, did you try reconnect that AP to the ethernet network and access it again? It will be helpful for us to understand what happened if you can access that AP webadmin and download its diagnostic report.
For the second part, the auto channel of AP Controller is not trying to assign different channels to APs. Its aim is to coordinating each AP to find the least congested channel at their locations, so the most dominating factor is the channel background scanning result provided by AP itself.
The deployment methods are designed to provide flexibility for users to trade off the config update speed and degree of connectivity interruption. In terms of auto channel result, “One at a time” should provide a better result, because APs do Full-Time channel scanning during activation one by one, but it may take much longer time to update all the APs’ configuration.
I dig some more digging and it gets a bit more interesting. When I am unable to get to the web admin page directly by IP - I also cannot ping the IP of the non-wired AP.
However, when I log into the non-wired AP through the controller, I can use the PING feature in the system menu and send some pings out to the LAN. After those packets go across, I can ping the AP and access the web admin site.
It looks like there may be an issue with ARP or routing whenever the AP is attached via mesh. Any thoughts?
I had typed up my other comment before signing off yesterday and I forgot to hit post. Oops.
To answer your questions directly…
All APs are using static IPs in the LAN subnet outside of DHCP range.
I set all APs up to use a persistent AP controller with IP of Balance One Core
I was able to access the web admin directly via IP only after forcing the AP to send some ping traffic to the LAN (I just chose the IP of the laptop I was using for testing). The first ping took over 200 ms, and then subsequent ping replies were in the 2-3ms range. I logged in through the controller UI and used the system-ping utility. The Balance One reported the AP as UP the whole time and the AP responded to my reboot requests. But, I could not ping it or load the web admin utility directly until after forcing the outbound traffic.
Your explanation about the channel scanning is helpful. I will have to do some more digging, but I am pretty sure that the AP chose channel 36 after it has already “discovered” a nearby device using channel 36 at a pretty strong signal strength. I will start another thread about the channel scanning in the future. I am going to prune this topic back to just the mesh connectivity.
It looks like the connectivity issue has something to do with ARP. It may be an issue on the mac that I am using as opposed to a Peplink problem. But, the same mac is able to get to the non-meshed APs without issues – so, I don’t know.
Here is the arp cache entry when the web UI does NOT load
(192.168.20.3) at (incomplete) on en0 ifscope [ethernet]
After I have the AP ping the mac laptop (UI does load)
(192.168.20.3) at 0:1a:dd:e4:fc:0 on en0 ifscope [ethernet]
I am not using any layer 2 isolation or firewalls, but I will do a packet capture and see if I can catch a failed ARP request/response or something.
Yup, no ARP response returns on the query asking for the IP of the access points attached via mesh.
I am wondering if I have misconfigured my AP One AX access points. I was kind of taken off guard when I saw one physical interface, but yet there were spots for WAN and LAN addresses. I set them up as “Bridge mode (without LAN IP address)”.
For WAN1, I set it to static IP with and IP address inside my LAN subnet (outside of DHCP range). Then, for LAN (which I thought I had disabled with the option above), I have the same IP network configured. That can’t be right, and is probably part of my problem.
On the AP One Mini AC, when I choose the operating mode of “Bridge” - all the LAN options disappear. That is not the case with the AP One AX.
Another update…
This definitely has something to do with an ARP request going unanswered. My mac cannot ping or connect to the IP until after I ping the mac from the access point. I set my mesh up to be 5Ghz, and I noticed that the mac address of the 5Ghz antenna is different than the 2.4Ghz and Ethernet (eth and 2.4 have the same mac address). I am seeing if setting up the mesh as a 2.4 will allow the antenna to respond to the ARP requests. I did packet captures and see that the ARP requests are making it out of my mac and into the router. If that doesn’t work, I am going to try the static ARP feature in the support.cgi to see if I can get the router to respond to these ARP requests instead of the AP. More to come… this is getting fun.
Much appreciated on the detailed testing and reports. Please open a ticket to submit the captures and also grab a diagnostic report from each router/AP if you are able to after experiencing the issue.
Yeah, I spent the whole morning on this, and I have come to the conclusion that you shouldn’t try to mesh AP One AC Minis with AP One AXs. No matter what I tried, I could not get it to work. It looks to me like there is an issue with broadcast traffic to the AP attached via mesh. ARP query/responses is what I found to be the biggest culprit. Bear in mind, it does “work” technically - I actually didn’t even try to associate a client to a non-wired AP and verify that traffic flows through to the internet - If I cannot manage the AP through the IP nor ping the IP from the LAN - it is a no go for me. Too many - “if this doesn’t work, is this other issue related?” type of scenarios. I do find it odd that the Balance router was always able to communicate with the meshed AP. Maybe the ARP cache is more “permanent”, or perhaps since the AP is checking in with the router - ARP is not really needed.
I did get it all to work with my AP One AC Minis exclusively. Maybe it has something to do with them all being the same hardware and hardware revision. Heck, for all I know the HW1 version of these APs just may not be compatible with any of the new antennas. I imagine it is not a common scenario that Peplink would have tested.
I just cloned a second profile in the AP controller and removed the mesh from it. I applied the non-mesh version to my AP One AXs and as soon as all the configs were pushed out - everything worked as expected.
So, I ended up with a single wired Mini that is meshed with two non-wired minis, and then the AP One AXs are not included in the mesh at all. I used the 2.4 Ghz band for the mesh since there is a larger space between the APs. The 5 are pretty much in a line. I was trying to get the two outer APs to connect to the AP directly next to them. But, having the two outer APs connecting to the one in the middle is fine too.
I will continue to test it out, but this looks to be the only way I can get it to reliably allow for direct AP management through IP address.
Now, if I can just figure out how to set the channels to what I want – I might consider myself clever. I suspect that when an AP is part of a mesh, the channel is static and shared between the partners of the mesh. i.e. All APs in the mesh really like to use channel 6. Even though the wired one was hard set to be channel 3, and the other 2 were put on auto. At one time, all 5 APs chose channel 6.
Are you using the 3.6.2 build 1398 on the AP One AC mini hw1? We found that 3.6.2b01 mesh connection have compatibility issue with 3.7.3 and 3.8.1 AP One firmware and fixed the issue in latest RC firmware.
If you are already using the RC firmware on both Mini and AX, could you please help to open a support ticket with diagnostic reports from both APs? We can check the root cause from them.
Interesting following along in this. I suggest you allow all the access points to acquire their address from the B1 using DHCP reservations. Let the system work until you get it connected, then tweak for performance later.
I agree with your strategy of manually selecting wifi channels in general, but in this case I suggest you allow that to work automatically as well. The worst that can happen is reduced data speed due to channel saturation.
I am going pretty much by trial and error, and I am learning as I go. Some of what I was seeing with the channel selection was due to the mesh settings. I am assuming that 2 APs connected by mesh will use the same channels. So, currently with my mesh of 1 wired and 2 non-wired APs - all three of them are using channel 3 for the 2.4Ghz antenna.
I see where you are going with the “let the APs pull a DHCP address” stuff, but that is kind of cheating. Forcing them to broadcast the DHCP request would most likely result in connectivity working up until the ARP cache expired on the mac doing the testing.
One thing that I did find a bit odd is that with my three AP mesh, I would expect only two connections. I was expecting just a connection from each non-wired AP to the wired AP. What I am finding is that there is an additional connection established between each non-wired AP to the other non-wired AP.
Wired AP - AP_Alpha
Non-wired APs - AP_Beta and AP_Charlie
But, as I wrote this reply - I went and checked and the unexpected connections have released and now it is only connected via the “expected” connections. Very odd.
All in all, it is behaving the way I want and appears to be fairly reliable. I haven’t had any issues with client connectivity and my wifi coverage has increased in the areas I was trying to cover. Happy days.