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.
142 REPLIES 142
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-20-2016 05:26 AM
Hi all
Can I ask that everyone that had or currently have a open case regarding this problem please post the Case Number here?
I would like to put all of this together in one Case.
My Case number is :01206949
Perhaps combined with all the traces from the various cases a resolution can be found..
Thx
Andre
Can I ask that everyone that had or currently have a open case regarding this problem please post the Case Number here?
I would like to put all of this together in one Case.
My Case number is :01206949
Perhaps combined with all the traces from the various cases a resolution can be found..
Thx
Andre
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
05-20-2016 05:26 AM
01206630
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
05-20-2016 05:26 AM
01199484 was my latest case though it appears it was recently closed with out a real resolution other than upgrade to latest code 😞
Others include : 01179547 , 01153963 and 01160255
These are all old cases, but still the underlying problem.The first of the cases was opened when we were on 9.15.07.08 The problem originally was most noticeable with 2.4 clients or if you had radio preference groups enabled and if anything has gotten progressively worse.
If there is an old firmware where the problem is not present, I would be willing to test with an an eval license for v2110 controller if that is possible. I currently have 2 physical controllers that are paired so I can't really downgrade one of those, but maybe we can get an eval to test with until this is resolved ?
Others include : 01179547 , 01153963 and 01160255
These are all old cases, but still the underlying problem.The first of the cases was opened when we were on 9.15.07.08 The problem originally was most noticeable with 2.4 clients or if you had radio preference groups enabled and if anything has gotten progressively worse.
If there is an old firmware where the problem is not present, I would be willing to test with an an eval license for v2110 controller if that is possible. I currently have 2 physical controllers that are paired so I can't really downgrade one of those, but maybe we can get an eval to test with until this is resolved ?
