Using Location Feed

Figure 8: AeroScout Network Diagram

In addition to Fortinet standard Wi-Fi infrastructure, AeroScout Location Receivers and Exciters can be deployed for time-different of arrival (TDOA) locationing and choke points respectively.

Configuring AeroScout

Tracking tags is done from the AeroScout product using a Forti WLC and APs. To configure a Forti WLC to work with AeroScout, use the command aeroscout enable as shown here:

 

controller(config)# aeroscout ?

disable                (10) Disabling AeroScout Feature. enable                 (10) Enabling AeroScout Feature. ip‐address             (10) The Aeroscout engine IP address. port                   (10) The Aeroscout engine port. controller(config)#

Location Accuracy

Since RSSI values are the basis of the location calculation, the access point must match its channel with the tag’s transmission channel, and drop tag messages that were transmitted on a channel other than that of the access point. The matching is implemented because tag reports contain the transmission channel in each message.

For this reason, the combination of AeroScout’s solution architecture with Fortinet’s Virtual Cell deployments and Air Traffic ControlTM technology provide a more accurate location for tags. In other words, Fortinet’s APs can all be deployed in a single channel with a virtualized BSSID, thereby providing more reference points for the tag messages and a more accurate location.

For the location of a tag to be calculated accurately, at least three access points need to report the Wi-Fi message transmitted by the tag. A message received and reported by less than three APs provides only a very general location which, in most cases, is the location of the AP closest to the tag. To see the tag locations, use AeroScout. Tags do not show up when you use the Fortinet CLI command show discovered-station or anywhere else from the Fortinet CLI.

It is important to place APs closer to the perimeter of the space that will tag and track assets, filling in coverage holes in the center of the coverage area. It is better to surround the tracking area. Aside from this, use standard Fortinet Networks deployment guidelines in placing the APs and distancing them from one another. In other words, plan for coverage and optimal data rates. When AeroScout Exciters are used for choke-point location, one AP receiving the Tag message is enough to deliver an accurate location report.

Tag Protocol Implementation

The Tag protocol operates between access points and the AeroScout engine. The Fortinet AeroScout implementation supports tag (but not laptop) messages transmitted in either in IBSS (default) or WDS frame format, although Fortinet APs receive and process tag frames only in IBSS format.

Once the Forti WLC and access points are upgraded to the current version, the tag protocol is enabled automatically. No additional configuration steps are necessary. Management of the AeroScout Tags, Engine, and MobileView application are managed through the AeroScout platform. Figure 9 on page 81 shows the operation and messages used in the Tag protocol:

Figure 9: AeroScout Tag Protocol Messages

AeroScout Tag                    AP                            Controller                         AeroScout Engine

AeroScout and Rogue Detection

If an AP interface is in dedicated scanning mode with Rogue AP enabled, tags are not forwarded for any channels. If an AP interface is in normal mode with Rogue AP enabled, tags are forwarded on the home channel only. Tags on foreign channels are not forwarded.

AeroScout Syslog Error Messages

Error Condition	Severity	Message
Cannot create a ATS AeroScout Manager mailbox	critical	AeroScoutMgr mailbox creation failed
Cannot set AeroScout mode in the driver	critical	Cannot set AeroScout mode to enable/disable
Invalid AE messages	warning	Unknown Message Code[0xXX]
		Data length error. rcvdLength[%d], expect at least [%d]
Messages from unknown or unsupported mailboxes	miscellaneous	Msg from Unknown MailboxId[xx]
Cannot allocate a mailbox buffer to send a controller message	warning	AllocBuf failed reqID[0xXXXX]
IOCTL to the AeroScout kernel module failed	warning	reqID[0xXXXX] IOCTL[xx] to AeroScout kernel module failed
Cannot get wireless channel config information	warning	Could not get wireless interface config for interface[xx]

AeroScout Mobile Unit

AeroScout offers Wi-Fi-based solutions for Real Time Location Service (RTLS). The following devices support AeroScout tag based location management:

• AP400 AP822
• AP832
• FAP-U421EV
• FAP-U423EV
• AP1000

