Setting Up Event Logs

Information log: records status changes that occur in the normal operation of the system. For example, when an end node associates to a parent Access Point.
Error log: records errors that occur occasionally, but which are easily recovered from by the bridge. For example, errors that occur during the reception and transmission of packets to and from the bridge.
Severe error log: records errors that drastically affect the operation of the system. The system continues to run, but action is required to return the bridge to normal operating standards.

Information Log

The following are events that appear in the Information log:

BOOTP/DHCP set new IP address

The BOOTP/DHCP server answered the request and assigned the bridge an IP address different from the configured value.

Node "node address" "device name" added

A nonvolatile entry was added to the association table.

Node "node address" "device name" "ASCII name" removed, max radio retries

A node was removed from the table because a response was not received from the node after attempts were made to transmit a packet to it. The node may have failed or moved to another cell.

RARP set new IP address

A Reverse Address Resolution Protocol (RARP) server answered a request for an IP address with an address different from the one currently saved. The currently saved value is overwritten.

Connected to parent "node address"

The bridge associated to its parent node.

SNMP: "command text"

A SNMP management station sent the bridge a set variable request which was successfully executed. The command tex t is a similar menu command that has the same effect as the SNMP request.

SNMP access failure from "community name" "IP address" (node address)

A SNMP management station attempted to access the SNMP agent with an invalid community name or a name that it was not allowed to use.

TFTP is loading "file name" from "ip address"

The BOOTP server gives the bridge the name of a configuration file and then the name of a firmware file to load.

Error Log

The following are events that appear in the Error log:

"Category" Error: nnn "type" errors

An error occurred that is marked by an asterisk * after its count in the statistics displays. These errors are serious enough to affect the operation of the bridge. See the sections on each display for an explanation of each error.

Unable to locate IP address "ip address"

The bridge was trying to send a packet to an IP address without knowing the hardware node ID. When this occurs, the bridge uses the ARP protocol to try to determine the proper address. This event is produced if there was no answer to the ARP request. Usually the bridge is trying to find the destination for the SNMP traps.

Severe Error Log

The following are events that appear in the Severe Error log:

Ethernet cabling problem

If no traffic was sent or received on the Ethernet cable in the last 10 seconds, the bridge sends a packet to itself to test the connection. If the transmission succeeds, the timer is reset. If it fails, this event is logged and traffic for the connection is discarded until the test succeeds.

Configuration is too large to save

The number of commands in the configuration is too large for the available nonvolatile memory. This error might be caused by too many nonvolatile entries in the association table.

Could not program the flash memory

An error occurred when trying to program a new version of the firmware into flash memory. The bridge must be serviced.

Lost our association, max radio retries

The bridge lost communications with its parent node after trying to send a packet the maximum number of times. The bridge will try to re-associate. The problem may be a parent Access Point failure. All local associations will be dropped.

Lost our association, radio restarted

A radio configuration parameter was changed. All associations are dropped and the radio is restarted.

Lost our association, new specified router

The specified router parameter of this bridge was changed. The bridge drops its current association and tries to reassociate.

Lost our association, NAK from router

The bridge responds as though it was associated to its parent but the parent does not have the association. The bridge will attempt to reassociate. The parent may have been rebooted.

The address PROM is invalid

Each bridge contains a programmable read-only memory (PROM) chip that contains the bridge's hardware address. During power up, the bridge was not able to read a valid address from the PROM. The bridge must be serviced.

Using the Logs Menu

Use the Logs menu to view event logs.

Navigation: Main > Logs

Viewing the History Log (History)

Use the History option to view a history of the events that have occurred on the bridge and the infrastructure. All events are stored within the bridge in a 10-KB memory buffer. The actual number of events the bridge saves depends on the size of each log stored in the buffer.

Log events display in a least-recent to most-recent order. If the memory buffer becomes full, the oldest event in the buffer is replaced by the most recent.

Only events that occurred since the bridge was last powered up or since the memory buffer was cleared are saved. See "Clearing the History Buffer (Clear)" later in this chapter.

Note If a power failure occurs, events contained in the memory are not saved.

The display will be similar to the following; each line of the display is described below:

Navigation: Main > Logs > History

OLDEST

0:00:00 I Node 004096109e30 APBR2000-E Floor_2_109e30 added locally

0:00:03 I Node 0040961064de AP2000-E F3_1064de added for 004096109e30

30:35:09 NEWEST, cleared at 0:00:00

b[ackward], f[orward], n[ewest], o[ldest], a[ll], C[lear], q[uit] :

OLDEST 0:00:00 I Node 004096109e30 APBR2000-E Floor_2_109e30 added locally 0:00:03 I Node 0040961064de AP2000-E F3_1064de added for 004096109e30 30:35:09 NEWEST, cleared at 0:00:00 b[ackward], f[orward], n[ewest], o[ldest], a[ll], C[lear], q[uit] :

First line: OLDEST indicates the end of the buffer display. This word will appear at the end of the history log.
Display lines: these two lines display the time since power-up that the event occurred, the severity level (I=information, E=error, S=severe) and the actual event text.
Last line: indicates the current time and the time the buffer was last cleared by the operator. NEWEST indicates the start of the history log.
Option line: indicates the movement keys to use when viewing the history log. Since displaying the entire history uses more than a screen page, use the following keys to navigate through the history log:

: b: moves back one page in the log
: f: moves forward one page in the log
: n: moves to the newest log entry
: o: moves to the oldest log entry
: a: dumps entire log (usually captured to a file on a PC)
: C: clears the entries from the history buffer
: q: exits the history log screen

