1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

A Possible broken in PPPoE features Shibby/tomato 104 AIO

Discussion in 'Tomato Firmware' started by Sarick, Dec 19, 2012.

  1. Sarick

    Sarick Serious Server Member

    Hey, guys and gals I've been having stability issues with my DSL. I might have found a bug or located something that could improve the way PPPoE connections are handled on Tomato.

    Here is the problem. The modem sometimes resyncs. This causes the router to disconnect PPPoE erratically.

    This is fine under 99% of the connections. However, I've detected an issue in this tomato that's bugging me. If the DSL connection re-establishes the router can maintain the same IP and won't drop the PPPoE connection unless the "lcp echo fails -- "Tolerance to unanswered echo-requests" exceeds the user defined perimeters.

    I know these can be raised using this commands but at the cost of the router not disconnecting/reconnecting with the connection is really down (unable to self correct)

    pppoe_lei=30
    # lcp echo interval -- "Interval between LCP echo-requests"; default is 30

    pppoe_lef=5
    # lcp echo fails -- "Tolerance to unanswered echo-requests"; default is 5

    The problem I'm having is the tolerance isn't based around consecutive failures. If this is set to the default of five and the connection drops 4 request at 5 am then ten hours later drops one more it'll incorrectly disconnect on the first unanswered echo request instead of restarting at one.

    What this setting should be doing IMHO is counting consecutive failed request. From my understanding the original tomato version tolerance would restart the count and disconnect/reconnect based on the last successful echo request. It would maintain the PPPoE connection with a big lag spike.

    Is there another way to bypass this problem through a script or something so every few hours the tolerance gets reset without the errors stacking? This way the router can maintain/tolerate a few failed request that aren't consecutive. While detecting when the connection really need to be reestablished?
     
  2. Sarick

    Sarick Serious Server Member

    Forgot to add this info.

    Asus RT-N66U: Tomato 1.28.0000 MIPSR2-104 K26 USB AIO-64K
    unknown daemon.info pppd[6639]: Plugin rp-pppoe.so loaded.
    unknown daemon.info pppd[6639]: RP-PPPoE plugin version 3.10 compiled against pppd 2.4.5
     
  3. Sarick

    Sarick Serious Server Member

    I've waited few days for this with no reply, can someone please look into this. Issue? I have the utmost respect for the firmware developers and sincerely hope one or more can discuss this with me.

    Here is the problem explanation as simple as possible.

    Currently this event does not reset failed echos. If the tolerance "pppoe_lef=" is set to "pppoe_lef=5" and 4/5 echo attempts fail, even if the next consecutive 100 are successful it'll continue the count down causing an automatic redial on the 5th echo fail.

    IMHO this is flawed and could be improved for intermittent network errors.

    The redial event should only occur if pppoe_lef=?? are consecutive echo fails. It should then clear/reset the values. If the equal number of successful consecutive replies are detected. This makes the PPPoE client redial only when its really needed.

    The only work around solution is to increase the interval and tolerances to high levels but this breaks the auto redial feature. The solution above would make the PPPoE more stable without making it constantly redial if there are intermittent network issues.

    Shibby, Toastman, or anyone care to discuss this?
     

Share This Page