The AeroScout Mobile Unit architecture is displayed in Figure 10 on page 83. The following is the high-level process that occurs in the implementation:

• Wi-Fi mobile units send wireless frames to one or more APs.
• The AP sends reports for each Wi-Fi mobile unit (by using a dilution mechanism to control traffic between AP and Engine) to the AeroScout Engine.
• The AeroScout Engine determines the coordinates and sends it to AeroScout MobileView.
• The AeroScout Mobile View uses location data to display maps, enable searches, create alerts, manage assets, work with third-parties, and much more.

Figure 10: Aeroscout Mobile Unit

Wi-Fi Mobile Units (MUs) can be located, if associated to some access point, or while transmitting broadcast or unicast messages. The messages transmitted by Wi-Fi Mobile Units are received by Access Points and are passed along with additional information (e.g., signal strength measurements) to the AeroScout Engine, which is a core component of the AeroScout visibility system. The AeroScout Engine also calculates an accurate location of the WiFi device. In order to locate the Mobile Units, Access Points that receive their messages must pass the RSSI values of each message to the AeroScout Engine. The access points must also be able to collect data messages from MUs that are not associated with them and pass the RSSI values to the AeroScout Engine.

Reporting Tags and/or Wi-Fi mobile units must not affect the normal operation of the AP—that is, the AP must be performing in all its supported modes, such as normal 802.11a/b/g communication, monitoring, bridge modes, etc. Due to the high MU traffic, it is possible to dilute the MU messages that are sent to AeroScout Engine.

Configuring AeroScout

Tracking tags is preformed from the AeroScout product using a Forti WLC and APs. To configure a Forti WLC to work with AeroScout, use the command aeroscout enable, as shown below:

default# sh aeroscout

Aeroscout Parameters

Enable/Disable              : enable

Aeroscout Engine IP Address : 0.0.0.0 Aeroscout Engine Port       : 12092 default#

Configure AeroScout Mobile Unit from AeroScout Engine

Follow the steps below to configure an AeroScout Mobile Unit from the AeroScout Engine:

1. Enable Aeroscout on the controller.
2. Open the Aeroscout Engine.
3. Load the Floor Map on the Engine.
4. Add the APs on the Aeroscout Engine.
5. In the Configuration->System Parameters->Access Points, check the “Enable mobile-unit location with access Points” checkbox.
6. To start the Mobile Unit Positioning option on the AeroScout engine, select ‘Start MU positioning’ from the Actions menu.

AeroScout Compounded Report

For better performance, several MU reports can be combined within a fixed pre-defined period in Compounded Reports. Fortinet’s system combines a maximum of 18 MU reports in one Compounded Report. The number of Mobile Unit reports inside the Compounded Report varies as per the Compounded Message Timeout configured on the Aeroscout Integration Tool. The ‘Compounded Message timeout’ is configured on the Aeroscout Integration tool under ‘Set Configuration’.

Dilution Timeout

In certain scenarios, the Mobile Unit traffic may be high, and the time resolution needed for location is much lower than the data rate of most Mobile Units. If every AP starts reporting every Wi-Fi frame to the Aeroscout Engine, it will create unnecessary data overhead on the network, and provide a real-time location in a level much higher than required.

To help the AP dilute messages from each Mobile Unit, the Aeroscout protocol provides the following two parameters:

• Dilution Factor
• Dilution Timeout

Fortinet Mobile Unit reporting supports and implements only Dilution Timeout. The Dilution Timeout allows to set a limitation for the amount of time with no Mobile Unit messages from a specific Mobile Unit.

For Example: If the Dilution Timeout value is set to 60 seconds and, if the AP receives a message from an MU for which it has not reported a message to the AE for more than 60 seconds, the new message will be reported to the AE immediately regardless of the dilution factor and the dilution counter will be initialized. Commands broadcast by an MU (e.g. Probe Requests) are required to be forwarded to the AE regardless of the dilution parameters.

The Dilution Timeout can be configured on the Aeroscout Engine as follows Configuration->system parameters->Access Points->Dilution Time out.

Generic AP Notification

