Featured

Fortinet WLAN controller Refresh

WLAN Controller Refresh

  • 3 new FortiWLC Controllers:
    • AP capacity equivalent to MC1550, MC3200 and MC4200.
    • higher performance (faster CPU – will provide more details later).
    • complete transition to Fortinet branding.
    • FortiWLC Controllers run System Director 8.1 (SD 8.0 Minor Release)3 N.

meru

Advertisements
Featured

Introduction to Wireless Local Area Network

Wireless Network:

A  wireless local-area network (LAN) uses radio waves to connect devices such as laptops to the Internet and to your business network and its applications. When you connect a laptop to a WiFi hotspot at a cafe, hotel, airport lounge, or other public place, you’re connecting to that business’s wireless network.

•Why WLAN?
•Mobility
▫Increases working efficiency and productivity.
▫Roaming support: extended on-line times
-> universal access & seamless services
•No new wiring and installation on difficult-to-wire areas
▫Offices, public places, and homes
▫Factories, vehicles, roads, and railroads
•Reduced installation time
▫No cabling time
▫Easy setup

How are Wireless LANs (WLANs) Similar to (wired) LANs?

Featured

First blog post

Hii tr,

I am IT Networking Profession with Extensive experience in Wi-Fi and Security. Working with a leading security company as Sr.Wireless Expert and Field Support Engineer. My passion towards Wireless have driven me so far and I am pleased to introduce myself as a Wi-Fi Engineer.

Wireless Experts blogs and other Wi-Fi communities have always been so helpful in finding solutions for all my question ever. I am Very much excited and happy to share my thoughts and experience about Wireless and Security.

Featured

Useful Wireless Troubleshooting commands for windows clients

#To display all wireless interfaces: netsh wlan show interfaces
#To show the wireless drivers installed run this command. This is particularly interesting as exploits in drivers do exist and most admins do not pay as close attention to driver versions as other types of software: netsh wlan show drivers

#To list available wireless networks (similar to Linux’s iwlist scan option):

netsh wlan show networks
#To view profiles of networks saved on this machine: netsh wlan show profiles

#To make Windows connect to the specified profile (usually named after the SSID of the network): netsh wlan connect name=”ProfileName”

#To export the profile details to an XML file (which includes an encrypted version of the PSK if applicable): netsh wlan export profile name=”ProfileName”

#Now crucially, here are the commands to turn the Windows 7 (or Server 2008 R2) into an Access Point sharing its existing wireless connection out to others: netsh wlan set hostednetwork mode=allow ssid=SomeSSID key=passphrase

#The hosted network is now created but it is not yet started. To start it, issue the command: netsh wlan start hostednetwork

#Your Windows box is now advertising a network “SomeSSID” (in this case) which other machines can connect to. No notification is given on the Windows box that this has happened and no further notification happens when someone connects.

Wi-Fi Now Conference Bangkok-2017

I recently got chance to attend the Wi-Fi Now conference held at Bangkok this year. Met some wonderful people in WiFi community.

Got engaged on discussion with latest WiFi deployments and its success stories.

How to meet customer demands with right solutions available in the market. Vendors gave some insight on how they are meeting customer demands already and what they can offer to meet the customer requirements and some Proof of success from POCs and production network.

img_0699img_0715img_0697

At the same day, met some of my favorite wi-fi peers.

#iBWAVE 

I was given a demo on iBWAVE WiFi Design Tool by  Sunder Arumugam and Swee Leong Sim

#My favorite features on  iBWAVE :

Advanced 3D modeling of the venue
Cable routing and costing
Complete bill of materials reporting
project proposal generation
Automatic link budget calculations

img_0721

#Ekahau Folks

Met Brandon Biggs and Mark Winter from inTechnology Distribution

I was given a Demo on New Sidekick Tool and had some discussed on Single Channel planning with Ekahau Wi-Fi design Tool.

img_0709

#Wi-FI Now CEO and chairman | Claus Hetting

Got chance to have a short conversation regarding the conference.

img_0723

#Globeron CEO and CWNE Board of Advisor | Ronald van Kleunen

I was able to catch-up with Ronald at Bangkok

img_0685

 

 

 

Wi-Fi Roaming on a Fortinet Single Channel Architecture(SCA)

Successful Wi-Fi client Roaming is moving across Access point / BSSID  to a best possible service AP for the wireless client in term’s of SNR and RSSI while with least time involved in the process and with zero Hard hand off seen.

