TechSpot

WBR-2310 and connection issues

By BellaMarie
Jan 3, 2012
Post New Reply
  1. First I want to say thank you for this great forum to come to, I am somewhat new to problems with my router, but have been learning fast!
    I have read over other posts about this issue, and have learned lurking here in many other areas as well, much thanks!


    ~*~*~*~*~*~*~*~*~*~*~*~

    So have always loved my WBR-2310, have had two of them, I know they get hard knocks from some folks, but my experience has been good, the only reason I have a 2nd one now is my first one burned up in my housefire.
    I recently moved from Frontier DSL: (krappy krappy krappy) to Wireless Microwave connection which has been great.
    They had me on DHCP and I use FFox as my primary browser, and things were zooming along. THEN they changed me to PPPoe, so I have been searching about 8 hours on the web taking ping tests,etc.etc. to target my perfect MTU. Constant time-outs, more especially secure https sites, the bank, my work for the State I live in, etc. Constant-constant reloads even on regular non https pages too.

    I wrote three people at DLink and they said the default 1492 is just fine and keep it like that. I have calculated my MTU at four diff.websites and it is where it is: 1492. I have tweaked FFox with no change in timeouts. I have made my FFox profile not read-only, which was supposed to help

    Additionally the speed of loading pages on PPPoe is about where I was with Frontier, besides timing out, the pages sometimes seem premature in that timeout, doing it sooner than before.

    Me thinks it is the MTU and PPPoe settings????? My connection should be roaring, as I have direct LOS to the new wireless tower in my region.
    WHEW!....need coffee HAHA)

    Hoping to make this simple and not render no connection at all.

    Thanks so much!




    ***PS
    I also have upgraded to the 1.05 firmware with no change, as well.
     
  2. jobeard

    jobeard TS Ambassador Posts: 9,351   +622

    just for clarity, the MTU size is very dependent upon the path to the destination,
    as the test ping -f -l 1500 google.com will show the fragmentation (if required) to the site name given.
    The -F sets the test to report and the -L xxxx sets the buffer(mtu) size.
    Now it is NOT the destination per se that causes the fragmentation, but rather, the node in the path that has the smallest mtu capability.

    So an MTU of 1492 (correct for all DSL / PPoE connections) may work well for 90% of your experience, but fail for the other 10%. This suggests that there's a 10% chance that whatever you select for YOUR mtu, it will mismatch somewhere else anyway :(
    Set it to 1492 and just live with it.

    As to timeouts.
    Just like the MTU test above, you can also test to see just which node is causing the timeouts.
    Use the tracert destination.name command to see;
    1. exactly the path to the named destination (use a domain.name or IP address)
    2. and the timing between the nodes
    example of a good trace without timeouts
    Code:
    tracert 8.8.8.8
    
    Tracing route to google-public-dns-a.google.com [8.8.8.8]
    over a maximum of 30 hops:
    
      1    <1 ms    <1 ms    <1 ms  localrouter [192.168.0.1]
      2    29 ms    19 ms    20 ms  rr.com [gateway address]
      3    10 ms     8 ms     9 ms  76.167.22.185
      4    25 ms    24 ms    23 ms  tge2-2-0.vnnyca2-rtr1.socal.rr.com [72.129.13.96]
     [B] 5    12 ms    12 ms    23 ms  72.129.13.0[/B]
      6    11 ms    12 ms    12 ms  107.14.17.132
      7    13 ms    12 ms    13 ms  66.109.9.24
      8    13 ms    12 ms    12 ms  72.14.197.157
      9    14 ms    12 ms    12 ms  216.239.46.40
     10    41 ms    41 ms    37 ms  72.14.238.2
     11    39 ms    37 ms    38 ms  72.14.239.159
     12    40 ms    38 ms    38 ms  216.239.48.165
     13     *        *       38 ms  72.14.232.6
     14    40 ms    38 ms    38 ms  google-public-dns-a.google.com [8.8.8.8]
    
    [B]Trace complete.[/B]
    
    if you are suffering TO's, you may never get to Trace Complete and one or more lines will read
    Code:
    nn   *   *   *   Timeout
    Line 5 is the last node still withing my ISP addresses,
    so any timeout ABOVE line 5 would be the fault of my ISP (and I can call to complain) and any below line 5 - - will I'm just up a creek without a paddle and there's nothing I can do about it.

    I hope you get better service than we've seen here. Your symptoms are typical of this service.
    I would guess you are in a rural location as that's the environment this product attempts to serve.

    You might BEG them to put you back on DHCP?
     

Similar Topics

Add New Comment

You need to be a member to leave a comment. Join thousands of tech enthusiasts and participate.
TechSpot Account You may also...