hopefully simple ppp dns or routing problem on Slack 9.1

Walt R wrote:
> [snip]
> **
>
> Here is the output of my route -n and ifconfig -a
>
> root@wmr_srv01:~ # route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 69.19.219.148 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
> 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
> 0.0.0.0 69.19.219.148 0.0.0.0 UG 0 0 0 ppp0
>
> It looks like you are connected to the modem, but not to the server.

I don't know the IP address of the server/gateway/router at my ISP.
Presumably, my default route (for ppp0 -- I think the way it works
is that there's a default route for each net connection) gets set by
pppd when the dialup connection gets made. I'm a little fuzzy on that,
but learning.

> you are missing the IP address on the ppp0 interface.
>
>
> root@wmr_srv01:~ # ifconfig -a
> 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:30 errors:0 dropped:0 overruns:0 frame:0
> TX packets:30 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:1500 (1.4 Kb) TX bytes:1500 (1.4 Kb)
>
> ppp0 Link encap:Point-to-Point Protocol
> inet addr:66.81.27.54 P-t-P:69.19.219.148 Mask:255.255.255.255
> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1524 Metric:1
> RX packets:1724 errors:0 dropped:0 overruns:0 frame:0
> TX packets:1274 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:3
> RX bytes:1757393 (1.6 Mb) TX bytes:284191 (277.5 Kb)
>
> Have you uncommented the debug in the /etc/ppp/options script?
> This will give you extensive error messages.

I have, but they weren't as extensive as I'd hoped! :)

> Walt R.

John Gabriele <john3gz@bestwebz.net> wrote:

> One thing to note is how my ISP requires that I use my email address
> (username plus their domain name) to login with. Though, not sure
> if that might be an issue here.

What does "login with" mean? Do you *really* mean a login at a login
prompt? If so then it is certainly an issue.

I've been assuming, until just now, that you would do PAP or CHAP
authentication within the PPP negotiations - without actually logging
in. Even if you are required to do both it is an issue. In order to
do an actual login at a prompt you have to configure chat to do it, and
there is no sign in the chat messages that you try do an actual login.

If the ISP is waiting at a prompt for a login/password then that could
explain why it never starts PPP negotiation. I don't have a ppp-go
or /etc/ppp/pppscript but do have ppp-on and /etc/ppp/ppp-on-dialer.
Those scripts *are* configured to login at a prompt. But these daze
they don't get used much since most ISPs do PAP or CHAP authentication
instead of logging in. The "name john3gz@bestwebz.net" is *not* used
for logging in at a prompt, and, except for some special cases, any PAP
or CHAP authentication should use "user john3gz@bestwebz.net" instead.

After thinking about this, and going back to the beginning of the post,
it seems that

Hm? Everything seems to end just fine when I run /usr/sbin/ppp-off.
That line above that says "Terminating on signal 2." is what happens
when I run ppp-off.

implies that the ISP was waiting for a prompt when you terminated pppd.

Have the /etc/ppp/{pap,chap}-secrets files been configured? They need
to be if either PAP or CHAP is used. But you've never reached that stage
in PPP negotiations so we can't tell. One thing is certain, you have
to authenticate yourself to the ISP some way.

> Oh, and that character after CONNECT in my pppscript was just a space.
> I removed it. No change.

Gimmie a break! Have you or have you not tried

CONNECT \d\c

as the last chat expect-send in /etc/ppp/pppscript?

> I'm still reading Bill's "How to Hook up PPP in Linux" doc.

It's almost certainly the best available on the web.

-- Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* "PPPoE has many advantages for DSL service providers, and
practically none for DSL consumers."
- David F. Skoll */

Clifford Kite wrote:

> John Gabriele <john3gz@bestwebz.net> wrote:
>
>
>>One thing to note is how my ISP requires that I use my email address
>>(username plus their domain name) to login with. Though, not sure
>>if that might be an issue here.
>
>
> What does "login with" mean? Do you *really* mean a login at a login
> prompt? If so then it is certainly an issue.