Generic AP notifications are autonomous messages sent to the Aeroscout Integration tool on port 12092 to report the AP connectivity state (AP comes online, offline, Aersocout parameter configuration changes).The Aeroscout Integration tool acknowledges all Generic AP notification messages sent by the controller. For Generic AP Notifications, the IP address of the Aeroscout engine must be configured on the controller.

In the Fortinet solution, Generic AP notifications are sent out from the controller to the Aeroscout Engine during the AP connectivity state change or when aeroscout configurations on the controller undergoes a change. In general a Generic AP notification is used to communicate an IP address change, a “wake up” from reboot, and or any error conditions that need to be communicated to the Aeroscout engine.

Configure AeroScout Integration tool for Receiving the Generic AP Notification

To Configure AeroScout Integration tool for receiving the Generic AP Notification, perform the following steps:

• Enable AeroScout on the controller and configure the ip-address of the AeroScout Integration tool on controller.

 

• Open the AeroScout Integration Tool and configure the port from the default value 1122′ to ‘12092’. In the scenario where the AP’s come online and go offline, change the AeroScout Configuration parameter on the controller. The Controller sends a generic AP Notification for all the AP’s on the Controller and the AeroScout Integration Tool acknowledges to the controller’s notification for each generic AP Notification.

Using AeroScout

The AeroScout System version 3 (but not version 2) product works with Forti WLC and AP400, A822, AP832, FAP-U421EV and FAP-U423EV and AP1000 models to locate and track tagged assets to deliver direct benefits such as process automation and theft prevention. Tags are small, battery-powered devices attached to equipment or personnel. See AeroScout’s web site for more detailed information about the various tags available from AeroScout.

AeroScout tags do not associate to an access point; instead they send out beacon signals in pre-configurable intervals or when an event is triggered (the tag is in motion, a button is pressed, etc.). Messages transmitted by AeroScout tags are received by access points and are forwarded with additional information, such as RSSI values or signal strength measurements, to the AeroScout Engine. The Engine calculates the accurate location of the tag.

Reporting Tags do not affect the normal operation of access points; they keep performing in all of the supported modes (802.11a/b/g communication). AeroScout Tags also do not have an IP address and are unidirectional in the sense that they transmit and do not receive standard WiFi messages.

For APs to process the tag signals and communicate with the AeroScout Engine, the AeroScout Engine-AP Interface protocol must be implemented on access points. In Figure 8 on page 79, the AeroScout solution architecture is shown. The following is the high-level process that occurs in the implementation:

• AeroScout tags send short wireless messages at a regular interval.

Using AeroScout

• The signal is received by access points that are connected to a Forti WLC running AeroScout software, and the signal is sent to the AeroScout engine along with its measured signal strength.
• The AeroScout engine uses signal strength to determine the coordinates of the reported location, and sends this data to AeroScout MobileView. AeroScout MobileView uses location data to display maps, enable searches, create alerts, manage assets, interface to third parties through an API.

802.11n Video Service Module (ViSM)

Video streaming has the low latency and loss requirements of  with the high-throughput requirements of data. The Fortinet Video Service Module™ (ViSM) is an optional licensed software module that delivers predictable 802.11 video performance with minimal delay, latency and jitter. Sustainable high data rates, even in mixed traffic, are supported along with synchronization of video and audio transmissions.

ViSM also introduces additional mechanisms for optimizing unicast and multicast video such as application aware scheduling, /video synchronization, and client-specific multicast group management. Features include the following:

• High throughput with low burstiness offers predictable performance and consistent user experience
• Application-aware prioritization synchronizes the and video components of a video stream, adapting the delivery of each frame based on its importance to the application.

802.11n Video Service Module (ViSM)

• Multicast group management optimizes delivery to only those Virtual Ports whose clients are members of the multicast group.
• Seamless video-optimized handoff proactively reroutes the multicast delivery tree to prevent lost video frames during a transition between access points and ensures zero loss for mobile video.
• User and role based policy enforcement provides granular control over application behavior.
• Visualization reveals which clients are running which applications.

Implementing ViSM

