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 (Identifi)
- RE: Wireless clients sporadically getting Limited ...
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
Wireless clients sporadically getting Limited Connectivity, APs dropping packets
Wireless clients sporadically getting Limited Connectivity, APs dropping packets
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
01-25-2016 02:32 PM
We have a pair of V2110 wireless controllers and around 400 3825i access points. Controller firmware is 09.21.06.0002. AP firmware is 9.21.27.1387X.
About 4 months ago we noticed a problem where the APs would just drop traffic. A packet capture will show a ping coming into the radio from the client, going out the Eth interface on the AP, the reply coming back into the Eth interface, and never going out of the radio.
A particularly strange detail is that this only happens with certain source/destination traffic. For instance a client cant ping the gateway of 10.1.20.1/24. but cannot pint the server at 10.1.20.2. Since we can see the ping making it to the server and the ping reply making it back to the AP, we know it's not a firewall/ACL/routing issue on any other part of the network. The traffic disappears at the AP. Clients cannot communicate with anything on the Internet or any of our servers (DNS, DHCP, etc.) during this time. They can ping gateways in any subnet but that's it; everything else is failed.
More details:
-We've gone through several firmware updates with GTAC. Nothing has helped.
-The issue can affect any client on any AP in any location at any time.
-The issue is intermittent; it may happen every few minutes or once per month to a particular client in a particular area. Once failed it may last for seconds or days.
-While it's affecting one client, other clients on the AP may be working fine or may also fail.
-It can happen on either 2.4 or 5.7GHz.
-It can affect any type of client (phone, laptop, tablet) and any OS.
-Restarting the client or AP will sometimes fix the issue, sometimes not.
-It happens with our without using NAC, or any other type of authentication. It happens on completely open networks as well.
-It happens on both bridged at AP and bridged at controller topologies.
-It's not limited to a particular subnet or VLAN.
-It happens with or without Flexible Client Access enabled.
-It happens on either controller.
-GTAC hasn't made much progress on the issue in 4 months.
About 4 months ago we noticed a problem where the APs would just drop traffic. A packet capture will show a ping coming into the radio from the client, going out the Eth interface on the AP, the reply coming back into the Eth interface, and never going out of the radio.
A particularly strange detail is that this only happens with certain source/destination traffic. For instance a client cant ping the gateway of 10.1.20.1/24. but cannot pint the server at 10.1.20.2. Since we can see the ping making it to the server and the ping reply making it back to the AP, we know it's not a firewall/ACL/routing issue on any other part of the network. The traffic disappears at the AP. Clients cannot communicate with anything on the Internet or any of our servers (DNS, DHCP, etc.) during this time. They can ping gateways in any subnet but that's it; everything else is failed.
More details:
-We've gone through several firmware updates with GTAC. Nothing has helped.
-The issue can affect any client on any AP in any location at any time.
-The issue is intermittent; it may happen every few minutes or once per month to a particular client in a particular area. Once failed it may last for seconds or days.
-While it's affecting one client, other clients on the AP may be working fine or may also fail.
-It can happen on either 2.4 or 5.7GHz.
-It can affect any type of client (phone, laptop, tablet) and any OS.
-Restarting the client or AP will sometimes fix the issue, sometimes not.
-It happens with our without using NAC, or any other type of authentication. It happens on completely open networks as well.
-It happens on both bridged at AP and bridged at controller topologies.
-It's not limited to a particular subnet or VLAN.
-It happens with or without Flexible Client Access enabled.
-It happens on either controller.
-GTAC hasn't made much progress on the issue in 4 months.
157 REPLIES 157
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
06-01-2016 06:04 PM
I have read complete post, can anyone give a final resolution on clients disconnecting frequently on identifi wireless.
I am having the issue from 1 year , I have done several up gradations currently running C5210 controllers and 3805i AP's on software version 9.21.8.x.
I am having the issue from 1 year , I have done several up gradations currently running C5210 controllers and 3805i AP's on software version 9.21.8.x.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
06-01-2016 06:04 PM
In the recommended settings for my environment is to set the DTIM to 2 we have not had problems for a few months. 3825i on V2110 09.21.09.0004. I believe Our issues were fixed in the 09.21.07.
Honestly I believe most of these issues are RF settings based. Co-Channel interference or due to ATPC being enabled and Dynamic Channel Selection set to active mode. Enabling both for 60min when we add a new ap in a building other than that we disable it. You really have to pay attention to what values you set for DCS.
https://gtacknowledge.extremenetworks.com/articles/Q_A/What-are-the-best-radio-settings-for-my-envir...
Possible ATPC and DCS Fighting to keep the low nose floor threshold set in the advanced radio options. "DCS Noise Threshold [dBm]" When the AP changes output levels and or changes clients channel without the client adapting. Just a theory but I'm not veteran wireless expert.
Honestly I believe most of these issues are RF settings based. Co-Channel interference or due to ATPC being enabled and Dynamic Channel Selection set to active mode. Enabling both for 60min when we add a new ap in a building other than that we disable it. You really have to pay attention to what values you set for DCS.
https://gtacknowledge.extremenetworks.com/articles/Q_A/What-are-the-best-radio-settings-for-my-envir...
Possible ATPC and DCS Fighting to keep the low nose floor threshold set in the advanced radio options. "DCS Noise Threshold [dBm]" When the AP changes output levels and or changes clients channel without the client adapting. Just a theory but I'm not veteran wireless expert.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
06-01-2016 06:04 PM
Is this for the limited connectivity issue, disconnects or all of the above ? How are these suggestions different if running Bridged @ controller, there is no check box for arp proxy on the topology like bridged @ AP.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
05-25-2016 05:17 AM
For those who might be interested, I have captured wireshark traces for a client. The one set of traces was when the client connected correctly and the other was when he connected and had limited connectivity.
Both sets of traces was to the same AP running the latest V10 code.
The traces can be found here:
https://www.dropbox.com/sh/1jk289pe3i...
The client Details is as follows:
IP: 10.99.252.167
MAC: 54-B8-0A-63-10-47
Gtac is busy investigating my logs....
If we have a look at the failed traces, you can see form the “Client WiFi Trace Fail” you will notice that the Client connects, receives an IP address and then does a ARP request for the default gateway. The client never receives the ARP response from the gateway. If we look at the “AP- ETH Trace Failed” you will notice that the Clients ARP request is sent out on the Ethernet and the Gateway’s ARP response arrives at the AP but never sends this to the client. If we compare this with the working traces the ARP response reaches the Client.
Thx
Andre
Both sets of traces was to the same AP running the latest V10 code.
The traces can be found here:
https://www.dropbox.com/sh/1jk289pe3i...
The client Details is as follows:
IP: 10.99.252.167
MAC: 54-B8-0A-63-10-47
Gtac is busy investigating my logs....
If we have a look at the failed traces, you can see form the “Client WiFi Trace Fail” you will notice that the Client connects, receives an IP address and then does a ARP request for the default gateway. The client never receives the ARP response from the gateway. If we look at the “AP- ETH Trace Failed” you will notice that the Clients ARP request is sent out on the Ethernet and the Gateway’s ARP response arrives at the AP but never sends this to the client. If we compare this with the working traces the ARP response reaches the Client.
Thx
Andre
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
05-25-2016 05:17 AM
Well, they can't reproduce it any more, but in our case turning on ARP Proxy works around the problem effectively.
With the loss of connectivity problem on 3825s, I saw it on a Surface Pro 3 the other day, and got a great trace today from my laptop and a standalone capture AP. The capture AP saw ~10 retransmits of a packet, but monitor mode (tshark -I) on the laptop saw only one copy, with the previous packet seen being similar but having bit flips. It's come to the point where we're going to swap out our 3825s with the 3710s they replaced, fortunately we still have them lying about.
With the loss of connectivity problem on 3825s, I saw it on a Surface Pro 3 the other day, and got a great trace today from my laptop and a standalone capture AP. The capture AP saw ~10 retransmits of a packet, but monitor mode (tshark -I) on the laptop saw only one copy, with the previous packet seen being similar but having bit flips. It's come to the point where we're going to swap out our 3825s with the 3710s they replaced, fortunately we still have them lying about.