No. Once again, I'm sorry for the sloppy language. My ISP said,
"We use PAP. Use your username plus "@bestweb.net" to get
authenticated". I don't have any sort of interactive prompt
where I'd have to type in anything.

> I've been assuming, until just now, that you would do PAP or CHAP
> authentication within the PPP negotiations

Right.

> - without actually logging
> in.

Again, my fault for the confusion.

> Even if you are required to do both it is an issue.

Nope. Not required to do any sort of manual scripted logging in
to get connected to the net.

> In order to
> do an actual login at a prompt you have to configure chat to do it, and
> there is no sign in the chat messages that you try do an actual login.
>
> If the ISP is waiting at a prompt for a login/password then that could
> explain why it never starts PPP negotiation.

Well, their tech support guy got back to me via email and said
it's PAP.

> I don't have a ppp-go
> or /etc/ppp/pppscript but do have ppp-on and /etc/ppp/ppp-on-dialer.
> Those scripts *are* configured to login at a prompt. But these daze
> they don't get used much since most ISPs do PAP or CHAP authentication
> instead of logging in. The "name john3gz@bestwebz.net" is *not* used
> for logging in at a prompt, and, except for some special cases, any PAP
> or CHAP authentication should use "user john3gz@bestwebz.net" instead.

The reason (so they tell me) that they require the whole name plus
domain name is that they use some third-party folks (Aleron and
MegaPOP) for me to dial in to. Say, Aleron uses the "@bestweb.net"
so they know who to pass the authentication on to.

The Aleron dialup server then passes my "john3gz@bestwebz.net" to
the bestweb server (I guess it's just some sort of "authentication
server") which then authenticates me to be part of bestweb's net.

> After thinking about this, and going back to the beginning of the post,
> it seems that
>
> Hm? Everything seems to end just fine when I run /usr/sbin/ppp-off.
> That line above that says "Terminating on signal 2." is what happens
> when I run ppp-off.
>
> implies that the ISP was waiting for a prompt when you terminated pppd.

That sounds reasonable. If I sit there and do nothing, after a while
it'll disconnect me.

> Have the /etc/ppp/{pap,chap}-secrets files been configured?

Yes. The pppsetup program does this. My pap-secrets file says:

# PAP authentication file: /etc/ppp/pap-secrets
# This file should have a permission of 600.
# ~# chmod 600 /etc/ppp/pap-secrets
# Username Server Password IP addresses
"john3gz@bestwebz.net" * "not_real_password"

The permissions are set as directed.

> They need
> to be if either PAP or CHAP is used. But you've never reached that stage
> in PPP negotiations so we can't tell. One thing is certain, you have
> to authenticate yourself to the ISP some way.
>
>
>>Oh, and that character after CONNECT in my pppscript was just a space.
>>I removed it. No change.
>
>
> Gimmie a break!

Huh? I'm sorry -- I'm trying to follow your directions as closely
as possible. :)

> Have you or have you not tried
>
> CONNECT \d\c
>
> as the last chat expect-send in /etc/ppp/pppscript?

That's what I was asking you about in a previous post. I'd written:

|
| > [snip]
| >
| > The very last part of the chat configuration should read
| >
| > CONNECT \d\c
| >
| > or similar. Double escapes if on the chat command line.
| >
| > Not doing this could be causing the problem since otherwise, with some
| > ISPs, you might get a login prompt or menu that ignores pppd's attempt
| > at starting LCP negotiations.
| >
|
| ???
|
| Hmm... this could be something. My /etc/ppp/pppscript just ends with that
| one CONNECT line. There's nothing funny after it. I've tried with and without
| a newline after it, but it (thankfully :) doesn't seem to make a difference.
| (Note -- I've been on a software project where a module was bombing because
| of an extra newline at the end of a config file. Yikes.)
|
| Wait... I think there's a space character after the word CONNECT. Ack, now
| how do I get vim to show me this file in hex...

I didn't understand what you meant by: "or similar. Double escapes if on the
chat command line." so I replied with the "???" and some more explanatory notes.

I'll try just the backslash dee backslash cee, though I'm guessing you meant
something else that I didn't grasp.

[time passes during my attempt]

