Bug 803003

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/20100101 Firefox/18.0

I have openSUSE configured to connect over a DSL line via PPPoE:

  # /etc/sysconfig/network/ifcfg-dsl0
  BOOTPROTO='none'
  DEVICE='eth0'
  MODEM_IP='10.0.0.13'
  NAME='DSL Connection'
  PPPD_OPTIONS=''
  PPPMODE='pppoe'
  PROVIDER='provider5'
  STARTMODE='auto'
  UDI=''
  USERCONTROL='yes'
  VPIVCI='8/35'

When the eth0 ethernet interface comes up, the pppd process is properly started, it connects, and everything is great.

Running pstree shows that things are working:

  |-smpppd-ifcfg --up --rc -i ifcfg-dsl0
  |   `-pppd logfd 7 call pppoe eth0 mtu 1492 mru 1492 ipcp-accept-local ipcp-accept-remote idle 900 defaultroute replacedefaultroute nodetach usepeerdns ifname dsl0 ipparam 'ifcfg-dsl0' 'provider5' user username@example.com passwordfd 8

However, when there is heavy download traffic on the line, sometimes four consecutive LCP echo request and/or reply packets will get dropped, causing the PPP session to terminate (see logs starting at 21:43:13):

Feb  9 20:21:03 rebound pppd[15791]: Plugin rp-pppoe.so loaded.
Feb  9 20:21:03 rebound pppd[15791]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.5
Feb  9 20:21:03 rebound pppd[15791]: Plugin passwordfd.so loaded.
Feb  9 20:21:03 rebound pppd[15791]: pppd 2.4.5 started by root, uid 0
Feb  9 20:21:08 rebound pppd[15791]: PPP session is 1893
Feb  9 20:21:08 rebound pppd[15791]: Connected to 00:30:83:16:3d:43 via interface eth0
Feb  9 20:21:08 rebound pppd[15791]: Renamed interface ppp0 to dsl0
Feb  9 20:21:08 rebound pppd[15791]: Using interface dsl0
Feb  9 20:21:08 rebound pppd[15791]: Connect: dsl0 <--> eth0
Feb  9 20:21:08 rebound pppd[15791]: CHAP authentication succeeded: CHAP authentication success, unit 13425
Feb  9 20:21:08 rebound pppd[15791]: CHAP authentication succeeded
Feb  9 20:21:08 rebound pppd[15791]: peer from calling number 00:30:83:16:3D:43 authorized
Feb  9 20:21:09 rebound pppd[15791]: local  IP address 1.2.3.4
Feb  9 20:21:09 rebound pppd[15791]: remote IP address 5.6.7.8
Feb  9 20:21:09 rebound pppd[15791]: primary   DNS address 2.2.2.2
Feb  9 20:21:09 rebound pppd[15791]: secondary DNS address 2.2.2.3
Feb  9 20:21:09 rebound pppd[15791]: Script /etc/ppp/ip-up finished (pid 15971), status = 0x0
Feb  9 21:43:13 rebound pppd[15791]: No response to 4 echo-requests
Feb  9 21:43:13 rebound pppd[15791]: Serial link appears to be disconnected.
Feb  9 21:43:13 rebound pppd[15791]: Connect time 82.1 minutes.
Feb  9 21:43:13 rebound pppd[15791]: Sent 20606504 bytes, received 463895045 bytes.
Feb  9 21:43:13 rebound pppd[15791]: Connection terminated.
Feb  9 21:43:14 rebound pppd[15791]: Script /etc/ppp/ip-down finished (pid 16478), status = 0x0
Feb  9 21:43:14 rebound pppd[15791]: Exit.

At this point, the DSL connection is dead and will never come back. I have to then go down into the basement and manually restart networking (or, at least the ethernet interface).

This is a bug. The connection should automatically reconnect in this situation.

From my research, the solution to this is to provide the persist option to pppd:

       persist
              Do not exit after a connection is terminated; instead try to reopen the connection.

Apparently this can be done explicitly by smppd-ifcfg or by adding "persist" to /etc/ppp/options. However, I haven't fully tested this but it seems like it should work.


Reproducible: Always

Steps to Reproduce:
1. Configured DSL line over PPPoE
2. Create heavy traffic in both directions
3. Wait an hour or two for 4 consecutive PPP LCP echo failures
4. Watch the DSL line go down and never recover
Actual Results:  
Feb  9 21:43:13 rebound pppd[15791]: Connection terminated.
Feb  9 21:43:14 rebound pppd[15791]: Script /etc/ppp/ip-down finished (pid 16478), status = 0x0
Feb  9 21:43:14 rebound pppd[15791]: Exit.


Expected Results:  
Should have reconnected.