Faster Roaming is considered key for VoIP over Wi-Fi and for other application that is running over Wi-Fi Network which is very sensitive for latency and delay.

Wireless Vendor’s do have protocol implementations to deal these roaming problems with : PMK caching, OKC, FAST ROAMING 802.11 K/V/R

However Fortinet Infrastructure Wi-Fi being unique with single BSSID virtually visible across the network and roaming seems to be quite simple, but they still have to calculate the math to solve the roaming issue with their software.

I want to stress on this point: Yes, FortiWLC does  support both Single channel Architecture and Multi channel Architecture mode and you can take advantage of this with the help of feature grouping. So you can deploy sites some with single channel and other sites which you feel from Design point that it’s optimal to go with Multi channel architecture. So take some advantage of the SCA where it can really go well for you.

Ok, So how does SCA works together for client roaming?

Like other MCA vendors Fortinet Wi-Fi system also has the following tweaks and operations that will help you to build a system optimal for Good roaming (choice of which parameter really depends on wi-fi environment).

*Prob response threshold(This is based on SNR)

*Lower data rate changes

*TX power changes.

*Prob response from associated AP only.

*AP load balancing

*Frequency Band-steering

Apart from the settings mentioned above there are some  major factors that contribute SCA roaming :  

*Adequate RSSI

*NumRssiSamplesQuiet

*NewSignalGoodnessQuiet

*SuppressZeroRssiBasedHandoff

2 frame report with 3 dbm difference on RSSI strength   [ This is Interval between each frame report and its RSSI difference]

Coordinator  [wi-fi system which takes in-charge of  AP<->CLIENT association and here coordinator gives client assignment to the best access point to service the client based on the condition and threshold set]

coordinator reassignment and AP acknowledgment for that assignment.

silent client behavior and WLC features to handle such client behaviors.

Below are some client roaming behavior on different roaming condition.

#Normal system hand off based on adequate rssi(better signal strength).

2017-Sep-29 14:51:56.611901 | 78:31:c1:Xx:Xx:XX | 802.11 State | * <AID=31>[abgn](v0) handoff <OLD_AP=6> RSSI (-56 -55) <NEW_AP=13> RSSI (-52 -43) ESSID=XXXXX Ch=149 A-BSSID=00:0c:e6:02:67:70 reason=Normal handoff

#System Hand off based on  -256  frame report:

This condition of seeing -256 frame report and followed by normal handoff means that the station is found on different service AP while before the last serviced AP could flag the client as LOST.

station-log> 2017-Sep-29 15:44:55.069959 | 78:31:c1:XX:XX:XX | 802.11 State | * <AID=31>[abgn](v0) handoff <OLD_AP=13> RSSI (-256 -256) <NEW_AP=6> RSSI (-55 -55) ESSID=XXXX Ch=149 A-BSSID=00:0c:e6:02:67:70 reason=Normal handoff

#System LOST-FOUND on same Access point(-256):

When the wireless client is marked LOST on the connected Access point and not found on any other servicing Access point. And the client shows up(FOUND) again on the same access point after been marked as LOST.

–>Sample Station log:

If no other UNASSIGNED AP have marked it QUASI FOUND
01:40:30.503000 | 7c:7a:91:XX:XX:XX | 802.11 State | <AID=6>[abgn](pre lost) found on assigned <AP=97>(rssi=-256) ESSID=XXXX Ch=44 A-BSSID=00:0c:e6:5a:1b:44 reason=Station discovered

#System Hand off based on LOST-FOUND(station is declared as LOST but found on different servicing AP)

Here station is completely lost on the connected AP, while it probed on a different Access point resulting on a hand off.

–>Sample station log :

2017-Sep-29 15:44:53.507727 | 78:31:c1:XX:XX:XX| 802.11 State | * <AID=31>[abgn](v0) (pre found) lost from assigned <AP=13> ESSID=XXXX Ch=149 A-BSSID=00:0c:e6:02:67:70 reason=Station lost from AP
station-log> 2017-Sep-29 15:44:55.069956 | 78:31:c1:XX:XX:XX | 802.11 State | * <AID=31>[abgn](v0) (pre lost) quasi found on unassigned <AP=6>(rssi=-55) ESSID=XXXX Ch=149 A-BSSID=00:0c:e6:02:67:70 reason=Station probed
station-log> 2017-Sep-29 15:44:55.069959 | 78:31:c1:XX:XX:XX | 802.11 State | * <AID=31>[abgn](v0) handoff <OLD_AP=13> RSSI (-256 -256) <NEW_AP=6> RSSI (-55 -55) ESSID=XXXX Ch=149 A-BSSID=00:0c:e6:02:67:70 reason=Normal handoff

 

