PPP connection problems - can anyone help? - PPP

This is a discussion on PPP connection problems - can anyone help? - PPP ; Are they any experts out there that can help? I am attempting to connect to an ISP via dialup in Debian. I open the connection in minicom give my user/pass info and start ppp, and then start the pppd daemon ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: PPP connection problems - can anyone help?

  1. PPP connection problems - can anyone help?

    Are they any experts out there that can help? I am attempting to
    connect to an ISP via dialup in Debian. I open the connection in
    minicom give my user/pass info and start ppp, and then start the pppd
    daemon on my machine as root and it seems to connect fine, but I cannot
    ping the address of host given by pppd (or anywhere else). Here is the
    pppd debug information. As far as I've read on newsgroups, 'Can't
    locate module ppp-compress-21' and 'Cannot determine ethernet address
    for proxy ARP' are not the cause of the problem. Any help is much
    appreciated. Thank you,

    -A

    Jan 19 19:01:28 taco pppd[234]: pppd 2.4.1 started by root, uid 0
    Jan 19 19:01:28 taco pppd[234]: using channel 2
    Jan 19 19:01:28 taco pppd[234]: Using interface ppp0
    Jan 19 19:01:28 taco pppd[234]: Connect: ppp0 <--> /dev/ttyS3
    Jan 19 19:01:28 taco pppd[234]: sent [LCP ConfReq id=0x1
    ]
    Jan 19 19:01:28 taco pppd[234]: rcvd [LCP ConfReq id=0x3 0xa0000> ]
    Jan 19 19:01:28 taco pppd[234]: sent [LCP ConfAck id=0x3 0xa0000> ]
    Jan 19 19:01:28 taco pppd[234]: rcvd [LCP ConfReq id=0x4 0xa0000> ]
    Jan 19 19:01:28 taco pppd[234]: sent [LCP ConfAck id=0x4 0xa0000> ]
    Jan 19 19:01:28 taco pppd[234]: rcvd [LCP ConfAck id=0x1
    ]
    Jan 19 19:01:28 taco pppd[234]: sent [LCP EchoReq id=0x0
    magic=0xa278ff5]
    Jan 19 19:01:28 taco pppd[234]: kernel does not support PPP filtering
    Jan 19 19:01:28 taco pppd[234]: sent [IPCP ConfReq id=0x1
    ]
    Jan 19 19:01:28 taco modprobe: modprobe: Can't locate module
    ppp-compress-21
    Jan 19 19:01:28 taco modprobe: modprobe: Can't locate module
    ppp-compress-21
    Jan 19 19:01:28 taco pppd[234]: sent [CCP ConfReq id=0x1
    ]
    Jan 19 19:01:29 taco pppd[234]: rcvd [LCP EchoRep id=0x0
    magic=0xed8c21ee]
    Jan 19 19:01:29 taco pppd[234]: rcvd [IPCP ConfReq id=0x1 0f 00> ]
    Jan 19 19:01:29 taco pppd[234]: sent [IPCP ConfAck id=0x1 0f 00> ]
    Jan 19 19:01:29 taco pppd[234]: rcvd [IPCP ConfNak id=0x1 142.150.134.132>]
    Jan 19 19:01:29 taco pppd[234]: sent [IPCP ConfReq id=0x2 142.150.134.132> ]
    Jan 19 19:01:29 taco pppd[234]: rcvd [LCP ProtRej id=0x5 80 fd 01 01 00
    0c 1a 04 78 00 18 04 78 00]
    Jan 19 19:01:29 taco pppd[234]: rcvd [IPCP ConfAck id=0x2 142.150.134.132> ]
    Jan 19 19:01:29 taco pppd[234]: Cannot determine ethernet address for
    proxy ARP
    Jan 19 19:01:29 taco pppd[234]: local IP address 142.150.134.132
    Jan 19 19:01:29 taco pppd[234]: remote IP address 142.150.128.50
    Jan 19 19:01:29 taco pppd[234]: Script /etc/ppp/ip-up started (pid 239)
    Jan 19 19:01:29 taco pppd[234]: Script /etc/ppp/ip-up finished (pid
    239), status = 0x0
    Jan 19 19:01:58 taco pppd[234]: sent [LCP EchoReq id=0x1
    magic=0xa278ff5]
    Jan 19 19:01:58 taco pppd[234]: rcvd [LCP EchoRep id=0x1
    magic=0xed8c21ee]
    Jan 19 19:02:28 taco pppd[234]: sent [LCP EchoReq id=0x2
    magic=0xa278ff5]
    Jan 19 19:02:28 taco pppd[234]: rcvd [LCP EchoRep id=0x2
    magic=0xed8c21ee]
    Jan 19 19:02:58 taco pppd[234]: sent [LCP EchoReq id=0x3
    magic=0xa278ff5]
    Jan 19 19:02:58 taco pppd[234]: rcvd [LCP EchoRep id=0x3
    magic=0xed8c21ee]
    Jan 19 19:03:28 taco pppd[234]: sent [LCP EchoReq id=0x4
    magic=0xa278ff5]
    Jan 19 19:03:28 taco pppd[234]: rcvd [LCP EchoRep id=0x4
    magic=0xed8c21ee]
    Jan 19 19:03:58 taco pppd[234]: sent [LCP EchoReq id=0x5
    magic=0xa278ff5]
    Jan 19 19:03:58 taco pppd[234]: rcvd [LCP EchoRep id=0x5
    magic=0xed8c21ee]
    Jan 19 19:04:28 taco pppd[234]: sent [LCP EchoReq id=0x6
    magic=0xa278ff5]
    Jan 19 19:04:28 taco pppd[234]: rcvd [LCP EchoRep id=0x6
    magic=0xed8c21ee]
    Jan 19 19:04:58 taco pppd[234]: sent [LCP EchoReq id=0x7
    magic=0xa278ff5]
    Jan 19 19:04:59 taco pppd[234]: rcvd [LCP EchoRep id=0x7
    magic=0xed8c21ee]
    Jan 19 19:05:28 taco pppd[234]: sent [LCP EchoReq id=0x8
    magic=0xa278ff5]
    Jan 19 19:05:28 taco pppd[234]: rcvd [LCP EchoRep id=0x8
    magic=0xed8c21ee]
    Jan 19 19:05:58 taco pppd[234]: sent [LCP EchoReq id=0x9
    magic=0xa278ff5]
    Jan 19 19:05:58 taco pppd[234]: rcvd [LCP EchoRep id=0x9
    magic=0xed8c21ee]
    Jan 19 19:06:28 taco pppd[234]: sent [LCP EchoReq id=0xa
    magic=0xa278ff5]
    Jan 19 19:06:28 taco pppd[234]: rcvd [LCP EchoRep id=0xa
    magic=0xed8c21ee]
    Jan 19 19:06:58 taco pppd[234]: sent [LCP EchoReq id=0xb
    magic=0xa278ff5]
    Jan 19 19:06:58 taco pppd[234]: rcvd [LCP EchoRep id=0xb
    magic=0xed8c21ee]
    Jan 19 19:07:28 taco pppd[234]: sent [LCP EchoReq id=0xc
    magic=0xa278ff5]
    Jan 19 19:07:28 taco pppd[234]: rcvd [LCP EchoRep id=0xc
    magic=0xed8c21ee]
    Jan 19 19:07:58 taco pppd[234]: sent [LCP EchoReq id=0xd
    magic=0xa278ff5]
    Jan 19 19:07:58 taco pppd[234]: rcvd [LCP EchoRep id=0xd
    magic=0xed8c21ee]
    Jan 19 19:08:28 taco pppd[234]: sent [LCP EchoReq id=0xe
    magic=0xa278ff5]
    Jan 19 19:08:28 taco pppd[234]: rcvd [LCP EchoRep id=0xe
    magic=0xed8c21ee]
    Jan 19 19:08:58 taco pppd[234]: sent [LCP EchoReq id=0xf
    magic=0xa278ff5]
    Jan 19 19:08:58 taco pppd[234]: rcvd [LCP EchoRep id=0xf
    magic=0xed8c21ee]
    Jan 19 19:09:28 taco pppd[234]: sent [LCP EchoReq id=0x10
    magic=0xa278ff5]
    Jan 19 19:09:28 taco pppd[234]: rcvd [LCP EchoRep id=0x10
    magic=0xed8c21ee]
    Jan 19 19:09:58 taco pppd[234]: sent [LCP EchoReq id=0x11
    magic=0xa278ff5]
    Jan 19 19:09:58 taco pppd[234]: rcvd [LCP EchoRep id=0x11
    magic=0xed8c21ee]
    Jan 19 19:10:28 taco pppd[234]: sent [LCP EchoReq id=0x12
    magic=0xa278ff5]
    Jan 19 19:10:29 taco pppd[234]: rcvd [LCP EchoRep id=0x12
    magic=0xed8c21ee]
    Jan 19 19:10:58 taco pppd[234]: sent [LCP EchoReq id=0x13
    magic=0xa278ff5]
    Jan 19 19:10:59 taco pppd[234]: rcvd [LCP EchoRep id=0x13
    magic=0xed8c21ee]
    Jan 19 19:11:28 taco pppd[234]: sent [LCP EchoReq id=0x14
    magic=0xa278ff5]
    Jan 19 19:11:29 taco pppd[234]: rcvd [LCP EchoRep id=0x14
    magic=0xed8c21ee]
    Jan 19 19:11:58 taco pppd[234]: sent [LCP EchoReq id=0x15
    magic=0xa278ff5]
    Jan 19 19:11:59 taco pppd[234]: rcvd [LCP EchoRep id=0x15
    magic=0xed8c21ee]
    Jan 19 19:12:23 taco pppd[234]: Terminating on signal 15.
    Jan 19 19:12:23 taco pppd[234]: Script /etc/ppp/ip-down started (pid
    275)
    Jan 19 19:12:23 taco pppd[234]: sent [LCP TermReq id=0x2 "User request"]

    Jan 19 19:12:23 taco pppd[234]: Script /etc/ppp/ip-down finished (pid
    275), status = 0x0
    Jan 19 19:12:23 taco pppd[234]: rcvd [LCP TermAck id=0x2]
    Jan 19 19:12:23 taco pppd[234]: Connection terminated.
    Jan 19 19:12:23 taco pppd[234]: Connect time 11.0 minutes.
    Jan 19 19:12:23 taco pppd[234]: Sent 7672 bytes, received 1070 bytes.
    Jan 19 19:12:24 taco pppd[234]: Exit.


  2. Re: PPP connection problems - can anyone help?

    Weathermon Adam Clifford writes:
    > Are they any experts out there that can help? I am attempting to
    > connect to an ISP via dialup in Debian. I open the connection in
    > minicom give my user/pass info and start ppp, and then start the pppd
    > daemon on my machine as root and it seems to connect fine, but I cannot
    > ping the address of host given by pppd (or anywhere else). Here is the
    > pppd debug information. As far as I've read on newsgroups, 'Can't
    > locate module ppp-compress-21' and 'Cannot determine ethernet address
    > for proxy ARP' are not the cause of the problem.


    Right. The former is just a nit with the way the compression modules
    are installed (and causes no harm), and the latter is a minor
    misconfiguration -- you have the pppd "proxyarp" option somewhere in
    your configuration, and you should not. Neither will cause trouble.

    > Jan 19 19:01:29 taco pppd[234]: local IP address 142.150.134.132
    > Jan 19 19:01:29 taco pppd[234]: remote IP address 142.150.128.50


    Looks like a healthy connection to me. I suggest you look elsewhere
    for the problem. The PPP link itself seems to be working.

    Is routing configured correctly? What about name resolution?

    --
    James Carlson, IP Systems Group
    Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

  3. Re: PPP connection problems - can anyone help?

    Weathermon Adam Clifford wrote:
    > Are they any experts out there that can help? I am attempting to
    > connect to an ISP via dialup in Debian. I open the connection in
    > minicom give my user/pass info and start ppp, and then start the pppd
    > daemon on my machine as root and it seems to connect fine, but I cannot
    > ping the address of host given by pppd (or anywhere else). Here is the
    > pppd debug information. As far as I've read on newsgroups, 'Can't
    > locate module ppp-compress-21' and 'Cannot determine ethernet address
    > for proxy ARP' are not the cause of the problem. Any help is much
    > appreciated. Thank you,


    > -A


    > Jan 19 19:01:28 taco pppd[234]: pppd 2.4.1 started by root, uid 0
    > Jan 19 19:01:28 taco pppd[234]: using channel 2
    > Jan 19 19:01:28 taco pppd[234]: Using interface ppp0
    > Jan 19 19:01:28 taco pppd[234]: Connect: ppp0 <--> /dev/ttyS3
    > Jan 19 19:01:28 taco pppd[234]: sent [LCP ConfReq id=0x1
    > ]
    > Jan 19 19:01:28 taco pppd[234]: rcvd [LCP ConfReq id=0x3 > 0xa0000> ]


    One thing you might try is to imitate the peer by adding the pppd option
    "asyncmap a0000" which sometimes means the peer's ACCM implementation
    is broken and it must receive data with Xon/Xoff escaped.

    [For clarity, echo requests and replies were removed, as well as modprobe
    complaints, and useless CCP negotiations.]

    > Jan 19 19:01:28 taco pppd[234]: sent [LCP ConfAck id=0x3 > 0xa0000> ]
    > Jan 19 19:01:28 taco pppd[234]: rcvd [LCP ConfReq id=0x4 > 0xa0000> ]
    > Jan 19 19:01:28 taco pppd[234]: sent [LCP ConfAck id=0x4 > 0xa0000> ]
    > Jan 19 19:01:28 taco pppd[234]: rcvd [LCP ConfAck id=0x1
    > ]
    > Jan 19 19:01:28 taco pppd[234]: kernel does not support PPP filtering


    Filtering does work in pppd 2.4.1 if the kernel is compiled with support
    for it. I've found that active filtering can be useful.

    > Jan 19 19:01:28 taco pppd[234]: sent [IPCP ConfReq id=0x1
    > ]
    > Jan 19 19:01:29 taco pppd[234]: rcvd [IPCP ConfReq id=0x1 > 0f 00> ]
    > Jan 19 19:01:29 taco pppd[234]: sent [IPCP ConfAck id=0x1 > 0f 00> ]


    Here is another red flag. Peers that request VJ compression with no
    Van Jacobson compressed TCP/IP headers (the 00 in may be broken in that regard. Again try imitating the peer with the
    pppd option novjccomp.

    > Jan 19 19:01:29 taco pppd[234]: rcvd [IPCP ConfNak id=0x1 > 142.150.134.132>]
    > Jan 19 19:01:29 taco pppd[234]: sent [IPCP ConfReq id=0x2 > 142.150.134.132> ]
    > Jan 19 19:01:29 taco pppd[234]: rcvd [IPCP ConfAck id=0x2 > 142.150.134.132> ]
    > Jan 19 19:01:29 taco pppd[234]: Cannot determine ethernet address for
    > proxy ARP
    > Jan 19 19:01:29 taco pppd[234]: local IP address 142.150.134.132
    > Jan 19 19:01:29 taco pppd[234]: remote IP address 142.150.128.50
    > Jan 19 19:01:29 taco pppd[234]: Script /etc/ppp/ip-up started (pid 239)
    > Jan 19 19:01:29 taco pppd[234]: Script /etc/ppp/ip-up finished (pid
    > 239), status = 0x0


    It does _look_ like a good connection, as James Carlson remarked.

    > Jan 19 19:12:23 taco pppd[234]: Terminating on signal 15.
    > Jan 19 19:12:23 taco pppd[234]: Script /etc/ppp/ip-down started (pid
    > 275)
    > Jan 19 19:12:23 taco pppd[234]: sent [LCP TermReq id=0x2 "User request"]


    > Jan 19 19:12:23 taco pppd[234]: Script /etc/ppp/ip-down finished (pid
    > 275), status = 0x0
    > Jan 19 19:12:23 taco pppd[234]: rcvd [LCP TermAck id=0x2]
    > Jan 19 19:12:23 taco pppd[234]: Connection terminated.
    > Jan 19 19:12:23 taco pppd[234]: Connect time 11.0 minutes.
    > Jan 19 19:12:23 taco pppd[234]: Sent 7672 bytes, received 1070 bytes.
    > Jan 19 19:12:24 taco pppd[234]: Exit.


    Are you supposed to supply the IP address you use for the PPP link?
    Most ISPs provide dynamic IP address for both itself and the ISP client.

    You might try adding the noipdefault option and removing the pppd IP
    address option, if it's in use, to see if that helps. It's not beyond
    belief that an ISP would accept a client's IP address request even when
    the IP address requested won't work.

    -- Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/
    /* The signal-to-noise ratio is too low in many [news] groups to make
    * them good candidates for archiving.
    * --- Mike Moraes, Answers to FAQs about Usenet */

  4. Re: PPP connection problems - can anyone help?

    Thanks for your help. I tried your suggestions by adding 'novjccomp',
    'noipdefault', and 'asyncmap a0000' to the options file separately and none
    of these fixed the problem. I should also clarify, I AM able to ping my own
    address, but not the other end of the connection and anything beyond that.
    I believe the problem might have something to do with routing. Here is the
    '/etc/ppp/options' file and the result of 'route -n' after getting the
    connection "up". I am a newbie so I could be doing something really stupid
    in the network setup. If you could suggest the essentials for network setup
    to make ppp work that might help. Thank you again for your assistance.

    'route -n'
    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref Use
    Iface
    142.150.128.46 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0

    'options file' (comments removed for clarity)
    -detach
    asyncmap 0
    auth
    crtscts
    lock
    hide-password
    noipdefault
    debug
    lcp-echo-interval 30
    lcp-echo-failure 4


    "Clifford Kite" wrote in message
    news:qmckub.t55.ln@corncob.localhost.tld...
    > Weathermon Adam Clifford wrote:
    > > Are they any experts out there that can help? I am attempting to
    > > connect to an ISP via dialup in Debian. I open the connection in
    > > minicom give my user/pass info and start ppp, and then start the pppd
    > > daemon on my machine as root and it seems to connect fine, but I cannot
    > > ping the address of host given by pppd (or anywhere else). Here is the
    > > pppd debug information. As far as I've read on newsgroups, 'Can't
    > > locate module ppp-compress-21' and 'Cannot determine ethernet address
    > > for proxy ARP' are not the cause of the problem. Any help is much
    > > appreciated. Thank you,

    >
    > > -A

    >
    > > Jan 19 19:01:28 taco pppd[234]: pppd 2.4.1 started by root, uid 0
    > > Jan 19 19:01:28 taco pppd[234]: using channel 2
    > > Jan 19 19:01:28 taco pppd[234]: Using interface ppp0
    > > Jan 19 19:01:28 taco pppd[234]: Connect: ppp0 <--> /dev/ttyS3
    > > Jan 19 19:01:28 taco pppd[234]: sent [LCP ConfReq id=0x1
    > > ]
    > > Jan 19 19:01:28 taco pppd[234]: rcvd [LCP ConfReq id=0x3 > > 0xa0000> ]

    >
    > One thing you might try is to imitate the peer by adding the pppd option
    > "asyncmap a0000" which sometimes means the peer's ACCM implementation
    > is broken and it must receive data with Xon/Xoff escaped.
    >
    > [For clarity, echo requests and replies were removed, as well as modprobe
    > complaints, and useless CCP negotiations.]
    >
    > > Jan 19 19:01:28 taco pppd[234]: sent [LCP ConfAck id=0x3 > > 0xa0000> ]
    > > Jan 19 19:01:28 taco pppd[234]: rcvd [LCP ConfReq id=0x4 > > 0xa0000> ]
    > > Jan 19 19:01:28 taco pppd[234]: sent [LCP ConfAck id=0x4 > > 0xa0000> ]
    > > Jan 19 19:01:28 taco pppd[234]: rcvd [LCP ConfAck id=0x1
    > > ]
    > > Jan 19 19:01:28 taco pppd[234]: kernel does not support PPP filtering

    >
    > Filtering does work in pppd 2.4.1 if the kernel is compiled with support
    > for it. I've found that active filtering can be useful.
    >
    > > Jan 19 19:01:28 taco pppd[234]: sent [IPCP ConfReq id=0x1
    > > ]
    > > Jan 19 19:01:29 taco pppd[234]: rcvd [IPCP ConfReq id=0x1 > > 0f 00> ]
    > > Jan 19 19:01:29 taco pppd[234]: sent [IPCP ConfAck id=0x1 > > 0f 00> ]

    >
    > Here is another red flag. Peers that request VJ compression with no
    > Van Jacobson compressed TCP/IP headers (the 00 in > may be broken in that regard. Again try imitating the peer with the
    > pppd option novjccomp.
    >
    > > Jan 19 19:01:29 taco pppd[234]: rcvd [IPCP ConfNak id=0x1 > > 142.150.134.132>]
    > > Jan 19 19:01:29 taco pppd[234]: sent [IPCP ConfReq id=0x2 > > 142.150.134.132> ]
    > > Jan 19 19:01:29 taco pppd[234]: rcvd [IPCP ConfAck id=0x2 > > 142.150.134.132> ]
    > > Jan 19 19:01:29 taco pppd[234]: Cannot determine ethernet address for
    > > proxy ARP
    > > Jan 19 19:01:29 taco pppd[234]: local IP address 142.150.134.132
    > > Jan 19 19:01:29 taco pppd[234]: remote IP address 142.150.128.50
    > > Jan 19 19:01:29 taco pppd[234]: Script /etc/ppp/ip-up started (pid 239)
    > > Jan 19 19:01:29 taco pppd[234]: Script /etc/ppp/ip-up finished (pid
    > > 239), status = 0x0

    >
    > It does _look_ like a good connection, as James Carlson remarked.
    >
    > > Jan 19 19:12:23 taco pppd[234]: Terminating on signal 15.
    > > Jan 19 19:12:23 taco pppd[234]: Script /etc/ppp/ip-down started (pid
    > > 275)
    > > Jan 19 19:12:23 taco pppd[234]: sent [LCP TermReq id=0x2 "User request"]

    >
    > > Jan 19 19:12:23 taco pppd[234]: Script /etc/ppp/ip-down finished (pid
    > > 275), status = 0x0
    > > Jan 19 19:12:23 taco pppd[234]: rcvd [LCP TermAck id=0x2]
    > > Jan 19 19:12:23 taco pppd[234]: Connection terminated.
    > > Jan 19 19:12:23 taco pppd[234]: Connect time 11.0 minutes.
    > > Jan 19 19:12:23 taco pppd[234]: Sent 7672 bytes, received 1070 bytes.
    > > Jan 19 19:12:24 taco pppd[234]: Exit.

    >
    > Are you supposed to supply the IP address you use for the PPP link?
    > Most ISPs provide dynamic IP address for both itself and the ISP client.
    >
    > You might try adding the noipdefault option and removing the pppd IP
    > address option, if it's in use, to see if that helps. It's not beyond
    > belief that an ISP would accept a client's IP address request even when
    > the IP address requested won't work.
    >
    > -- Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    > PPP-Q&A links, downloads: http://ckite.no-ip.net/
    > /* The signal-to-noise ratio is too low in many [news] groups to make
    > * them good candidates for archiving.
    > * --- Mike Moraes, Answers to FAQs about Usenet */




  5. Re: PPP connection problems - can anyone help?

    Adam wrote:
    > Thanks for your help. I tried your suggestions by adding 'novjccomp',
    > 'noipdefault', and 'asyncmap a0000' to the options file separately and none
    > of these fixed the problem. I should also clarify, I AM able to ping my own
    > address, but not the other end of the connection and anything beyond that.
    > I believe the problem might have something to do with routing. Here is the
    > '/etc/ppp/options' file and the result of 'route -n' after getting the
    > connection "up". I am a newbie so I could be doing something really stupid
    > in the network setup. If you could suggest the essentials for network setup
    > to make ppp work that might help. Thank you again for your assistance.


    > 'route -n'
    > Kernel IP routing table
    > Destination Gateway Genmask Flags Metric Ref Use
    > Iface
    > 142.150.128.46 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0


    Indeed, there is no default route.

    > 'options file' (comments removed for clarity)
    > -detach
    > asyncmap 0
    > auth
    > crtscts
    > lock
    > hide-password
    > noipdefault
    > debug
    > lcp-echo-interval 30
    > lcp-echo-failure 4


    Add the pppd defaultroute option. Note that pppd won't override an
    existing default route by adding one through the PPP interface, even
    with this option.

    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/
    /* I gave up on politics when no matter who I voted for, I regretted it.
    * -- Pepper...and Salt, WSJ */

  6. Re: PPP connection problems - can anyone help?

    Weathermon Adam Clifford writes:

    ]Are they any experts out there that can help? I am attempting to
    ]connect to an ISP via dialup in Debian. I open the connection in
    ]minicom give my user/pass info and start ppp, and then start the pppd
    ]daemon on my machine as root and it seems to connect fine, but I cannot
    ]ping the address of host given by pppd (or anywhere else). Here is the
    ]pppd debug information. As far as I've read on newsgroups, 'Can't
    ]locate module ppp-compress-21' and 'Cannot determine ethernet address
    ]for proxy ARP' are not the cause of the problem. Any help is much
    ]appreciated. Thank you,

    remove
    proxyarp
    from /etc/ppp/options and put in
    noccp
    defaultroute

    Post the output of
    ifconfig -a
    route -n

    If you have an ethernet card, put
    route del default
    into the end of rc.local (whereever Debian puts it)



    ]-A

    ]Jan 19 19:01:28 taco pppd[234]: pppd 2.4.1 started by root, uid 0
    ]Jan 19 19:01:28 taco pppd[234]: using channel 2
    ]Jan 19 19:01:28 taco pppd[234]: Using interface ppp0
    ]Jan 19 19:01:28 taco pppd[234]: Connect: ppp0 <--> /dev/ttyS3
    ]Jan 19 19:01:28 taco pppd[234]: sent [LCP ConfReq id=0x1
    ] ]
    ]Jan 19 19:01:28 taco pppd[234]: rcvd [LCP ConfReq id=0x3 ]0xa0000> ]
    ]Jan 19 19:01:28 taco pppd[234]: sent [LCP ConfAck id=0x3 ]0xa0000> ]
    ]Jan 19 19:01:28 taco pppd[234]: rcvd [LCP ConfReq id=0x4 ]0xa0000> ]
    ]Jan 19 19:01:28 taco pppd[234]: sent [LCP ConfAck id=0x4 ]0xa0000> ]
    ]Jan 19 19:01:28 taco pppd[234]: rcvd [LCP ConfAck id=0x1
    ] ]
    ]Jan 19 19:01:28 taco pppd[234]: sent [LCP EchoReq id=0x0
    ]magic=0xa278ff5]
    ]Jan 19 19:01:28 taco pppd[234]: kernel does not support PPP filtering
    ]Jan 19 19:01:28 taco pppd[234]: sent [IPCP ConfReq id=0x1
    ]]
    ]Jan 19 19:01:28 taco modprobe: modprobe: Can't locate module
    ]ppp-compress-21
    ]Jan 19 19:01:28 taco modprobe: modprobe: Can't locate module
    ]ppp-compress-21
    ]Jan 19 19:01:28 taco pppd[234]: sent [CCP ConfReq id=0x1
    ]]
    ]Jan 19 19:01:29 taco pppd[234]: rcvd [LCP EchoRep id=0x0
    ]magic=0xed8c21ee]
    ]Jan 19 19:01:29 taco pppd[234]: rcvd [IPCP ConfReq id=0x1 ]0f 00> ]
    ]Jan 19 19:01:29 taco pppd[234]: sent [IPCP ConfAck id=0x1 ]0f 00> ]
    ]Jan 19 19:01:29 taco pppd[234]: rcvd [IPCP ConfNak id=0x1 ]142.150.134.132>]
    ]Jan 19 19:01:29 taco pppd[234]: sent [IPCP ConfReq id=0x2 ]142.150.134.132> ]
    ]Jan 19 19:01:29 taco pppd[234]: rcvd [LCP ProtRej id=0x5 80 fd 01 01 00
    ]0c 1a 04 78 00 18 04 78 00]
    ]Jan 19 19:01:29 taco pppd[234]: rcvd [IPCP ConfAck id=0x2 ]142.150.134.132> ]
    ]Jan 19 19:01:29 taco pppd[234]: Cannot determine ethernet address for
    ]proxy ARP
    ]Jan 19 19:01:29 taco pppd[234]: local IP address 142.150.134.132
    ]Jan 19 19:01:29 taco pppd[234]: remote IP address 142.150.128.50
    ]Jan 19 19:01:29 taco pppd[234]: Script /etc/ppp/ip-up started (pid 239)
    ]Jan 19 19:01:29 taco pppd[234]: Script /etc/ppp/ip-up finished (pid
    ]239), status = 0x0
    ]Jan 19 19:01:58 taco pppd[234]: sent [LCP EchoReq id=0x1
    ]magic=0xa278ff5]
    ]Jan 19 19:01:58 taco pppd[234]: rcvd [LCP EchoRep id=0x1
    ]magic=0xed8c21ee]
    ]Jan 19 19:02:28 taco pppd[234]: sent [LCP EchoReq id=0x2
    ]magic=0xa278ff5]
    ]Jan 19 19:02:28 taco pppd[234]: rcvd [LCP EchoRep id=0x2
    ]magic=0xed8c21ee]
    ]Jan 19 19:02:58 taco pppd[234]: sent [LCP EchoReq id=0x3
    ]magic=0xa278ff5]
    ]Jan 19 19:02:58 taco pppd[234]: rcvd [LCP EchoRep id=0x3
    ]magic=0xed8c21ee]
    ]Jan 19 19:03:28 taco pppd[234]: sent [LCP EchoReq id=0x4
    ]magic=0xa278ff5]
    ]Jan 19 19:03:28 taco pppd[234]: rcvd [LCP EchoRep id=0x4
    ]magic=0xed8c21ee]
    ]Jan 19 19:03:58 taco pppd[234]: sent [LCP EchoReq id=0x5
    ]magic=0xa278ff5]
    ]Jan 19 19:03:58 taco pppd[234]: rcvd [LCP EchoRep id=0x5
    ]magic=0xed8c21ee]
    ]Jan 19 19:04:28 taco pppd[234]: sent [LCP EchoReq id=0x6
    ]magic=0xa278ff5]
    ]Jan 19 19:04:28 taco pppd[234]: rcvd [LCP EchoRep id=0x6
    ]magic=0xed8c21ee]
    ]Jan 19 19:04:58 taco pppd[234]: sent [LCP EchoReq id=0x7
    ]magic=0xa278ff5]
    ]Jan 19 19:04:59 taco pppd[234]: rcvd [LCP EchoRep id=0x7
    ]magic=0xed8c21ee]
    ]Jan 19 19:05:28 taco pppd[234]: sent [LCP EchoReq id=0x8
    ]magic=0xa278ff5]
    ]Jan 19 19:05:28 taco pppd[234]: rcvd [LCP EchoRep id=0x8
    ]magic=0xed8c21ee]
    ]Jan 19 19:05:58 taco pppd[234]: sent [LCP EchoReq id=0x9
    ]magic=0xa278ff5]
    ]Jan 19 19:05:58 taco pppd[234]: rcvd [LCP EchoRep id=0x9
    ]magic=0xed8c21ee]
    ]Jan 19 19:06:28 taco pppd[234]: sent [LCP EchoReq id=0xa
    ]magic=0xa278ff5]
    ]Jan 19 19:06:28 taco pppd[234]: rcvd [LCP EchoRep id=0xa
    ]magic=0xed8c21ee]
    ]Jan 19 19:06:58 taco pppd[234]: sent [LCP EchoReq id=0xb
    ]magic=0xa278ff5]
    ]Jan 19 19:06:58 taco pppd[234]: rcvd [LCP EchoRep id=0xb
    ]magic=0xed8c21ee]
    ]Jan 19 19:07:28 taco pppd[234]: sent [LCP EchoReq id=0xc
    ]magic=0xa278ff5]
    ]Jan 19 19:07:28 taco pppd[234]: rcvd [LCP EchoRep id=0xc
    ]magic=0xed8c21ee]
    ]Jan 19 19:07:58 taco pppd[234]: sent [LCP EchoReq id=0xd
    ]magic=0xa278ff5]
    ]Jan 19 19:07:58 taco pppd[234]: rcvd [LCP EchoRep id=0xd
    ]magic=0xed8c21ee]
    ]Jan 19 19:08:28 taco pppd[234]: sent [LCP EchoReq id=0xe
    ]magic=0xa278ff5]
    ]Jan 19 19:08:28 taco pppd[234]: rcvd [LCP EchoRep id=0xe
    ]magic=0xed8c21ee]
    ]Jan 19 19:08:58 taco pppd[234]: sent [LCP EchoReq id=0xf
    ]magic=0xa278ff5]
    ]Jan 19 19:08:58 taco pppd[234]: rcvd [LCP EchoRep id=0xf
    ]magic=0xed8c21ee]
    ]Jan 19 19:09:28 taco pppd[234]: sent [LCP EchoReq id=0x10
    ]magic=0xa278ff5]
    ]Jan 19 19:09:28 taco pppd[234]: rcvd [LCP EchoRep id=0x10
    ]magic=0xed8c21ee]
    ]Jan 19 19:09:58 taco pppd[234]: sent [LCP EchoReq id=0x11
    ]magic=0xa278ff5]
    ]Jan 19 19:09:58 taco pppd[234]: rcvd [LCP EchoRep id=0x11
    ]magic=0xed8c21ee]
    ]Jan 19 19:10:28 taco pppd[234]: sent [LCP EchoReq id=0x12
    ]magic=0xa278ff5]
    ]Jan 19 19:10:29 taco pppd[234]: rcvd [LCP EchoRep id=0x12
    ]magic=0xed8c21ee]

  7. Re: PPP connection problems - can anyone help?

    "Adam" writes:

    ]Thanks for your help. I tried your suggestions by adding 'novjccomp',
    ]'noipdefault', and 'asyncmap a0000' to the options file separately and none
    ]of these fixed the problem. I should also clarify, I AM able to ping my own
    ]address, but not the other end of the connection and anything beyond that.
    ]I believe the problem might have something to do with routing. Here is the
    ]'/etc/ppp/options' file and the result of 'route -n' after getting the
    ]connection "up". I am a newbie so I could be doing something really stupid
    ]in the network setup. If you could suggest the essentials for network setup
    ]to make ppp work that might help. Thank you again for your assistance.

    ]'route -n'
    ]Kernel IP routing table
    ]Destination Gateway Genmask Flags Metric Ref Use
    ]Iface
    ]142.150.128.46 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
    Where did this come from? this is not the addess of the remote host.
    (see below)
    What is it the address of?


    ]'options file' (comments removed for clarity)
    ]-detach
    ]asyncmap 0

    As Kite said, make that asyncmap a0000
    ]auth

    Get rid of the auth.

    ]crtscts
    ]lock
    ]hide-password
    ]noipdefault
    ]debug
    Get rid of the below.
    ]lcp-echo-interval 30
    ]lcp-echo-failure 4

    Add
    defaultroute



    ]> > Jan 19 19:01:29 taco pppd[234]: local IP address 142.150.134.132
    ]> > Jan 19 19:01:29 taco pppd[234]: remote IP address 142.150.128.50

  8. Re: PPP connection problems - can anyone help?

    Ah i wish it was that simple. Added defaultroute and still no response to
    pinging beyond my own machine. I'm going to post the result of 'route -n'
    and 'ifconfig -a' once i've 'connected'. I've tried every suggested change
    in ppp options to no avail. People have suggested ip filtering, but i don't
    even have it installed in my kernel (iptables isn't there).

    'options'
    defaultroute
    -detach
    asyncmap a0000
    crtscts
    lock
    hide-password
    noipdefault
    debug

    'route -n'
    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref Use
    Iface
    142.150.128.47 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
    0.0.0.0 142.150.128.47 0.0.0.0 UG 0 0 0 ppp0

    'ifconfig -a'
    eth0 Link encap:Ethernet HWaddr 00:C0:A8:47:F7:85
    BROADCAST NOARP MULTICAST MTU:1500 Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:0 errors:1 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:100
    RX bytes:0 (0.0 b) TX bytes:684 (684.0 b)
    Interrupt:9 Base address:0x300

    lo Link encap:Local Loopback
    inet addr:127.0.0.1 Mask:255.0.0.0
    UP LOOPBACK RUNNING MTU:16436 Metric:1
    RX packets:14 errors:0 dropped:0 overruns:0 frame:0
    TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:1252 (1.2 KiB) TX bytes:1252 (1.2 KiB)

    ppp0 Link encap:Point-to-Point Protocol
    inet addr:142.150.134.89 P-t-P:142.150.128.47
    Mask:255.255.255.255
    UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
    RX packets:3 errors:1 dropped:0 overruns:0 frame:0
    TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:3
    RX bytes:42 (42.0 b) TX bytes:48 (48.0 b)

    tunl0 Link encap:IPIP Tunnel HWaddr
    NOARP MTU:1480 Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)


    "Clifford Kite" wrote in message
    news:3o4pub.oa1.ln@corncob.localhost.tld...
    > Adam wrote:
    > > Thanks for your help. I tried your suggestions by adding 'novjccomp',
    > > 'noipdefault', and 'asyncmap a0000' to the options file separately and

    none
    > > of these fixed the problem. I should also clarify, I AM able to ping my

    own
    > > address, but not the other end of the connection and anything beyond

    that.
    > > I believe the problem might have something to do with routing. Here is

    the
    > > '/etc/ppp/options' file and the result of 'route -n' after getting the
    > > connection "up". I am a newbie so I could be doing something really

    stupid
    > > in the network setup. If you could suggest the essentials for network

    setup
    > > to make ppp work that might help. Thank you again for your assistance.

    >
    > > 'route -n'
    > > Kernel IP routing table
    > > Destination Gateway Genmask Flags Metric Ref Use
    > > Iface
    > > 142.150.128.46 0.0.0.0 255.255.255.255 UH 0 0 0

    ppp0
    >
    > Indeed, there is no default route.
    >
    > > 'options file' (comments removed for clarity)
    > > -detach
    > > asyncmap 0
    > > auth
    > > crtscts
    > > lock
    > > hide-password
    > > noipdefault
    > > debug
    > > lcp-echo-interval 30
    > > lcp-echo-failure 4

    >
    > Add the pppd defaultroute option. Note that pppd won't override an
    > existing default route by adding one through the PPP interface, even
    > with this option.
    >
    > --
    > Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    > PPP-Q&A links, downloads: http://ckite.no-ip.net/
    > /* I gave up on politics when no matter who I voted for, I regretted it.
    > * -- Pepper...and Salt, WSJ */




  9. Re: PPP connection problems - can anyone help?

    "Adam" writes:
    > Ah i wish it was that simple. Added defaultroute and still no response to
    > pinging beyond my own machine. I'm going to post the result of 'route -n'
    > and 'ifconfig -a' once i've 'connected'. I've tried every suggested change
    > in ppp options to no avail. People have suggested ip filtering, but i don't
    > even have it installed in my kernel (iptables isn't there).


    All those bits look good. Have you checked name services?

    What happens if you do "ping -n" instead of "ping"?

    --
    James Carlson, IP Systems Group
    Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

  10. Re: PPP connection problems - can anyone help?

    Okay, you do need the defaultroute option, but now back to square one.

    Weathermon Adam Clifford wrote:
    > Are they any experts out there that can help? I am attempting to
    > connect to an ISP via dialup in Debian. I open the connection in
    > minicom give my user/pass info and start ppp, and then start the pppd
    > daemon on my machine as root and it seems to connect fine, but I cannot
    > ping the address of host given by pppd (or anywhere else). Here is the
    > pppd debug information. As far as I've read on newsgroups, 'Can't
    > locate module ppp-compress-21' and 'Cannot determine ethernet address
    > for proxy ARP' are not the cause of the problem. Any help is much
    > appreciated. Thank you,


    > -A


    Are you sure that connecting to the ISP via minicom, entering your
    name and password, and then starting pppd is appropriate? Not many
    ISPs allow login/password for a PPP link now, they usually expect to
    do client authentication with PAP or CHAP during PPP negotiations.

    > Jan 19 19:01:28 taco pppd[234]: pppd 2.4.1 started by root, uid 0
    > Jan 19 19:01:28 taco pppd[234]: using channel 2
    > Jan 19 19:01:28 taco pppd[234]: Using interface ppp0
    > Jan 19 19:01:28 taco pppd[234]: Connect: ppp0 <--> /dev/ttyS3
    > Jan 19 19:01:28 taco pppd[234]: sent [LCP ConfReq id=0x1
    > ]
    > Jan 19 19:01:28 taco pppd[234]: rcvd [LCP ConfReq id=0x3 > 0xa0000> ]

    ...

    > Jan 19 19:01:29 taco pppd[234]: local IP address 142.150.134.132
    > Jan 19 19:01:29 taco pppd[234]: remote IP address 142.150.128.50
    > Jan 19 19:01:29 taco pppd[234]: Script /etc/ppp/ip-up started (pid 239)
    > Jan 19 19:01:29 taco pppd[234]: Script /etc/ppp/ip-up finished (pid
    > 239), status = 0x0


    Riddle me this: How can you complete asynchronous PPP link negotiations
    over a landline within one second of starting pppd? That's amazing to
    me, if true.

    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/

  11. Re: PPP connection problems - can anyone help?


    "Clifford Kite" wrote in message
    news:8h1sub.992.ln@corncob.localhost.tld...
    > Okay, you do need the defaultroute option, but now back to square one.
    >
    > Weathermon Adam Clifford wrote:
    > > Are they any experts out there that can help? I am attempting to
    > > connect to an ISP via dialup in Debian. I open the connection in
    > > minicom give my user/pass info and start ppp, and then start the pppd
    > > daemon on my machine as root and it seems to connect fine, but I cannot
    > > ping the address of host given by pppd (or anywhere else). Here is the
    > > pppd debug information. As far as I've read on newsgroups, 'Can't
    > > locate module ppp-compress-21' and 'Cannot determine ethernet address
    > > for proxy ARP' are not the cause of the problem. Any help is much
    > > appreciated. Thank you,

    >
    > > -A

    >
    > Are you sure that connecting to the ISP via minicom, entering your
    > name and password, and then starting pppd is appropriate? Not many
    > ISPs allow login/password for a PPP link now, they usually expect to
    > do client authentication with PAP or CHAP during PPP negotiations.
    >

    I was following the step by step instructions in the PPP-HOWTO. I tried
    running wvdial, and what happened was that it logged in correctly with the
    username/password, but entered 'ppp' instead of 'ppp default' which is what
    my ISP requires and hence, never worked. My ISP claims the login procedure
    is to dial up, enter user/pass, and then enter 'ppp default' at the prompt,
    and then "start surfing". I assume that I have to initiate ppp on the
    remote machine and then start pppd on my own machine (seems to be what is in
    the PPP-HOWTO). I assume the authentication is me entering my
    username/password to begin with. But i could be wrong but nowhere is
    PAP/CHAP mentioned. I just want to do it manually and then automate it
    using chat.

    > > Jan 19 19:01:28 taco pppd[234]: pppd 2.4.1 started by root, uid 0
    > > Jan 19 19:01:28 taco pppd[234]: using channel 2
    > > Jan 19 19:01:28 taco pppd[234]: Using interface ppp0
    > > Jan 19 19:01:28 taco pppd[234]: Connect: ppp0 <--> /dev/ttyS3
    > > Jan 19 19:01:28 taco pppd[234]: sent [LCP ConfReq id=0x1
    > > ]
    > > Jan 19 19:01:28 taco pppd[234]: rcvd [LCP ConfReq id=0x3 > > 0xa0000> ]

    > ...
    >
    > > Jan 19 19:01:29 taco pppd[234]: local IP address 142.150.134.132
    > > Jan 19 19:01:29 taco pppd[234]: remote IP address 142.150.128.50
    > > Jan 19 19:01:29 taco pppd[234]: Script /etc/ppp/ip-up started (pid 239)
    > > Jan 19 19:01:29 taco pppd[234]: Script /etc/ppp/ip-up finished (pid
    > > 239), status = 0x0

    >
    > Riddle me this: How can you complete asynchronous PPP link negotiations
    > over a landline within one second of starting pppd? That's amazing to
    > me, if true.


    Is this not what would be expected? and if so, what would it indicate? I'm
    a newbie here so anything that is obvious is probably clear as mud to me.
    It seems that once i run PPPD the link is set up 'very' fast (1 sec as you
    observed). Does alot of data need to be exchanged? I hadn't thought that
    it would need very long to set up.

    >
    > --
    > Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    > PPP-Q&A links, downloads: http://ckite.no-ip.net/




  12. Re: PPP connection problems - can anyone help?

    Adam wrote:

    > "Clifford Kite" wrote in message
    > news:8h1sub.992.ln@corncob.localhost.tld...
    >>
    >> Are you sure that connecting to the ISP via minicom, entering your
    >> name and password, and then starting pppd is appropriate? Not many
    >> ISPs allow login/password for a PPP link now, they usually expect to
    >> do client authentication with PAP or CHAP during PPP negotiations.
    >>

    > I was following the step by step instructions in the PPP-HOWTO. I tried
    > running wvdial, and what happened was that it logged in correctly with the
    > username/password, but entered 'ppp' instead of 'ppp default' which is what
    > my ISP requires and hence, never worked. My ISP claims the login procedure
    > is to dial up, enter user/pass, and then enter 'ppp default' at the prompt,
    > and then "start surfing". I assume that I have to initiate ppp on the
    > remote machine and then start pppd on my own machine (seems to be what is in
    > the PPP-HOWTO). I assume the authentication is me entering my
    > username/password to begin with. But i could be wrong but nowhere is
    > PAP/CHAP mentioned. I just want to do it manually and then automate it
    > using chat.


    If the ISP says that's the way to authenticate then it's surprising but
    not wrong. You seem to be doing exactly the right thing and are correct
    in your assumptions as to what is happening.

    ....

    >> Riddle me this: How can you complete asynchronous PPP link negotiations
    >> over a landline within one second of starting pppd? That's amazing to
    >> me, if true.


    > Is this not what would be expected? and if so, what would it indicate? I'm
    > a newbie here so anything that is obvious is probably clear as mud to me.
    > It seems that once i run PPPD the link is set up 'very' fast (1 sec as you
    > observed). Does alot of data need to be exchanged? I hadn't thought that
    > it would need very long to set up.


    Sometimes I fail to look before I leap. Checking back through my log
    files, it looks like it could well be under one second. The logs here
    show that it usually takes pppd no more than 2 seconds, but up to as
    many as 5 seconds on occasion, to establish a link. That includes
    PAP authentication and some negotiations to change what's requested on
    each side. If there aren't many negotiations for change (both sides
    accept everything the other requests) then perhaps the duration could
    easily be consistently in the neighborhood of one second or less.

    I've assumed that failure to ping by IP addresses was also accompanied
    by failure to access sites in any other way, e.g., web browsing. Is that
    so? As I said in the coln thread, if the connection host blocks ping
    requests then it won't send a ping reply and no ping will get past it
    to any other host beyond. The reason I ask is that there is both
    outgoing and incoming traffic through the PPP interface:

    Jan 19 19:12:23 taco pppd[234]: Sent 7672 bytes, received 1070 bytes

    It's not the LCP echo-requests, those are not recorded by the interface.
    However, it could be the outgoing ping requests and incoming IPCP "error"
    messages that say the ping requests are denied.

    If you ping then you can use

    tcpdump -x -s 38 'icmp[icmptype] = icmp-echo or \
    icmp[icmptype] = icmp-echoreply' -i ppp0

    to find out what type and code any incoming ICMP messages have. The last
    group of 4 hex digits of the tcpdump output will tell you type and code,
    respectively. The ping requests are type 8, code 0 (0800), and if ping
    requests are denied but not dropped, then there should be incoming ICMP
    messages of type 3, code x (030x).

    What message, if any, does ping generate when you ping the IP address
    of the ISP connection host and fail to get a reply?

    If there is no message then how long does it hang, a short time, a period
    of several minutes, or seemingly forever?

    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/

  13. Re: PPP connection problems - can anyone help?

    Problem is solved. It would seem that the remote machine ignores pings, but
    otherwise works fine. When I fired up my browser, everything worked fine.
    Store that under the "things to try before assuming it doesn't work"
    category. On the plus side I've learned alot about PPP and I hope i haven't
    wasted too much of your time. I appreciate everyone's effort in sharing
    their knowledge, and when I have questions about PPPoE i'll post them here
    (after checking things more carefully)

    cheers
    Adam



    "Clifford Kite" wrote in message
    newsgiuub.8q4.ln@corncob.localhost.tld...
    > Adam wrote:
    >
    > > "Clifford Kite" wrote in message
    > > news:8h1sub.992.ln@corncob.localhost.tld...
    > >>
    > >> Are you sure that connecting to the ISP via minicom, entering your
    > >> name and password, and then starting pppd is appropriate? Not many
    > >> ISPs allow login/password for a PPP link now, they usually expect to
    > >> do client authentication with PAP or CHAP during PPP negotiations.
    > >>

    > > I was following the step by step instructions in the PPP-HOWTO. I tried
    > > running wvdial, and what happened was that it logged in correctly with

    the
    > > username/password, but entered 'ppp' instead of 'ppp default' which is

    what
    > > my ISP requires and hence, never worked. My ISP claims the login

    procedure
    > > is to dial up, enter user/pass, and then enter 'ppp default' at the

    prompt,
    > > and then "start surfing". I assume that I have to initiate ppp on the
    > > remote machine and then start pppd on my own machine (seems to be what

    is in
    > > the PPP-HOWTO). I assume the authentication is me entering my
    > > username/password to begin with. But i could be wrong but nowhere is
    > > PAP/CHAP mentioned. I just want to do it manually and then automate it
    > > using chat.

    >
    > If the ISP says that's the way to authenticate then it's surprising but
    > not wrong. You seem to be doing exactly the right thing and are correct
    > in your assumptions as to what is happening.
    >
    > ...
    >
    > >> Riddle me this: How can you complete asynchronous PPP link

    negotiations
    > >> over a landline within one second of starting pppd? That's amazing to
    > >> me, if true.

    >
    > > Is this not what would be expected? and if so, what would it indicate?

    I'm
    > > a newbie here so anything that is obvious is probably clear as mud to

    me.
    > > It seems that once i run PPPD the link is set up 'very' fast (1 sec as

    you
    > > observed). Does alot of data need to be exchanged? I hadn't thought

    that
    > > it would need very long to set up.

    >
    > Sometimes I fail to look before I leap. Checking back through my log
    > files, it looks like it could well be under one second. The logs here
    > show that it usually takes pppd no more than 2 seconds, but up to as
    > many as 5 seconds on occasion, to establish a link. That includes
    > PAP authentication and some negotiations to change what's requested on
    > each side. If there aren't many negotiations for change (both sides
    > accept everything the other requests) then perhaps the duration could
    > easily be consistently in the neighborhood of one second or less.
    >
    > I've assumed that failure to ping by IP addresses was also accompanied
    > by failure to access sites in any other way, e.g., web browsing. Is that
    > so? As I said in the coln thread, if the connection host blocks ping
    > requests then it won't send a ping reply and no ping will get past it
    > to any other host beyond. The reason I ask is that there is both
    > outgoing and incoming traffic through the PPP interface:
    >
    > Jan 19 19:12:23 taco pppd[234]: Sent 7672 bytes, received 1070 bytes
    >
    > It's not the LCP echo-requests, those are not recorded by the interface.
    > However, it could be the outgoing ping requests and incoming IPCP "error"
    > messages that say the ping requests are denied.
    >
    > If you ping then you can use
    >
    > tcpdump -x -s 38 'icmp[icmptype] = icmp-echo or \
    > icmp[icmptype] = icmp-echoreply' -i ppp0
    >
    > to find out what type and code any incoming ICMP messages have. The last
    > group of 4 hex digits of the tcpdump output will tell you type and code,
    > respectively. The ping requests are type 8, code 0 (0800), and if ping
    > requests are denied but not dropped, then there should be incoming ICMP
    > messages of type 3, code x (030x).
    >
    > What message, if any, does ping generate when you ping the IP address
    > of the ISP connection host and fail to get a reply?
    >
    > If there is no message then how long does it hang, a short time, a period
    > of several minutes, or seemingly forever?
    >
    > --
    > Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    > PPP-Q&A links, downloads: http://ckite.no-ip.net/




+ Reply to Thread