Virtual Port already changes multicast to unicast transmissions. ViSM adds per-client IGMP Snooping to the transmission. Therefore, to implement ViSM, turn on IGMP Snooping. CLI commands control IGMP snooping (see FortiWLC (SD) Command Reference). At this time, ViSM licensing is not enforced.

Configuring FortiWLM Location Manager

Location Manager is supported by release 3.7 and later.

Configuring with the CLI

This example creates a packet-capture-profile named Location on a controller and then forwards the captured packets directly from AP 16 to Location Manager on port #9177. Port 9177 is the port where Location Manager is listening for incoming packets in L3 mode.

MC3K‐1#

MC3K‐1# configure terminal

Licensing for Virtual Controllers

 

MC3K‐1(config)# packet‐capture‐profile Location

MC3K‐1(config‐pcap)# mode l3 destination‐ip 1.1.1.1 port 9177

MC3K‐1(config‐pcap)# ap‐list 16

MC3K‐1(config‐pcap)# exit

MC3K‐1(config)# exit

MC3K‐1# show packet‐capture‐profile Location AP Packet Capture profiles

Packet Capture Profile Name            : Location Packet Capture profile Enable/Disable   : off

Modes Allowed L2/L3                     : l3

Destination IP Address                  : 1.1.1.1

UDP Destination Port                    : 9177

Destination MAC for L2 mode             : 00:00:00:00:00:00

Rx only/Tx only/Both                    : rx

Rate Limiting per station or cumulative : station

Token Bucket Rate                       : 10 Token Bucket Size                       : 10 AP Selection                            : 16

Extended Filter String                  : Interface List                          :

Packet Truncation Length                : 82

Rate Limiting                           : off

Capture frames sent by other APs in the network : on MC3K‐1#

For a detailed explanation of the packet capture profile commands, see the Troubleshooting chapter of the FortiWLC (SD) Configuration Guide.

Configure Controller Parameters From the CLI

Reset System and System Passwords from the CLI

The passwords for the system users “admin’ and “guest” can be reset to their default values during a system boot. When the controller prompts “accepting reset request” displays, type pass to reset the passwords.

To reset the settings for the entire system to their default values, type reset at the reset system values prompt.

Limit Wireless Client Access to the Controller From the CLI

Administrators wishing to block access to the controller management utilities for wireless clients can do so with the no management access command. When wireless management access is blocked, all packets sent to the controller by wireless clients are dropped except for those used for Captive Portal.

To remove wireless access to the controller, enter the command: controller(config)# no management wireless

To check the management status, use the show controller command. The line near the bottom of the output, Management by wireless stations: will show either an on or off value.

mc3200# show controller

Global Controller Parameters

Controller ID : 1

Description : controller Host Name : MC3200 Uptime : 05d:17h:10m:59s

Location :

Contact :

Operational State : Enabled

Availability Status : Online

Alarm State : Major

Automatic AP Upgrade : on

Virtual IP Address : 172.29.0.137

Virtual Netmask : 255.255.192.0

Default Gateway : 172.29.0.1

DHCP Server : 10.0.0.240

Statistics Polling Period (seconds)/0 disable Polling : 60

Audit Polling Period (seconds)/0 disable Polling : 60

Software Version : 6.0.SR1‐4

Network Device Id : 00:90:0b:23:2e:d3 System Id : 08659559054A Default AP Init Script :

DHCP Relay Passthrough : on

Controller Model : MC3200

Region Setting : Unknown

Country Setting : United States Of America

Manufacturing Serial # : 4911MC32009025

Management by wireless stations : on

Controller Index : 0

FastPath Mode : on

Bonding Mode : single

Station Aging Out Period(minutes) : 2

Configure Controller Parameters From the CLI

Roaming Domain State : disable Layer3 Routing Mode : off

To re-enable access to wireless clients, use the management wireless command: controller(config)# management wireless

Limit Wired Client Access to the Controller With QoS Rules

To control access to the controller from wired network devices, you can configure rule-based IP ACL lists using the qosrules command. This section provides qosrule examples for several types of configurations.