->>The below log indicates that the station is now handed-off to new access point and the access point ack’ed the “coordinator” that he is going to take over the client service.
station-log> 2017-Sep-29 15:44:55.070826 | 78:31:c1:XX:XX:XX | 802.11 State | * <AID=31>[abgn](v0) (pre quasi found) marked found as received handoff ack from assigned <AP=6> ESSID=wireless-nation Ch=149 A-BSSID=00:0c:e6:02:67:70

 

#Wireless Client Assoc-Assoc .

This is a problem condition in SCA where the wi-fi station does a re-association to the access point but to the wireless system already know him as a associated client in his DB.

The client does this thinking  it needs a re-association to the wireless network because he hasn’t heard any beacon for some time interval or could be because beacons are found to be corrupted while decoding or client didn’t like the frames sent by Access point(Have seen such behavior mostly with INTEL chip-set based clients). This needs a investigation if these log show up on system and matches the time frame user reporting any connectivity issues.

This  condition could cause client going through authentications phase again and/or even disconnections (8021.x and 802.11i  happens every time when hits Assoc to Assoc)

–>Sample events for Assoc-Assoc situation:
station-log> 2017-Sep-29 15:44:59.257873 | 78:31:c1:XX:XX:XX | 802.11 State | * <AID=31>[abgn](v0) state change <old=Associated><new=Associated><AP[6]=00:0c:e6:1a:34:11> ESSID=XXXX Ch=149 A-<BSSID=00:0c:e6:02:67:70>
station-log> 2017-Sep-29 15:44:59.257877 | 78:31:c1:XX:XX:XX | 802.11 State | * <AID=31>[abgn](v0) state change <old=Associated> <new=Associated> <AP=6> ESSID=XXXX Ch=149 A-<BSSID=00:0c:e6:02:67:70>
station-log> 2017-Sep-29 15:44:59.258432 | 78:31:c1:XX:XX:XX | 1X Authentication | <AID=0> <EAP code=request> <EAP ID=1> <EAP type=Identity> sent
station-log> 2017-Sep-29 15:44:59.290511 | 78:31:c1:XX:XX:XX | 1X Authentication | <AID=31> <pkt type=EAP_PACKET> <EAP code=response><EAP ID=1>
station-log> 2017-Sep-29 15:44:59.290514 | 78:31:c1:XX:XX:XX | 1X Authentication | <AID=31> Radius <msg code=access_request><msg ID=174> sent <ip=10.16.70.40>:<port=1812>
station-log> 2017-Sep-29 15:44:59.299477 | 78:31:c1:XX:XX:XX | 1X Authentication | <AID=31> <pkt type=EAP_PACKET> <EAP code=request><EAP ID=2> <info=relay eap-request from Radius> sent

station-log> 2017-Sep-29 15:44:59.572152 | 78:31:c1:XX:XX:XX | 1X Authentication | <AID=31> <pkt type=EAP_PACKET> <EAP code=response><EAP ID=9>
station-log> 2017-Sep-29 15:44:59.572156 | 78:31:c1:XX:XX:XX | 1X Authentication |
station-log> 2017-Sep-29 15:44:59.645547 | 78:31:c1:XX:XX:XX | 1X Authentication | <AID=31> <pkt type=EAP_PACKET> <EAP code=response><EAP ID=12>
station-log> 2017-Sep-29 15:44:59.646297 | 78:31:c1:XX:XX:XX | 1X Authentication | <AID=31> Radius <msg code=access_request><msg ID=189> sent <ip=10.16.70.40>:<port=1812>
station-log> 2017-Sep-29 15:44:59.647948 | 78:31:c1:XX:XX:XX | 1X Authentication | <AID=31> Radius ACCESS-ACCEPT received : Session Timeout: None, VLAN Tag : 0, Filter id : , CUI : None.

 

How does Fortinet SCA Wi-Fi Network manages Silent Client issues

Small Wi-Fi devices, Bar-code scanners and other IOT devices does go for doze state very often to save power. Every Wi-Fi vendor will have some kind of implementations to get attention of those Wi-Fi Client that tend to go silent often.

