Random Network drop out issue

We're not done yet. I wanna know what's causing the reconnection problem. (Curiosity kills cats and hacks).

Well, that was easy enough to try. No, it doesn't persist through a reboot.

Make a batch file with the above arp -s command line in it. Drop it into the:

c:\\Documents and Settings\\your_login\\Start Menu\\Programs\\Startup\\

directory. If you have more than one user of the machine, instead of the your_login directory use the:

c:\\Documents and Settings\\All Users\\Start Menu\\Programs\\Startup\\

So far so good - but will have to wait at least another 24 hours to be certain....

-Al

Bah. I want instant gratification.

Try running FreePing to both your gateway and some distant server to see if they're up or down.

Make sure your computer doesn't go standby, hibernate, or comatose. Keep it running overnight. You can edit each entry to set how often it pings. The default is every 30 seconds. By morning, you should have a clue as to how well your connection is running.

Ok here we go,

I setup two cmd windows with a ping every 30 seconds. The first window pinged my dns gateway, the second

The results are:

DNS SERVER: Pinging 192.168.252.254 with 32 bytes of data every 30000 ms:

On 5 seperate occasions I get the following set of errors: 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

Pinging [66.102.7.99] with 32 bytes of data every

30000 ms:

On 4 seperate occasions I get the following set of errors: 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 192.168.252.254

What interesting is: (a) I had the ping windows output a time stamp, and the errors were happening at different times. (b) Notice how it complains about too few bytes from the Google window in the DNS window and visa versa? (c) There does not appear to be any pattern to how often/when this happens.

HTH?

Cheers

-Al

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 ms TTL=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

lines, ie above at 00:01:04

-Al

snipped-for-privacy@gmail.com hath wroth:

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.

Hi It is an Onboard NIC? If yes, find $5, get a PCI NIC, and disable the Onboard. Jack (MVP-Networking).

Oooh, good suggestion!

What I think he's after here is on the other side of the ISP router, the box inside your house that's making the uplink to the ISP, is running into a conflict for your IP address. What you need to see if the arp table inside the router in your house, and if possible, get the ISP to look into the one on their end.

Looking at the arp table on your PC won't help. You'd only be seeing MAC addresses for stuff on your internal house network, not between your router and the ISP.

Tangentally, it's VERY odd to see a router being setup on .254 and the client being setup on a .1 address. There's nothing requiring the use of any particular address, just that it's customary for a router to be on .1, not client machines. Go figure.

-Bill Kearney

Well no dropouts today, but as you say we may be fixing the symptom - not the problem.

-Al