What doens pppoe[3544]: Timeout waiting for PADO packets mean?

Discussion in 'Linux Networking' started by Stefan Viljoen, Jun 19, 2004.

  1. Hi all

    I get the above error message in var/log/messages after using the adsl-setup
    script on Rh9 Linux:

    Jun 19 01:26:45 StefanLinux pppd[3637]: pppd 2.4.1 started by root, uid 0
    Jun 19 01:26:45 StefanLinux pppd[3637]: Using interface ppp0
    Jun 19 01:26:45 StefanLinux pppd[3637]: Connect: ppp0 <--> /dev/pts/4
    Jun 19 01:26:45 StefanLinux /etc/hotplug/net.agent: assuming ppp0 is already
    up
    Jun 19 01:27:16 StefanLinux pppd[3637]: LCP: timeout sending Config-Requests
    Jun 19 01:27:16 StefanLinux pppd[3637]: Connection terminated.
    Jun 19 01:27:16 StefanLinux /etc/hotplug/net.agent: NET unregister event not
    supported
    Jun 19 01:27:20 StefanLinux pppoe[3638]: Timeout waiting for PADO packets
    Jun 19 01:27:20 StefanLinux pppd[3637]: Exit.
    Jun 19 01:27:20 StefanLinux adsl-connect: ADSL connection lost; attempting
    re-connection.

    My ADSL modem works fine in Windows - what is the "PAD0" packets error? How
    can I fix it?

    Thanks!
     
    Stefan Viljoen, Jun 19, 2004
    #1
    1. Advertisements

  2. A web search for 'rfc pppoe' might explain this more completely. But I
    believe that your PC would first send a PADI request, would receive PADO
    and then supply authentication information using what it got from the PADO
    response. Although I am using demand kernel pppoe (instead of rp-pppoe)
    either uses pppd (my pppd is also 2.4.1). Mine first sets up a dummy
    route for the demand connection and when it gets traffic initiating a
    connection, that part goes something like this:

    May 25 22:15:25 realhost pppd[940]: Starting link
    May 25 22:15:25 realhost pppd[940]: Sending PADI
    May 25 22:15:25 realhost pppd[940]: HOST_UNIQ successful match
    May 25 22:15:25 realhost pppd[940]: HOST_UNIQ successful match
    May 25 22:15:25 realhost pppd[940]: Got connection: 191f
    May 25 22:15:25 realhost pppd[940]: Connecting PPPoE socket:
    00:10:67:00:f9:18 1f19 eth1 0x808a630
    May 25 22:15:25 realhost pppd[940]: Connect: ppp0 <--> eth1
    May 25 22:15:25 realhost pppd[940]: Setting MTU to 1492.
    May 25 22:15:25 realhost pppd[940]: Couldn't increase MRU to 1500
    May 25 22:15:25 realhost pppd[940]: Setting MTU to 1492.
    May 25 22:15:27 realhost pppd[940]: Local IP address changed to
    68.20.x.226
    May 25 22:15:27 realhost pppd[940]: Remote IP address changed to
    68.20.y.254

    Notice that mine shows Connect: ppp0 <--> eth1 (the ethernet to my pppoe
    modem) and yours shows Connect: ppp0 <--> /dev/pts/4, but /dev/pts usually
    refers to terminals. So I wonder if pppd is attempting to use your
    terminal instead of ethernet to modem. Or maybe rp-pppoe does it
    differently through a psuedo terminal for interactive hooks to monitor
    things (like pppoe transmission speeds).

    Whatever the case, whatever interface pppd is attempting to use is not
    returning a PADO response or responding to LCP requests for pppoe.
     
    David Efflandt, Jun 19, 2004
    #2
    1. Advertisements

  3. Hi David! Thanks for the reply. Any idea how it sets up this dummy
    connection to do LCP negotiation?

    Everything works fine in Windows as regards ADSL surfing (on physically same
    machine - I dual boot) so I guess hardware is ok...

    Thanks for the reply,
     
    Stefan Viljoen, Jun 19, 2004
    #3
  4. -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1
    NotDashEscaped: You need GnuPG to verify this message

    PADO == PPPoE Active Discovery Offer

    If I get this, it usually means there's some problem on my ISP
    side, albeit if it works for you with M$, it's probably a
    misconfiguration on your side, perhaps MTU settings? Hard to
    tell, perhaps a google search for you ISP/Linux could offer some
    more hints if there's something missing.

    --
    Michael Heiming (GPG-Key ID: 0xEDD27B94)
    mail: echo | perl -pe 'y/a-z/n-za-m/'
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.1 (GNU/Linux)

    iD8DBQFA0/GdAkPEju3Se5QRAvo3AKCU1UNLBk/aWfo/lSWBNV8kqJ7VYgCeKO9g
    1453asxWsKpyYomJX5CQTCE=
    =Sune
    -----END PGP SIGNATURE-----
     
    Michael Heiming, Jun 19, 2004
    #4
  5. Thanks for replying, Michael!

    Any idea how or where I can change MTU settings? Is it an adjustment done on
    the PC side or at the router/POTS modem itself?

    Thanks!
     
    Stefan Viljoen, Jun 19, 2004
    #5
  6. -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1
    NotDashEscaped: You need GnuPG to verify this message

    That was just a random guess, since it's common with pppoe
    problems. I don't know your setup, I have these lines in
    /etc/ppp/options:

    mru 1492
    mtu 1492

    But then I'm using the kernel pppoe module and this setting is
    specific to my ISP. Bets idea would be looking/searching for
    suggestions on your ISP regarding Linux/pppoe or even asking him.

    --
    Michael Heiming (GPG-Key ID: 0xEDD27B94)
    mail: echo | perl -pe 'y/a-z/n-za-m/'
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.1 (GNU/Linux)

    iD8DBQFA1INDAkPEju3Se5QRAoBFAKCcOBnwG2gX4A1JcHk7u2G9SE+KsQCeO6rR
    wmaNDp9S3NmJ43gB28o9CgE=
    =QsM4
    -----END PGP SIGNATURE-----
     
    Michael Heiming, Jun 19, 2004
    #6
  7. I experienced this behavior (ppp0 <--> /dev/pts/N) briefly while
    floundering around to make the transition to the 2.6.x kernel series.
    Still, pppd worked okay with my regular POTS PPP connection which
    specifies /dev/ttyS1.
    Yes, and pppd should not start before the PPP0E Active Discovery phase
    is completed, unless pppd itself does the PAD as in kernel-mode PPPoE.
    If the OP expects pppd to do PAD then he should read KERNEL-MODE-PPPOE,
    which is in the top directory of pppd's source. If he is using rp-pppoe
    then he should read README.pppoe in that directory.
     
    Clifford Kite, Jun 19, 2004
    #7
  8. -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1
    NotDashEscaped: You need GnuPG to verify this message

    Hadn't any problems with pppd while moving to kernel 2.6, but
    this seems to be the reason for the problems, mine shows of
    course:
    Connect: ppp0 <--> eth0

    --
    Michael Heiming (GPG-Key ID: 0xEDD27B94)
    mail: echo | perl -pe 'y/a-z/n-za-m/'
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.1 (GNU/Linux)

    iD8DBQFA1IY2AkPEju3Se5QRApg8AKCeZ1/LmMfWBPZa5Fybv0dWguZR1wCguwhE
    pkP25FTa0m/GkBxJdbZh15I=
    =k1cN
    -----END PGP SIGNATURE-----
     
    Michael Heiming, Jun 19, 2004
    #8
  9. Perhaps that was badly worded. What I meant to say was at one point I
    had seen ppp0 <--> /dev/pts/<N> even while still specifying /dev/ttyS1
    for pppd, but PPP worked anyway. The 2.6 kernel compiled as per the final
    configuration reverted to Connect: ppp0 <--> /dev/ttyS1. I believe the
    difference was caused by configuring CONFIG_LEGACY_PTYS as opposed to
    CONFIG_UNIX98_PTYS. The xterms, or rather rxvt terms here, show up as
    /dev/pts/<N> for both configurations.
     
    Clifford Kite, Jun 19, 2004
    #9
    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.