<?xml version="1.0" encoding="UTF-8"?>
<list xmlns="http://www.wildpackets.com/xml/internationalization" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.wildpackets.com/xml/internationalization internationalization.xsd">
	<problem name="ptBusyNetwork">
		<desc>There is a moderate to high fluctuation in response time. The higher the sensitivity, the higher the likelihood that this problem will be flagged.</desc>
		<cause>Busy server, bandwidth contention, congested switches or routers.</cause>
		<remedy>Optimize application usage on the server or upgrade server platform, upgrade or segment highly utilized network segments between the client and server, check packet processing delay on switches and routers.</remedy>
	</problem>
	<problem name="ptInefficientClient">
		<desc>"Chatty" conversations in which data packets from a server have small average packet sizes. The higher the sensitivity, the higher the likelihood that this problem will be flagged.</desc>
		<cause>Client may be asking for small amounts of data or most any application that operates on small amounts of data at a time. The Expert exempts a number of apps that use small packets by nature (Telnet, DNS, RTP, etc.).</cause>
		<remedy>If these applications are generating a significant number of packets, you may want to optimize the application (if possible) to send or receive more data per packet rather than across several smaller packets or consider a three-tier client/server architecture.</remedy>
	</problem>
	<problem name="ptLowSCThroughput">
		<desc>The throughput from the server to the client is at or lower than the threshold.</desc>
		<cause>Busy server, network segments with low bandwidth, client is not using sliding window or packet burst protocol to receive data.</cause>
		<remedy>Optimize application usage on the server or upgrade server platform, upgrade low bandwidth segments between the client and server, re-architect the application to receive multiple packets per request.</remedy>
	</problem>
	<problem name="ptLowCSThroughput">
		<desc>The throughput from the client to the server is at or lower than the threshold.</desc>
		<cause>Busy client, network segments with low bandwidth, client is not using sliding window or packet burst protocol to send data.</cause>
		<remedy>Optimize application usage on the client or upgrade client platform, upgrade low bandwidth segments between the client and server, re-architect the application to send multiple packets per request.</remedy>
	</problem>
	<problem name="ptClientNotResponding">
		<desc>Often indicates that a client or peer (for which a connection has already been established) is not acknowledging data received from server or peer.</desc>
		<cause>Consecutive data or ack packets are being discarding by a congested or error-prone network path, switch, or router, client process is busy, has died, or can no longer respond for some other reason.</cause>
		<remedy>Ensure that network is error-free end-to-end and has adequate bandwidth, check client platform for reliability and adequate resources to handle a given load.</remedy>
	</problem>
	<problem name="ptServerNotResponding">
		<desc>Often indicates that a server or peer (for which a connection has already been established) is no longer responding to repeated packet retransmissions from a client or peer.</desc>
		<cause>Consecutive request or data packets are being discarding by a congested or error-prone network path, switch, or router, server process is busy, has died, or can no longer respond for some other reason.</cause>
		<remedy>Ensure that network is error-free end-to-end and has adequate bandwidth, check server platform for reliability and adequate resources to handle a given load.</remedy>
	</problem>
	<problem name="ptOneWayTraffic">
		<desc>No packets have been seen in the reverse direction for a user-settable length of time. This diagnosis is flagged only once for a given "conversation."</desc>
		<cause>Reply packets are taking a different path than the segment the capture is from, destination is not responding (such as repeated DNS attempts), packet is misrouted, sent or received packets are being filtered by the analyzer.</cause>
		<remedy>Check for non-responsive destination or dropped packets to/from the destination, check analyzer filter settings, look at switch/router/load balancing path between client/server.</remedy>
	</problem>
	<problem name="ptSlowSCResponseTime">
		<desc>The average response time from the server is equal to or higher than the threshold.</desc>
		<cause>Busy server, network segments with low bandwidth, high round-trip delay due to distance or highly latent networks such as frame relay.</cause>
		<remedy>Optimize application usage on the server or upgrade server platform, upgrade low bandwidth segments between the client and server, consider point-to-point or cell relay for WANs.</remedy>
	</problem>
	<problem name="ptAppDHCPLowLeaseTime">
		<desc>The client has been offered an IP address lease in which the lease time is at or below the threshold.</desc>
		<cause>The DHCP servers lease time is configured "too low".</cause>
		<remedy>Consider an appropriate lease time for your environment taking in consideration the number of fixed (desktop) nodes, static (server and router) nodes, mobile (laptop wired and wireless) nodes, and the available IP address space for each subnet.</remedy>
	</problem>
	<problem name="ptAppDHCPReject">
		<desc>A DHCP Request has been rejected by a DHCP server.</desc>
		<cause>A client is booting and attempting to renew an IP address that has already been re-allocated, the client has moved to a different subnet and the IP address was statically configured in the DHCP server.</cause>
		<remedy>Ensure that there are adequate IP addresses to be dynamically allocated and consider reducing the lease time, check to see if the client has moved and if its IP address has been statically assigned at the DHCP server to its physical address.</remedy>
	</problem>
	<problem name="ptAppDNSSlow">
		<desc>The average response time from the DNS server is equal to or higher than the threshold.</desc>
		<cause>Request is to a caching DNS server that may have to in turn look it up from an Authoritative DNS server, the network may be congested network or have a high round-trip delay from client or between DNS servers.</cause>
		<remedy>Optimize application usage on the server or upgrade server platform, upgrade low bandwidth segments between the client and server, consider point-to-point or cell relay for WANs.</remedy>
	</problem>
  <problem name="ptAppDNSNonExistentDomain">
		<desc>The domain name requested in a DNS name query cannot be found or a domain for a given IP address cannot be found (reverse lookup).</desc>
		<cause>The name or IP address is invalid; a new entry has not propagated to all DNS servers.</cause>
		<remedy>Check the packet decode for the name or IP address for which a user or service is attempting to locate for typos or other errant information, ensure that the domain name and IP address has been entered into a DNS database correctly.</remedy>
	</problem>
  <problem name="ptAppDNSServerError">
		<desc>An error response from a DNS server usually more serious than an invalid name (see "DNS Non-Existent Domain.")</desc>
		<cause>Examples include format error, server failure, not implemented, query refused (often when attempting a zone transfer), name exists when it should not be set, server not authoritative for zone, etc. </cause>
		<remedy>Look at the source IP address and nature of the request in the decodes to help determine if the problems are prompted by (possibily malicious) users or from other DNS servers (requesting zone transfers, for instance).   Refer to the latest DNS RFCs and other authoritative resources.</remedy>
	</problem>
	<problem name="ptAppFTPControlSlow">
		<desc>The average response time from the server is equal to or higher than the threshold.</desc>
		<cause>Busy server, network segments with low bandwidth, high round-trip delay due to distance or highly latent networks such as frame relay.</cause>
		<remedy>Optimize application usage on the server or upgrade server platform, upgrade low bandwidth segments between the client and server, consider point-to-point or cell relay for WANs.</remedy>
	</problem>
	<problem name="ptAppHTTPSlow">
		<desc>The average response time from the server is equal to or higher than the threshold.</desc>
		<cause>Busy server, network segments with low bandwidth, high round-trip delay due to distance or highly latent networks such as frame relay.</cause>
		<remedy>Optimize application usage on the server or upgrade server platform, upgrade low bandwidth segments between the client and server, consider point-to-point or cell relay for WANs.</remedy>
	</problem>
  <problem name="ptAppHTTPClientError">
		<desc>Returned from the server as a result of an invalid HTTP client request and usually a more serious error than an invalid URL (see "HTTP Request Not Found").  Also known as "Client Error 4xx" (except 404, which is covered by Request Not Found).</desc>
		<cause>Some examples include malformed HTTP syntax, requires user authentication, forbidden (server refuses to fulfill request), request method not allowed, proxy authentication required, request timeout, resource state conflict, resource is gone, Universal Resource Identifier too long. </cause>
		<remedy>Check the syntax in the original request packet that generated the error, see if location is restricted, check for illegal POST attempts,  etc. Refer to the latest HTTP RFCs for more details.</remedy>
	</problem>
  <problem name="ptAppHTTPRequestNotFound">
		<desc>Also known as a "Client Error 404", the HTTP server has nothing matching the client's request.  NOTE:  Some servers handle their own 404 errors and return "user friendly" information.  In these causes a normal HTTP error-free packet is returned that contains the vendor's own information.</desc>
		<cause>Often caused by a user typing in an invalid Uniform Resource Location (URL) in a browser, generating an invalid GET request.  Usually minor unless it happens frequently.</cause>
		<remedy>Inform users of proper URL, check other applications and scripts than may have contain invalid URLs, check to see if a resource has moved within the server or to a different server altogether.</remedy>
	</problem>
  <problem name="ptAppHTTPServerError">
		<desc>A client's request is usually valid, but the server has erred.  Also known as "Server Error 5xx".</desc>
		<cause>Unexpected internal server error, function requested is not implemented by the server, server is acting as a gateway and has received an invalid upstream server response or has timed out, service is temporarily unavailable, the HTTP version is not supported.</cause>
		<remedy>Check server hardware and software integrity of the server and upstream server if applicable, server overloaded or in "maintenance" mode, latest HTTP versions supported.</remedy>
	</problem>
	<problem name="ptAppKerberosReject">
		<desc>A Kerberos Request has been rejected by a Kerberos server.</desc>
		<cause>There are some fifty error possibilities including Ticket Expired, Clients Credentials Have Been Revoked, Password has Expired, Ticket Not Yet Valid, Clock Skew Too Great, Incorrect Sequence Number in Message, etc.</cause>
		<remedy>Due to the large number of error messages, examine the nature of the message in the decode window. For example, Ticket Not Yet Valid could be due to an attempt to use a postdated ticket. Consult RFC 1510 for more Kerberos operational and error details.</remedy>
	</problem>
	<problem name="ptAppLDAPSlow">
		<desc>The average response time from the LDAP server is equal to or higher than the threshold.</desc>
		<cause>Busy server, network segments with low bandwidth, high round-trip delay due to distance or highly latent networks such as frame relay.</cause>
		<remedy>Ensure that the LDAP database is indexed, check load on LDAP server, upgrade low bandwidth segments between the client and server.</remedy>
	</problem>
	<problem name="ptAppNCPLoopOnRequest">
		<desc>An NCP application or OS redirector has sent the same (back-to-back) request command within the threshold time setting.</desc>
		<cause>The application may be polling (such as checking a print queue), the application is inefficiently processing a portion of the data for each request (such as a batch file, a script file, or portion of a database record).</cause>
		<remedy>Check polling intervals, examine inefficient applications that process only portions of repeated returned data.</remedy>
	</problem>
	<problem name="ptAppNCPServerBusy">
		<desc>The server has already queued a previously identical NCP command packet but has not yet acted on the command.</desc>
		<cause>The server is busy processing other tasks, the server is performing a single-threaded operation such as a bindery lookup using NDS bindery emulation, the server is waiting for a response from another server such as an NDS authentication.</cause>
		<remedy>Distribute the overall load to another server, check for frequency of bindery lookups under NDS, check the NDS tree structure, increase the hardware (CPU, memory, NIC, etc.) performance of the platform.</remedy>
	</problem>
	<problem name="ptAppNFSRetrans">
		<desc>One or more packets of an NFS transaction using UDP has not reached its destination.</desc>
		<cause>Often the result of UDP packets broken down into IP fragments that are corrupted or dropped by a switch or router due to congestion or physical CRC errors.</cause>
		<remedy>Check packet captures closer to the source to determine if switches or routers are dropping packets, look for packets with CRC errors or dropped IP fragments, ensure that the recipient is able to keep up with the NFS throughput.</remedy>
	</problem>
	<problem name="ptAppTNSLoginReject">
		<desc>The Oracle clients logon data was rejected by the remote server.</desc>
		<cause>Usually due to an invalid username or password.</cause>
		<remedy>Check the clients user name and password or if problem is frequent, for rouge logon attempts.</remedy>
	</problem>
	<problem name="ptAppTNSSlow">
		<desc>The average response time from the Oracle server is equal to or higher than the threshold.</desc>
		<cause>Busy server, non-optimal client, protocol, or database, network segments with low bandwidth, high round-trip delay due to distance or highly latent networks such as frame relay.</cause>
		<remedy>Consult your Oracle documentation for database tuning and client or protocol optimizations, check for high utilization on the server, upgrade low bandwidth segments between the client and server, consider point-to-point or cell relay for WANs.</remedy>
	</problem>
	<problem name="ptAppTNSRefused">
		<desc>The clients connect request was denied by the remote server.</desc>
		<cause>Check the packet contents for the Oracle message number and correlate with the Oracle "Database Error Messages" document. For example, ERR=12514 correlates with "TNS-12514 TNS:listener could not resolve SERVICE_NAME given in connect descriptor."</cause>
		<remedy>In the above example, check to make sure that the user is specifying the correct service name.</remedy>
	</problem>
	<problem name="ptAppPOPLoginReject">
		<desc>A POP3 server has rejected a clients attempt to authenticate.</desc>
		<cause>User name or password is invalid.</cause>
		<remedy>Ensure that account names and passwords agree at client and server and that the server is not being probed with user names or password attempts.</remedy>
	</problem>
	<problem name="ptAppPOPReject">
		<desc>A POP3 connection or request has been rejected by a POP3 server after a TCP connection has already been established.</desc>
		<cause>Server is busy or the client has issued an invalid command.</cause>
		<remedy>Ensure that the server has adequate resources, is not in a modal state (such as waiting in a dialog for admin action), check commands that POP3 client is attempting.</remedy>
	</problem>
	<problem name="ptAppPOPSlow">
		<desc>The average response time from the server is equal to or higher than the threshold.</desc>
		<cause>Busy server, network segments with low bandwidth, high round-trip delay due to distance or highly latent networks such as frame relay.</cause>
		<remedy>Optimize application usage on the server or upgrade server platform, upgrade low bandwidth segments between the client and server, consider point-to-point or cell relay for WANs.</remedy>
	</problem>
	<problem name="ptAppSMBLogonFailure">
		<desc>A Server Message Block (SMB) attempt to logon or share a remote resource has failed.</desc>
		<cause>Often caused by an invalid user name or password as a result of browsing or connecting via the network neighborhood when the local user name and password does not authenticate to a remote resource. May also be caused by inadequate server resources.</cause>
		<remedy>Check with the offending client for the proper user name and/or password. Ensure that the server has adequate resources for desired number of simultaneous sessions.</remedy>
	</problem>
	<problem name="ptAppSMBError">
		<desc>A Server Message Block (SMB) command has been rejected.</desc>
		<cause>Causes range from "Bad Password" to "File Not Found". Check the packet decode for the exact reason.</cause>
		<remedy>Consider the error type to remedy the problem, such as a user trying to login with a bad password, an application attempting to open a non-existent file, or a file in the wrong directory.</remedy>
	</problem>
	<problem name="ptAppSMBBadName">
		<desc>A Server Message Block (SMB) command to connect to a network resource name has been rejected.</desc>
		<cause>The name of the resource does not exist on the destination SMB node (usually a server).</cause>
		<remedy>Check why the client/user is trying to connect to that resource or determine if that resource should exist on that server.</remedy>
	</problem>
	<problem name="ptAppSMBLoopOnRequest">
		<desc>An SMB application or OS redirector has sent the same (back-to-back) transaction command within the threshold time setting.</desc>
		<cause>The application may be polling (such as checking a print queue), the application is inefficiently processing a portion of the data for each request (such as a batch file, a script file, or portion of a database record).</cause>
		<remedy>Check polling intervals, examine inefficient applications that process only portions of repeated returned data.</remedy>
	</problem>
	<problem name="ptAppSMTPReject">
		<desc>A SMTP request has been rejected by an SMTP server.</desc>
		<cause>Command is not implemented, has a syntax error or is unrecognized, mail relay not permitted, insufficient system storage or user exceeded their allocation, mailbox unavailable, transaction failed.</cause>
		<remedy>Check clients that are issuing bad commands, look for attempted spam relay, check user or server storage limits, check for mailbox busy, access not permitted, or not found.</remedy>
	</problem>
	<problem name="ptAppSMTPSlow">
		<desc>The average response time from the server is equal to or higher than the threshold.</desc>
		<cause>Busy server, network segments with low bandwidth, high round-trip delay due to distance or highly latent networks such as frame relay.</cause>
		<remedy>Optimize application usage on the server or upgrade server platform, upgrade low bandwidth segments between the client and server, consider point-to-point or cell relay for WANs.</remedy>
	</problem>
	<problem name="ptAppSQLLoginReject">
		<desc>The SQL Server clients login was rejected by the remote server.</desc>
		<cause>Check the message in the rejected packet. Examples include invalid database specified in login, maximum client license count reached, not a valid user of or user not associated with a trusted SQL Server connection, invalid username or password.</cause>
		<remedy>Check database name at login, license counts, user trust associations, clients user name and password or if problem count is high, for rouge logon attempts.</remedy>
	</problem>
	<problem name="ptAppSQLUserError">
		<desc>The SQL Server has encountered errors that can be corrected by the client. The threshold is triggered every "n" number of errors over a single session (TCP connection) to an SQL server. To see every client-generated error, set the threshold to "1".</desc>
		<cause>There can be literally hundreds of causes ranging from unknown database names to transaction problems to rollbacks.</cause>
		<remedy>Take remedial action at the client based on the message in the returned error packet. Consult your SQL error messages documentation for more help.</remedy>
	</problem>
	<problem name="ptAppSQLFatalError">
		<desc>The SQL Server has encountered a non-recoverable system problem in which the program code that carries out a particular SQL statement is no longer running.</desc>
		<cause>Check the returned packet for the severity level. A level 20 is confined to a given SQL statement, level 21 affects all processes in the current DB, level 22 is a table or index integrity problem, level 23 is a DB integrity problem, level 24 is a hardware failure.</cause>
		<remedy>Check specifics of an SQL statement causing the problem. It may be necessary to rebuild an index, DB, and/or replace failed hardware. Refer to your SQL Server documentation or an SQL Server expert for more help.</remedy>
	</problem>
	<problem name="ptAppSQLResourceError">
		<desc>The SQL Server has run out of resources.</desc>
		<cause>Check the returned error packet contents for a message as to the exact cause. Examples include running out of disk space, locks, or other administrator settable limit. It could also be a non-fatal internal error such as an error during query optimization.</cause>
		<remedy>Check limitations as imposed by system hardware or as set by an administrator.</remedy>
	</problem>
	<problem name="ptAppSQLSlow">
		<desc>The average response time from the SQL Server is equal to or higher than the threshold.</desc>
		<cause>Busy server, non-optimal client, protocol, or database, network segments with low bandwidth, high round-trip delay due to distance or highly latent networks such as frame relay.</cause>
		<remedy>Consult your SQL Server documentation for database tuning and client or protocol optimizations, check for high utilization on the server, upgrade low bandwidth segments between the client and server, consider point-to-point or cell relay for WANs.</remedy>
	</problem>
	<problem name="ptAppExcessiveLoops">
		<desc>An application or OS redirector has sent too many back-to-back request or transaction commands within the threshold percentage of packets.</desc>
		<cause>The application may be polling (such as checking a print queue), the application is inefficiently processing a portion of the data for each request (such as a batch file, a script file, or portion of a database record).</cause>
		<remedy>Check polling intervals, examine inefficient applications that process only portions of repeated returned data.</remedy>
	</problem>
	<problem name="ptAppBrowserElect">
		<desc>A windows node has broadcast an election datagram to force a master browser election. The Browser protocol is used to maintain the Network Neighborhood.</desc>
		<cause>A computer cannot find the master browser at boot time, a computer determines that a master browser has disappeared, a preferred master browser is started.</cause>
		<remedy>Have at least one Windows computer always on per subnet, move all naming to WINs.</remedy>
	</problem>
	<problem name="ptIPNetBIOSSessionRefused">
		<desc>The host is rejecting a clients NetBIOS connection attempt.</desc>
		<cause>The host is not listening for the called name, the called name is not present, there are insufficient resources. Check the packet decodes for the exact reason.</cause>
		<remedy>Make sure that the correct name is being used in the original calling packet and that the host has adequate resources to handle another NetBIOS session.</remedy>
	</problem>
	<problem name="ptSIPReject">
		<desc>A Clients Session Initialization Protocol (SIP) request generated a failure response (with the exception of "Busy") from a Server.</desc>
		<cause>The client's request contains bad syntax or cannot be fulfilled at this server; the server failed to fulfill a valid request the request cannot be fulfilled at any server. Examples include Bad Request, Request Timeout, Internal Server Error, Service unavailable, Busy Everywhere.</cause>
		<remedy>Many 4xx error codes are recoverable by the client, such as retrying a request with credentials in response to a a 401 (Unauthorized) or 407 (Proxy Authentication Required) error. Server errors may be more serious. Consult RFC 3261 for more details.</remedy>
	</problem>
	<problem name="ptRASReject">
		<desc>An H.225 Registration, Admission and Status (RAS) request has been rejected by a Gatekeeper.</desc>
		<cause>Invalid Admission, Bandwidth, Registration, Discovery, Disengage, or Location Request. Examples include caller or called party not registered, policy violation, resource unavailable, level of QOS not supported, etc. Check the request and reject packet decodes for details.</cause>
		<remedy>Based on the reject reason, check the calling party's setup and call parameters and configuration of the Gatekeeper.</remedy>
	</problem>
	<problem name="ptQ931Reject">
		<desc>An H.225/Q.931 Signaling Protocol Release Complete with a cause other than most "normal" causes (user busy, user doesn't answer, number has changed, and so forth). The location (such as "private network serving the local user (LPN))" can be found in the packet decodes.</desc>
		<cause>Usually due to a resource, service, or option not available such as no route to the destination, no circuit/channel available, network out of order, equipment congestion, QOS not available, bearer capability not authorized or available.</cause>
		<remedy>Check routes, equipment capacity and configuration, etc. Check ITU standard Q.850 for a more detailed explanation of the causes and location. Exact remedies are beyond the scope of this dialog, but remedies for many of the causes should be self-evident.</remedy>
	</problem>
	<problem name="ptH245Reject">
		<desc>An H.245 Control Protocol Request has been rejected.</desc>
		<cause>Invalid Terminal Capability, Logical Channel, Close Channel Request, Multiplex Entry Request, Mode, Maintenance Loop. Check the request and reject packet decodes for further details.</cause>
		<remedy>Based on the reject reason, check for compatibility between the calling and receiving party. For example, it could be that a receiver doesn't have an codec as specified by the sender.</remedy>
	</problem>
	<problem name="ptNCPFastRetransmission">
		<desc>The source node is sending an NCP command packet with a sequence number that matches a previously sent NCP packet to the same server and socket number. Retransmits are flagged as "fast" if they occur before the NCP Fast Retransmission threshold</desc>
		<cause>The packet being retransmitted may not have reached the destination or a returning acknowledgement may not have reached the source. Packets could be discarded by switches or routers because of network congestion or CRC errors.</cause>
		<remedy>Check round-trip packet delay (latency) to see if it exceeds the NCP timeout value, ensure that network is error-free end-to-end and has adequate bandwidth. For fast retransmits, check client NCP timeout parameters to allow for packet delay.</remedy>
	</problem>
	<problem name="ptNCPPacketBurstRetransmissionRequest">
		<desc>One or more packets in a packet burst have not be received.</desc>
		<cause>One or more burst packets did not return to the sender. Packets could be discarded by switches or routers because of network congestion or CRC errors, the recipient of the burst may be dropping packets.</cause>
		<remedy>Ensure that network is error-free end-to-end and has adequate bandwidth, if packet bursts are being received at the destination segment then check for adequate NIC buffer and platform processing capability.</remedy>
	</problem>
	<problem name="ptNCPTooManyRetransmissions">
		<desc>The source node is sending an NCP command packet with a sequence number that matches a previously sent NCP packet to the same server and socket number. "Too many" is when the percentage threshold exceeds that of total transmitted packets.</desc>
		<cause>The packet being retransmitted may not have reached the destination or a returning acknowledgement may not have reached the source. Packets could be discarded by switches or routers because of network congestion or CRC errors.</cause>
		<remedy>Check round-trip packet delay (latency) to see if it exceeds the NCP timeout value, ensure that network is error-free end-to-end and has adequate bandwidth. For fast retransmits, check client NCP timeout parameters to allow for packet delay.</remedy>
	</problem>
	<problem name="ptNCPTransportRetransmission">
		<desc>The source node is sending an NCP command packet with a sequence number that matches a previously sent NCP packet to the same server and socket number.</desc>
		<cause>The packet being retransmitted may not have reached the destination or a returning acknowledgement may not have reached the source. Packets could be discarded by switches or routers because of network congestion or CRC errors.</cause>
		<remedy>Check round-trip packet delay (latency) to see if it exceeds the NCP timeout value, ensure that network is error-free end-to-end and has adequate bandwidth. For fast retransmits, check client NCP timeout parameters to allow for packet delay. </remedy>
	</problem>
	<problem name="ptRTPJitter">
		<desc>There is an RTP packet (VoIP and other streaming media) interarrival jitter (packets which are not arriving at constant intervals) over a given period of time. In a perfect world, the value should be near zero.</desc>
		<cause>Packets are affected by bandwidth, number of hops (both switches and routers), and volume of other traffic between the sender and receiver, especially over an unpredictable topology such as the Internet.</cause>
		<remedy>If possible, tune the routers and increase bandwidth. VoIP applications will usually send out one or more RSVP packets to the end IP address for routers to examine along the way and set up prioritized processing.</remedy>
	</problem>
	<problem name="ptRTPPercentPacketLoss">
		<desc>There is a percentage of RTP packets (VoIP and other streaming media) not seen by the recipient over a given period of time, usually reported by RTCP (Real-time Transport Control Protocol) at 5 second or shorter intervals.</desc>
		<cause>Usually this means insufficient bandwidth between the sender and receiver. Either the network is congested by other traffic and/or there's insufficient bandwidth such as a user on a dial-up connection.</cause>
		<remedy>If possible, increase bandwidth or change the VoIP Codec parameters to send more voice data in fewer packets.</remedy>
	</problem>
	<problem name="ptRTPLatePacket">
		<desc>An RTP packet (VoIP and other streaming media) that has arrived later than the expected arrival rate, expressed as a multiplier. If the Expert calculates the arrival rate as 30 ms, then 2x is a packet arriving after 60 ms. The receiver may discard the packet unless the jitter buffer is adjusted (manually or dynamically).</desc>
		<cause>Packets are affected by bandwidth, number of hops (both switches and routers), and volume of other traffic between the sender and receiver, especially over an unpredictable topology such as the Internet.</cause>
		<remedy>If possible, tune the routers and increase bandwidth. VoIP applications will usually send out one or more RSVP packets to the end IP address for routers to examine along the way and set up prioritized processing.</remedy>
	</problem>
	<problem name="ptRTPPacketOutofSequence">
		<desc>An RTP packet (VoIP and other streaming media) has arrived ahead of a previously sent RTP packet.</desc>
		<cause>In a packet network with many hops and redundancy, it is possible for packets to take different paths.</cause>
		<remedy>Usually this is not a problem unless the out-of-sequence packet is too late for the receivers jitter buffer in which case the packet is discarded.</remedy>
	</problem>
	<problem name="ptSPXFastRetransmission">
		<desc>The source node is sending an SPX packet with a sequence number that matches a previously sent NCP packet to the same server and socket number. Retransmits are flagged as "fast" if they occur before the SPX Fast Retransmission threshold.</desc>
		<cause>The packet being retransmitted may not have reached the destination or a returning acknowledgement may not have reached the source. Packets could be discarded by switches or routers because of network congestion or CRC errors.</cause>
		<remedy>Check round-trip packet delay (latency) to see if it exceeds the NCP timeout value, ensure that network is error-free end-to-end and has adequate bandwidth. For fast retransmits, check client SPX timeout parameters to allow for packet delay.</remedy>
	</problem>
	<problem name="ptSPXTooManyRetransmissions">
		<desc>The source node is sending an SPX packet with a sequence number that matches a previously sent NCP packet to the same server and socket number. "Too many" is when the percentage threshold exceeds that of total transmitted packets.</desc>
		<cause>The packet being retransmitted may not have reached the destination or a returning acknowledgement may not have reached the source. Packets could be discarded by switches or routers because of network congestion or CRC errors.</cause>
		<remedy>Check round-trip packet delay (latency) to see if it exceeds the NCP timeout value, ensure that network is error-free end-to-end and has adequate bandwidth. For fast retransmits, check client SPX timeout parameters to allow for packet delay.</remedy>
	</problem>
	<problem name="ptSPXTransportRetransmission">
		<desc>The source node is sending an SPX packet with a sequence number that matches a previously sent NCP packet to the same server and socket number.</desc>
		<cause>The packet being retransmitted may not have reached the destination or a returning acknowledgement may not have reached the source. Packets could be discarded by switches or routers because of network congestion or CRC errors.</cause>
		<remedy>Check round-trip packet delay (latency) to see if it exceeds the NCP timeout value, ensure that network is error-free end-to-end and has adequate bandwidth. For fast retransmits, check client SPX timeout parameters to allow for packet delay.</remedy>
	</problem>
	<problem name="ptTCPRejectConnection">
		<desc>The host is rejecting a clients initial TCP connection attempt.</desc>
		<cause>A client is requesting a service such as FTP or HTTP that the host does not offer or there are no more available connections on the server to handle the request.</cause>
		<remedy>Check for service availability at the host, check for abnormally high connection attempts on different ports which may indicate hacking, check for the maximum number of incoming connections that a host can handle.</remedy>
	</problem>
	<problem name="ptTCPFastRetransmission">
		<desc>The source IP node is sending another TCP packet with a sequence number that matches a previously sent TCP packet to the same destination IP address and TCP port numbers. Retransmits are flagged as "fast" if they occur before the TCP Fast Retransmission threshold.</desc>
		<cause>The packet being retransmitted may not have reached the destination or a returning acknowledgement may not have reached the source. Packets could be discarded by switches or routers because of network congestion or CRC errors.</cause>
		<remedy>Check round-trip packet delay (latency) to see if it exceeds the TCP timeout value, ensure that network is error-free end-to-end and has adequate bandwidth. For fast retransmits, check client TCP retransmit parameters to allow for packet delay.</remedy>
	</problem>
	<problem name="ptTCPIdleTooLong">
		<desc>The TCP connection hasn't been used since the threshold setting in seconds.</desc>
		<cause>Normally, applications such as a Web browser will free up a connection as soon as a file loads. TCP "SYN" attacks or other applications such as Telnet or FTP, can hold a port open much longer.</cause>
		<remedy>Have the server time-out connections after a certain amount of time, increase the server's port capacity, check the apps that are communicating with your server.</remedy>
	</problem>
	<problem name="ptTCPChecksum">
		<desc>The TCP header and/or data is in error. One or more bits has erroneously changed since the TCP segment was transmitted by the source IP host.</desc>
		<cause>A store and forward device such as a switch or router may have corrupted the IP header, the frame contains a CRC error, the source stack incorrectly computed the checksum.</cause>
		<remedy>Check to see if a switch or router is corrupting packets in memory by simultaneously capturing packets on both sides, see if the packet/frame also contains a CRC error (if so, check "Ethernet CRC Error"), check for checksum errors on the same segment as the host.</remedy>
	</problem>
	<problem name="ptTCPLostConnection">
		<desc>TCP data is repeatedly being sent with no acknowledgement until the sender gives up and resets the connection.</desc>
		<cause>The packets being retransmitted may not be reaching the destination, returning acknowledgements may not be reaching the source, or the recipient of the transmitted data may have stopped responding.</cause>
		<remedy>Check for data packets reaching the recipient and ensure that the recipient is acknowledging these data packets.</remedy>
	</problem>
	<problem name="ptTCPLowMSS">
		<desc>The TCP Maximum Segment Size (MSS) is at or below the threshold setting.</desc>
		<cause>Either the default TCP MSS or the MSS set by an application may not be set to the optimal value. Some TCP speed optimizers will change the MSS for low-speed dial-up connections.</cause>
		<remedy>Check the default TCP MSS setting, check the application using TCP.</remedy>
	</problem>
	<problem name="ptTCPLowWindow">
		<desc>The application is not keeping up with the incoming TCP segments. The threshold is based on the percentage of the maximum observed window for this conversation.</desc>
		<cause>Inefficient application , CPU contention, inefficient adapter/drivers.</cause>
		<remedy>Check to see if the application or other applications are CPU intensive, consider setting the TCP window size to at least four times the TCP segment size, check for adapter and adapter driver efficiency, consider upgrading the platform.</remedy>
	</problem>
	<problem name="ptTCPSYNRepeated">
		<desc>A client is attempting multiple times to establish a TCP connection.</desc>
		<cause>The server may be ignoring the packet, the server may be rejecting the connection, a firewall may be blocking the packet. Also see "TCP Transport Retransmission".</cause>
		<remedy>Make sure that the SYN packet is reaching the Server and if the Server ACKs, that the ACK packet reaches the client. Also see "TCP Reject Connection".</remedy>
	</problem>
	<problem name="ptTCPResetConnection">
		<desc>One end of a TCP connection has set the RST flag in a TCP packet which sometimes indicates an abrupt disconnect. The normal TCP disconnect is to FIN although some applications will terminate with a reset or a FIN followed by a reset.</desc>
		<cause>A client may be attempting to send data on a half-closed connection (client ACKs a servers FIN but sends data instead of a reciprocal FIN), an error condition is causing a host or proxy server to drop the connection.</cause>
		<remedy>Check if server will accept data on a half-closed TCP connection, check for overload problems at the client, host, or dropped connections on the Internet side of a proxy server.</remedy>
	</problem>
	<problem name="ptTCPInactiveConnection">
		<desc>The sender has set the RST flag in a TCP packet.</desc>
		<cause>Server may be timing out an inactive connection.</cause>
		<remedy>Check for client applications not properly terminating their TCP connections, client abruptly dropping off the network, users not properly terminating their applications.</remedy>
	</problem>
	<problem name="ptTCPTransportRetransmission">
		<desc>The source IP node is sending another TCP packet with a sequence number that matches a previously sent TCP packet to the same destination IP address and TCP port numbers.</desc>
		<cause>The packet being retransmitted may not have reached the destination or a returning acknowledgement may not have reached the source. Packets could be discarded by switches or routers because of network congestion or CRC errors.</cause>
		<remedy>Check round-trip packet delay (latency) to see if it exceeds the TCP timeout value, ensure that network is error-free end-to-end and has adequate bandwidth. For fast retransmits, check client TCP retransmit parameters to allow for packet delay.</remedy>
	</problem>
	<problem name="ptTCPSlowAck">
		<desc>The recipient appears to be slow in acknowledging TCP data segments based on the threshold added to the average ack time.</desc>
		<cause>Network latency, recipient is slow to process the data.</cause>
		<remedy>Check round-trip packet delay (latency), check the CPU utilization of the receiver, check the responsiveness of the receiver by capturing at the receiving end of the data.</remedy>
	</problem>
	<problem name="ptTCPSlowRetransmission">
		<desc>The first retransmission is taking longer than the threshold which may indicate slow recovery time and throughput.</desc>
		<cause>Usually due to acknowledgements that are very slow to return. May also be due to TCP timeout values which are manually or automatically tuned too high.</cause>
		<remedy>Check round-trip packet delay (latency), ensure that network is error-free end-to-end and has adequate bandwidth, check client TCP retransmit parameters.</remedy>
	</problem>
	<problem name="ptTCPStuckWindow">
		<desc>The TCP window size has not changed for three or more consecutive packets and has dropped below a percentage of the maximum window. The application may be one or more packets behind in processing incoming TCP segments.</desc>
		<cause>Inefficient application, CPU contention, inefficient adapter/drivers.</cause>
		<remedy>Check to see if the application or other applications are CPU intensive. This problem is usually not as serious as a Zero Window.</remedy>
	</problem>
	<problem name="ptTCPTooManyRetransmissions">
		<desc>The source IP node is sending another TCP packet with a sequence number that matches a previously sent TCP packet to the same destination IP address and TCP port numbers. "Too many" is when the percentage threshold exceeds that of total transmitted (non-ack) packets.</desc>
		<cause>The packet being retransmitted may not have reached the destination or a returning acknowledgement may not have reached the source. Packets could be discarded by switches or routers because of network congestion or CRC errors.</cause>
		<remedy>Check round-trip packet delay (latency) to see if it exceeds the TCP timeout value, ensure that network is error-free end-to-end and has adequate bandwidth. For fast retransmits, check client TCP retransmit parameters to allow for packet delay.</remedy>
	</problem>
	<problem name="ptTCPZeroWindow">
		<desc>The recipients TCP receive buffer is filling up (low window) or full (zero window).</desc>
		<cause>Inefficient application , CPU contention, inefficient adapter/drivers.</cause>
		<remedy>Check to see if the application or other applications are CPU intensive, consider setting the TCP window size to at least four times the TCP segment size, check for adapter and adapter driver efficiency, consider upgrading the platform.</remedy>
	</problem>
	<problem name="ptUDPChecksum">
		<desc>The UDP header and/or data is in error. One or more bits has erroneously changed since the UDP datagram was transmitted by the source IP host.</desc>
		<cause>A store and forward device such as a switch or router may have corrupted the IP header, the frame contains a CRC error, the source stack incorrectly computed the checksum.</cause>
		<remedy>Check to see if a switch or router is corrupting packets in memory by simultaneously capturing packets on both sides, see if the packet/frame also contains a CRC error (if so, check "Ethernet CRC Error"), check for checksum errors on the same segment as the host.</remedy>
	</problem>
	<problem name="ptIPChecksum">
		<desc>The header portion of the IP datagram is in error. One or more bits has erroneously changed (with the exception of the TTL) since the IP datagram was transmitted by the source IP host.</desc>
		<cause>A store and forward device such as a switch or router may have corrupted the IP header, the frame contains a CRC error, the source stack incorrectly computed the checksum.</cause>
		<remedy>Check to see if a switch or router is corrupting packets in memory by simultaneously capturing packets on both sides, see if the packet/frame also contains a CRC error (if so, check "Ethernet CRC Error"), check for checksum errors on the same segment as the host.</remedy>
	</problem>
	<problem name="ptICMPErrorReports">
		<desc>ICMP is an integral part of IP used to report an error in datagram processing.</desc>
		<cause>The ICMP message will indicate the cause, such as network, host, protocol, or port unreachable, datagram redirect from a router, time (IP TTL) expired, etc.</cause>
		<remedy>Look at the end host or network that the report on datagram is trying to reach and use the ICMP information to correct the problem at the end host or intervening network.</remedy>
	</problem>
	<problem name="ptIPLocalRouting">
		<desc>Two identical IP packets except for the TTL have been detected.</desc>
		<cause>A router may have multiple subnet's assigned to a port and a host is sending the packet to the "default gateway" for packets not on the same subnet as the host.</cause>
		<remedy>Consider rearchitecting the IP subnet space.</remedy>
	</problem>
	<problem name="ptIPLowTTL">
		<desc>The IP Time-To-Live (TTL) has fallen to or below a pre-determined threshold indicating that the packet can only traverse that many more routers before it is discarded.</desc>
		<cause>The originating IP host transmitted the packet with a low TTL to to begin with, the packet has traversed a large number of routers, the packet is looping.</cause>
		<remedy>Check the starting TTL at the source host, trace the path between the host and the segment that the packet was captured from, check for routing loops.</remedy>
	</problem>
	<problem name="ptIPCRC">
		<desc>The CRC re-computed by the analyzer when the frame was received did not match the CRC at the end of the frame, indicating one or more corrupted bits in the frame. If the IP Header Checksum is okay, then the problem is most likely elsewhere in the frame.</desc>
		<cause>Bad NIC or transceiver, bad connector termination, poor patch panel connections split pair in the wiring, wrong cable type, excessive cable length, cable crosstalk or interference, channel interference or weak signal at receiver (wireless).</cause>
		<remedy>Check NIC-to-hub wiring with a good cable tester, check hub, check source port on the segment from which the frame was captured, move node closer to an access point (ensure that analyzer is collecting packets close to node suspected of receiving CRC errors).</remedy>
	</problem>
	<problem name="ptIPMissingFragment">
		<desc>An IP datagram has been fragmented by the host application or a router, and one of the fragments is missing.</desc>
		<cause>A fragment was corrupted, has been dropped by a switch or router, or the analyzer couldn't keep up with the packet transmission rate.</cause>
		<remedy>Capture at other points in the path between the source and destination to look for dropped fragments, check dropped packet statistics and buffer sizing in switches or routers, check performance of analyzer.</remedy>
	</problem>
	<problem name="ptIPZeroBroadcastAddress">
		<desc>An IP UDP packet is being broadcast using the old IP broadcast address of 0.0.0.0</desc>
		<cause>Obsolete application, possibly BOOTP using 0.0.0.0.</cause>
		<remedy>Check the node for applications that may be sending this packet.</remedy>
	</problem>
	<problem name="ptIPXLocalRouting">
		<desc>Two identical IPX packets except for the hop count have been detected.</desc>
		<cause>A client with an incorrect DLC encapsulation type may be sending packets to a server/router router for DLC encapsulation translation.</cause>
		<remedy>Consider using one DLC encapsulation type for IPX throughput your network.</remedy>
	</problem>
	<problem name="ptIPXCRC">
		<desc>The CRC re-computed by the analyzer when the frame was received did not match the CRC at the end of the frame, indicating one or more corrupted bits in the frame.</desc>
		<cause>Bad NIC or transceiver, bad connector termination, poor patch panel connections, split pair in the wiring, wrong cable type, excessive cable length, cable crosstalk or interference, channel interference or weak signal at receiver (wireless).</cause>
		<remedy>Check NIC-to-hub wiring with a good cable tester, check hub, check source port on the segment from which the frame was captured, move node closer to an access point (ensure that analyzer is collecting packets close to node suspected of receiving CRC errors).</remedy>
	</problem>
	<problem name="ptBroadcastStorm">
		<desc>A sustained level of all stations broadcast packets (the destination physical address consists of all 1s) has met or exceeded the threshold.</desc>
		<cause>Aberrant application, spanning tree failure, bridge (or switch) failure, loop in parallel bridges with spanning tree disabled.</cause>
		<remedy>Mirror or put the analyzer on the same segment as the physical source and check for multicast rate, check for spanning tree BPDU problem, check bridge topology.</remedy>
	</problem>
	<problem name="ptMulticastStorm">
		<desc>A sustained level of multicast (the broadcast bit in the destination physical address is set to 1) packets has met or exceeded the threshold.</desc>
		<cause>Segment is not supposed to be receiving multicast packets, aberrant application, spanning tree failure, bridge (or switch) failure, loop in parallel bridges with spanning tree disabled.</cause>
		<remedy>Check router configuration of IP multicasting, mirror or put the analyzer on the same segment as the physical source and check the multicast rate, check for spanning tree BPDU problem, check bridge topology.</remedy>
	</problem>
	<problem name="ptSevereBroadcastStorm">
		<desc>A sustained level of all stations broadcast packets (the destination physical address consists of all 1s) has met or exceeded the threshold.</desc>
		<cause>Aberrant application, spanning tree failure, bridge (or switch) failure, loop in parallel bridges with spanning tree disabled.</cause>
		<remedy>Mirror or put the analyzer on the same segment as the physical source and check for multicast rate, check for spanning tree BPDU problem, check bridge topology.</remedy>
	</problem>
	<problem name="ptSevereMulticastStorm">
		<desc>A sustained level of multicast (the broadcast bit in the destination physical address is set to 1) packets has met or exceeded the threshold.</desc>
		<cause>Segment is not supposed to be receiving multicast packets, aberrant application, spanning tree failure, bridge (or switch) failure, loop in parallel bridges with spanning tree disabled.</cause>
		<remedy>Check router configuration of IP multicasting, mirror or put the analyzer on the same segment as the physical source and check the multicast rate, check for spanning tree BPDU problem, check bridge topology.</remedy>
	</problem>
	<problem name="ptBPDUTopologyChange">
		<desc>The actively forwarding bridge (or switch) port for this segment has changed.</desc>
		<cause>A bridge port on this segment has become inactive or is failing to send out periodic BPDU (Bridge Protocol Data Unit) packets.</cause>
		<remedy>Change for hardware, firmware, or software failure or reconfiguration of the port parameters (such as priority).</remedy>
	</problem>
	<problem name="ptCRC">
		<desc>The CRC re-computed by the analyzer when the frame was received did not match the CRC at the end of the frame, indicating one or more corrupted bits in the frame. The threshold applies to a window of consecutive CRC frames from any source.</desc>
		<cause>Bad NIC or transceiver, bad connector termination, poor patch panel connections, split pair in the wiring, wrong cable type, excessive cable length, cable crosstalk or interference, channel interference (such as from 2.4 GHz phones) or weak signal at receiver (wireless).</cause>
		<remedy>Check NIC-to-hub wiring with a good cable tester, check hub, check source port on the segment from which the frame was captured, move node closer to an access point (ensure that analyzer is collecting packets close to node suspected of receiving CRC errors).</remedy>
	</problem>
	<problem name="ptWirelessChannelBleed">
		<desc>The Expert has detected a management frame from a channel other than the capture channel, indicating channel overlap or "bleed".</desc>
		<cause>Access points whose channels are close together and are placed physically close together, will cause traffic to appear on other channels.</cause>
		<remedy>Space access points further apart, reassign channels with more spacing between them, such as using channels 1 and 6 instead of 1 and 2.</remedy>
	</problem>
	<problem name="ptWirelessDataRateChange">
		<desc>The data rate of this packet is lower or higher than the previous packet.</desc>
		<cause>The end-node or access point is not stationary or may be far apart, changes in physical obstacles, channel interference.</cause>
		<remedy>Ensure that the end-node and the device it is communicating with is stationary, check changing physical obstacles such as doors or carts, check for nearby 2.4 GHz wireless phones or other such wireless devices, switch to a different channel.</remedy>
	</problem>
	<problem name="ptWirelessTooManyRetries">
		<desc>The transmitter (an end-node or access point) has previously attempted to send packets over the wireless medium and the percentage threshold exceeds that of the total good transmitted packets.</desc>
		<cause>Possible packet corruption caused by interference during transmission or excessive distance between transmitter and receiver.</cause>
		<remedy>Check signal strength of packets at the receiver (which could be another end-node or access point), switch to a different channel, move sender &amp; receiver closer together. Also see "Wireless Data Rate Change".</remedy>
	</problem>
	<problem name="ptWirelessRetry">
		<desc>The transmitter has previously attempted to send this packet over the wireless medium.</desc>
		<cause>Possible packet corruption caused by interference during transmission or excessive distance between transmitter and receiver.</cause>
		<remedy>Check signal strength of packets at the receiver (which could be another end-node or access point), switch to a different channel, move sender &amp; receiver closer together. Also see "Wireless Data Rate Change".</remedy>
	</problem>
	<problem name="ptWirelessRogueAP">
		<desc>An unrecognized access point has been detected, since it does not exist in the AiroPeek name table and it is not designated as an Access Point.</desc>
		<cause>A new access point has been put into operation legitimately or illegitimately.</cause>
		<remedy>If the access point is legitimate, add it to the name table.  If not, use AiroPeek to help locate the suspect access point by moving to the area where the signal strength is strongest.</remedy>
	</problem>
	<problem name="ptWirelessExposedAPSSID">
		<desc>The access point is sending its SSID (Service Set Identifier, or network name) in beacon broadcasts, allowing all stations (including tools that snoop broadcast packets) to see the SSID.</desc>
		<cause>Most access points are configured by default to send their SSID in beacon frames.</cause>
		<remedy>Disable SSID broadcasts in the access point and do not allow stations which do not specify a matching SSID to join the network.  This is minor security benefit as the SSID is returned in probe response packets to legitimate clients, allowing snooping tools to gather this information.</remedy>
	</problem>
	<problem name="ptWirelessAccessPointRestart">
		<desc>An access point has been restarted within the past number of minutes as determined by the threshold.  Set the value higher to see access points which have been restarted some time ago or lower, to see only more recent restarts.</desc>
		<cause>Possible power failure, intentional soft reset via a management utility, intentional &quot;hard reset&quot;.</cause>
		<remedy>Put a UPS on the access point, continue to capture packets to and from the access point looking for suspicious access point management activity.</remedy>
	</problem>
	<problem name="ptWirelessAccessPointWeakSignal">
		<desc>The signal strength of a frame transmitted by an access point and captured at this location is at or below the threshold.  The second threshold, in minutes, is how often this event is reported.</desc>
		<cause>The analyzer is too far away from the access point, there are many radio attenuating barriers between the AP and analyzer, the AP has a poor antenna gain or orientation, the AP is set to transmit at lower than its maximum setting.</cause>
		<remedy>Relocate analyzer closer to the access point, relocate access point, check AP antenna orientation and AP transmit power setting, consider a higher gain antenna.</remedy>
	</problem>
	<problem name="ptWirelessAccessPointTooMany">
		<desc>The number of access points observed on a given channel is at or greater than the threshold, decreasing the efficiency of utilization (contention) of that channel.</desc>
		<cause>Too many access points in close proximity are sharing the same channel.  This is less of a problem if a few users are sharing multiple access points vs. many users sharing multiple access points.</cause>
		<remedy>If possible, Space the access points further apart or stagger the access point channels.  For 802.11b, allow at least 5 channels between them; i.e. alternately use channels 1, 6, 11 in a linear or honeycomb fashion.</remedy>
	</problem>
	<problem name="ptWirelessAdHocDetected">
		<desc>Two or more wireless nodes are communicating directly to each other without using an access point.  If communicating on the same or nearby channel as a wireless infrastructure using access points, available bandwidth can be severely impacted.</desc>
		<cause>Wireless clients are not setup properly or are intentionally avoiding the use of access points for peer-to-peer operation.</cause>
		<remedy>If possible, track down the offending clients based on their source wireless hardware address and re-configure for infrastructure operation.</remedy>
	</problem>
	<problem name="ptWirelessAssociationDenied">
		<desc>Node was not able to associate with the Nodes specified Access Point.</desc>
		<cause>Node was not able to associate with the Nodes specified Access Point because WEP is turned on, wrong SSID.</cause>
		<remedy>Add SSID to nodes wireless settings or add WEP key to nodes settings.</remedy>
	</problem>
	<problem name="ptWirelessAuthenticationDenied">
		<desc>An access point is rejecting a client’s Authentication request.  A &quot;normal insertion&quot; by a client into a wireless network is a Probe Request followed by Authentication (assuming a Probe Response is received), then Association.</desc>
		<cause>Commonly due to the access point not supporting the specified authentication algorithm.  Other causes include a challenge failure or authentication timed out waiting for next frame in sequence.  Some access points also return an &quot;unspecified failure&quot; when their station association tables are full.</cause>
		<remedy>Check WEP keys when using shared key authentication, check for station association limits and authentication attacks.</remedy>
	</problem>
	<problem name="ptWirelessReassociationDenied">
		<desc>An access point is rejecting a client’s Association request.  A &quot;normal insertion&quot; by a client into a wireless network is a Probe Request followed by Authentication (assuming a Probe Response is received), then Association.</desc>
		<cause>Requested capabilities not supported, station association table is full, station does not support specified data rates, unspecified failure (some access points reject a client trying to associate without an SSID).</cause>
		<remedy>Ensure that client supports the capabilities of the access point and if necessary, match the client and access points SSIDs (some access points can be configure to accept any SSID, including none).</remedy>
	</problem>
	<problem name="ptWirelessSameSndRcv">
		<desc>The source address and destination address are identical.</desc>
		<cause>A suspect application is intentionally sending packets to itself, some wireless devices generate packets with the same source and destination addresses as a test on start up.</cause>
		<remedy>Usually not serious, unless there is a large number of them in which the offending sender should be identified and tracked down.</remedy>
	</problem>
	<problem name="ptWirelessRogueClient">
		<desc>An unrecognized client has been detected, since it does not exist in the AiroPeek NX name table.</desc>
		<cause>A client has been put into operation legitimately or illegitimately.</cause>
		<remedy>If the client is legitimate, add it to the name table.  If not, use AiroPeek to help locate the suspect client by moving to the area where the signal strength is strongest.</remedy>
	</problem>
	<problem name="ptWirelessClientWeakSignal">
		<desc>The signal strength of a frame transmitted by a client and captured at this location is at or below the threshold.  The second threshold, in minutes, is how often this event is reported.</desc>
		<cause>The analyzer is too far away from the client, there are many radio attenuating barriers between the client and analyzer, the client has a poor antenna gain or orientation, the client is set to transmit at lower than its maximum setting.</cause>
		<remedy>Relocate analyzer closer to the client, relocate client,  check client antenna orientation and transmit power setting, consider a higher gain antenna at the client.</remedy>
	</problem>
	<problem name="ptDataEAPFailed">
		<desc>Using the 802.1x framework to carry EAP requests (such as Cisco LEAP) and responses, an authenticator cannot authenticate the client.</desc>
		<cause>Usually due to an 802.1x enabled Access Point that is unable to authenticate a wireless client using an authentication method such as Wi-Fi Protected Access (WPA) or a RADIUS server.</cause>
		<remedy>Ensure that clients and access points using 802.1x are set up properly. Check that user is known to a RADIUS server. Check WPA setup if applicable.</remedy>
	</problem>
	<problem name="ptWirelessClientCRC">
		<desc>There are frames from a wireless client captured at this location containing a CRC error.  The threshold is in number of CRC errors per second.</desc>
		<cause>The analyzer is too far away from the client (also check the signal strength of the frame), there is outside interference from another device or activity on an adjacent channel (check for a CRC error plus moderate-to-good signal strength).</cause>
		<remedy>Check for sources of potential interference such as cordless phones, microwave ovens or 802.11 wireless transmission in close or adjacent channels (see &quot;Channel Bleed&quot;). Also refer to &quot;Wireless Client - Weak Signal.&quot;</remedy>
	</problem>
	<problem name="ptWirelessAccessPointCRC">
		<desc>There are frames from an access point captured at this location containing a CRC error.  The threshold is in number of CRC errors per second.</desc>
		<cause>The analyzer is too far away from the access point (also check the signal strength of the frame), there is outside interference from another device or activity on an adjacent channel (check for a CRC error plus moderate-to-good signal strength).</cause>
		<remedy>Check for sources of potential interference such as cordless phones, microwave ovens or 802.11 wireless transmission in close or adjacent channels (see &quot;Channel Bleed&quot;). Also refer to &quot;Wireless Access Point - Weak Signal.&quot;</remedy>
	</problem>
	<problem name="ptWirelessAccessPointNoWep">
		<desc>The access point does not require WEP for stations to associate to it.</desc>
		<cause>The access point has been configured for non-WEP operation.</cause>
		<remedy>Configure the access point and clients to use WEP. Although not totally immune to hacking, WEP does prevent non-WEP clients from associating and WEP can be frequently re-keyed using access points that support 802.1x and RADIUS.</remedy>
	</problem>
	<problem name="ptWirelessAccessPointNotConfig">
		<desc>The access point is broadcasting an SSID that is one of several known default SSIDs.  The SSID table is contained in an XML file which can be updated.</desc>
		<cause>The access point has a factory set SSID. This is merely a suggestion that perhaps other parameters in the access point have not been configured, leaving it wide open.</cause>
		<remedy>Change the default SSID.</remedy>
	</problem>
	<problem name="ptWirelessAssociationAttack">
		<desc>The number of association requests is at or has exceeded the threshold, measured in number of associations in so many seconds.</desc>
		<cause>An abnormally high number of association requests in a short amount of time could indicate a DOS attack by filling up and access point’s association table.</cause>
		<remedy>Determine if the source addresses of the association request packets are random (indicating an attack) or legitimate (in which cause determine why legitimate nodes are associating at a &quot;high&quot; rate).</remedy>
	</problem>
	<problem name="ptWirelessAuthenticationAttack">
		<desc>The number of authentication requests is at or has exceeded the threshold, measured in number of authentications in so many seconds.</desc>
		<cause>An abnormally high number of authentication requests in a short amount of time could indicate an attack on the WEP key.</cause>
		<remedy>Determine if the source addresses of the association request packets are random (indicating an attack) or legitimate (in which cause determine why legitimate nodes are associating at a &quot;high&quot; rate).</remedy>
	</problem>
	<problem name="ptWirelessDeauthentication">
		<desc>A data frame has been received by the access point from a nonauthenticated station.  The access point will reject the frame and send a deauthenticate frame back to the station with the error status.</desc>
		<cause>The station has sent a data frame prior to being authenticated with an access point or following a station sending a deauthentication to the access point indicating that it is &quot;leaving the area&quot; (which can happen when a wireless card is disabled by the user or an application.)</cause>
		<remedy>Usually not serious, unless there is a large number of them in which the offending sender should be identified and tracked down.</remedy>
	</problem>
	<problem name="ptWirelessDeAuthenticationAttack">
		<desc>There are a large number of Deauthentication frames from a client spoofing an Access Point. These frames are usually sent to the all stations broadcast address causing all stations associated with that Access Point to Disassociate.</desc>
		<cause>There is a rogue client sending Deauthentication frames.</cause>
		<remedy>Track down the offender by homing in on its physical location using the signal strength indicated on each frame.</remedy>
	</problem>
	<problem name="ptWirelessSourceIsBroadcast">
		<desc>A station has assigned an all stations broadcast address (all 1’s or FFFFFFFFFFFF in hex) as its source address.  This is especially bad on wireless networks since the station will send acknowledge frames for all broadcast packets including all beacon frames from access points.</desc>
		<cause>Usually deliberately set via adapter properties or the registry.</cause>
		<remedy>Use only client adapters that do not allow the wireless NIC’s network address to be re-programmed as a broadcast or multicast address.  Beware that even NIC’s without a network address property setting can still be changed via the registry.</remedy>
	</problem>
	<problem name="ptWirelessSourceIsMulticast">
		<desc>A station has assigned a multicast address (the lower bit of the first byte of an address is set to &quot;1&quot;) as its source address.</desc>
		<cause>Usually deliberately set via adapter properties or the registry.</cause>
		<remedy>Use only client adapters that do not allow the wireless NIC’s network address to be re-programmed as a broadcast or multicast address.  Beware that even NIC’s without a network address property setting can still be changed via the registry.</remedy>
	</problem>
	<problem name="ptWirelessClientUsingAPMac">
		<desc>A station is transmitting frames using the same source address as an access point.</desc>
		<cause>Usually deliberately set via adapter properties or the registry as an attempt to spoof an access point for man in the middle or other such attacks.</cause>
		<remedy>Track down the offender by homing in on its physical location using the signal strength indicated on each frame.</remedy>
	</problem>
</list>