Clearing the History Buffer (Clear)

The Clear option deletes all event entries from the history buffer.

Specifying the Type of Log to Print (Printlevel)

The Printlevel option specifies the type of event logs that appear on the console screen. The level you select determines which events or errors appear on the screen.

There are three types of logs:

Error/severe: displays all errors and severe errors.
Severe: displays severe errors only.
All: displays all errors, severe errors and information.

Specifying the Type of Log to Save (Loglevel)

The Loglevel option specifies the type of log you want to save to memory and view on the history log screen.

There are three types of logs:

Error/severe: displays all errors and severe errors.
Severe: displays severe errors only.
All: displays all errors, severe errors and information.

Specifying the Type of Event to Light Status Indicators (Ledlevel)

The ledlevel option triggers the indicator status LED to turn amber when a specific type of event or error occurs.

There are four types of logging:

Error/severe: displays all errors and severe errors.
Severe: displays severe errors only.
All: displays all errors, severe errors and information.
Off: no events are displayed.

Setting Statistic Parameters (Statistics)

The Statistics option controls how alarms are generated based on any of the available statistics kept by the bridge. Logs may be:

Disabled for statistics
Generated if the statistic changes at all
Generated if the statistic changes at a greater than specified rate

To Set Statistic Parameters:

Step 1 Select Statistics.

Step 2 The following menu appears:

Type your statistics category choice. Type the number or the short form. The short form is used to store the command in the configuration.

Step 3 The menu of the types of statistics for your chosen statistics category appears. As an example, if you type 1_ ra Radio, the following menu appears:

Step 4 If any of the statistics already have an alarm associated, the current setting is displayed after the name.

Type a category number or the short form of the particular statistics that you wish to change and press Enter.

Step 5 Then the following prompt appears:

Enter an action, one of [off, any, rate]:

Step 6 Type an action. Choose from the following list:

Off: turns off any alarms based on the statistics value.
Any: an alarm is generated if the statistics change value.
Rate: prompts for a rate-per-second change. If the statistic value changes faster than this rate, an alarm is produced.

Logging Network Roaming (Network)

The Network parameter, if enabled, logs any change to radio nodes in the network. Normally, the bridge only logs changes in location for a client that moves to or from this unit.

Backbone Nodes (Bnodelog)

The Bnodelog parameter, if enabled, logs clients that roamed to different backbone nodes. Normally, the bridge only logs changes in the state or location of its own radio nodes.

SNMP Traps (Snmp)

This selection displays a menu of SNMP trap actions.

Navigation: Main > Logs > SNMP

Setting SNMP Trap Destinations (Trapdest)

The Trapdest option generates SNMP trap messages to a particular Network Management Station (NMS) whenever a significant event occurs.

With SNMP enabled and the Trapdest option configured with a valid IP address, the system generates SNMP trap messages. If the Trapdest option is set to none or if the IP address 0.0.0.0 is typed, traps are not sent.

The following trap messages are sent as they occur:

A cold start trap is sent when the bridge first powers up.
A link up trap is sent when the configuration is changed or restored for a severe error condition.
A link down trap is sent when the configuration is changed or encounters a severe error condition.
A link up trap is sent for a bridge as soon as the radio is configured.
An authentication failure trap is sent if an SNMP request is received with an unknown community name. This trap may be disabled by setting the Authtrap parameter to off. See "Logging Failed Attempts (Authtrap)" later in this chapter.
Any normal alarms and logs you have configured to be sent by setting the Loglevel parameter.

Note Since the path to the trap destination may be through a failed or not yet established radio link, it is possible that cold start and link down traps could be lost.

Specifying Community Names for Trap Messages (Trapcomm)

The Trapcomm option specifies the community name to be used in the trap message.

Specifying the Type of Event to Cause an SNMP Trap (Loglevel)

The bridge may be configured to generate an enterprise specific trap whenever an event of a given severity or higher is recorded. The trapdest parameter must be on.

The generated trap contains the text of the event message along with the severity of the event. The different severities are:

Error/severe: displays all errors and severe errors.
Severe: displays severe errors only.
All: displays all errors, severe errors and information.
Off: no events are displayed.

Logging Failed Attempts (Authtrap)

The Authtrap parameter allows logging of failed attempts of SNMP authentication. Default setting is off which means authentication failures are not logged.

Forwarding Events to a UNIX System (Syslog, SysLevel, Facility, Rcvsyslog)

The Syslog option forwards events to a UNIX host running the Syslogd daemon process. Enter the IP address of the UNIX host. If the address remains at the default of 0.0.0.0., events are not sent. You can control the type of events sent to the daemon with the Syslevel option, which has the same arguments as the Printlevel function described above.

Packets received by the Syslogd daemon process are recorded in the system log file on the UNIX host. The events display on the console and are forwarded to the UNIX host. If the bridge should fail for any reason, the events can still be viewed on the UNIX host.

The events carry the syslog facility code LOG_LOCAL0, which has a value of 16. You can change this value with the option Facility. The syslog priority depends on the priority of the events locally.

On the UNIX host, the Syslogd daemon process usually adds the current time and IP address of the bridge that sent the event. The bridge pre-pends its own name to the event before it is sent. See the example below.

Jan 11 10:46:30 192.009.200.206 AIR-WGB340_285e73:
 
Node 0000c0d1587e ENODE added for 004096285e73

By default, the bridge receives and displays syslog messages from other bridges in the network. The Rcvsyslog option enables or disables this function. You could choose one bridge to monitor and have all other units configured with this bridge as their syslog host.

Table of Contents

Setting Up Event Logs