(e-mail address removed) hath wroth:
One more thing:
00:00:04 : Reply[115] from 192.168.252.254: bytes=32 time=9.0 ms TTL=64
00:00:34 : Reply[116] from 192.168.252.254: bytes=32 time=191.6 msTTL=64
recvfrom() - A connection attempt failed because the connected party
did not properly respond after a period of time, or established
connection failed because connected host has failed to respond.
recvfrom() - A connection attempt failed because the connected party
did not properly respond after a period of time, or established
connection failed because connected host has failed to respond.
recvfrom() - A connection attempt failed because the connected party
did not properly respond after a period of time, or established
connection failed because connected host has failed to respond.
Too few bytes from 66.102.7.99
00:01:39 : Reply[118] from 192.168.252.254: bytes=32 time=3.2 ms TTL=64
00:02:09 : Reply[119] from 192.168.252.254: bytes=32 time=11.8 ms
TTL=64
00:02:39 : Reply[120] from 192.168.252.254: bytes=32 time=37.9 ms
TTL=64
From the time stamps you can see its only missing one ping per 3 error
lines, ie above at 00:01:04
Retch. You may have radio link problems.
What is the smallest number your get for the ping time to your ISP's
gateway/DNS server?
You can deduce quite a bit from ping results. From the above mess, I
would think that 3.2msec is about normal for two hops to a central
access point. You should get about 1-2 msec per hop. It might also
be just one hop to the gateway, but I can't tell without seeing some
ping history. Such huge variations in latency times is usually a sure
sign of interference or a marginal path. The problem is that it's
obviously a shared system and the other users may be causing some (not
all) of the variations in latency. Also, if it's a two hop system
(with a wireless backhaul to the ISP from the central AP), traffic
from other users on the backhaul will cause substantial variations in
latency.
However, the wide variations seem to indicate that the problem is
chronic. Even with traffic on the backhaul, you should not see any
lost packets, and certainly not 30:1 variations in latency. It
appeasrs that the latency variations are caused by packet loss, and
not traffic. I think you have a radio path or interference problem.
Did you tell your ISP that you're getting such awful results for ping
times?
Try to guess when the system is lightly used and run the ping test
again. Use 1 second intervals and small packets. That should be the
best case. You should see a series of 3msec (or less) results.
Interference tends to show up as large latency values or lost packets,
but only for short periods. There should be long periods in between
where the latency is constant and a low value. However, if you have a
marginal radio path, you'll see constant packet loss, and continuous
variations in latency. Again, it's difficult to tell without known
the network topology and without knowing how the backhaul is handled.
If possible, try to get the ISP to give you the IP address of the
central access point. If you can ping this, instead of the gateway,
then you can eliminate the backhaul traffic from the test. If they
won't release the IP address (or it's on a different IP net), then try
to get the MAC address and just assign yourself an unused IP address.
You should be able to get the MAC address from Ethereal (WireShark)
sniffing. Look for a MAC address of 00-13-4F-xx-xx-xx for Tranzeo.
Methinks you're trying to fix the symptoms instead of fixing the cause
of the problem. My guess(tm) is that you have lousy radio path or
interference. The interference is probably from other users on the
WISP's system. Ask them if they have any users that are along the
line of sight, but are beyond the central access point, that might
have their Tranzeo radio pointed directly at your radio. Never mind
users that are to the side, just the ones along the line of sight. The
reason you're having such a difficult time reconnecting after a loss
of connectivity is that the error rate is so high, that the
reconnection sequence probably gives up after a few failed attempts.
Tranzeo also has some diagnostics for the radio that will display
signal strength, signal to noise ratio, and data error rate. These
are needed to determine if you have a decent radio path. Your WISP
should be able to point you to these. It may be something as simple
as moving your rooftop radio, or just aiming it better. You'll need
these diagnostic tools that display your progress in order to aim the
unit.
Gotta run. Good luck.