Nope. No joy. My ppplog just comes out looking like:

Apr 23 22:49:31 avocado chat[1472]: expect (OK)
Apr 23 22:49:31 avocado chat[1472]: AT&FH0^M^M
Apr 23 22:49:31 avocado chat[1472]: OK
Apr 23 22:49:31 avocado chat[1472]: -- got it
Apr 23 22:49:31 avocado chat[1472]: send (atdt6632166^M)
Apr 23 22:49:32 avocado chat[1472]: timeout set to 75 seconds
Apr 23 22:49:32 avocado chat[1472]: expect (CONNECT)
Apr 23 22:49:32 avocado chat[1472]: ^M
Apr 23 22:49:59 avocado chat[1472]: atdt6632166^M^M
Apr 23 22:49:59 avocado chat[1472]: CONNECT
Apr 23 22:49:59 avocado chat[1472]: -- got it
Apr 23 22:49:59 avocado chat[1472]: send (\d)
Apr 23 22:50:00 avocado pppd[1469]: Serial connection established.
Apr 23 22:50:00 avocado pppd[1469]: using channel 1
Apr 23 22:50:00 avocado pppd[1469]: Using interface ppp0
Apr 23 22:50:00 avocado pppd[1469]: Connect: ppp0 <--> /dev/modem
Apr 23 22:50:01 avocado pppd[1469]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x5a0ca80d> <pcomp>
<accomp>]Apr 23 22:50:29 avocado last message repeated 9 times
Apr 23 22:50:32 avocado pppd[1469]: LCP: timeout sending Config-Requests
Apr 23 22:51:00 avocado pppd[1469]: Terminating on signal 2.
Apr 23 22:51:00 avocado pppd[1469]: Connection terminated.
Apr 23 22:51:01 avocado pppd[1469]: Exit.

---J

John Gabriele <john3gz@bestwebz.net> wrote:
> Clifford Kite wrote:

....

>> Have you or have you not tried
>>
>> CONNECT \d\c
>>
>> as the last chat expect-send in /etc/ppp/pppscript?

> That's what I was asking you about in a previous post. I'd written:

> |
> | > [snip]
> | >
> | > The very last part of the chat configuration should read
> | >
> | > CONNECT \d\c
> | >
> | > or similar. Double escapes if on the chat command line.

Admittedly poorly worded. :/ If your command line for pppd was, say,

pppd <pppd options> connect "chat -v <modem related stuff> <expect-sends>"

then the last expect-send should be CONNECT \\d\\c not CONNECT \d\c .

....

> Nope. No joy. My ppplog just comes out looking like:

> Apr 23 22:49:31 avocado chat[1472]: expect (OK)
> Apr 23 22:49:31 avocado chat[1472]: AT&FH0^M^M
> Apr 23 22:49:31 avocado chat[1472]: OK
> Apr 23 22:49:31 avocado chat[1472]: -- got it
> Apr 23 22:49:31 avocado chat[1472]: send (atdt6632166^M)
> Apr 23 22:49:32 avocado chat[1472]: timeout set to 75 seconds
> Apr 23 22:49:32 avocado chat[1472]: expect (CONNECT)
> Apr 23 22:49:32 avocado chat[1472]: ^M
> Apr 23 22:49:59 avocado chat[1472]: atdt6632166^M^M
> Apr 23 22:49:59 avocado chat[1472]: CONNECT
> Apr 23 22:49:59 avocado chat[1472]: -- got it
> Apr 23 22:49:59 avocado chat[1472]: send (\d)
^^^^^^^^^
This is the send I expected.

> Apr 23 22:50:00 avocado pppd[1469]: Serial connection established.
> Apr 23 22:50:00 avocado pppd[1469]: using channel 1
> Apr 23 22:50:00 avocado pppd[1469]: Using interface ppp0
> Apr 23 22:50:00 avocado pppd[1469]: Connect: ppp0 <--> /dev/modem
> Apr 23 22:50:01 avocado pppd[1469]: sent [LCP ConfReq id=0x1 <asyncmap
> 0x0> <magic 0x5a0ca80d> <pcomp> <accomp>]

