Troubleshooting
QB.11-R Installation and Management
Link Problems
158
Link Problems
While wireless networking emerges more and more, the number of wireless connections to networks grows every day.
The Tsunami QuickBridge.11 unit is one of the successful product families used by customers today who enjoy the day
after day high-speed, cost-effective connections. To successfully use the connections, technicians must be able to
troubleshoot the system effectively. This section gives hints on how a unit network could be analyzed in the case of “no
link,” a situation in which the customer thinks that the link is down because there is no traffic being passed.
The four general reasons that a wireless link may not work are related to:
• Hardware
• Configuration
• Path issues (such as distance, cable loss, obstacles)
• Environment (anything that is outside the equipment and not part of the path itself)
You have tested the equipment in the office and have verified that the hardware and configurations are sound. The path
calculation has been reviewed, and the path has been double-checked for obstacles and canceling reflections. Still, the
user reports that the link does not work.
Most likely, the problem reported is caused by the environment or by improper tests to verify the connection. This article
assumes that the test method, cabling, antennas, and antenna alignment have been checked. Always do this before
checking the environment.
General Check
Two general checks are recommended before taking any action:
• Check whether the software version at both sides is the most current
• Check for any reported alarm messages in the Event Log
Statistics Check
Interference and other negative environment factors always have an impact on the number of correctly received frames.
The Tsunami QuickBridge.11 models give detailed information about transmission errors in the Web interface, under
Monitor
.
The windows that are important for validating the health of the link are:
•
Monitor / Wireless / General (Lowest level of the wireless network):
Check FCS errors: Rising FCS errors
indicate interference or low fade margin. So does
Failed count
. If only one of those is high, this indicates that a
source of interference is significant near one end of the link.
•
Monitor / Interfaces / Wireless (One level higher than Wireless / General):
The information is given after the
wireless Ethernet frame is converted into a normal Ethernet frame. The parameters shown are part of the MIB-II.
–
Both operational and admin status should be
up
. An admin status of
down
indicates that the interface is
configured to be down.
–
In Discards
and
Out Discards
indicate overload of the buffers, likely caused by network traffic, which is too
heavy.
–
In Errors
and
Out Errors
should never happen; however, it might happen if a frame’s FCS was correct while the
content was still invalid.
•
Monitor / Wireless / WORP (Statistics on WORP):
WORP runs on top of normal Ethernet, which means that the
WORP frame is in fact the data field of the Ethernet frame.
Send Failure
or
Send Retries
must be low in comparison
to
Send Success
.
Low
is about 1%. The same applies for
Receive Success
versus
Receive Retries
and
Receive
Failures
. Note that the
Receive Failures
and
Retries
can be inaccurate. A frame from the remote site might have
been transmitted without even being received; therefore, the count of that frame might not have been added to the
statistics and the receiver simply could not know that there was a frame.