Traditionally Meru Wi-Fi system have a feature called CLIENT LOCATOR. While after adding the client devices MAC-OUI on the WI-FI System it keeps sending ICMP request and gets an ICMP reply  from those silent clients, by this way the clients connection is kept active. Also Wi-Fi system sends out Qos Null frame in earlier days for those Silent clients.

Now in recent Fortinet Infrastructure based AP models there are certain client upstream and downstream silent client feature implemented.

#DOWNSTREAM :

For Active Clients (If Wi-Fi client hasn’t informed about going for a power save but remains silent):

Scenario_1:

> If the client is silent for more than 2 seconds, silent client polling kicks in from AP every  2 seconds.

                                              AP                                                                             STA
                                          
                                                           No upstream packet from STA
                                                              (Start RTS mechanism)
                                                  RTS->
                                                                                                                  <-  CTS
                                                  CFE->

 

Scenario_2:

> Consider, if no reply from the silent client then the AP tried to send the RTS for 8 – 30 seconds and gives up. Then the AP will update the “coordinator” about the client is been lost now.

station log will look like this:

| 802.11 State | * <AID=31>[abgn](v0) (pre found) lost from assigned <AP=13> ESSID=***** Ch=149 A-BSSID=***** reason=Station lost from AP

>So, Once station is declared lost, TIM bit is enabled in the beacon.

>And if station is back on network, then a found notification will be send. If not found then the system will run the station ideal time out for 33 min(default) and will send out a De-auth.

 

                                       AP                                                                                    STA
                                          
                                                    No upstream packet from STA
                                                              
                                             RTS 1–>
                                                     |2secs|         
                        
                                             RTS 2–>
                                                                                   ..
                                                                                   ..
                                            RTS 8–>
                                                                   Station lost message
                                            TIM bit set in Beacon–>
                                                              After 33minutes TIM bit cleared

#UPSTREAM: 

Power Save Clients (Client informed going for power save)

scenario_1:

>Again if client is silent for 2 sec, silent client polling kicks in from AP every 2 sec.

> Silent client polling starts by AP setting TIM vector in beacons.

> However, TIM bit is still set in the beacons for 33 minutes and if no response from client then  later TIM bit is reset and De-auth will be sent out.

                                              AP                                                                              STA
                                          
                                                                 No upstream packet from STA
                                                    Beacon (TIM bit set)–>

                                                

                                                                           (After 33minutes)
                                                   Beacon (TIM bit reset)–>
 
  Scenario_2:

>Silent client polling starts by AP setting TIM vector in beacons and stations sends PS-   POLL frame to AP, AP in turn sends QOS NULL data.

                                              AP                                                                               STA
                                               
                                                                 No upstream packet from STA
                                                      
                                                       Beacon (TIM bit set)–>
                                                                                                                   <–PS-Poll 
                   
                                                       ACK–>
                                                       QOS Null Data–>
                                                                                                                   <–ACK

The default  silent_client.frame_fail_threshold varies from “8 – 30” depending on the Firmware version on the system and this can be changed with the help of AP Boot script. However, before any changes i would advise you to get some tips from Experts.

 

 

My Troubleshooting experience with 802.11 Beacon Frames.

Wireless Frame Analysis involve understanding what to look for in the 802.11 packet. Here lets look at “Beacon” Wi-Fi Management frames and those Interesting packet fields that can come handy while you troubleshoot client connectivity and performance issues caused by beacon frames.

802.11 management frames enable stations to establish and maintain communications.

The following are common 802.11 management frame subtypes:

802.11managementframes

#Beacon Frame:

The access point periodically sends a beacon frame to announce its presence and relay information, such as timestamp, SSID, and other parameters regarding the access point to radio NICs that are within range. Radio NICs continually scan all 802.11 radio channels and listen to beacons as the basis for choosing which access point is best to associate with.

 

beacon

The  Beacon frame has some information that we could glance through.

Section 1 : Physical Header of a Beacon: The radio tap header information are basically pseudo-header to supply additional info from driver to userspace.

And I use wire-shark to decode the packets for analysis and sometime it also depends on how best the software decodes the Wi-Fi packets for analysis. Rarely you might get to see some issues on the protocol analyzers that fail to decode the information right. we might need to double confirm with another (It just happens in corner cases)

