Header Only - DO NOT REMOVE - Extreme Networks
Question

AP7532 Client Bridge Not connecting to host


I have 2 AP7532s and I'm trying to set up the 2nd to connect to an existing WiFi network. Ultimately, the 2nd 7532 would connect to a completely different WiFi network not associated with a 7532 (though it could be, I suppose).

The 2nd 7532 is not connecting to the original wifi network. I have Radio2 in bridge mode, with the SSID and PSK entered, but the radio does not show that it is connected and the host does not show the 2nd AP as a client. What critical step am I missing?

19 replies

Userlevel 4
Did you set the country code in the RFDomain? If not, neither of the radios will turn on.
The country code has been set. Radio1 on the 2nd AP (the one that Radio2 is not working for the bridge) is successfully broadcasting a WLAN as a test.
Userlevel 4
Okay...so when setting up the AP to operate in client-bride mode, that is really all that should be needed.
- Country code-Just to enable the radios
- RFmode set to Bridge
- Client Bridge Settings - Specify SSID and whatever authentication the WLAN uses

So easiest things first:
Can you grab a shot of the output of the command:
#show event history

Also, what version of WiNG is running on the 7532?

Wing is v5.9

Here is the show event-history output:

Generated on '2018-11-06 15:30:31 GMT-6' by 'admin'

