Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
- Cisco Community
- :
- About Michael Combs
03-08-2019
Michael Combs
Member since
07-16-2013
Cisco Employee
Created by
Michael Combs
in Networking Documents
in Networking Documents
02-02-2018
09:25 AM
02-02-2018
09:25 AM
Symptoms
While deploying a number of 18xx/2802/3802 model access points (APs), which run AP-COS as their operating platform. It can be observed on some occasions that while many of their access points were able to join the fabric WLC without any issues. Some APs were not able to join the WLC and never even show under Monitor > Statistics > AP Join from the WLC UI.
The affected APs are not able to retrieve an IP address in the expected AP address pool specified from DNA Center, nor are there any CDP info displayed on the connected fabric edge (FE) switch.
Diagnosis
Determined that this particular fabric AP join issue was due to the following, prior CDP related bug on the AP-COS platform, as used by the 2802I model APs:
CSCvd86274 Cisco 1800,2800,3800 Series AP does not send the platform value via CDP when it is brand new
Due to the above CDP issues with the AP-COS access points, the expected lightweight AP event macro was not applied to the switch port used by those APs fresh out of the box that have prior, affected software images installed from the factory. Those that had unaffected versions preloaded were able to join without issue to the fabric WLC without any intervention, given that both CDP and the smart port macros on the fabric edge nodes worked as expected.
Furthermore, when faced with this issue you may be unable to configure a static port for the affected APs, as the last-resort smart macro would then override any manual switch port configurations attempted on the fabric edge (FE) node that the APs were connected to.
Solution
To work around this issue, apply the following command for the switch port interface used by the APs affected, so that you can then manually assign the switch port on the FE to the correct VLAN intended for the access points:
FE-1(config-if)# no macro auto processing
This will allow the affected AP(s) to join the fabric WLC and download their new code from the WLC, which includes the CDP bug fix. Given that 8.5.x code or later is required to support SDA-Wireless, and CSCvd86274 has been fixed as of 8.5.103.0 and later.
Once the above workaround was implemented, we confirmed that the static port configs persisted once applied and that the affected APs were able to then join the WLC and download their new code. We were further able to then place the previously affected AP-COS access points on another port on the fabric edge node(s) and confirmed that the proper lightweight-AP event smart port macro was then applied, and that the APs are still able to join the fabric enabled WLC as a result.
You can then continue to use the workaround on the switch port using the "no macro auto processing" command, then once all APs are on the fixed version of code. You can thereafter remove the static configs - including the "no macro auto processing" config - and let the lightweight-AP event smart macros push the appropriate configs to the AP switch ports on the fabric edge nodes.
From there the APs are able to join the fabric WLC without issue, and operate within the SDA fabric as intended.
... View more
04-04-2017
02:35 PM
That's great to hear! Glad the console is now responsive to your whims.
Since your AP is running a lightweight recovery image, sadly no such luck. There is no GUI or the like you can access for the AP even after manually configuring a BVI address and the like to use to upload an image directly thereafter. Given your previous note, the AP should be pulling a DHCP address at this point, but do ping the IP address of your TFTP server in question from the console of the AP to confirm it can reach it over the network.
Best thing to do thereafter is the following from the CLI of the AP you are consoled into (default credentials are Cisco / Cisco):
en
debug capwap console cli
debug capwap client no-reload
archive download-sw /force-reload /overwrite tftp://<TFTP-Server_IP-address>/<AP-image-name.tar>
Once the last command above is entered, the AP will reach out to the TFTP server and download the referenced tar file (latest autonomous IOS is ap3g2-k9w7-tar.153-3.JD4.tar ), install it and reboot. From there, you'll have yourself an autonomous AP that you can configure standalone from a WLC or the like, to your heart's content.
https://supportforums.cisco.com/document/61936/autonomous-ap-and-bridge-basic-configuration-template
... View more
04-04-2017
02:19 PM
Hi Lukas,
To echo what Leo stated, it would be good to possibly migrate to a newer and recommended version of AireOS on your WLC:
https://www.cisco.com/c/en/us/support/docs/wireless/wireless-lan-controller-software/200046-TAC-Recommended-AireOS.html?cachemode=refresh
Now with that out of the way, sounds like you have an interesting scenario on your hands! If I understand you correctly, you're stating that your Android client devices on the latest Android build are roaming but not well. Whereas the iOS 10 devices are not roaming at all?
What is the make/model of Android client devices you are encountering this issue with? Given that Android devices vary wildly in capabilities and behavior across that partner ecosystem, this will be an important distinction.
What is the make/model of the Apple iOS devices you are encountering this issue with?
What is the name or WLAN ID that these respective devices are connecting to? Can you post the full WLAN config for review?
For starters, do you know if your Android devices support 802.11r (Fast Transition / FT)? If so, you may want to consider enabling it on a test WLAN and connect a test Android as well as iOS 10 device to the test SSID and roam about your facility. Otherwise, the iOS devices will only be able to use Sticky Key Caching (SKC), and depending on your Android devices in question, they may or may not use SKC or OKC as a PMK caching/fast secure roaming method. At worst, your clients are having to go through full 802.1X/EAP authentication at every roam, which is typically time consuming and can be disruptive to ongoing VoWiFi calls, etc.
Can't say unless we can check the device specs to confirm/deny. Best case scenario is if they both support 802.11r, then you can enable it and use FT over-the-air methodology as outlined in the iOS Enterprise Best Practices on Cisco WLANs as a general template:
http://www.cisco.com/c/dam/en/us/td/docs/wireless/controller/technotes/8-3/Enterprise_Best_Practices_for_Apple_Devices_on_Cisco_Wireless_LAN.pdf
That said, as you observed issues with FT enabled (though do try FT over-the-air by disabling FT over-the-DS), the best thing at this point is to reproduce the issue you're observing and collect the following:
1. An over-the-air (OTA) packet capture (sniffer should be NTP synchronized).
You'll need to have multiple USB WLAN adapters that can be placed into monitor mode using OmniPeek or similar (so long as it can save to a *.pcapng or similar pcap format file)
This is due to the fact that you'll need to simultaneously monitor multiple channels and aggregate the frames into a single capture file given that the issue is with a roaming scenario (and thus multiple channels in use).
2. Save the CLI session output for the following WLC debugs to a text file:
config sessions timeout 0
config paging disable
debug client <client_MAC-address>
show client detail <client_MAC-address> (Note: collect several samples of this last command every 10-15 seconds or so until the end of the test)
Once you have reproduced the issue and the test has concluded, you can disable the above debugs using the following CLI command:
debug disable-all
3. At the end of your test, save the following CLI session output from your WLC to another text file:
config paging disable
show run-config
show msglog
show traplog
4. At the end of your test, also save the following CLI session output from the AP(s) you encountered the issue on to separate text files (per AP) as well:
en
term len 0
show clock
show tech
show capwap client mn
show int do1 dfs
show logging
more event.log
show trace dot11_rst display time format local
show trace dot11_rst
show trace dot11_bcn display time format local
show trace dot11_bcn
With that, you should be able to pinpoint what may be the issue or at the very least, get you started down the right path to resolution. You can also then upload these logs and OTA captures to a Cisco TAC case once opened and they can further advise if/as needed, and continue troubleshooting with you.
For those that are not faint of heart; if you want to do a true deep-dive (or if the above is found to not be sufficient in and of itself), you can go through all steps as outlined in the below article:
https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/200480-Troubleshooting-Guide-for-Wireless-Clien.html
Hopefully that helps!
... View more
04-04-2017
01:03 PM
Sure thing, my pleasure.
If you're not getting any keyboard input recognized whatsoever, then this is likely attributed to a) incorrect settings on your terminal emulator program of choice (i.e. putty, secureCRT, etc.), or b) bad hardware (either Cisco console cable, USB-to-Serial adapter, etc.).
Let's move forward in tribute to Occam's razor to start, and double-check that your terminal emulator program is using the following settings:
9600 baud
8 data bits
1 stop bit
No parity
While you're at it, make sure that for the serial settings that the terminal emulator program is using is correct. For instance, when using USB-to-Serial adapters the COM port designation can change from time to time for driver related events, so if you were using COM3 previously but now the adapter is recognized as COM4. We'll want to update the setting accordingly in Putty or similar (can check COM port mappings in Windows device manager, etc.).
Go ahead and also double-check the connections to make sure that your console cable is properly re-seated in the console port of the AP, securely connected to the USB-to-Serial adapter if applicable, and so forth.
After that, your keyboard input will hopefully be able to be recognized on the AP console. If all else fails a restart of the terminal emulator program and/or reboot of the PC in question might be called for to rule out any other idiosyncrasies. You could also use another blue Cisco console cable if needed, out of an abundance of caution and/or confirm that it works on another Cisco device like a switch, router, or better yet, another AP if you have one handy.
... View more
04-04-2017
11:21 AM
Hi there,
The AP will only use DHCP option 43 to help discover a WLC, it won't utilize option 150 or the like to reach out to a TFTP server directly.
http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-1/Enterprise-Mobility-8-1-Design-Guide/Enterprise_Mobility_8-1_Deployment_Guide/cuwn.html#pgfId-1259523
Easiest way to convert your lightweight IOS AP to standalone (i.e. autonomous), is to follow the steps outlined at the below article:
https://supportforums.cisco.com/document/57476/lwapp-autonomous-conversion-and-vice-versa-access-points#LWAPP_to_IOS
Once the steps are followed, and assuming your AP can communicate with the TFTP server in use. You should be good to go.
... View more
03-24-2017
08:16 AM
Hi Tomas,
You certainly can using the likes of Application Visibility Control (AVC), assuming of course you're running a relatively recent release of WLC code (7.4 or above, 8.3 is the latest). Here is some documentation to that effect:
http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-2/AVC_DG/AVC_8point2_dg.html
http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-3/config-guide/b_cg83/b_cg83_chapter_0100010.html
http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-1/Enterprise-Mobility-8-1-Design-Guide/Enterprise_Mobility_8-1_Deployment_Guide/ch5_QoS.html
... View more
02-10-2017
08:28 AM
Hi Johannes,
Sounds good, and keep in mind that ACM can be implemented for both the voice (AC_VO) and video (AC_VI) access categories (though for same considerations, likely wouldn't want to enable for AC_VI in your use-case).
You are also correct that the QoS mappings from DSCP to UP has been inconsistent among a large number of wireless infrastructure and client vendors alike. Thankfully, this was addressed in the latest IEEE 802.11-2016 EDCA specification. By enabling Fastlane (even in the presence or absence of iOS 10 clients) on a WLC running AireOS 8.3 or later, you implement these latest EDCA parameters on the WLC. Naturally, iOS 10 clients also support them. Though the uplink UP mapping behavior will still vary (sometimes wildly) for other client devices, but hopefully in time these manufacturers shall also implement the latest EDCA specifications.
The 4.1 Voice over Wireless Design Guide is indeed long in the tooth, though still applicable, and was drafted at a time that the overwhelming majority of VoWLAN use-cases involved purpose built wireless IP phones. There has been a more recent, similar document in the form of the Real-Time Traffic over Wireless LAN Solution Reference Network Design Guide (say that three times fast). I've provided a link to the WLAN QoS section of that document below, which touches upon ACM/CAC/TSPEC and other considerations:
http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Mobility/RToWLAN/CCVP_BK_R7805F20_00_rtowlan-srnd/CCVP_BK_R7805F20_00_rtowlan-srnd_chapter_011.html
One final comment on the use of CAC/ACM is to consider that preserving bandwidth in the AC_VO is to not only ensure the highest number of possible calls (depending on local environmental factors, etc.) are preserved per AP radio cell, and that the quality of these calls is preserved as much as possible therein. Also consider that in doing so you also help reserve sufficient bandwidth for a E911 call or similar as well, even if the AP radio cell is saturated with client activity. Again, simply an additional mechanism and by no means a substitute for proper RF network design that properly addresses both coverage and capacity in a given environment.
However, due to the disappointing lack of ACM/TSPEC support among most client vendors today, outside of purpose-built VoWLAN wireless IP phones and similar. It is simply not in the cards for a number of voice deployments that rely upon soft clients on a diverse suite of client devices, for all of the considerations you and I have discussed and more.
/Michael
... View more
02-09-2017
06:35 PM
Hi Johannes,
It all comes down to your specific wireless network, diversity of client devices, and use-cases of interest to your particular organization in question. Only in taking all of these factors and potentially more into careful consideration, can one say thereafter whether CAC is best left disabled or enabled accordingly.
Call Admission Control (CAC) in the wireless sense invokes Admission Control Mandatory (ACM) for the particular access category (AC) in question as you detail. In your case and for our example, that would be the voice AC (AC_VO) which is traditionally mapped to the metallic Platinum QoS profile on the AireOS WLCs. The method by which ACM is negotiated is indeed via ADDTS action frames and similar which include TSPEC and TCLAS parameters, to ultimately control both access to and use of AC_VO. This is an additional means of preserving capacity for calls and reserving bandwidth in AC_VO for mission and/or business critical communications and similar real-time applications. Though this is mechanism is of course in addition to, and by no means a substitute for proper wireless network design that takes both coverage and capacity into account.
If your primary voice deployment/use-case involves dedicated and purpose built VoWLAN phones (i.e. Cisco 7925G or 8821, Ascom i62/Myco, SpectraLink 84xx, etc.) which support CAC/ACM then enabling it is often a good option as it reserves the voice access category as detailed above. Thereby ensuring that less important applications that still mark their traffic as UP 6 / EF (46) or similar do not detract any more airtime and bandwidth than is absolutely necessary from those devices or applications deemed more critical in a given environment.
If instead the primary voice applications in use are soft clients running on a mix of various devices, whether Android, iOS, macOS, Windows laptops, or a combination of most or all the above. Then you are correct, there has always been a disappointing lack of client support for ADDTS/TSPEC/TCLAS, etc. If these voice soft clients are considered mission/business critical then given the lack of support for CAC/ACM in this instance, the decision is apparent that CAC should likely be disabled in this particular environment.
Though the 802.11e standard upon which WMM is based does indeed include these mechanisms. As with most things, client manufacturers often pick and choose what they wish to actually support and this is a prime example of an aspect that rarely made the cut (debatable as to the validity of those decisions from case to case). It should be noted that CAC is not unique to wireless (merely the mechanisms by which it operates), but can also be implemented for preserving and controlling call bandwidth for WAN links, etc., as well.
Fastlane introduced in AireOS 8.3 and iOS 10 on Apple devices introduces greater flexibility to extend the benefits of CAC to additional mobile devices that don't implement ADDTS but can still be granted access to the voice AC as needed. Given the granularity of QoS control that Fastlane introduces for compatible iOS 10 apps and use cases.
TL/DR = one size does not fit all. CAC/ACM can be utilized to great effect in some environments, but might not add as much value or even be a hindrance for others based on their device types and capabilities, and corresponding use cases.
/Michael
... View more
Created by
Michael Combs
in Other Wireless - Mobility Subjects
in Other Wireless - Mobility Subjects
02-09-2017
09:41 AM
02-09-2017
09:41 AM
Sounds like you should open a TAC case on this issue, as there's no guarantee that anything is addressed until troubleshooting is conducted and a proper root cause is determined. Whether it ends up being a bug or similar on the Cisco AP/WLC, Apple iOS device(s), or even a combination of all the above and more.
That said, you can find the latest AireOS WLC code recommendations from Cisco TAC and HTTS at the URL below, which we update frequently:
https://www.cisco.com/c/en/us/support/docs/wireless/wireless-lan-controller-software/200046-TAC-Recommended-AireOS.html?cachemode=refresh
Also, for highly mobile devices like iOS clients and the like, my recommendation is to use FT over-the-air method rather than FT over-the-DS. You can find the enterprise best practices guide for Apple iOS devices on Cisco WLANs below as well:
http://www.cisco.com/c/dam/en/us/td/docs/wireless/controller/technotes/8-3/Enterprise_Best_Practices_for_Apple_Devices_on_Cisco_Wireless_LAN.pdf
I hope that helps!
/Michael
... View more
02-09-2017
08:59 AM
Hi Bruno,
What version of iOS is running on the affected iPhones?
There was an issue introduced in iOS 10.0 whereby the 'hidden' flag for a WLAN profile on an iOS device might be disabled for a configured SSID. Per AppleCare Enterprise Support (ACES) this was fixed in iOS 10.2. However, if an iOS client device was previously affected prior to upgrading to iOS 10.2 or later you may still observe that you need to reconfigure/push the WLAN config once more to the device. Thereafter you shouldn't see the issue again due to this fix in 10.2.
So if you're running 10.2 or later on your iThings, then you may still have some stragglers that will have this issue from time to time as they were previously affected. Though they should be good after reconfiguring the WLAN profile on that particular device. Going forward you shouldn't have to go through the same exercise as before for that same iPhone/iPad. Though if you find otherwise for any reason, then your best recourse would be to open a case with AppleCare Enterprise Support (not regular/consumer AppleCare support).
The other workaround as Scott alluded to is to not "hide" the SSID as well (not really hidden, but that's another topic).
/Michael
... View more
Created by
Michael Combs
in Other Wireless - Mobility Subjects
in Other Wireless - Mobility Subjects
02-07-2017
06:59 AM
02-07-2017
06:59 AM
You need to also install the AP Supplemental Bundle for your 5508 (same applies to 2504 and WiSM2 WLC models) when upgrading to 8.3 and above code. This is detailed in the corresponding release notes for 8.3.102.0:
http://www.cisco.com/c/en/us/td/docs/wireless/controller/release/notes/crn83.html#pgfId-1437983
Going forward you should install both of these images accordingly (will be needed for any subsequent, new release on the 2504/5508/WiSM2 WLC):
AIR-CT5500-K9-8-3-102-0.aes
AIR-CT5500-AP_BUNDLE-K9-8-3-102-0.aes
If the WLC was already upgraded to 8.3.102.0 code previously, then you can just install the supplemental AP bundle by itself at this time.
... View more
Created by
Michael Combs
in Other Wireless - Mobility Subjects
in Other Wireless - Mobility Subjects
01-05-2017
02:38 PM
01-05-2017
02:38 PM
That's certainly interesting if you observe these radio channel changes due to perceived DFS events 100% of the time whenever the ASUS EeeBook X205TA connects (or attempts to connect) to an AP on a UNII-2 or UNII-2e channel.
Though not common, I have seen this before with certain client STAs in the field. Essentially the WLAN adapter and specific antenna design in your particular client device is emitting an RF "spur" whose signature is similar to that of a radar signal as perceived by an 802.11 radio. Due to stringent regulatory and associated DFS requirements, the AP will therefore of course immediately defer the current channel to the perceived radar entity and begin to move to another channel accordingly. Though without some kind of spectrum analysis when such an event occurs, it's of course difficult to say if that is indeed your issue with any real kind of certainty.
There has been some improvements here and there in more recent versions of WLC code (i.e. 8.0+, preferably latest 8.2 code) in attempts to reduce and mitigate some of these "false positive" events. However, that is of course a non-starter in your scenario sadly given that the EoL 4400 series WLC only supports up to the 7.0 code train. Given that this is for a home/home office I imagine there is a limited number of APs in use, so perhaps the simplest solution is to indeed use non-DFS channels (i.e. UNII-1 and UNII-3) or utilize an alternate WLAN adapter (i.e. USB, etc.) on your ASUS EeeBook and disable the offending internal adapter.
It may well be worth your while to try to see if updating your WLAN adapter drivers first and see if it hopefully offers some improvements. Otherwise, it would certainly be worth reaching out to ASUS for support on this, as they can then engage the WLAN adapter manufacturer as an OEM partner.
... View more
12-14-2016
12:51 PM
Hi Daniel,
Even when session timeout on a WLAN is "disabled," it really just means that the session timeout is set to 24 hours. A couple considerations to mull over. For one, I'd look into possibly upgrading your WLC code to a more recent release as there have been quite a number of bug fixes. A list of TAC/HTTS recommended WLC codes by AireOS code train (i.e. 8.0, 8.2, etc.) can be found at the below URL, which is frequently updated:
https://www.cisco.com/c/en/us/support/docs/wireless/wireless-lan-controller-software/200046-TAC-Recommended-AireOS.html?cachemode=refresh
The other option is to roll up our sleeves and troubleshoot this scenario directly, and pin it down either to a bug on the WLC/AP side, the client side (WLAN driver, supplicant, etc.), or a combination of the two. To do so, I'd recommend opening a TAC case for this issue and upload the following collected information once you reproduce the issue as reported:
Save the following CLI session output to a text file from your WLC in question (may take some time to complete):
config paging disable
show run-config
show msglog
show traplog
While reproducing the issue, collect an over-the-air (OTA) packet capture taken in close proximity to the client under test at all times. Make certain that the sniffer is NTP synchronized.
While reproducing the issue, collect a Wireshark capture off the wireless interface on the test device (say a Windows laptop or MacBook). Make certain that the PC is NTP synchronized with the other sniffer.
At the same time that the above packet captures are being collected, get the following debug output from the WLC, as saved to a text file:
config sessions timeout 0
config paging disable
debug client <MAC-address>
debug dhcp message enable
show client detail <MAC-address>
Note: execute this last command every 15 seconds or so during the test
Be sure to include the exact time the issue occurred, what the symptoms were, and full details about the client device that was used during the test (i.e. make/model, OS version, WLAN adapter model, WLAN adapter driver version, etc.).
Depending on what the above captures and debugs show, additional debugs or packet captures (such as a span session upstream) may need to be collected in a subsequent test. However, this will definitely get you started down the path to pinpointing the root cause for this issue. Though you could upgrade your WLC first as detailed above, then if the issue persists, collect this information and raise a TAC case accordingly.
Dealer's choice, as it best fits your requirements and procedures.
... View more
12-14-2016
12:24 PM
Hi Toivo,
Best resource for this will be the 8821 Wireless LAN Deployment Guide, which will clarify most of these points. Including the use of a docking cradle and compatible USB-to-Ethernet adapter for auto-provisioning, as further detailed on page 140:
http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/cuipph/8821/english/Deployment/8821_wlandg.pdf
If you have CUCM 11.0 and later, you can use the Wireless LAN Profiles on CUCM (as 11.0 added support for EAP-TLS).
... View more
12-14-2016
12:17 PM
Hi Mis,
I'm hoping it's a typo, but I noticed you twice listed the IP address of the phone as 192.3168.10.95, which is invalid (believe you meant 168 instead of 3168). Next thing is to confirm that DHCP option 150 or 66 is properly configured for the scope to return the correct CUCM IP address.
You can also find additional details and recommendations in the 8821 deployment guide:
http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/cuipph/8821/english/Deployment/8821_wlandg.pdf
... View more
Created by
Michael Combs
in Networking Documents
02-02-2018 09:25 AM
02-02-2018 09:25 AM
Symptoms While deploying a number of 18xx/2802/3802 model access points
(APs), which run AP-COS as t...
04-04-2017 02:35 PM
That's great to hear! Glad the console is now responsive to your whims.
Since your AP is running a l...
04-04-2017 02:19 PM
Hi Lukas, To echo what Leo stated, it would be good to possibly migrate
to a newer and recommended v...
04-04-2017 01:03 PM
Sure thing, my pleasure. If you're not getting any keyboard input
recognized whatsoever, then this i...
04-04-2017 11:21 AM
Hi there, The AP will only use DHCP option 43 to help discover a WLC, it
won't utilize option 150 or...
03-24-2017 08:16 AM
Hi Tomas, You certainly can using the likes of Application Visibility
Control (AVC), assuming of cou...
02-10-2017 08:28 AM
Hi Johannes, Sounds good, and keep in mind that ACM can be implemented
for both the voice (AC_VO) an...
02-09-2017 06:35 PM
Hi Johannes, It all comes down to your specific wireless network,
diversity of client devices, and u...
Created by
Michael Combs
in Other Wireless - Mobility Subjects
02-09-2017 09:41 AM
02-09-2017 09:41 AM
Sounds like you should open a TAC case on this issue, as there's no
guarantee that anything is addre...
02-09-2017 08:59 AM
Hi Bruno, What version of iOS is running on the affected iPhones? There
was an issue introduced in i...
Created by
Michael Combs
in Other Wireless - Mobility Subjects
02-07-2017 06:59 AM
02-07-2017 06:59 AM
You need to also install the AP Supplemental Bundle for your 5508 (same
applies to 2504 and WiSM2 WL...
Created by
Michael Combs
in Other Wireless - Mobility Subjects
01-05-2017 02:38 PM
01-05-2017 02:38 PM
That's certainly interesting if you observe these radio channel changes
due to perceived DFS events ...
12-14-2016 12:51 PM
Hi Daniel, Even when session timeout on a WLAN is "disabled," it really
just means that the session ...
12-14-2016 12:24 PM
Hi Toivo, Best resource for this will be the 8821 Wireless LAN
Deployment Guide, which will clarify ...
Public Statistics
| Date Registered | 07-16-2013 03:41 PM |
| Date Last Visited | 03-08-2019 01:44 PM |
| Total Messages Posted | 16 |
| Total Helpful Votes Received | 40 |
Helpful Votes From
| User | Helpful Count |
|---|---|
| 5 | |
| 5 | |
| 5 | |
| 5 | |
| 5 |
