Apart from the change of "Check Interval" to "Redial Interval, (which I am doing now) I didn't see anything needed changing. What are you suggesting?
Without further info it's difficult to know but I see this in the syslog: Code: May 17 20:38:55 unknown daemon.info pppd[7378]: No response to 5 echo-requests May 17 20:38:55 unknown daemon.notice pppd[7378]: Serial link appears to be disconnected. May 17 20:38:55 unknown daemon.info pppd[7378]: Connect time 38.6 minutes. May 17 20:38:55 unknown daemon.info pppd[7378]: Sent 1151 bytes, received 1776 bytes. May 17 20:38:58 unknown user.info redial[7379]: WAN down. Reconnecting... Now, a) that's not exactly an busy link (!) and b) pppd tried to get 5 link echo responses and failed. Bear in mind that the link was up for 38 minutes. What I would try is setting up an IP ping every 30 secs or so, just to put a bit of traffic on the link. I'm wondering if your ISP doesn't count the LCP echos as an 'active' indicator and drops the link after 30 something minutes. Years ago I had a very strange ISP fault whereby the pppoe link was dropped silently, it looked to all intents & purposes like Tomato was the problem with certain firmware only...went and bought another router...similar issues but both the original firmware & the new router firmware masked them slightly better. Eventually ISP cleared the misconfiguration.
my first post about that ... Tomato RAF with included BitTorrent Client - beta testing @Toastman we need the lcp-echo-intervall option in gui too .... to set the intervall time lcp echo is for checking connection from router to isp ... if some isp's answer an echo only all 30 secs and u echo all 10 secs and one echo get really loosed .... and the isp answers only after 30 secs again ... there are 3 more that not answered echos ... now we have 5 ore more and connection drops :\ and u don't really need the lcp echo thing at all .... the router checks itself if he has no connection there was long time ago a discuss with the robert schlabbach ... he wrote paspppoe ... about the same thing with lcp echo with same conclusion
So what I think you're saying is that if 5 LCP echoes are lost IN TOTAL then ppp thinks the connection has gone away. Surely this is a ppp bug, it should be if 5 contiguous LCP echoes are lost then we should consider the link gone. In my opinion a successful LCP echo reply should reset the counter to 0. Every other solution is really a sticking plaster over the problem...either just not looking for echos are not worrying about how many are lost. I wonder what the RFCs say? Man page say: lcp-echo-failure nIf this option is given, pppd will presume the peer to be dead if n LCP echo-requests are sent without receiving a valid LCP echo-reply. If this happens, pppd will terminate the connection. Use of this option requires a non-zero value for the lcp-echo-interval parameter. This option can be used to enable pppd to terminate after the physical connection has been broken (e.g., the modem has hung up) in situations where no hardware modem control lines are available. this is ambiguous. It could be interpreted as saying 'if I get n LCP echo failures then the connection has dropped' - it doesn't say the failures have to be contiguous. The source code lcp-echo-failure option says 'number of consecutive echo failures....' I need to try and work out what the code is *really* doing.
Ok i set pppoe_lei to 0 and restarted wan. I left the web config page open so it refresh every 3 seconds the result is it still disconnect after 2 hours something. below is the log. http://pastebin.com/xc9a59Ew