The following are few information we have in physical header

*The signal strength

*channel (frequency)

*data rate of the packet

Section 2 : MAC Header and Frame Control of a beacon frame

Following information’s are available in  MAC-LAYER.

*Type of fame

*sub-frame type

*Frame control Flags

*Source address of the frame

*Destination address of the frame : FF:FF:FF:FF:FF:FF(Broadcast)

*BSSID

Section 3: Beacon Frame Body

Following information’s are available in  frame body of Beacon frame.

*Beacon Interval

*capability information: Support for APSD, BLOCK-ACK

*SSID parameter

*Supported rates

*Country Information

*RSN Information

*HT Capability

*Vendor Specific attributes

Wi-Fi troubleshooting with Beacon Frame:

1.)Beacon Miss : I have experienced issues where client missing to hear the beacons would cause them go for repeated frequency scanning and re-association request or disconnections. Some clients are so sensitive that missing 3 or 4 beacons will cause a disconnection and few other survive till 7 too.

You might need to analyse the AIR traffic to see if AP sending out beacons at regular interval or if the beacons getting corrupted in Air or if client receives a corrupted frames.

In such cases try to plot a IO graph in your Wireshark application and/or enable the column DELTA TIME  in Wireshark, which ever is your choice or if both. I prefer to use IO output(this can be further more customized during the Tshoot). NOTE: Getting the exact/close enough problem time frame is key thing.

IO Graph:

The Below sample graph shows you the total traffic on AIR captured VS Beacon (IN RED)send out by AP for a given time.

IO_Beacon

Y-axis represents number of packets and X-axis shows with respect to the time interval.

Default beacon interval time on most vendors are usually every 0.1024 second.

2.)Wifi signal strength identifier: If you get to sniff the traffic staying as close as possible to the client machine , you get to see how well the client can hear the SSID(signal strength). [ considering comparing receiving sensitivity of the sniffing adapter and client NIC ]. Then by Looking at the signal strength parameter you can tell if the client is connected to far away access point or having week signal.

This will help mostly to isolate issues such as network coverage holes especially for engineers who is validating the network from remote.

3.)Date rate: Looking at the rate Beacon is sent out, you can tell if lower data rate has been disabled or not. Since Beacons always sent out @ lowest rate (base rate) configured on the Essid. Also the supported rate parameter in the frame body gives you information at the lowest rate the data packet(QoS data) will be send.

4.) BSSID parameter on the Beacon will tell you which AP the beacon belong to. So you get to know how far the AP is away from the user(if the capture is taken close to the user). NOTE: BSSID is unique to an AP.

Unless the wireless infrastructure is a single channel architecture where all the APs will share the same BSSID on a given radio.

5.) If you want to know whether if the AP supports or advertising its support for WMM, Fast BSS transition support , you should be able to find that by looking at the beacon frame.

6.)RSN information on the Beacon frame will tell if the SSID is secured or open. This field is critical for a wireless client to identify if they are connected to open network or secured network and after the wireless layer 1 association(I like to call this as Layer-1) if client need to send out a DHCP packet(Layer-3) or it has to perform layer 2 authentication further like MAC-AUTH/MACHINE-AUTH/DOT1.X before layer 3.

Seen following cases in field:  On a beacon frame RSN bit is set for a captive portal SSID(incorrect behavior of AP a software bug) causing the client connection issues. While in the same environment Macintosh laptops were able to survive this issue while the other IOS devices couldn’t and they were not able to associate to Wireless network.

7.)Beacon frame carries information about the AP vendor and even the AP chipset vendor in use.

Its been helpful for me adding some useful column’s such as “DATE RATE , SIGNAL STRENGTH, CHANNEL, RETRY, DELTA-TIME” in Wire-shark application during my packet analysis.

You can always add more packet list column preference that will help your packet analysis.

wireshark colume's

 

 

 

 

 

 

 

 

The Problematic CTS TO SELF packet

Recently, I was working on a VOIP over Wi-Fi issue for a Japan customer. The complain from the user is that the VOIP calls over Wi-Fi goes static or disconnects often.  I started to Debug this issue analyzing the station log to see the behavior of the client while its associated to wireless network. I couldn’t find the issue straight forward.

Checked to Confirm the RF Numbers and Network configuration with best practices for VOIP over Wi-Fi is already in place. So, i though its better to sniff the Air and  read the packets to narrow down the issue.

