ppp chat script failed
 

Trying to get a dial-up going on Zenwalk 2.6 (slack based). Ran pppsetup, accepted the default init string. Run ppp-go, exits with "Connection script failed", no other info echoed or in /var/log/syslog. Added a verbose option (chat -e -V) to ppp-go, and something echoed the string "^@^@", whatever that means. Man pages don't seem helpful. Is there some magic incantation I'm missing? What's the next step?

From http://www.slackware.com/config/ppp.php :

Is the "program" ppp-go perchance a script? (Try looking at it with a text editor or the program less.) If so, are you familiar with that scripting language? Usually the first line will be something like
Which in this case indicates it is a bash script.

Also, from the same webpage (link above), there are several scripts in /etc/ppp which might be useful to look at.

I believe the ^@^@ represent two null ascii characters, i.e. characters whose hex value is zero. But I have no idea what they mean.

I hope this can get you started. (I have no idea how much you know about scripts.) Post back with additional questions or info.

Thanks for responding.

Yes, ppp-go is a sh/bash script. I added a -v option that calls chat with more verbosity. Now it's calling "chat -evsV". After a few "abort on ..." lines, the output looks like this:

send (AT&FH0^M)
expect (OK)
^@^@alarm
Failed

So I'm guessing the ^@^@ isn't good :(

I tried experimenting with the modem speed in /etc/ppp/pppscript, and this output occurred through the whole range, from 9600 to the highest speed mentioned in pppsetup.

I found a web page that says to try "cat /dev/ttySN" to test your modem device, where N is the device number. No output means it's there, I/O error means it's not. I set the modem to ttyS0 in pppscript, and "cat /dev/ttyS0" returns no output with no error, whereas "cat /dev/ttyS[1-4]" returns an error. So I think I have the right device file.

The modem is a Rockwell
RCVDL56ACF/SP
R6761-21
COM ID RSS0250, ISAPNP\RSS 0250

That's what I know about the modem.

This is a fresh install of the OS as of a day or two ago. The installer didn't say anything about a modem driver, so I don't know whether it found the driver itself or just did nothing. Is there a way to check that? Is the driver's presence implied by "cat /dev/ttyS0"? I'll see if dmesg says anything.

btw, is this the best forum to post this question on? Is there another forum that would be good to cross-post it on? The Slack forum? Hardware? Software? Don't want to bug too many people :)

Thanx for the help.

I don't know what the best forum is to post this on, but you are not supposed to post the same thing on more than one forum. If moderators become aware that you have done so, they will move or delete posts. You can, however, "tag" your post with relevant tags to attract people's attention to it. Look down at the bottom of your posts to see how to do this. (This rule keeps things simple. For example if somebody else is helping you also, it is useful for me to see those posts to reduce duplication and increase cooperation/synergy.)

The info about cat sounds right if you run as root. Just be aware that when I have brute forced things using cat on serial lines, I have occasionally hosed things. :-( If you want to try a slightly more sophisticated test to see if you can talk to your modem, see if your system has minicom. Check out the man pages before you try to use it -- you must first run it as root with the -s option to configure it before it can be used by normal users. After configuring, try it as a normal user. If it comes up w/o errors, try giving it an ATZ command. This is the initialization command and it should respond OK. If this works fine, try that AT&FH0 command that seems to have failed in your script. (The ^M at the end just indicates a carriage return.) You can also try dialing your ISP with the command ATDT followed by the telephone number (e.g. ATDT5551212). If you connect succesfully, I would just drop the connection by first hitting three "plus signs" in rapid succession (which tells the modem to stop paying attention to the telephone line and come back to command mode) followed by ATH0 (the last character is a zero), which tells the modem to hang up.

One more thing. You say your modem is on /dev/ttyS0. On older computers, this would usually be a built in serial line on the motherboard. If your modem is external, all is well. If your modem is internal (a quick google on your model didn't help me determine), make sure it isn't conflicting with a built in serial line.

If all went well with your minicom test, you can modify your ppp-go script so it shows you every line as it executes. Use your favorite text editor to add
at the beginning of the script. This might produce a lot of output when you run it, so might might need to pipe the output to less.

Look into "tagging" your post.
Again, post back as needed.
Good luck.

If all went well with your minicom test, you can modify your ppp-go script so it shows you every line as it executes. Use your favorite text editor to add
at the beginning of the script.

Oops!!! I should have set put "set -x" on the second line ... after the #!/bin/[ba]sh line!

Null Bytes
 

Sorry for this succession of posts, but I just had an idea what those two null bytes (^@^@) might be. They could be what the script is seeing coming back from the modem in response to AT&FH0 instead of the expected OK. This would suggest a problem communicating with the modem (a conflict between devices?). This would probably best be investigated with minicom, as I suggested above.

What about /etc/ppp/options what does it contains?
Add "debug" to see if it is pppd the problem (errors go to /var/log/daemon or /var/log/messages). Also, adding "crtscts" and "modem" can help.

How do you get minicom to take typed input? It doesn't echo anything I type in. All I've been able to do is use the Ctrl-A commands, and it failed when I tried to dial.

I'm not sure everything is set up correctly. When the machine was running W98 a couple weeks ago (now overwritten by Linux), it said the modem was on COM2, and the jumpers on the card are set to IRQ 3. It's a separate card plugged into the big long black socket way at the bottom of the motherboard, which is mounted on the side of the case. There are two shorter white sockets above it, and something plugged into the motherboard just above the modem card. This other thing is a very small card with a big black connector on the outside of the case that looks like an oversized phone jack. I don't know what it's for.

Anyway, the minicom man page says the modem is usually on ttyS1, and the setserial man page says ttyS0 should have IRQ 4 and ttyS1 should have IRQ 3. But the Zenwalk installer found a modem on ttyS0, not ttyS1, and setserial -a says "UART: 16550A" for ttyS0, but "UART: unknown" for ttyS1, plus catting ttyS1 returns a device error.

So it almost sounds like the modem is on ttyS1/COM2, but the installer somehow didn't figure that out so it didn't setup the modem correctly(?).

Isn't there some sort of command-line utility to sort all this out? ppp, chat, and minicom all seem to assume the modem is setup already.

The command is Ctrl-A E to put it to "echo on"

There's pppconfig and wvdial. Wvdial search all devices. You may try this one.

Either you are not actually talking to the modem or (less likely) your modem is not set up to echo characters back. You could turn local echo on as primo suggested. However, when I do that, I get each character echoed twice -- once from the local echo and once from the modem echoing.



I think you are aware that MS's "com2" corresponds to /dev/ttyS1. It sounds like you are describing (your modem card) an ISA card which I supect is manually jumpered both for its IRQ and for its I/O address. That is how my internal modem is. That other card sounds like it could be an ethernet card.


You might be right about us not knowing where the modem is. I would suggest you first look at your logs to see what the kernel finds when it boots. In my /var/log/messages file, I find these lines:

The first two lines are the built-in serial lines on my motherboard. The last line is my internal modem. (That IRQ conflict is taken care of later by a setserial command in my rc.local file.) I don't know why it lists a leading zero on the devices; the actual devices are /dev/ttyS3, etc.

Your log entries should give you an idea of what your choices are on when you look for your modem.

As far a command line tool, all I know is using cat and echo as follows:
If you are in a graphical environment you can open up two terminal windows and try to talk to the modem manually. (If not in a GUI, you can use two virtual terminals. But a GUI is better, because if things run away -- and they might -- you can kill things by simply closing the windows.) In both windows use su to become root. In one window, listen like you did before using cat,
e.g. cat /dev/ttyS0. In the other window you can send commands, e.g. echo "ATZ" > /dev/ttyS0.

You already know about setserial. In this excercise, the stty command can also be relevant. It controls a bunch of higher level functions of the port, including echoing. Software like pppd and minicom handle these settings for you. When you brute force things like I describe above, you are on your own. When I first tried this back when, I had both the modem and port echoing to each other, and as soon as I sent the first command, it went into a perpetual, viscous cycle! Other times I totally hosed things. Never knew how. But worse case scenario, it was nothing a reboot wouldn't fix.

I hope this helps you get a little further.

Yes, it has a manual jumper.

Yes, that sounds right.

This is what /var/log/messages says:

That's all it says. No other ttySN entries, either for other devices found or for errors or failed attempts.

No response. I tried moving the jumper to irq 4, but there was still no response. I only changed the irq, nothing else.

OK, we're scraping the bottom of the barrel here. These are desperation questions/suggestions:

1. Do you know for sure whether this modem worked when the computer had Win98 on it?
2. How is the I/O address of the card jumpered? My modem has jumper positions labelled COM1 through COM4. Of course, your's may have hex numbers like 03F8 or some other scheme.
3. Try booting your computer w/o the modem card and see what (if any) serial ports are reported in /var/log/messages.

If you are starting to move jumpers around on the card, I would recommend you make a written note (perhaps picture) of where the jumpers were originally positioned. This is always good practice, so when you've gotten yourself thoroughly confused while trying everything under the sun (yeah, I've been there, done that! :)) you can return to your starting point.

(later)

With regard to #2 above, I just searched some Linux hardware compatibility lists. If I found the right thing and read the list right, it looked like both PnP and jumpers were checked. So perhaps the address is PnP, or perhaps can be jumpered either PnP or a manual address?:scratch: I hope this is not a "winmodem" or "software modem." See what you can figure out from the jumpers, or lack thereof. Also, feel free to google.

Progress!
 

Okay, we're dialing.

That was a very good idea. Thank you. ttyS0 was still there with the card out, so maybe it's the ethernet card?

I learned from the PCI and ISA wikis that the big black slot is an ISA port. The card has three sets of jumpers, including one for the IO address and one for the IRQ. The third set has three jumpers, but the key lists only two options: PNP and COM. The card was set to PNP and the address and IRQ for COM4/ttys3. I changed them to COM and the settings for COM2/ttyS1.

ttyS1 is now showing a 16550A UART, and pppd is dialing out. This distribution doesn't seem to have isapnp, so maybe the system wasn't able to configure the ISA card.

No, but there may be a problem with data compression. I've been working with the modem howto, which I found a couple days ago. It says some old Rockwell modems need a special driver for compression, which isn't ported to Linux.

Anyway, this is a BIG step forward. :)