Note the one second delay between "Connect .." and "sent .." that \d
introduces.

> Apr 23 22:50:29 avocado last message repeated 9 times
> Apr 23 22:50:32 avocado pppd[1469]: LCP: timeout sending Config-Requests
> Apr 23 22:51:00 avocado pppd[1469]: Terminating on signal 2.
> Apr 23 22:51:00 avocado pppd[1469]: Connection terminated.
> Apr 23 22:51:01 avocado pppd[1469]: Exit.

Indeed, no joy. Sigh.

The times between events (from the timestamps) look right and the serial
device file seems to be configured with the correct IRQ.

Everything points to the ISP not starting PPP and waiting for something
from you to cause it to do so. Yet you seem to have a good rapport with
the ISP, and it said to use PAP to authenticate, but with no mention of
anything else. I don't really believe configuring pppd to send more LCP
requests or using the "passive" option will help. But try them if you
like.

The only thing I can think to do now is use minicom to dial in and see
what, if anything, the ISP displays. A desperation measure. :(

-- 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 */

Clifford Kite wrote:


>
> The only thing I can think to do now is use minicom to dial in and see
> what, if anything, the ISP displays. A desperation measure. :(
>

Thanks for all the help Cliff (and Bill, if you're still reading :).
I'm going to try a few more things, google around a bit more, and maybe
contact a few folks. If I ever get this thing working, you and Bill will
be the first folks I tell about it! :)

---J
--- remove zees if contacting via email ---

John Gabriele wrote:
> Clifford Kite wrote:
>
>
>>
>> The only thing I can think to do now is use minicom to dial in and see
>> what, if anything, the ISP displays. A desperation measure. :(
>>
>
> Thanks for all the help Cliff (and Bill, if you're still reading :).
> I'm going to try a few more things, google around a bit more, and maybe
> contact a few folks. If I ever get this thing working, you and Bill will
> be the first folks I tell about it! :)
>
> ---J
> --- remove zees if contacting via email ---
>

EPILOGUE

I spoke with my ISP's tech support again. The fellow said that you can
use a login chat script method of logging in when you dial up, or else
you can use PAP. You dial the same telephone number for both. I asked
him how the other end knows whether I'm using a login script or PAP,
but he didn't know the answer (and wasn't interested in finding out).

Well, unfortunately, that was it. I really needed to just get back to
work. Since the Slackware install was very recent, I pulled out my
Redhat 9 ("Shrike") CD set and wiped the whole thing, installing RH9.

RH9 comes with some redhat-config-* internet setup wizard that helps
you get set up right away with a simple point-and-drool interface :) .

Turns out that it was confused a bit (maybe the Fedora folks have fixed
it by now) and was insisting on using its own seemingly random dns
addresses in a 2nd (2nd to /etc/resolv.conf) resolv.conf located in
/etc/ppp. After changing those first in the GUI network wizard and then
manually, DNS was working and everything was fine.

Moral? Dunno. Maybe my Slack install had some corrupted file. Maybe
I was making some obvious mistake that never got uncovered in this
discussion thread. Maybe Slack's ppp integration needed more testing.
Anyway, I'm back online with a GNU/Linux setup and getting my work
done again. I also plan on having a look at the next Fedora release.

Thanks.
---J

John Gabriele <john3gz@bestwebz.net> wrote:

> EPILOGUE

> I spoke with my ISP's tech support again. The fellow said that you can
> use a login chat script method of logging in when you dial up, or else
> you can use PAP. You dial the same telephone number for both. I asked
> him how the other end knows whether I'm using a login script or PAP,
> but he didn't know the answer (and wasn't interested in finding out).

No surprise. The usually the answer is to use login/password you
configure chat to do it. If you don't use login/password then make
sure chat doesn't send anything, including a carriage-return, after
getting CONNECT, and that pppd starts PPP negotiations right away.
The ISP then recognizes that PPP negotiation is started by the client,
and starts PPP at it's end.

Here I just don't know what was causing the problem.

