Random Network drop out issue

Discussion in 'Wireless Networking' started by BigAl.NZ, Jan 2, 2007.

  1. BigAl.NZ

    BigAl.NZ Guest

    Hi Jeff,

    Thanks for all your help to date. I have issued the command:

    arp -s 192.168.252.254 00-02-a5-02-44-bd


    Will this command persist over a reboot or should i reissue it if I
    reboot?

    Cheers

    -Al
     
    BigAl.NZ, Jan 4, 2007
    #21
    1. Advertisements

  2. 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\
     
    Jeff Liebermann, Jan 4, 2007
    #22
    1. Advertisements

  3. BigAl.NZ

    BigAl.NZ Guest

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

    -Al
     
    BigAl.NZ, Jan 4, 2007
    #23
  4. Bah. I want instant gratification.

    Try running FreePing to both your gateway and some distant server to
    see if they're up or down.
    <http://www.tools4ever.com/products/free/freeping/>
    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.
     
    Jeff Liebermann, Jan 4, 2007
    #24
  5. BigAl.NZ

    BigAl.NZ Guest

    Ok here we go,

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

    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

    WWW.GOOGLE.COM
    Pinging www.l.google.com [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
     
    BigAl.NZ, Jan 4, 2007
    #25
  6. BigAl.NZ

    BigAl.NZ Guest

    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
     
    BigAl.NZ, Jan 4, 2007
    #26
  7. 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.
     
    Jeff Liebermann, Jan 4, 2007
    #27
  8. Hi
    It is an Onboard NIC?
    If yes, find $5, get a PCI NIC, and disable the Onboard.
    Jack (MVP-Networking).
     
    Jack \(MVP-Networking\)., Jan 4, 2007
    #28
  9. BigAl.NZ

    Bill Kearney Guest

    In that case, the one answer is another host trying to come
    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
     
    Bill Kearney, Jan 5, 2007
    #29
  10. BigAl.NZ

    BigAl.NZ Guest

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

    -Al
     
    BigAl.NZ, Jan 5, 2007
    #30
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.