I ran pppsetup, which created /etc/ppp/[options && pppscript] with ttyS1 and all the info for my ISP and userid. Now pppd does this:

So what exactly is the failure? Verbose mode just double-echos every character and says things like "alarm" and "Failed".

Also, this disrtibution doesn't seem to have wvdial either, not even in /sbin or /usr/sbin.

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.

I can't read minds any better than you can.;)

Seriously, you might check /var/log/messages to see if there is anything there. Also, on post #3 you reported ppp-go giving messages like:
You can't get it to do that sort of thing anymore? Or is there just no info after CONNECT? 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.

You can try to download and install it. I have never used slackware, so I can't give you any help in that department. wvdial is what I use. It is pretty good about logging info to the system log.

BTW, an ethernet card should not show up as a serial port. I am guessing you have a serial port on your motherboard.

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.

I tried to check everywhere. There's no man page, so I'm not expecting to find it.

You & me both.

Darn!

Nothing special.

No, I just turned down the verbosity to eliminate the ddoouubbllee eecchhooiinngg.

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):

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:

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.

(done)

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.

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.

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):
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..

Seems closer, but that whole non-ppp thing seems strange.

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.

I am not sure I followed everything you posted. I think you started with a chatscript that had something like this in it:

and you changed it to something like:

I was going to suggest you try:

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:
Where the server name is (I believe) the name in your pppoptions file supplied on the line starting with remotename.

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.)