VOIP SETUP IN PLACE: Android phone running VOIP application.

-Android client 4.4.2

-VOIP Application :Covia Networks(softphone)

-Fortinet(Meru)Wireless System.

My first level of Troubleshooting analysis on the aircapture took a different direction while analysis the packets in Ominpeek with the time frame of issue mentioned (I was bit lazy at this point)

CTS_TO_SELF

Attached the Wi-Fi packet capture for your reference. Packets to look for are #45571,#65972

>I felt,  haaa why is the AP sending CTS frame with a 10000 Microsecond of duration time.

CTS1

>You see Omnipeek EVENT/LOG viewer tells so. The AP has sent this CTS  frame to the client device with 10000 microsecond

CTS_TO_SELF

Then i was looking at the same capture on wire shark protocol analyser(no event or log view ) and realized that client has never sent an RTS frame requesting for channel access.

cts-self_wireshark

>I then realized its a CTS TO SELF frame from Android client with high duration values set and that’s causing all the problem for VOIP application running over it.

>I felt, i gone so lazy that i almost decided that the issue is because of the AP sending high duration value by comparing EVENT/LOG in Omnipeek.(that was definitely incorrect).

>The android client build with Broadcom SOC chipset , so no quick fix from client side on this issue. Customer was asked to run the VOIP application on a different client device to sort this client side issue(Workaround i was able to suggest for)

Packet capture download link:

https://www.dropbox.com/s/969z0w8xr881c1g/100ch_3min_default.pkt?dl=0

 

System commander Script for troubleshooting Fortinet Infrastructure AP reboot/radio reset issues

Its sometime get tough troubleshooting an AP Reboot issue. While troubleshooting Fortinet WiFi APs, You might need to capture the AP flash event log to identify the cause of reboot. However, some time AP flash space ran out  already storing Maximum logs files(This could happen if AP is Up and running log time in production or there are many events happening in AP that filled up the space soon). In this case you might need to clear those flash log space, so it can store the latest/ fresh log files.

This is needed because you making sure that those are latest logs of the crash/reboot happened.

#You run the following command on AP to clear the old flash logs:

file areaerase logk0 

file areaerase logk1

#You run the following command to read the flashlogs in the AP:

flashcmds show logk0

flashcmds show logk1

However, Incase of big deployments where you cannot run this on each AP separately and  also without causing WIFI service disruption you have to run this at-least on a bunch of AP to save your time. We have something called “system commander” where you will be executing a script to clear those AP flash logs.

Step1:

To use the system commander tool you have to enable telnet on the controller.
FortiWLC# configure terminal

FortiWLC(config)# telnet enable

Step2:

Please create a folder on the c drive of your computer and copy these two files shared on the link below:
https://www.dropbox.com/s/82ir713iegxj0tt/SystemCommandExecutor_Ver14.exe?dl=0

https://www.dropbox.com/s/otrkiobxmhnhq4y/SystemCommands_AP.txt?dl=0

Step3:
Run the following commands from your computer command prompt window.

SYNTAX: cfolder_name SystemCommandExecutor_Ver14.exe -c ipaddressofcontroller-username-password -o 4 -a APMODEL -l 1

Example for AP822s: 

C:\PRAVEEN>SystemCommandExecutor_Ver14.exe -c 192.168.10.3-admin-admin -o 4 -a AP822 -l 1

Explanation:

The folder name is the name of the folder in which you have saved the files(SystemCommands_AP.txt) on c drive. The username and password are the login credentials of the controller. The logs will be saved in the same folder on c drive once the loop is completed.

If you look at the syntax it has AP model mentioned in that so please choose the AP model accordingly, depending on for which AP you want to collect the logs.
* For any and all AP reboots we need to run this to gather AP reboot logs (file areaerase logk0/logk1)
* After collecting Disable Telnet

1. On the command prompt we need to specify AP model. Since we can only collect with particular AP type. If customer has mixed AP environment we need to collect separately for each AP model.
2. If we have any AP which is disable offline. Make sure to delete that entry before running System commander, since loop will end at that point and we don’t have option to start again from there. (Ex: If we have 100 AP on network and AP ID 44 is offline, loop will end at AP Id 44)

Addon :You can add more commands on the script file(SystemCommands_AP.txt) to execute and get to collect a dump of those command output’s too.

 

 

Single Channel Architecture VS Multi Channel Architecture

