LinkSys BEFSR81 v1: Bad latency/ping issues of over a second. Anyone else seen it?

Discussion in 'Broadband' started by Bloke at the pennine puddle (Replace n.a.v.d with, Oct 22, 2003.

  1. Calling all who have a LinkSys router and more then one computer on
    it. Specifically the `BEFSR81 v2` router with the latest firmware.
    Router is firmware date `2.44.2z, Dec 13 2002`

    The `BEFSR41 v2` might show the same symptoms.

    If you've got the 8 port version, do the following. I'm trying to
    identify a problem with the router's firmware and if others have the
    same problem and may also have a need to bombard LinkSys to get the
    bug fixed. It affects the people who love to have the lowest ping

    If the fault is there, post your request to have it fixed as indicated

    <<<<<< The first bit >>>>>>

    Connect a computer to port 1 and another to port 2.

    Turn on and configure QoS on the router (if you have it) and configure
    it to the following.

    FTP, HTTP, POP3 and port 554 to high priority.
    TELNET, SMTP and port 119 to low priority.
    Set the last entry to port 0 and to `disable`.

    Port 1 to high priority.
    Ports 2, 3 and 4 to low priority.

    Plug a computer into port 1 on the router and turn off the computer,
    to the point where the router is showing no link present. Maybe it'll
    work by unplugging the network cable from port 1 on on the router and
    turn on the computer on port 2, open up a DOS box and type the


    Do you get the following timings stupid?

    Tracing route to []
    over a maximum of 30 hops:

    1 1014 ms 1008 ms 1004 ms 10-23-32-1 []
    2 1009 ms 1006 ms 1006 ms []
    3 1029 ms 1007 ms 1077 ms []
    4 1008 ms 1006 ms 1008 ms []
    5 1012 ms 1014 ms 1013 ms []
    6 1007 ms 1811 ms 1012 ms []
    7 1012 ms 1016 ms 1017 ms []
    8 1016 ms 1010 ms 1019 ms
    9 2009 ms 2005 ms 2005 ms []

    Your route to will be different to mine, but notice the
    time taken (or noted) for the echo to return from each router/server!

    Now, telnet (and it's allowed!) to `` and trace
    route back to your router's public IP, so if NTL assigns you an IP of, the command to issue to the remote router is . ..


    Everything between that router hosted at Energis and the last hop to
    your router will be small and normal, but the last hop from the UBR to
    your router will be in the high-milliseconds! Remember to have `Block
    WAN requests` on your router for this to work.

    <<<<<< The second bit >>>>>>

    Make port 1 on the router active. As in, just plug in the cable, or
    turn on the computer if it's off. Just so the router registers that
    there is a network card attached to port 1, and do the same thing.

    Tracing route to []
    over a maximum of 30 hops:

    1 10 ms 9 ms 10 ms 10-23-32-1 []
    2 10 ms 11 ms 9 ms []
    3 14 ms 15 ms 10 ms []
    4 10 ms 30 ms 9 ms []
    5 18 ms 19 ms 16 ms []
    6 38 ms 18 ms 42 ms []
    7 18 ms 18 ms 19 ms []
    8 19 ms 20 ms 18 ms
    9 52 ms 21 ms 19 ms []

    Now, spot the huge difference!

    Question: Anyone else suffering from this problem? Complain to
    LinkSys if you are.

    My diagnosis shows that the firmware is faulty, especially that the
    same stupid timings can be replicated by a ping or trace route
    originating to my public IP from the Internet.
    Bloke at the pennine puddle (Replace n.a.v.d with , Oct 22, 2003
    1. Advertisements

  2. Bloke at the pennine puddle (Replace n.a.v.d with

    Ian Stirling Guest

    The "high/low" priorities are probably at fault.
    All else being equal, if two computers start to download the same file
    from the same place over the same connection, then the higher latency one
    will tend to get starved out of the connection.
    This is apparently what happens when you set a port to low priority.
    Don't do that then.

    -- | mailto: | Ian Stirling.
    He had been eight years upon a project for extracting sunbeams out of cucumbers,
    which were to be put in vials hermetically sealed, and let out to warm the air
    in raw inclement summers. -- Jonathan Swift, "Gulliver's Travels" (1726)
    Ian Stirling, Oct 22, 2003
    1. Advertisements

  3. Thanks for reply Ian. I'll try your suggestion and set all the ports
    to low priority, but the issue is that the timings are all screwed up
    when there is no `link` present on port 1. As soon as a `link` is
    detected on port one, everything on the other ports show believeable

    Remember, it's not about data transfer. Just turning on the PC on
    port 1 and pressing pause so it's not even had a chance to boot
    anything from the hard disk `cures` the symptom. Remove the `network
    device` from port 1 and we are back to stupid 1000ms+ for the echo to
    return. as opposed the the usual average of 11ms.
    Bloke at the pennine puddle (Replace n.a.v.d with , Oct 22, 2003
  4. Did the extra tests....

    Okay. I turned off the QoS on the router and also, for good measure,
    reset the router. I turned on the computer on port 2 and turned off
    the computer on port 1.

    The trace route result from my end to `` ...

    Tracing route to []
    over a maximum of 30 hops:
    1 999 ms 1008 ms 1020 ms
    2 1007 ms 1002 ms 1006 ms []
    3 1006 ms 998 ms 1000 ms []
    4 1828 ms 1010 ms 1007 ms []
    5 1009 ms 1006 ms 999 ms []
    6 1014 ms 1038 ms 1012 ms []
    7 1007 ms 1009 ms 1009 ms []
    8 1016 ms 1029 ms 1039 ms []
    9 1029 ms 1010 ms 1016 ms
    10 2684 ms 2009 ms 2009 ms []
    Trace complete.

    Now, I got `` to trace route to my router, and
    the result is ...>traceroute
    Type escape sequence to abort.
    Tracing the route to (
    1 ( 0 msec 0 msec 0 msec
    2 8 msec 8 msec 8 msec
    3 ( [AS 5459] 8 msec 8 msec 20 msec
    4 ( [AS 5089] 8 msec 8 msec 8 msec
    5 ( [AS 5089] 12 msec 8 msec 12 msec
    6 ( [AS 5089] 8 msec 12 msec 8 msec
    7 ( [AS 5089] 16 msec 16 msec 16 msec
    8 ( [AS 5089] 16 msec 16 msec 16 msec
    9 ( [AS 5089] 28 msec 28 msec 32 msec
    10 ( [AS 5089] 24 msec 16 msec 16 msec
    11 ( [AS 5089] 1044 msec 1064 msec 1112 msec>

    Notice the 11th entry. It's in the thousands, and at the preceeding
    UBR it's only in the tens, and QoS is knocked off.

    While getting the computer on port 2 to ping ``
    constantly I turned on the computer on port 1. After about 15 seconds
    the ping times on port 2 suddenly dropped from the thousands to the
    tens. Maybe that was triggered within the router by the computer on
    port 1 sending data of whatever nature? Also, doing a trace route from
    `` also shows things return to normal.

    With the fault active, and tracerouting from
    ``, the 1000 is what it says. It takes a second
    for each echo sent to the router to return to

    It's a fault with the firmware within LinkSys router. I'm convinced.
    If it was any settings then the WAN side of the router would not be a

    Maybe if enough people indicate this potential bug to LinkSys/Cisco,
    something might be done about it.
    Bloke at the pennine puddle (Replace n.a.v.d with , Oct 22, 2003

    The router is set to send all it's logging data to my main machine
    ``. If the logging client is not there to receive the log
    data then the router waits for one second! Like if the computer is
    turned off!

    I just proven it. On the router I changed the logger IP from
    `` to an IP that does not exist on my LAN and guess what, 2
    second pings for every packet! Changed it back to `` and we
    are back to 10ms(ish).

    I knew it was a bug with the Firmware. It's not often that I'm wrong.
    Bloke at the pennine puddle (Replace n.a.v.d with , Oct 22, 2003
    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.