GWN local master/slave issue

#1

I have a client that has a couple of buildings (main and annex) where I have installed a client bridge between the two with the master at the main and the client at the annex. The client bridge has its own unique SSID. The models are GWN 7600LR running in 5g only and the bridge works quite well except when -

On the annex side, there is an additional 7600LR operating in AP mode that is outside on a different SSID than the bridge and with a different master (or even in a standalone mode as its own master) that when I bring it on-line, it manages to somehow take the client AP for the bridge down (off-line) so that the link between the 2 buildings is broken. The purpose of this other AP is to accommodate the folks who walk between the two buildings so that they continue to have WiFi service.

The internal APs in both buildings are running the same SSID (gwn7615 and Draytek 903c) and it was the desire to have the one external 7600 also on the same SSID as a slave to one of the 7615 so that fast roaming would occur as one exited a building to go to the other one.

I am just missing why one 7600 configured completely different from the bridge would have an impact on the client side of the bridge and cause it to go off-line.

I am still planning to test more today, but ran out of time yesterday. It’s like there is a loop, but I am not grasping how yet.

Any thoughts appreciated.

#2

Maybe you added SSID to this extra GWN with same name?
try set channel manually in link and move to some extreme where there is nothing, can be bug and it catch on same channel.
As for one going down -> rogue AP detection ?
Really hard to advice;-) lack of data

#3

Same SSID, no. The client bridge SSID is TMF_Link and only the one. The other is TMF Enterpise.
Bridge set manually to 5g only ch 48, Other set to dual, different channels with different authentication and all APs are set security wise with others as friendly for rouge.

#4

I don’t know if it could be the same thing,
I noticed that if I entered 2 similar but different things on GWN (for example 2 different SSIDs with the same wifi pswd, the SSID was deactivated and I didn’t understand why.

It’s true that putting 2 different SSIDs with the same pswd doesn’t make much sense, but in any case it created this problem for me. (I wasted a lot of time before figuring out what the problem was)
And I’m talking about latest FW.

I wouldn’t want a similar situation to exist in your case.

#5

@lpneblett
When the AP fails to connect and the route fails, what Ip does the far end (annex) obtain?

What is providing the IP addresses?
where is the DHCP server?
Is it for both networks far (annex) and local (main) ends?

If the DHCP server is at the local end (main), and the far end (annex) network receives no IP addresses due to the break, what IP’s if any are assigned to that network due to said AP failure.169’s?

Is the network topology like this?

MAIN
DHCP server at main
Master AP 1 in main network
Slave AP 1 in main network

SLAVE
Master AP 2 in annex network
Slave AP 2 in annex network

In the above is the following true ?
Interconnection from Slave AP 1 to Master AP 2 via cabling?

If it is then the communications for interconnecting AP’s and the physical connection from the Slave AP 1 to the Master AP 2 is trying to add the Master AP 2 as a slave to the main building perhaps breaking the route connection.
You may need a dedicated router between the 2 x buildings.

#6

There is one DHCP server that handles the IP issue for both the annex and main, but for the client/slave AP for the link, it is statically set in addition to the reservation in the router given that the router comes up before the AP and I worry that the router might otherwise issue out. It is required in bridge mode for the slave to have static.

Topology *(numbers represent qty of AP)-
MAIN
DHCP server at main
Master AP 1 for bridge (SSID -TMF_Link)
Master AP 1 for Internal WiFi at both annex and main SSID (TMF Enterprise)
Slave AP 2 for Internal WiFI

Annex
Slave AP 1 for bridge TMF_Link (TMF_Link)
Slave AP 4 for Internal WiFi (TMF Enterprise)

I suppose it possible that the master of one SSID is trying to hijack a slave from a different one, but if such is the case, then that seems to defeat the function of adoption. I assume that once the client link for the bridge is adopted by the master, then it is out of play for adoption by another master unless and until the other master uses the takeover function.

#7

This is what I suspect that one of the Master AP’s is trying to take over the role for all AP discovery and allocate slave role to the others. It might be an undocumented feature (bug) that you are facing.