PPPoE connections timeout and die within 5 seconds of connecting

[Mark Derricutt]

Since the release of Breezy Badger I've been running PPPoE to my ISP, however since upgrading to Dapper I'm finding my PPPoE sessions no longer work.

According to my ISP I'm properly connected and transferring some form of data.

My logs show the following:

Mar 3 07:58:54 spawn pppd[4888]: Timeout waiting for PADO packets
Mar 3 07:59:05 spawn pppd[5289]: Plugin rp-pppoe.so loaded.
Mar 3 07:59:05 spawn pppd[5292]: pppd 2.4.4b1 started by root, uid 0
Mar 3 07:59:30 spawn pppd[5302]: Plugin rp-pppoe.so loaded.
Mar 3 07:59:30 spawn pppd[5304]: pppd 2.4.4b1 started by root, uid 0
Mar 3 07:59:40 spawn pppd[5292]: Timeout waiting for PADO packets
Mar 3 07:59:55 spawn pppd[5095]: No response to 4 echo-requests
Mar 3 07:59:55 spawn pppd[5095]: Serial link appears to be disconnected.
Mar 3 07:59:55 spawn pppd[5095]: Connect time 3.5 minutes.
Mar 3 07:59:55 spawn pppd[5095]: Sent 114327 bytes, received 564192 bytes.
Mar 3 07:59:59 spawn pppd[5120]: Timeout waiting for PADO packets
Mar 3 07:59:59 spawn pppd[5169]: Timeout waiting for PADO packets
Mar 3 07:59:59 spawn pppd[5137]: Timeout waiting for PADO packets
Mar 3 07:59:59 spawn pppd[5077]: Timeout waiting for PADO packets
Mar 3 07:59:59 spawn pppd[5148]: Timeout waiting for PADO packets
Mar 3 07:59:59 spawn pppd[5084]: Timeout waiting for PADO packets
Mar 3 07:59:59 spawn pppd[4841]: Timeout waiting for PADO packets
Mar 3 07:59:59 spawn pppd[4888]: Timeout waiting for PADO packets
Mar 3 07:59:59 spawn pppd[4888]: Exit.
Mar 3 08:00:01 spawn pppd[5095]: Connection terminated.
Mar 3 08:00:01 spawn pppd[5095]: Modem hangup
Mar 3 08:00:05 spawn pppd[5304]: Timeout waiting for PADO packets

Everything worked fine with Breezy prior to the Dapper update.

There's clearly a regression problem somewhere with respect to PPPoE connections.

[Mark Derricutt (mark-talios)]

This still occurs in flight5 - but then it doesn't look like any packages in this area have changed either.

[davekempe (dave-solutionsfirst)]

A copy of your /etc/ppp/dsl-provider (without the comments) would be helpful. Also to know your ISP and modem might help. I use PPPoE extensively and have found even hoary to be less stable than woody for some things. I think its a pppoe tweaking thing, but lets see the configs first.

[Mark Derricutt (mark-talios)]

/etc/ppp/peers/dsl-provider contains:

noipdefault
defaultroute
replacedefaultroute
hide-password
#lcp-echo-interval 30
#lcp-echo-failure 4
noauth
persist
#mtu 1492
usepeerdns
plugin rp-pppoe.so eth0
user "<email address hidden>"

I left the 3 comments there, I notice the mtu line is commented out, pppoeconf had prompted me if I wanted to limit this to 1492 which I said yes to. Manually uncommenting this line doesn't seem to help, nor does setting the value to 1412 which pppoeconf suggested doing if problems persisted.

Additionally, I just noticed the following line in /var/log/messages which I'd not seen before under breezy, I get a feeling this might be the root cause:

Mar 18 15:01:36 spawn kernel: [4788284.016000] eth0: Setting half-duplex based on MII#1 link partner capability of 0021.