The following is an example that blocks management access (on TCP and UDP) to the controller (at 192.168.1.2) for all devices except the host at 192.168.1.7. Notice that match tags are enabled when srcip, dstip, srcport, dstport, netprotocol, or packet min-length is configured for a rule.

Allow the host 192.168.1.7 to access the controller with TCP/UDP:

controller(config)#  qosrule 20 netprotocol 6 qosprotocol none controller(config‐qosrule)# netprotocol‐match controller(config‐qosrule)# srcip 192.168.1.7 controller(config‐qosrule)# srcip‐match controller(config‐qosrule)# srcmask 255.255.255.255 controller(config‐qosrule)# dstip 192.168.1.2 controller(config‐qosrule)# dstip‐match controller(config‐qosrule)# dstmask 255.255.255.255 controller(config‐qosrule)# action forward controller(config‐qosrule)# end

controller(config)# qosrule 21 netprotocol 17 qosprotocol none controller(config‐qosrule)# netprotocol‐match controller(config‐qosrule)# srcip 192.168.1.7 controller(config‐qosrule)# srcip‐match controller(config‐qosrule)# srcmask 255.255.255.255 controller(config‐qosrule)# dstip 192.168.1.2 controller(config‐qosrule)# dstip‐match controller(config‐qosrule)# dstmask 255.255.255.255 controller(config‐qosrule)# action forward controller(config‐qosrule)# end

The following qosrules allow wireless clients to access the controller on TCP ports 8080/8081 if using the Captive Portal feature.

controller(config)# qosrule 22 netprotocol 6 qosprotocol none controller(config‐qosrule)# netprotocol‐match

controller(config‐qosrule)# srcip <subnet of wireless clients> controller(config‐qosrule)# srcip‐match

controller(config‐qosrule)# srcmask <netmask of wireless clients>

controller(config‐qosrule)# dstport‐match on controller(config‐qosrule)# dstip 192.168.1.2 controller(config‐qosrule)# dstip‐match controller(config‐qosrule)# dstmask 255.255.255.255 controller(config‐qosrule)# dstport 8080 controller(config‐qosrule)# action forward controller(config‐qosrule)# end

controller(config)# qosrule 23 netprotocol 6 qosprotocol none controller(config‐qosrule)# netprotocol‐match

controller(config‐qosrule)# srcip <subnet of wireless clients> controller(config‐qosrule)# srcmask <netmask of wireless clients> controller(config‐qosrule)# dstport‐match on controller(config‐qosrule)# dstip 192.168.1.2 controller(config‐qosrule)# dstip‐match controller(config‐qosrule)# dstmask 255.255.255.255 controller(config‐qosrule)# dstport 8081 controller(config‐qosrule)# action forward controller(config‐qosrule)# end

The following qosrules block all hosts from accessing the Controller using TCP/UDP.

controller(config)# qosrule 24 netprotocol 6 qosprotocol none controller(config‐qosrule)# netprotocol‐match controller(config‐qosrule)# dstip 192.168.1.2 controller(config‐qosrule)# dstip‐match controller(config‐qosrule)# dstmask 255.255.255.255 controller(config‐qosrule)# action drop controller(config‐qosrule)# end

controller(config)# qosrule 25 netprotocol 17 qosprotocol none controller(config‐qosrule)# dstip 192.168.1.2 controller(config‐qosrule)# dstip‐match controller(config‐qosrule)# dstmask 255.255.255.255 controller(config‐qosrule)# action drop controller(config‐qosrule)# end

Configuring UDP Broadcast From the CLI

You can enable all UDP ports at once with the CLI commands for upstream and downstream traffic. Fortinet does not recommend that you enable this feature on a production network because it could lead to broadcast storms leading to network outages. This feature is provided for testing purposes only.

Configure Controller Parameters From the CLI

You need to assign each ESS (see the chapter “Configuring an ESS.”) to a specific VLAN (see the chapter “Configuring VLANs.”) before enabling all UDP broadcast ports. Having multiple ESS’s in the default VLAN and enabling all UDP broadcast ports does not work.

To configure UDP broadcast upstream/downstream for all ports, use these two CLI commands:

default# configure terminal default(config)# ip udp‐broadcast upstream all‐ports selected default(config)# ip udp‐broadcast downstream all‐ports on default(config)# end

To display configured UDP broadcast upstream/downstream for all ports, use these two CLI commands:

default# show ip udp‐broadcast upstream all‐ports

Upstream UDP Broadcast All Ports

UDP All Ports : on default#

default# show ip udp‐broadcast downstream all‐ports

Downstream UDP Broadcast All Ports

UDP All Ports : selected default#

To view the currently configured broadcast ports for either upstream or downstream, use show ip udp-broadcast [downstream/downstream-bridged/upstream/upstream-bridged].

Configure Time Services From the CLI

We recommend that you configure controllers to synchronize their system clock with a Network Time Protocol (NTP) server. This ensures the system time is accurate and standardized with other systems. Accurate and standardized system time is important for alarms, traces, syslog, and applications such as cryptography that use timestamps as a parameter for key management and lifetime control. An accurate clock is also necessary for intrusion detection, isolation and logging, as well as network monitoring, measurement, and control.

During the initial system configuration, the setup script prompts for an IP address of an NTP server. If you do not supply an IP address of an NTP server at that time, or if you wish to change an assigned server at a later time, you can use the ntp server followed by the ntp sync commands.

• To set up automatic periodic synchronizing with the configured NTP server, use the command start-ntp.

There are several NTP servers that can be designated as the time server. The site www.ntp.org provides a list of servers that can be used.

To set a server as an NTP server, use the command:

ntp server ip-address

where ip-address is the IP address of the NTP server providing clock synchronization.

Configure a Controller Index with the CLI

To configure a controller index from CLI, using the following commands

ramecntrl(0)# configure terminal ramecntrl(0)(config)# controller‐index 22 ramecntrl(0)(config)# exit

Note that changing the index causes a controller to reboot.

Configure Controller Parameters From the Web UI

To reconfigure an existing controller, click Configuration > Devices > Controller > [select a controller] > Settings. The following parameters can be configured from the Web UI with Level 10 permission:

• Information for recognizing and tracking controllers such as the Description, Location, and Contact person
• Whether or not APs should be Automatically Upgraded by a controller
• DHCP Server address and DHCP Relay Passthrough (whether or not packets are actually passed to the DHCP server)
• Statistics Polling Period and Audit Polling Period, which affect how often a controller refreshes data
• Default AP Initialization Script (bootscript) that run on APs with no other script specified
• Controller Index number used for identification (Note that changing this initiates a controller reboot.)
• Whether or not the controller will interact with the AeroScout Location Engine and associated APs will interact with AeroScout Tags to provide real-time asset tracking
• Whether or not Fastpath Mode is used. Fastpath Mode accelerates the rate that packets move through the Ethernet interface based on identification of an IP packet stream. When FastPath is enabled, the beginning of the IP packet stream is processed by the controller, and all subsequent packets of the same stream are forwarded according to the disposition of the initial packets, without being processed by the controller. This offloads a significant amount of processing from the controller.
• Bonding Mode affects MC4200, MC5000, and MC6000 models. Single Bonding combines all Ethernet ports into one port for accelerated throughput. Dual Bonding configures two ports for the controller.

Configure Controller Parameters From the Web UI

• Virtual Cell for AP400, or AP1000 is not determined by any controller setting.
• Whether or not Dynamic Frequency Selection (DFS) is enforced. For installations within the United States, enforcing DFS means that channels 52-64 (5.25-5.35 GHz), 100-116 (5.475.725 GHz), and 136-140 (5.68-5.70 GHz) conform to DFS regulations, protecting radar from interference on these channels.
• The number of minutes of station inactivity that causes a client to time out is set by the Station Aging Out Period.

Configure UDP Broadcast with Web UI

You can enable all UDP ports at once with the WebUI commands for upstream and downstream traffic. Fortinet does not recommend that you enable this feature on a production network because it could lead to broadcast storms leading to network outages. This feature is provided for testing purposes only.