Yes.

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?

I thought the presence of a login prompt implied the absence of PAP. I guess not. I'll ask my ISP about it.

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.

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.

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.

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.)
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.
Yes, of course. You're right.

Quote Hacker X
I thought the presence of a login prompt implied the absence of PAP.
Okay, I emailed the ISP.

PAP is working
 

bh54: Good call on PAP. All I had to do was exit chat on CONNECT without doing anything. Now I get this:

CONNECT
-- got it

send (\d\d\d\d)
Serial connection established.
using channel 2
Using interface ppp0
Connect: ppp0 <--> /dev/ttyS1
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xb65706f3> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0xc9 <asyncmap 0xa0000> <auth pap> <magic 0x13152e85> <pcomp> <accomp>]
sent [LCP ConfAck id=0xc9 <asyncmap 0xa0000> <auth pap> <magic 0x13152e85> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xb65706f3> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xb65706f3> <pcomp> <accomp>]
sent [PAP AuthReq id=0x1 user="hx" password=<hidden>]
sent [PAP AuthReq id=0x2 user="hx" password=<hidden>]
rcvd [PAP AuthAck id=0x2 ""]
PAP authentication succeeded
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0>]
rcvd [IPCP ConfReq id=0x95 <compress VJ 0f 00> <addr .........>]
sent [IPCP ConfAck id=0x95 <compress VJ 0f 00> <addr .........>]
rcvd [LCP ProtRej id=0xca 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
Protocol-Reject for 'Compression Control Protocol' (0x80fd) received
rcvd [IPCP ConfNak id=0x1 <addr 123.45.6.91>]
sent [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr .........>]
rcvd [IPCP ConfAck id=0x2 <compress VJ 0f 01> <addr .........>]
local IP address 123.45.6.91
remote IP address 123.45.6.13
Script /etc/ppp/ip-up started (pid 2300)
Script /etc/ppp/ip-up finished (pid 2300), status = 0x0

Web pages are still not coming up, and I'm worried about the compression being rejected. Sounds like the Rockwell modem maybe.

BTW, I'm posting from home thru Lynx on my ISP's terminal dialup. Definitely an interesting experience!

:cool: Congratulations!

And we now know you have ppp in your kernel!



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.

Added "usepeerdns" to options. Slight change in output.
Ping -c 3 is still finding 64.179.4.146, but not finding linuxquestions.org.

How about this: When I point my browser (FF) to http://64.179.4.146,
it echoes http://www.linuxquestions.org/ in the address bar, but still can't find the server.

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.

Current output:

PAP authentication succeeded
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
rcvd [IPCP ConfReq id=0xe4 <compress VJ 0f 00> <addr 123.45.6.13>]
sent [IPCP ConfAck id=0xe4 <compress VJ 0f 00> <addr 123.45.6.13>]
rcvd [LCP ProtRej id=0x45 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
Protocol-Reject for 'Compression Control Protocol' (0x80fd) received
rcvd [IPCP ConfNak id=0x1 <addr 123.45.6.88> <ms-dns1 987.654.3.58> <ms-dns3 987.654.3.102>]
sent [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr 123.45.6.88> <ms-dns1 987.654.3.58> <ms-dns3 987.654.3.102>]rcvd [IPCP ConfAck id=0x2 <compress VJ 0f 01> <addr 123.45.6.88> <ms-dns1 987.654.3.58> <ms-dns3 987.654.3.102>]local IP address 123.45.6.88
remote IP address 123.45.6.13
primary DNS address 987.654.3.58
secondary DNS address 987.654.3.102
Script /etc/ppp/ip-up started (pid 2150)
Script /etc/ppp/ip-up finished (pid 2150), status = 0x0

Section 22.1 of the PPP Howto says
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?

I'm On!
 

Good job blackhole54! Thanks for the help!

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. :p

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.

DNS, resolv.conf, ip-up & YOU ;-)
 

:cool:You did it!:D
You're right. This was an ordeal! There were three major problems to overcome: talking to the modem, authentication, and DNS. You did a lot of research, and I am sure you learned a lot.

I am just wrapping up with an observation about your last question.

What follows is based on my /etc/ppp/ip-up and /etc/sysconfig/network-scripts/ifup-post scripts. You're running a different system, so your mileage may vary.

ip-up is run automatically as described in the pppd man page. On my system, ip-up calls ifup-post.
One of the main functions of ifup-post is (potentially) altering resolv.conf to reflect the nameservers needed for the ppp connection. (Conversely, ip-down & ifdown-post change it back.)

These are bash scripts. If you know bash (or want to learn it :)), you can study what ip-up and its descendants do with resolv.conf. If your ISP gave you specific addresses for DNS, maybe you don't even want to use usepeerdns. It's up to you. If/when you know how to read bash scripts, you now have enough knowledge to make a rational decision. Good luck, and happy surfing!

Invalid IPv4 Addresses
 

I was just reading through your earlier posts and noticed something strange. You said that pppd reported the following:

Unless your lack of a normal I-net connection led you to enter this by hand and you made some typos, this is very strange!

These are not valid IPv4 (Internet Protocol version 4) addresses, and I don't think the format is right for IPv6!

IPv4 uses 4 byte addresses. The notation we have been using is called "dotted decimal," where each byte is represented by its decimal value, and the values are separated by dots. (For more info and "fun with IP address values" see this Internet Storm Center diary entry.) That means that each of those numbers should be less than 256! If these are not typos I have no idea what this means, but it sure is strange.

-----

--later-- (The edit to the above post)

O.K., O.K., I get it. You obfuscated the addresses with the sequence "9876543.":rolleyes: My mistake. The rest of what I said about addresses is valid.