This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
- Extreme Networks
- Community List
- Wireless
- ExtremeWireless (WiNG)
- AP-7522 Client Bridging Isn't Working
Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
AP-7522 Client Bridging Isn't Working
AP-7522 Client Bridging Isn't Working
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
11-09-2018 12:29 PM
I have two AP-7522 access points. Both have version 5.9.1.4-004R. Both receive their power and network through a Symbol AP-PSBIAS-2P2-AFR "brick". I set the country name to "United States-us" on both because I read the radios will not turn on until you do.
AP#1 - This is the "host" access point connected to the wired LAN with access to the internet. The internal network is 192.168.1.0/24. I've given this AP the IP address 192.168.1.101. I configured a wireless network with SSID "myWireless", Secure-PSK, WPA2-CCMP, and the key is "myWirelessKey". Radio 1 is 2.4GHz, radio 2 is 5GHz.
AP#2 - This is the "client" access point that I want to bridge to AP#1. I have AP#2 connected to an unmanaged 5 port switch, which also connects a desktop PC. It's this desktop PC that needs access to the internet. I've given this AP the IP address 192.168.1.101. For the bridging configuration I followed the directions here (https://extremeportal.force.com/ExtrArticleDetail?an=000082884)
- en
- conf t
- profile
- interface radio 2
- rf-mode bridge
- bridge ssid myWireless
- bridge vlan 1
- bridge encryption-type ccmp
- bridge authentication-type none
- bridge wpa-wpa2 psk 0 myWirelessKey
- no bridge eap username
- no bridge eap password
- bridge eap type peap-mschapv2
- bridge roam-criteria missed-beacons 20
- bridge roam-criteria rssi-threshold -75
- bridge channel-list 5GHz 36,40,44,48
- bridge channel-list 2.4GHz
- comm wr
However when I run "show wireless bridge candidate-ap" it reports 0 candidate APs. AP#1 shows no wireless clients. The workstation can successfully ping AP#2 and vice versa. I am able to reach the web interface and ssh on AP#1 on the 192.168.1.0/24 network. But AP#1 can't ping AP#2 and vice versa. Nothing on the 192.168.1.0/24 network can ping AP#2 or the desktop PC. The desktop PC cannot reach anything on the 192.168.1.0/24 network.
Right now both APs are in the same room, 10 feet from each other, no physical obstacles between them.
In my searching I also found (https://extremeportal.force.com/ExtrArticleDetail?an=000063492) I tried the solution there but it didn't help.
Does anyone know what I'm doing wrong, or what I'm missing?
Additional questions:
1 - Do I have to configure any bridging properties on the AP#1 that is connected to the wired network with internet access? None of the guides I've read mention anything about configuration on the "host" AP, but since I can't get this working I'm wondering if some configuration is necessary on AP#1.
2 - Do I have to load a special firmware version to be able to access bridging configuration in the web GUI? Right now none of those configuration options are there and I have to do everything through ssh/command line. I know this was the case for some APs in the past that didn't have a web GUI at all and you had to download the firmware that included the GUI.
Thanks for any help you can provide!
Aaron
44 REPLIES 44
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
11-14-2018 06:50 PM
Aaron, good to hear that there's at least connectivity at this point using the client-bridge. Based on your information, I'm still not sure if the AP has a hardware problem or not, but the fact that it has established a connection while operating as the host AP seems to make that unlikely.
It would be interesting to default things again and re-setup the APs again in their original positions, with the only change being the WiNG code. If it works...then that seems to implicate the WiNG code...but then I'm at a loss because in my lab, using the original same firmware, it worked. The *only* difference being that I used a 7532 and you're using a 7522.
Regarding #3 though:
Win10 apparently thinks there's an IP conflict. Guessing that's the reason it's throwing away its static address.
Need to clear out the ARP cache and try again. I think you're almost there.
It would be interesting to default things again and re-setup the APs again in their original positions, with the only change being the WiNG code. If it works...then that seems to implicate the WiNG code...but then I'm at a loss because in my lab, using the original same firmware, it worked. The *only* difference being that I used a 7532 and you're using a 7522.
Regarding #3 though:
Win10 apparently thinks there's an IP conflict. Guessing that's the reason it's throwing away its static address.
Need to clear out the ARP cache and try again. I think you're almost there.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
11-14-2018 06:44 PM
Some more information: I had a packet capture running on the Windows 10 workstation for a while. I see an ARP response from that B8-50-01-EC-D8-B0 MAC address stating that it belonged to 192.168.111.10.
I figured that the arp entry for the 192.168.111.10 address was still cached from when I had the workstation directly connected to the wired network and not though the 5 port switch / wireless client bridge. So I'm restarting both APs to clear their arp tables.
I figured that the arp entry for the 192.168.111.10 address was still cached from when I had the workstation directly connected to the wired network and not though the 5 port switch / wireless client bridge. So I'm restarting both APs to clear their arp tables.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
11-14-2018 06:35 PM
Ok I've made some progress. #3 is what I need the most help on right now.
1 - The client bridge is partially successful right now. I switched the roles so now AP#2 is the "host" AP that is connected to the wired LAN, and AP#1 is the client bridge. I updated to firmware version 5.9.3 on both APs. I also have 1 antenna plugged into each AP. The client bridge reports that there is 1 candidate AP, and the "host" AP reports the client bridge AP as a wireless client. I introduced several variables here. If I get a chance later I'll factory reset both APs, remove all the antennas and try to set up the client bridge again with their original roles and report back. I know others might like to know if the firmware upgrade is what fixed the problem or not.
2 - Lesson learned: For a while I had both APs connected to the wired network so I could ssh into them instead of using the console port for terminal access. But once I got the client bridge successfully configured, that created a network loop / broadcast storm and brought down the network until I unplugged the client bridge AP from the wired network. The client bridge AP is connected to the 5 port unmanaged switch again, and the only other device connected to that is the Windows 10 workstation that needs internet access.
3 - The desktop on the "client bridge" side can't reach the rest of the 192.168.111.0/24 network or the internet. It is a Windows 10 workstation with a static IP address of 192.168.111.10. When I plug it directly into the wired network (not the 5 port unmanaged switch) everything works correctly. However when I re-attach it to the unmanaged 5 port switch that the client bridge AP is connected to, it self assigns a 169.254.x.y address instead of keeping its 192.168.111.10 address. There are errors in the Windows 10 event log "The system detected an address conflict for IP address 192.168.111.10 with the system having network hardware address B8-50-01-EC-D8-B0. Network operations on this system may be disrupted as a result." B8-50-01-EC-D8-B0 is the same MAC address I was seeing in packet captures during the network loop problem. I don't know where that's coming from because it doesn't match any of the 2 MAC addresses that AP#1 reports or the 2 MAC addresses that AP#2 reports when I run "show interface brief". But "B8-50-01" is registered to Extreme Networks.
Thoughts?
1 - The client bridge is partially successful right now. I switched the roles so now AP#2 is the "host" AP that is connected to the wired LAN, and AP#1 is the client bridge. I updated to firmware version 5.9.3 on both APs. I also have 1 antenna plugged into each AP. The client bridge reports that there is 1 candidate AP, and the "host" AP reports the client bridge AP as a wireless client. I introduced several variables here. If I get a chance later I'll factory reset both APs, remove all the antennas and try to set up the client bridge again with their original roles and report back. I know others might like to know if the firmware upgrade is what fixed the problem or not.
2 - Lesson learned: For a while I had both APs connected to the wired network so I could ssh into them instead of using the console port for terminal access. But once I got the client bridge successfully configured, that created a network loop / broadcast storm and brought down the network until I unplugged the client bridge AP from the wired network. The client bridge AP is connected to the 5 port unmanaged switch again, and the only other device connected to that is the Windows 10 workstation that needs internet access.
3 - The desktop on the "client bridge" side can't reach the rest of the 192.168.111.0/24 network or the internet. It is a Windows 10 workstation with a static IP address of 192.168.111.10. When I plug it directly into the wired network (not the 5 port unmanaged switch) everything works correctly. However when I re-attach it to the unmanaged 5 port switch that the client bridge AP is connected to, it self assigns a 169.254.x.y address instead of keeping its 192.168.111.10 address. There are errors in the Windows 10 event log "The system detected an address conflict for IP address 192.168.111.10 with the system having network hardware address B8-50-01-EC-D8-B0. Network operations on this system may be disrupted as a result." B8-50-01-EC-D8-B0 is the same MAC address I was seeing in packet captures during the network loop problem. I don't know where that's coming from because it doesn't match any of the 2 MAC addresses that AP#1 reports or the 2 MAC addresses that AP#2 reports when I run "show interface brief". But "B8-50-01" is registered to Extreme Networks.
Thoughts?
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
11-13-2018 10:07 PM
You could try that...since we're dealing with an unknown issue here though, I can't say how exactly it will behave...even if it IS a hardware issue. Won't hurt to try though.
When you make the switch though, setup the PSK and SSID to match that of existing APs on other *working* network where you're at though. If the AP isn't currently close enough to those other APs to be able to see them and connect, then go ahead and implement the configurations on the AP and then carry it to where it needs to be...along with your laptop and console cable so you can run those queries to see if it now sees candidate host APs.
When you make the switch though, setup the PSK and SSID to match that of existing APs on other *working* network where you're at though. If the AP isn't currently close enough to those other APs to be able to see them and connect, then go ahead and implement the configurations on the AP and then carry it to where it needs to be...along with your laptop and console cable so you can run those queries to see if it now sees candidate host APs.