You need to assign each ESS (see the chapter “Configuring an ESS.”) to a specific VLAN (see the chapter “Configuring VLANs.”) before enabling all UDP broadcast ports. Having multiple ESS’s in the default VLAN and enabling all UDP broadcast ports does not work.

To configure UDP broadcast upstream/downstream for all ports, follow these steps:

1. Click Configuration > Devices > System Settings.
2. Click the tab UDP Broadcast Ports.
3. Determine the type of UDP Broadcast mode you wish to configure (Tunnel Mode or Bridge Mode) and click that Tab.
4. Click Add.
5. Check the type of UDP Broadcast rule you wish to configure, Upstream or Downstream.
6. Enter a UDP Port Number in the range 1-65355 and then click Save. The port number now appears in the UDP Broadcast Port list.

Perform the above steps for as many ports as desired.

Configure Basic Controller Parameters During Setup

These basic controller parameters are configured by someone with Level 15 permission, using the interactive setup script that sets up every new controller:

• Country setting
• Controller location

Configure Basic Controller Parameters During Setup                                                                                                             69

• Hostname
• Passwords for admins and guests
• Dynamic IP address or a static IP address and netmask
• Time zone
• DNS server names
• Gateway server name
• Network Time Protocol server

To start the setup script, at the Privileged EXEC prompt, type setup. Refer to the “Initial Setup” chapter of the FortiWLC (SD) Getting Started Guide for an example session using the setup command.

Upgrading Patches

In addition to providing options to install and un-install patches, you can now easily view more details about the contents of a patch and also get history of patches installed in the controller.

These new options are available via the controller WebUI and the CLI.

Using the WebUI

Patch management options are available in the Maintenance > File Management > Patches tab. If there patch build file copied in the controller, they will be listed on this page. For specific option, select a patch file and click the option at the bottom of the page.

1. List of Patches
2. Patch History
3. Patch Install

Using CLI

1. show patches

Displays the list of patch builds copied to the controller.

#show patches

8.0‐0dev‐51‐patch‐bug1234 [installed]

8.0‐0dev‐50‐patch‐bug1234_bug1236

8.0‐0dev‐50‐patch‐bug1234

8.0‐0dev‐50‐patch‐2015.07.22‐17h.12m.09s

8.0‐0dev‐50‐patch‐bug1234_bug1235

8.0‐0dev‐51‐patch‐bug1234_bug1235

8.0‐0dev‐51‐patch‐bug1234

2. show patch installed

Displays the patch currently installed in the controller.

controller(15)# show patch installed

8.0-0dev-51-patch-bug1234

3. show patch history

Displays the history of all the patches installed and uninstalled in the controller controller(15)# show patch history

2015:07:24 01:51:13: uninstalled 8.0‐0dev‐50‐patch‐bug1234 on build 8.0‐0dev‐51

2015:07:24 01:54:13: installed 8.0‐0dev‐51‐patch‐bug1234_bug1235 on build 8.00dev‐51

2015:07:24 01:56:39: uninstalled 8.0‐0dev‐51‐patch‐bug1234_bug1235 on build

8.0‐0dev‐51

….<snipped>….

2015:07:24 14:54:50: uninstalled 8.0‐0dev‐51‐patch‐bug1234 on build 8.0‐0dev‐51

4. show patch details <patch-name>

Displays the list of bug fixes available in this patch.

controller(15)# show patch details 8.0‐0dev‐50‐patch‐bug1234

8.0‐0dev‐50‐patch‐bug1234 patch is revertable bugs:   37405: summary of bug 37405

controller(15)#

5. show patch contents <patch-name>

Displays the md5 sum of the patch build.

controller(15)# show patch contents 8.0‐0dev‐50‐patch‐bug1234

8.0‐0dev‐50‐patch‐bug1234

files:

  /opt/meru/etc/coord.config: 3d4c720265e21a53dfafe2a484e8bf11

6. patch uninstall <patch-name>

Use this command to un-install the patch build from the controller. controller(15)# patch uninstall 7. Reverting from backup.

cp ‐f /data/.patch‐backup//meru‐8.0‐0dev‐51‐patch‐bug1234/coord.config /opt/ meru/etc/coord.config

Reverting from backup done.