Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
One more thing. I just checked, and on my system wvdial is in /usr/bin/. The which command is very useful for finding where binaries are, but it will only search the PATH of the account you run it from. whereis and locate are also useful commands for locating things.
Last edited by blackhole54; 06-28-2006 at 09:56 PM.
I am glad you can at least now talk to the modem!!! You probably gathered from my last post that I was beginning to fear the worst.
You & me both.
Quote:
I can't read minds any better than you can.
Darn!
Quote:
Seriously, you might check /var/log/messages to see if there is anything there.
Nothing special.
Quote:
Also, on post #3 you reported ppp-go giving messages like:
Code:
send (AT&FH0^M)
expect (OK)
You can't get it to do that sort of thing anymore? Or is there just no info after CONNECT?
No, I just turned down the verbosity to eliminate the ddoouubbllee eecchhooiinngg.
Quote:
You can also try my old suggestion of editing ppp-go (adding set -x) so that it outputs what it is doing when the failure occurs.
It just says ppp-go exits and runs the chat script.
The current state is that minicom works but ppp/chat doesn't. Here's what minicom does (my input in red):
Code:
AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0
OK
atdt5551212
CONNECT 38400
<Rtrn>
Welcome to ...
blah blah blah
login: [me]
password: [my passwd]
[logged into non-ppp mode]
I was able to read this forum last night on Lynx, which was quite a new experience, but not able to post, maybe since the isp wouldn't accept cookies.
Now pppd + chat -vs:
Code:
[...]
send (atdt5551212^M)
timeout set to 75 seconds
expect (CONNECT)
^M
atdt5551212^M^M
CONNECT
-- got it
send (^M)
expect (ogin:)
57600^M
alarm
Failed
Connect script failed
I'm not sure why the modem speed 57600 was echoed after the expect statement. I guess it came after the previous expect string (CONNECT). I also tried the slower 38400 speed just in case that made a difference, which it didn't. I also tried putting a "\n" in the response to CONNECT in the chat script pppscript:
I changed
CONNECT ""
to
CONNECT "\n"
but the only difference in the output was that
send (^M)
changed to
send (^J^M)
I suppose if chat got hung up on that 57600, that could be the problem. I don't like the idea of a simple script trying to deal with an external environment it can't reliably predict. And why would you want to put your password in a file anyway? But I didn't see any way to make chat hand over control to the user interactively.
Would you please zip The ppp-go script and the following files from /etc/ppp:
1) options 2) pppscript 3) pppsetup.txt ?
If the chatscript is not one of the above files also include it.
And e-mail it to me. (Click on my name to the left.)
(Create a copy of any file that contains your usename/password and replace that info with dummy strings in the copy you send me.)
Thanks.
Last edited by blackhole54; 06-29-2006 at 02:14 PM.
Okay, I emailed the ISP. They don't know about dialing up from Linux, but they suggested adding another return character. I added the line
"" "\d"
immediately after the CONNECT line in pppscript. The delay \d and the placement immediately after CONNECT were both necessary to elicit the "Welcome ..." response.
Code:
root[ppp]# ppp-go -v
+ /usr/sbin/pppd -detach connect '/usr/sbin/chat -vs -f /etc/ppp/pppscript'
+ exit 0
root[ppp]#
timeout set to 60 seconds
abort on (ERROR)
abort on (BUSY)
abort on (NO CARRIER)
abort on (NO DIALTONE)
send (AT&FH0^M)
expect (OK)
AT&FH0^M^M
OK
-- got it
send (atdt5551212^M)
timeout set to 75 seconds
expect (CONNECT)
^M
atdt5551212^M^M
CONNECT
-- got it
send (^M)
timeout set to 45 seconds
send (\d\d^M)
NOTE: adding a line
"" "\d"
at this point resulted in a bad login, even though the ISP asked for a return character (see below). Continuing (without the extra line):
Code:
expect (ogin:)
57600^M
^M
Welcome ... ^M
blah blah blah ^M
^M
Press Enter or Return to login to Vapor Net.^M
^M
blah blah blah^M
Trying 123.45.6.7, 24 ... Open^M
Another DNS for the same site.
The official IP address entered into pppsetup would be something like 123.45.6.6.
Now we're logged into the old-fashioned non-ppp mode with pine, lynx, ftp, etc..
One more thing: About the pppsetup.txt file, there's a warning that says ppp isn't present either in the kernel or as a module. I don't know if that's responsible for the current problems or not, but I'm working on it now anyway.
# use *either* first or second line but not both
CONNECT \d\d\c
CONNECT \d\d
ogin:--ogin: alfredEnewman
ssword:--ssword: whatmeworry
The first line will wait 1-2 seconds, but not issue a <cr>. The second line will issue a carriage return after the wait. The last two lines will give the username and password when prompted, but if they time out w/o the respective prompt, they will issue another <cr> and wait again. (In case that did not display well, there are two dashes in both lines)
----
Another, and probably better, way to authenticate is to use PAP rather than to authenticate in the CHAT script. I say better because of an experience I had ... (Break out your hankey. This is a tear jerker. ) I had been using Linux with my ISP for about six months w/o problem. Then one day I couldn't connect. After a frustrating 24 hours with a lot of hair pulling and head banging, and with my ISP being less helpful than it might, I found out that Level 3 (which my ISP contracts with to provide my Internet connecton) had changed authentication procedure. Previously, they prompted for username/password, which wvdial dutifully provided (just as your chat script is attempting) and all was well with the world. Suddenly, while they continued to prompt for credentials, they punished you with an "authentication failure," or some such, if you were foolish enough to supply your credentials. The solution was to tell wvdial to use the aptly named "stupid mode" which, ignoring the prompt, immediately started pppd, and authenticated with PAP. After solving the problem and complaining to my ISP about it, I was told "that's the way Windows and MacIntosh do it." (sigh) Well, at least in the process I learned something about PAP and CHAP.
Sorry for the long story, but that is why I think in the long run you might have less grief if you just go with PAP. Plus, it might work around your chat script problems.
PAP and CHAP (see the pppd man page for explanation) are authentication protocols that run under ppp. (This where we find out if you really don't have ppp in your kernel!) I think if you simply end your chat script after the CONNECT line (perhaps just using "CONNECT \c") that pppd will start, your ISP will ask for PAP authentication, and if /etc/ppp/pap-secrets exists with the proper info, pppd will automatically authenticate you.
pap-secrets, which should be readable only by root, should contain a line like:
Code:
username servername password
Where the server name is (I believe) the name in your pppoptions file supplied on the line starting with remotename.
Quote:
Originally Posted by HackerX
Seems closer, but that whole non-ppp thing seems strange.
I didn't know you could even do this w/o ppp, and I still haven't figured out how you are doing it. So I can't help you. Maybe you can explain to me exactly what you did. (It sounded to me like you were using minicom, but that then somehow you were on the command line.)
Last edited by blackhole54; 06-30-2006 at 06:14 PM.
# use *either* first or second line but not both
CONNECT \d\d\c
CONNECT \d\d
ogin:--ogin: alfredEnewman
ssword:--ssword: whatmeworry
The second one looks fine. It looks like it does the same thing as mine. The first one looks like it does nothing at all. What does it mean to wait two seconds and then do nothing?
Quote:
Another, and probably better, way to authenticate is to use PAP rather than to authenticate in the CHAT script.
I thought the presence of a login prompt implied the absence of PAP. I guess not. I'll ask my ISP about it.
Quote:
I didn't know you could even do this w/o ppp, and I still haven't figured out how you are doing it. So I can't help you. Maybe you can explain to me exactly what you did. (It sounded to me like you were using minicom, but that then somehow you were on the command line.)
minicom brings up non-ppp mode just fine. chat brings up the login prompt for non-ppp mode, and then pppd gets the reflected config messages after chat exits.
I've been wondering about that. Once the ISP welcomes me to their non-ppp mode, I wonder if something has already gone wrong.
The first one looks like it does nothing at all. What does it mean to wait two seconds and then do nothing?
I am not a chat expert. My idea was to wait for the rest of the connect message and the welcome message to go by before "expecting" the login prompt. Mabe this was a really stupid idea.
Quote:
Originally Posted by Hacker X
The second one looks fine. It looks like it does the same thing as mine.
What it does different from what I thought you did, is, after getting CONNECT, it waits (giving time for rest of CONNECT message) before giving a <cr>. What I thought you had done, that I posted last time, gives a <cr> immediately, waits and then gives another one. I thought the difference might still give a <cr> to get the login prompt w/o generating an error. I was trying to play around with different combinations to get your ISP's server happy. There has got to be some combination that works! The other (possible) difference is that my 3rd & 4th lines have the chat script reissue a <cr> and again wait for a response if it initially times out.
Quote:
Originally Posted by Hacker X
I thought the presence of a login prompt implied the absence of PAP.
No. Although I suppose an ISP could disable PAP. I don't know why they would other than to force the use of CHAP. (That would be a security measure. In which case they shouldn't offer an original text login.)
Quote:
Originally Posted by Hacker X
Once the ISP welcomes me to their non-ppp mode, I wonder if something has already gone wrong.
Not necessarily. Refer back to the discussion in my last post about wvdial. For the first six months it was authenticating me through a login prompt and then starting pppd. After I told it to use "stupid mode," it ignored the welcome message and login prompt and immediately started pppd, which then authenticated with PAP.
Well, Zenwalk has been saying ppp is already compiled in.
Quote Hacker X
The second one looks fine. It looks like it does the same thing as mine.
Quote:
Originally Posted by blackhole54
What it does different from what I thought you did, is, after getting CONNECT, it waits (giving time for rest of CONNECT message) before giving a <cr>. What I thought you had done, that I posted last time, gives a <cr> immediately, waits and then gives another one.
Yes, of course. You're right.
Quote Hacker X
I thought the presence of a login prompt implied the absence of PAP.
Quote:
No. Although I suppose an ISP could disable PAP. I don't know why they would other than to force the use of CHAP.
bh54: Good call on PAP. All I had to do was exit chat on CONNECT without doing anything
Congratulations!
And we now know you have ppp in your kernel!
Quote:
Originally Posted by Hacker X
Web pages are still not coming up, and I'm worried about the compression being rejected. Sounds like the Rockwell modem maybe.
I don't think you actually need compression, but I could be wrong. I think it just makes things a little nicer.
As far as not getting web pages, I am concerned that I didn't see anything in your log about DNS. DNS (domain name system) is kind of like a phone book, and converts from the names we use (e.g. linuxquestions.org) to the Internet Protocol addresses (e.g. 64.179.4.146) that computers use.
Try calling up your ISP, starting PPP, and authenticating with PAP like you just reported. Then go to a terminal window and try the following commands:
The ping (named for analogy with sonar) command simply asks the recipient to respond to an echo request with an echo reply. The ping command reports whether it received anything back and how long it took. Some websites block ping requests, but LinuxQuestions is nice enough not to (at least when I checked).
These two commands do the same thing, but the second one requires a DNS lookup.
If the first command works and the second does not, try adding usepeerdns to your pppoptions file. On some systems you have to bee root to use the ping command.
Last edited by blackhole54; 07-04-2006 at 10:17 PM.
On the other hand, when I surf to the numerical IP address for my ISP, the browser goes straight to the address without subbing in the name, and brings up the ISP's homepage. I can surf around on the ISP's site just fine. The address bar keeps displaying http://123.45.6.7/directory-name/ and taking me successfully from page to page.
If [pinging the full Internet name of your service provider] does NOT work, you have a problem with the name resolution.
This is probably because of a typo in your /etc/resolv.conf file.
Following instructions in an earlier section of the Howto (i.e. it's their fault!), I previously added the line
nameserver xxx.xx.x.3
(except for the x's) to resolv.conf. This is the IP address specified by my ISP.
But pppd is outputting addresses xxx.xx.x.N, where the values of N so far have been 13, 91, and 99. And the DNS addresses are TOTALLY different.
It sounds like resolv.conf is sticking with the original/official address, but the ISP is deciding to use something else. So we need to either specify the nameserver more flexibly in resolv.conf or somehow change the nameserver based on what pppd says?
Wow. What an ordeal. I finally went back to my ISP's documentation and found out that one of the other IP numbers being echoed by pppd is the ISP's secondary DNS. Put that into resolv.conf along with the first DNS line, and it looks like we're in business.
Is that "Guaranteed" to be enough to work forever, or are there other details that will bite me in the butt later on? Oh well, I guess I can whine about them if & when they occur.
Anyway, this is my first post over Linux ppp. I'll come crying back here again if anything goes wrong. Thanks blackhole, your suggestion of bypassing the login and going straight to PAP authorization was a huge milestone.
---
Also primo, thanks for responding. And LQ, thank you for providing the forum.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
Congratulations!
I'm On!