> Well, unfortunately, that was it. I really needed to just get back to
> work. Since the Slackware install was very recent, I pulled out my
> Redhat 9 ("Shrike") CD set and wiped the whole thing, installing RH9.

> RH9 comes with some redhat-config-* internet setup wizard that helps
> you get set up right away with a simple point-and-drool interface :) .

> Turns out that it was confused a bit (maybe the Fedora folks have fixed
> it by now) and was insisting on using its own seemingly random dns
> addresses in a 2nd (2nd to /etc/resolv.conf) resolv.conf located in
> /etc/ppp. After changing those first in the GUI network wizard and then
> manually, DNS was working and everything was fine.

The /etc/ppp/resolv.conf is created and DNS server IP addresses received
from the ISP put in it by pppd when the pppd option usepeerdns is used.
Some distributions (notable RH) use the file to configure /etc/resolv.conf,
perhaps by "mv"ing each new/etc/ppp/resolv.conf to /etc, or linking it
to /etc/resolv.conf .

> Moral? Dunno. Maybe my Slack install had some corrupted file. Maybe
> I was making some obvious mistake that never got uncovered in this
> discussion thread. Maybe Slack's ppp integration needed more testing.
> Anyway, I'm back online with a GNU/Linux setup and getting my work
> done again. I also plan on having a look at the next Fedora release.

Glad to hear you are back on-line, but surprised that RH could get PPP
working with it's GUI configuration tool and regret that you abandoned
Slackware. As always, sometimes it's "whatever works."

-- Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* Editing with vi is a lot better than using a huge swiss army knife.
Use =} to wrap paragraphs in vi. Or put map ^] !}fmt -72^M in
~/.exrc and use ^] to wrap to 72 columns or whatever you choose. */

Clifford Kite wrote:
> John Gabriele <john3gz@bestwebz.net> wrote:
>
>
>>Turns out that it was confused a bit (maybe the Fedora folks have fixed
>>it by now) and was insisting on using its own seemingly random dns
>>addresses in a 2nd (2nd to /etc/resolv.conf) resolv.conf located in
>>/etc/ppp. After changing those first in the GUI network wizard and then
>>manually, DNS was working and everything was fine.
>
>
> The /etc/ppp/resolv.conf is created and DNS server IP addresses received
> from the ISP put in it by pppd when the pppd option usepeerdns is used.
> Some distributions (notable RH) use the file to configure /etc/resolv.conf,
> perhaps by "mv"ing each new/etc/ppp/resolv.conf to /etc, or linking it
> to /etc/resolv.conf .

Man you're good. :) It was my fault -- not RH's (lesson learned: I shouldn't
be so quick to think it's a bug on the other guy's end). I had some wizard
option set to dynamically get DNS addresses from the ISP. Once I shut that
off, my resolv.conf stopped getting written over by "seemingly random" non-
working DNS addresses.

>
>>Moral? Dunno. Maybe my Slack install had some corrupted file. Maybe
>>I was making some obvious mistake that never got uncovered in this
>>discussion thread. Maybe Slack's ppp integration needed more testing.
>>Anyway, I'm back online with a GNU/Linux setup and getting my work
>>done again. I also plan on having a look at the next Fedora release.
>
>
> Glad to hear you are back on-line, but surprised that RH could get PPP
> working with it's GUI configuration tool and regret that you abandoned
> Slackware.

Well, thank you Cliff. I still really like the simplicity of Slack (and
also the way packages are handled), so I will likely try it again sometime.

Actually, before installing Slack about a week ago, I was running Debian
Stable. I tried updating to Testing and after about a 180 MB download (on
dialup) and upgrade my machine wouldn't boot up. That's when I reached for
the Slack CD's. The next couple of weeks are hectic for me, so I just
needed something that works right away, right now -- hence the RH9 install.



> As always, sometimes it's "whatever works."
>
> -- Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
> PPP-Q&A links, downloads: http://ckite.no-ip.net/
> /* Editing with vi is a lot better than using a huge swiss army knife.
> Use =} to wrap paragraphs in vi. Or put map ^] !}fmt -72^M in
> ~/.exrc and use ^] to wrap to 72 columns or whatever you choose. */