This Blog post is about Fortinet Single Channel Architecture(legacy MERU) and Multi Channel Architecture. This blog is nothing related to the discussion on which will outperform the other.

Since I work on both SCA and Multi channel architecture, Just thought of sharing some insight about what is all this Single Channel Architecture and how that you can compare with that of traditional MCA.

 

Single Channel Architecture Multi-Channel Architecture

 

1 Wireless System in control of WLAN network by deciding the Client Association and Roaming Factors Wireless clients do make decisions in your WLAN network for Association and Roaming
2 Wireless clients are connected on single channel called VIRTUAL CELL and their Random back-off algorithm “CWmin – CWmax” for clients  in the same contention space are proposed by Wireless System.

Pros:#No Channel Planning required and easy administration.#Client’s Contention space is decided/Managed by wifi system. So even if there are other client sending/receiving data in same channel the system will calculate, if sending or receiving data from any other client on a calculated RSSI going to cause any impact for others and then decision will be made to give transmit opportunity.

Cons: Design flaws can cause:*high Channel usage*High AP Neighbor count*Management overhead

Wifi clients are allowed to run and select independent BACKOFF value(CWmin-CWmax) for channel access.Note:Since individual clients choose their  own backoff algorithm and no coordination between clients result in retry and Channel access collision mostly in High density environment. So You are forced to create small Cells.Pros:#Effective Spatial reuse(channel planning)and TX power operation is must but once done it works reliably#Can say MCA works parallel to RF physics

Cons: Design flaws can cause:*CCI and ACI*TX power and channel plan*Client contention causing Retries and    Collision when number of client increased.

3 Airtime Fairness is TIME based fairness Even MCA vendors doing Time based Airtime Fairness for long time now.
4 Recommended EIRP 2.4Ghz: 17dbm && 5Ghz: 23dbmNote: Might need to reduce TX power based on Deployments(considering the signal propagation.i.e, More open space env. Recommended EIRP 2.4ghz:10dbm  && 5ghz: 12dbm(+ or – 3dbm).

 

5 Number of Visible Access point for clients
Data = 2 or 3 APs
Number of Visible Access point for clients
Data = 2 APs
6 VHD=20MHZ, HD=40MHZ,Many SCA Deployments do have channel width of 80MHZ set and works pretty well.  Note sure about field values for 80+80(160)MHZ VHD=20MHZ, HD=20 and/or 40MHZCannot think about 80 MHZ or 80+80(160)MHZ in enterprise network.

 

7 In High density deployments you might need to check Duty Cycle because management frame and beacons are heard from other APs crowded on Same spacial Diversity(channel), Look for Retry and AP Neighbor counts because that could cause potential issues.Note: Refer High Density Design Guide In High Density Environment you might need to still bring down the TX power/disable low data rates consideration of Antenna Type, ie: Yagi or patch or omni

 

8 High Density SCA network With More client/bandwidth Requirement  needs Channel Layering or Channel striping and AP poding  and that depends on the Building Structure.  High density/capacity requirement needs you to add more radio and form small micro cells with least CCI by spacial reuse and either disabling radio or reducing AP TX power and more focused coverage pattern and etc.
9 Virtual Cell to Virtual Cell roaming is HARD HANDOFF.Since Microcell is also supported in Fortinet Infrstucture OS, I would like to mention Microcell to microcell is efficient with PMK, 802.11.                                                                Microcell to Microcell roaming is supported efficiently by PMK,OKC,802.11KVR.Note: No virtual cell support.

 

10 Supports both SCA and MCA with ARRP(Automatic radio resource provisioning. Supports MCA only with (Automatic radio resource provisioning).

 

My take on SCA over MCA:

SCA “Virtual cell” method take on the traditional “Micro cell” method by negotiation of RF overhead(How well can manage) vs Clients contention based Retry/Collision(How well can manage)

And the System has a central brain call “coordinator” which reads the RF condition based on the interim updates from different supporting worker modules, takes decision in providing better AIRTIME Fairness and user performance for wireless clients.

Test Bed:

If you would like to play around with Fortinet-SCA more just setup your test environment for the following and you can come up with your test cases and values.

A simple example that is easily replicated in the lab is to take five or six access points, all configured for the same channel, and 30 or so wireless clients. Put them all in one room and observe the aggregate throughput.

Then take those same clients and access points and distribute them across the floor of a building and observe the new, increased/decreased aggregate throughput.