2018-11-06 15:30:01 FSDclient SYSTEM LOGIN Successfully logged in user 'admin' with privilege 'superuser' from 'ssh'
2018-11-06 15:25:13 FSDclient NSM DHCPIP Interface vlan3 acquired IP address 192.168.3.18/25 via DHCP
2018-11-06 15:25:13 FSDclient NSM DHCPDEFRT Default route with gateway 192.168.3.1 learnt via DHCP
2018-11-06 15:24:24 FSDclient SYSTEM WARM_START_RECOVER Warm Start Recover. Reason: 'reload' command issued from CLI (user: admin) Timestamp: Nov 06 15:21:50 2018
2018-11-06 15:24:10 FSDclient NSM NTP_START NTP Daemon Restarted
2018-11-06 15:23:11 FSDclient DIAG NEW_LED_STATE LED state message RADIO_1_24G_LED_ON from module DOT11
2018-11-06 15:23:11 FSDclient RADIO RADIO_STATE_CHANGE Radio 'FSDclient:R1' changing state from 'Initializing' to 'On'
2018-11-06 15:23:10 FSDclient DIAG NEW_LED_STATE LED state message RADIO_1_24G_LED_ON from module DOT11
2018-11-06 15:23:10 FSDclient RADIO RADIO_STATE_CHANGE Radio 'FSDclient:R1' changing state from 'Off' to 'Initializing'
2018-11-06 15:23:09 FSDclient DIAG NEW_LED_STATE LED state message RADIO_1_24G_NOT_CONFIG from module DOT11
2018-11-06 15:23:09 FSDclient RADIO RADIO_STATE_CHANGE Radio 'FSDclient:R1' changing state from 'Calibrate' to 'Off(config update)'
2018-11-06 15:23:07 FSDclient DIAG NEW_LED_STATE LED state message RADIO_1_24G_LED_ON from module DOT11
2018-11-06 15:23:07 FSDclient RADIO RADIO_STATE_CHANGE Radio 'FSDclient:R1' changing state from 'Off' to 'Calibrate'
2018-11-06 15:23:06 FSDclient DIAG NEW_LED_STATE LED state message RADIO_1_24G_NOT_CONFIG from module DOT11
2018-11-06 15:23:06 FSDclient RADIO RADIO_STATE_CHANGE Radio 'FSDclient:R1' changing state from 'Calibrate' to 'Off(config update)'
2018-11-06 15:23:04 FSDclient DIAG NEW_LED_STATE LED state message RADIO_1_24G_LED_ON from module DOT11
2018-11-06 15:23:04 FSDclient RADIO RADIO_STATE_CHANGE Radio 'FSDclient:R1' changing state from 'Off' to 'Calibrate'
2018-11-06 15:23:03 FSDclient DIAG NEW_LED_STATE LED state message RADIO_1_24G_NOT_CONFIG from module DOT11
2018-11-06 15:23:03 FSDclient RADIO RADIO_STATE_CHANGE Radio 'FSDclient:R1' changing state from 'Calibrate' to 'Off(config update)'
2018-11-06 15:23:01 FSDclient DIAG NEW_LED_STATE LED state message RADIO_1_24G_LED_ON from module DOT11
2018-11-06 15:23:01 FSDclient RADIO RADIO_STATE_CHANGE Radio 'FSDclient:R1' changing state from 'Off' to 'Calibrate'
2018-11-06 15:23:00 FSDclient DIAG NEW_LED_STATE LED state message RADIO_1_24G_NOT_CONFIG from module DOT11
2018-11-06 15:23:00 FSDclient RADIO RADIO_STATE_CHANGE Radio 'FSDclient:R1' changing state from 'Calibrate' to 'Off(config update)'
2018-11-06 15:23:00 FSDclient DIAG NEW_LED_STATE LED state message RADIO_1_24G_LED_ON from module DOT11
2018-11-06 15:23:00 FSDclient RADIO RADIO_STATE_CHANGE Radio 'FSDclient:R1' changing state from 'Off' to 'Calibrate'
2018-11-06 15:22:59 FSDclient DIAG NEW_LED_STATE LED state message RADIO_1_24G_NOT_CONFIG from module DOT11
2018-11-06 15:22:59 FSDclient RADIO RADIO_STATE_CHANGE Radio 'FSDclient:R1' changing state from 'On' to 'Off(smart calibration)'
2018-11-06 15:22:53 FSDclient DIAG NEW_LED_STATE LED state message LED_POWER_OFF from module DOT11
2018-11-06 15:22:53 FSDclient RADIO RADIO_STATE_CHANGE Radio 'FSDclient:R2' changing state from 'Bridge' to 'On'
2018-11-06 15:22:53 FSDclient DIAG NEW_LED_STATE LED state message LED_POWER_OFF from module DOT11
2018-11-06 15:22:53 FSDclient RADIO RADIO_STATE_CHANGE Radio 'FSDclient:R2' changing state from 'Initializing' to 'Bridge'
2018-11-06 15:22:53 FSDclient DIAG NEW_LED_STATE LED state message LED_POWER_OFF from module DOT11
2018-11-06 15:22:53 FSDclient RADIO RADIO_STATE_CHANGE Radio 'FSDclient:R2' changing state from 'Off' to 'Initializing'
2018-11-06 15:22:52 FSDclient DIAG NEW_LED_STATE LED state message LED_POWER_OFF from module DOT11
2018-11-06 15:22:52 FSDclient RADIO RADIO_STATE_CHANGE Radio 'FSDclient:R2' changing state from 'On' to 'Off(cb reconfig)'
2018-11-06 15:22:50 FSDclient DIAG NEW_LED_STATE LED state message LED_POWER_OFF from module DOT11
2018-11-06 15:22:50 FSDclient DIAG NEW_LED_STATE LED state message LED_POWER_OFF from module DOT11
2018-11-06 15:22:50 FSDclient RADIO RADIO_STATE_CHANGE Radio 'FSDclient:R2' changing state from 'Bridge' to 'On'
2018-11-06 15:22:50 FSDclient DIAG NEW_LED_STATE LED state message LED_POWER_OFF from module DOT11
2018-11-06 15:22:50 FSDclient RADIO RADIO_STATE_CHANGE Radio 'FSDclient:R2' changing state from 'Initializing' to 'Bridge'
2018-11-06 15:22:50 FSDclient RADIO RADIO_STATE_CHANGE Radio 'FSDclient:R2' changing state from 'On' to 'Initializing'
2018-11-06 15:22:50 FSDclient DIAG NEW_LED_STATE LED state message RADIO_1_24G_LED_ON from module DOT11
2018-11-06 15:22:50 FSDclient RADIO RADIO_STATE_CHANGE Radio 'FSDclient:R1' changing state from 'Initializing' to 'On'
2018-11-06 15:22:49 FSDclient DIAG NEW_LED_STATE LED state message RADIO_1_24G_LED_ON from module DOT11
2018-11-06 15:22:49 FSDclient RADIO RADIO_STATE_CHANGE Radio 'FSDclient:R1' changing state from 'On' to 'Initializing'
2018-11-06 15:22:48 FSDclient DIAG NEW_LED_STATE LED state message LED_POWER_OFF from module DOT11
2018-11-06 15:22:48 FSDclient RADIO RADIO_STATE_CHANGE Radio 'FSDclient:R2' changing state from 'Bridge' to 'On'
2018-11-06 15:22:48 FSDclient DIAG NEW_LED_STATE LED state message LED_POWER_OFF from module DOT11
2018-11-06 15:22:48 FSDclient RADIO RADIO_STATE_CHANGE Radio 'FSDclient:R2' changing state from 'Initializing' to 'Bridge'
2018-11-06 15:22:48 FSDclient DIAG NEW_LED_STATE LED state message LED_POWER_OFF from module DOT11
2018-11-06 15:22:48 FSDclient RADIO RADIO_STATE_CHANGE Radio 'FSDclient:R2' changing state from 'Unconfigured' to 'Initializing'
2018-11-06 15:22:48 FSDclient DIAG NEW_LED_STATE LED state message RADIO_1_24G_LED_ON from module DOT11
2018-11-06 15:22:48 FSDclient RADIO RADIO_STATE_CHANGE Radio 'FSDclient:R1' changing state from 'Initializing' to 'On'
2018-11-06 15:22:48 FSDclient DIAG NEW_LED_STATE LED state message RADIO_1_24G_LED_ON from module DOT11
2018-11-06 15:22:48 FSDclient RADIO RADIO_STATE_CHANGE Radio 'FSDclient:R1' changing state from 'Unconfigured' to 'Initializing'
2018-11-06 15:22:48 FSDclient NSM NTP_START NTP Daemon Started
2018-11-06 15:22:48 FSDclient MESH MESHPOINT_LOOP_PREVENT_OFF Meshpoint loop prevention off (port ALL), all wired traffic is allowed
2018-11-06 15:22:48 FSDclient DIAG NEW_LED_STATE LED state message AP_LEDS_ON from module DOT11
2018-11-06 15:22:48 FSDclient DIAG NEW_LED_STATE LED state message LED_COUNTRY_CODE_SET from module DOT11
2018-11-06 15:22:48 FSDclient DOT11 COUNTRY_CODE Country of operation configured to US [United States]
2018-11-06 15:22:46 FSDclient DIAG NEW_LED_STATE LED state message LED_LOCATIONING_OFF from module cfgd
2018-11-06 15:22:45 FSDclient SYSTEM SYSTEM_AUTOUP_ENABLE Autoupgrade enabled for ap7562
2018-11-06 15:22:45 FSDclient DIAG NEW_LED_STATE LED state message LED_LOCAL_LICENSE from module CFGD
2018-11-06 15:22:45 FSDclient SYSTEM SYSTEM_AUTOUP_ENABLE Autoupgrade enabled for ap7522
2018-11-06 15:22:45 FSDclient DIAG NEW_LED_STATE LED state message LED_LOCAL_LICENSE from module CFGD
2018-11-06 15:22:45 FSDclient SYSTEM SYSTEM_AUTOUP_ENABLE Autoupgrade enabled for ap7532
2018-11-06 15:22:45 FSDclient LICMGR LIC_INSTALL_DEFAULT AP default license installed, count: 64
2018-11-06 15:22:45 MGMT LOG_HTTP_START lighttpd started in external mode
2018-11-06 15:22:45 DHCPSVR DHCPSVR_STOP DHCP server is stopped
2018-11-06 15:22:44 SYSTEM CONFIG_REVISION Configuration revision updated to 3 from 2
2018-11-06 15:22:44 SYSTEM CONFIG_REVISION Configuration revision updated to 2 from 1
2018-11-06 15:22:44 SYSTEM CONFIG_COMMIT Configuration commit by user 'cfgd' (read startup-config) from '127.0.0.1'
2018-11-06 15:22:44 CFGD ACL_ATTACHED_ALTERED USER: cfgd session 1: ACL attached to interface pppoe1 is getting altered
2018-11-06 15:22:46 NSM IFUP Interface ge1 is up
2018-11-06 15:22:44 CFGD ACL_ATTACHED_ALTERED USER: cfgd session 1: ACL attached to interface pppoe1 is getting altered
2018-11-06 15:22:44 CFGD ACL_ATTACHED_ALTERED USER: cfgd session 1: ACL attached to interface vlan3 is getting altered
2018-11-06 15:22:45 NSM IFDOWN Interface ge1 is down
2018-11-06 15:22:44 CFGD ACL_RULE_ALTERED USER: cfgd session 1: ACL PERMIT-ARP-AND-IPv4 rule is getting altered
2018-11-06 15:22:45 NSM IFUP Interface vlan1 is up
2018-11-06 15:22:44 CFGD ACL_RULE_ALTERED USER: cfgd session 1: ACL BROADCAST-MULTICAST-CONTROL rule is getting altered
Userlevel 4
I can see in the logs that the radio is changing state from 'bridged' to 'on'.
Not sure if maybe there's something else in the config that I'm not aware that might be causing this though.
What specific version of WiNG-5.9 is this? 5.9.0? 5.9.1? 5.9.2? 5.9.3?
AP7532 version 5.9.1.2-006R
Userlevel 4
Okay. Not finding any bugs that relate to this that are known to exist in 5.9.1.0.
At this point, I'd need to see the full config to see if maybe there's something else configured that is causing this.
Is the AP otherwise default? (just have it configured to operate as a client-bridge and nothing else setup?
The AP was default. I configured the ge1 port and a virtual interface to connect the wired port to the existing LAN for management purposes, configured NTP, and then eventually added a WLAN on radio1 to verify that radio was working and I could see its broadcast.

How can I get you the full config, or is that beyond the support of this forum?
Userlevel 4
just for grins, run:
#show wireless bridge candidate-ap
Chris Kelly wrote:

just for grins, run:
#show wireless bridge candidate-ap

show wireless bridge candidate-ap 84-24-8D-A5-2E-10 Client Bridge Candidate APs: AP-MAC BAND CHANNEL SIGNAL(dbm) STATUS Total number of candidates displayed: 0 Total number of client bridges displayed: 1
Userlevel 4
Chris Kelly wrote:

just for grins, run:
#show wireless bridge candidate-ap

Okay...so this leads us closer to the problem.
You can see there in the ouput that there are 0 candidate APs. These 'candidate APs' are APs that the bridge can see and potentially connect to.

So either the SSID that you configured isn't being used by any of your APs around the bridge...or if it is, then the signal strength is so weak that it cannot see them.
Userlevel 4
If in the CLI, just run:
# show running-config (before posting, edit out your PSK if it's in clear-text)

or in the UI, goto the Dashboard and expand the tree until you see the AP icon. Click on the chevron to the right of the AP name and you should see an option for 'Show running-config'. This will open a new small window. In that window, you can just highlight the config and copy it.
I poked around a little bit, there must have been some misconfiguration with the channels allowed. I matched the configs between the two APs regarding this and things seem to be connected. I'm sure I'll have to routing issues next, but that's beyond the scope of this thread. Thanks for the help, Chris!
Aaron Becker wrote:

I poked around a little bit, there must have been some misconfiguration with the channels allowed. I matched the configs between the two APs regarding this and things seem to be connected. I'm sure I'll have to routing issues next, but that's beyond the scope of this thread. Thanks for the help, Chris!

Can you share some details regarding what you changed specifically? I'm having the same problem as you but I can't get it working.

I've tried specifying a channel list for 2.4GHz and 5GHz. I've tried removing them completely too.

Did you use the fix from this page?
https://gtacknowledge.extremenetworks.com/articles/Solution/AP7522-Client-Bridge-not-able-to-making-...
Aaron Becker wrote:

I poked around a little bit, there must have been some misconfiguration with the channels allowed. I matched the configs between the two APs regarding this and things seem to be connected. I'm sure I'll have to routing issues next, but that's beyond the scope of this thread. Thanks for the help, Chris!

It ended up being a bit more complicated... regrettably. By that point, I had changed a ton of settings related to other stuff and wanted to start with a fresh config, so that's what I did.

After that, it still wasn't working as i hoped. I then set up an old 7131 on a different WLAN and SSID so i could test without disrupting production stuff. I did find that link you posted above to be slightly helpful in leading down the path, ultimately I found with the 7131 and 7532 (or 2x 7532) the "jumping" as I suspect was the issue. I'm a huge amateur at this and someone may come along with better explanations.

On the "receiving" AP - I went into the radio2 interface (config t, profile ap7532 profilename, in radio2) and did as the above article said.

Under "rfdomain" and basic tab - I also unchecked dynamic channel - but I don't know for sure this was or wasn't causing issues, but that's how I have it configured as it stands now. I made this change on both APs.

I noticed the first night I tested the bridge it kept its connection all night long - now it seems to be maxing out at around 1-2 hours (when I run a show wireless bridge stat). I haven't tested anything in production. The main thing I'm trying to test here is connectivity to multiple host APs, so I hope to transition this back into production side eventually.

Hopefully my rambles weren't too much to digest - let me know if I can be of any help as I t-shoot this as an ongoing experiment!
Aaron Becker wrote:

I poked around a little bit, there must have been some misconfiguration with the channels allowed. I matched the configs between the two APs regarding this and things seem to be connected. I'm sure I'll have to routing issues next, but that's beyond the scope of this thread. Thanks for the help, Chris!

Thanks for that information!

I only started investigating how to set up a client bridge yesterday, but I've been wondering if anything needed to be configured on the "receiving" AP. None of the articles I've found mention that it's necessary.

I've had to do everything through ssh/command line because the web GUI plain doesn't have these options available and I don't know why.

Not a very user friendly configuration, that's for sure.
Userlevel 4
Aaron Becker wrote:

I poked around a little bit, there must have been some misconfiguration with the channels allowed. I matched the configs between the two APs regarding this and things seem to be connected. I'm sure I'll have to routing issues next, but that's beyond the scope of this thread. Thanks for the help, Chris!

Aaron B,
You're correct in that nothing needs to be done on the infrastructure AP side. When one of these APs is configured to operate in client-bridge mode, they are then behaving just like a wireless client device (granted, a much more expensive and better performing one...but the same behaviors). Just like any client, you tell it the SSID, you give it the authentication credentials, and it connects. Done.

As for as the channel setup, since the client-bridge is operating like a regular client, you simply want it to scan all the channels, just like a regular laptop/phone client, right? You *could* statically assign a single channel or subset of channels...but just know that you are then confining the client-bridge AP to only be able to discover other APs that operate on those same channels.

Aaron W,
Regarding the configuration in CLI - In the early days when the client-bridge feature was introduced, all of the configuration work was done in the CLI. Since that time though, an AP can be setup completely from the GUI. (diagnostics/queries are still run from the CLI though, for troubleshooting).

You say that you're GUI doesn't have these options....what version of WiNG is running on the AP? If it's older, that would explain it. There's also a history where only certain APs supported the client-bridge option based on the version of WiNG (APs that previously didn't officially support client-bridge mode were later supported after newer versions of WiNG were released).

FYI: Client-bridge supported started in WiNG-5.8.5. WiNG-5.9.3.0 is the current release. There have been various fixes for different client-bridge issues since the initial release.
Aaron Becker wrote:

I poked around a little bit, there must have been some misconfiguration with the channels allowed. I matched the configs between the two APs regarding this and things seem to be connected. I'm sure I'll have to routing issues next, but that's beyond the scope of this thread. Thanks for the help, Chris!

Again, this could be due to my inexperience, but at one point I had some weird channel lists showing up in the general config (not in the profile for the AP) at the bottom of the running config under AP7532-XX-XX-XX-XX-XX-XX, and removing or changing them didn't help. I don't even know how I got them there, I'm guessing via the CLI before i correctly entered into the interface.

My only fear is that while I know my infrastructure AP is set to "smart" or "all channel" mode - I don't know which other infrastructure APs may be set to (and may not have access in the application I'm trying to bridge in). I could scan the environment, but I was hoping to steer away from this. Time will tell.
Userlevel 4
That's certainly a potential cause for the client-bridge AP to not be able to find any candidate APs. If the channels it's searching on don't coincide with the candidate APs operating channels...well, they wouldn't be found - and you'd be seeing exactly what you were seeing.
Nice work noticing that detail though.

Reply