The ISP in question is Woosh Wireless ( http://www.woosh.co.nz ) who unfortunately DO NOT support Linux or Macintosh users - and for the most part don't even seem to want to support PPPoE on Windows.

The modem is an IPWireless "Wireless Broadband Modem" of the "Phase 1(d)" model, the windows driver software (which connects via USB rather than PPPoE) says this modem has an IMEI number of 35269700001310 and firmware version 5.2.1.16a with an Rcv window size of 100000, and an MTU size of "automatic".

[Mark Derricutt (mark-talios)]

Note: IPWireless can be found at http://www.ipwireless.com

[Mark Derricutt (mark-talios)]

Some further notes. I tried removing ipv6 support to see if this was causing any problems but no change.

lspci reports the network card is:

0000:00:0a.0 Ethernet controller: Davicom Semiconductor, Inc. 21x4x DEC-Tulip compatible 10/100 Ethernet (rev 31)

I can always ping the lo and eth0 devices and ips, but not ppp when things stop.

I just recorded a tcpdump of a connection and subsequent timeout/disconnect, the logs for this were:

Mar 21 22:45:21 localhost kernel: [4310338.296000] eth0: Setting half-duplex based on MII#1 link partner capability of 0021.
Mar 21 22:45:28 localhost kernel: [4310345.247000] eth0: Promiscuous mode enabled.
Mar 21 22:45:28 localhost kernel: [4310345.247000] device eth0 entered promiscuous mode
Mar 21 22:46:01 localhost pppd[11811]: Plugin rp-pppoe.so loaded.
Mar 21 22:46:01 localhost pppd[11815]: pppd 2.4.4b1 started by root, uid 0
Mar 21 22:46:36 localhost pppd[11815]: Timeout waiting for PADO packets
Mar 21 22:47:12 localhost pppd[11815]: PPP session is 2
Mar 21 22:47:12 localhost pppd[11815]: Using interface ppp0
Mar 21 22:47:12 localhost pppd[11815]: Connect: ppp0 <--> eth0
Mar 21 22:49:04 localhost pppd[11815]: LCP terminated by peer
Mar 21 22:49:07 localhost pppd[11815]: Connection terminated.
Mar 21 22:49:07 localhost pppd[11815]: Modem hangup
Mar 21 22:49:20 localhost kernel: [4310577.368000] device eth0 left promiscuous mode

and the tcpdump is attach'd as dump.ppp.eth0

[Mark Derricutt (mark-talios)]

A tcpdump of my last connection and subsequent "timeout waiting for PADO" and following disconnection.

[Mark Derricutt (mark-talios)]

Looking at the dump in ethereal I see that there's a few PADO packets coming in, but the log seems to show it never saw them. Maybe the problems at the pppd end?

[Mark Derricutt (mark-talios)]

I found my Hoary Live CD and recorded this tcpdump of a pppoeconf configuration process, connection, and subsequent stable connection.

The logs from this:

Mar 22 10:27:53 localhost kernel: NET: Registered protocol family 10
Mar 22 10:27:53 localhost kernel: Disabled Privacy Extensions on device c02ef500(lo)
Mar 22 10:27:53 localhost kernel: IPv6 over IPv4 tunneling driver
Mar 22 10:28:16 localhost gconfd (ubuntu-23549): Resolved address "xml:readwrite:/home/ubuntu/.gconf" to a writable configuration source at position 0
Mar 22 10:30:16 localhost pppd[23983]: Plugin rp-pppoe.so loaded.
Mar 22 10:30:16 localhost pppd[23983]: RP-PPPoE plugin version 3.3 compiled against pppd 2.4.2
Mar 22 10:30:16 localhost pppd[23985]: pppd 2.4.2 started by root, uid 0
Mar 22 10:30:18 localhost pppd[23985]: PPP session is 2
Mar 22 10:30:18 localhost pppd[23985]: Using interface ppp0
Mar 22 10:30:18 localhost pppd[23985]: Connect: ppp0 <--> eth0
Mar 22 10:30:18 localhost pppd[23985]: Couldn't increase MTU to 1500
Mar 22 10:30:18 localhost pppd[23985]: Couldn't increase MRU to 1500
Mar 22 10:30:18 localhost pppd[23985]: Couldn't increase MRU to 1500
Mar 22 10:30:18 localhost pppd[23985]: CHAP authentication succeeded
Mar 22 10:30:18 localhost pppd[23985]: peer from calling number 00:01:D8:58:2C:30 authorized
Mar 22 10:30:18 localhost pppd[23985]: local IP address 202.74.212.161
Mar 22 10:30:18 localhost pppd[23985]: remote IP address 202.74.206.7
Mar 22 10:30:18 localhost pppd[23985]: primary DNS address 202.74.207.10
Mar 22 10:30:18 localhost pppd[23985]: secondary DNS address 202.74.207.100

ifconfig shows:

ubuntu@ubuntu:~$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:80:AD:71:6B:49
          inet6 addr: fe80::280:adff:fe71:6b49/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:14 errors:0 dropped:0 overruns:0 frame:0
          TX packets:27 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:933 (933.0 b) TX bytes:2045 (1.9 KiB)
          Interrupt:10 Base address:0xa400

lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.255.255.255
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MTU:16436 Metric:1
          RX packets:923 errors:0 dropped:0 overruns:0 frame:0
          TX packets:923 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:82876 (80.9 KiB) TX bytes:82876 (80.9 KiB)

ppp0 Link encap:Point-to-Point Protocol
          inet addr:202.74.212.161 P-t-P:202.74.206.7 Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1460 Metric:1
          RX packets:4 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:180 (180.0 b) TX bytes:208 (208.0 b)

[Mark Derricutt (mark-talios)]

This problem is now SOLVED.

After going through the bootlogs of the Flight6 livecd (which worked fine) and my Flight6 install (which didn't) I tracked things down to order in which the Davicom drivers are loaded, and that 'tulip' is loaded from the install, but NOT the livecd.

With this added information in tow, a different google search revealed the following Ubuntu Forums thread:

  http://www.ubuntuforums.org/archive/index.php/t-154172.html

Adding 'dmfe' to the end of /etc/modules and 'blacklist tulip' to the end of /etc/modprobe.d/blacklist solves the problem.

Mark

[Quark Green (quark-green-deactivatedaccount)]

Mark,

I too am having the same problem of the PPPOE connection dying within a few seconds in the release candidate of dapper. I have tried to follow the thread above, but I am new to Linux and Ubuntu and hence am not sure about what I need to look for, where to look for it and then what to do about it. I think I understand the the problem is to do with the loadable kernal module (device driver) that might have been automatically selected for my network adapter in my laptop? I would also like to learn by solving this problem. Can you help me through the steps of finding the source of the problem and fixing it?

Quark

[Michal Bogusz (nebeli)]

Hi,
I had the same problem in drapper. It gone with Edgy. But last time i had tried install Edgy on my friend laptop and a story have backed. I used the same ADSL conection and the same ADSl router. It works fine on my laptop but didn't work on his.
Later I had to install Fedora on his laptop and works fine.
Can't explain.
M.