Jens Granseuer wrote:
>
> I'm currently trying to persuade my Intel HAM modem to properly
> connect to the net. I installed the latest drivers from Intel (v453),
> and it seems to work. I can talk to the modem, it dials, pppd reports
> "Serial connection established" - and then things come to a halt.
>
> The ppp0 interface never comes up, and after about 20 seconds, the
> modem gives up with "NO CARRIER". pppd does not give up, however. I
> have to kill it.

> /etc/ppp/peers/freenet:
> noauth
> user freenet
> connect "/usr/sbin/chat -v -t 20 \
> ABORT 'NO CARRIER' \
> ABORT 'BUSY' \
> ABORT 'NO DIALTONE' \
> ABORT '\nRINGING\r\n\r\nRINGING\r' \
> '' '\rATQ0 V1 E1 S0=0 &C1 &D2 +GCI=42' \
> 'OK-+++\c-OK' ATH0 \
> TIMEOUT 45 \
> OK ATDT019231760 \
> CONNECT ''"


Perhaps I am missing something here, but where is your username and password
given to the remote host in the above?

Is there any reason you can't use something like kppp to setup your scripts
for you?


Phil

Floyd Davidson <floyd@barrow.com> wrote:
> Philip Bailey <pbailey10@nospam.hotmail.com> wrote:
>>Jens Granseuer wrote:
>>>
>>> I'm currently trying to persuade my Intel HAM modem to properly
>>> connect to the net. I installed the latest drivers from Intel (v453),
>>> and it seems to work. I can talk to the modem, it dials, pppd reports
>>> "Serial connection established" - and then things come to a halt.
>>>
>>> The ppp0 interface never comes up, and after about 20 seconds, the
>>> modem gives up with "NO CARRIER". pppd does not give up, however. I
>>> have to kill it.
>>
>>> /etc/ppp/peers/freenet:
>>> noauth
>>> user freenet
>>> connect "/usr/sbin/chat -v -t 20 \
>>> ABORT 'NO CARRIER' \
>>> ABORT 'BUSY' \
>>> ABORT 'NO DIALTONE' \
>>> ABORT '\nRINGING\r\n\r\nRINGING\r' \
>>> '' '\rATQ0 V1 E1 S0=0 &C1 &D2 +GCI=42' \
>>> 'OK-+++\c-OK' ATH0 \
>>> TIMEOUT 45 \
>>> OK ATDT019231760 \
>>> CONNECT ''"
>>
>>
>>Perhaps I am missing something here, but where is your username and password
>>given to the remote host in the above?

He doesn't need a password sent by chat if PAP or CHAP is used to
authenticate him at the ISP, almost universal these days.

> It isn't, and isn't needed either. Note the result when he used

The pppd option "user freenet" is specified. If that's what he
really should be using as a user name and the secrets files contain
the single line

freenet * <password>

then that should provide for authentication to the ISP.

> minicom to connect, the remote end goes directly to ppp and apparently
> authenticates via either PAP or CHAP, though we can't tell which from
> the information provided.

>>Is there any reason you can't use something like kppp to setup your scripts
>>for you?

> His script worked, as far as getting a connection. His problem appears
> to be in what ppp negociates, and it could very easily be authentication
> is what fails, but it might be something else too.

Doesn't kppp set up pppd too? But it's very doubtful that kppp would help,
frontends to pppd are fine when they work but are terrible at debugging
when they don't.

I rather doubt that any PPP implementation would spend the major part
of the almost x minutes connected in trying to authenticate a client.

In a previous post you mentioned "debug 1," which won't work; the 1 will
almost certainly be interpreted as the pppd-to-modem speed. A simple
"debug" might produce something of value, but even that's doubtful for a
modem that needs a software driver. You may have had "kdebug 1" in mind,
but that (or kdebug 7) won't produce a hex dump in pppd 2.4.1 or later.
Moreover the hex dump is very seldom needed for debugging.

Except for adding the pppd debug option and posting an exact copy
(including timestamps) of the PPP negotiations log messages, the only
other things I have to suggest is first, to try ending the chat script
with CONNECT \c , and second, to get (and use) an external modem.

BTW, to the original poster: I didn't see any "NO CARRIER" message
from the modem in the *chat* output.

--
Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* For every credibility gap, there is a gullibility fill.
-- R. Clopton */

Philip Bailey <pbailey10@nospam.hotmail.com> wrote in message news:<HH1A8n.1Jq@bath.ac.uk>...
>
> > /etc/ppp/peers/freenet:
> > noauth
> > user freenet
> > connect "/usr/sbin/chat -v -t 20 \
> > ABORT 'NO CARRIER' \
> > ABORT 'BUSY' \
> > ABORT 'NO DIALTONE' \
> > ABORT '\nRINGING\r\n\r\nRINGING\r' \
> > '' '\rATQ0 V1 E1 S0=0 &C1 &D2 +GCI=42' \
> > 'OK-+++\c-OK' ATH0 \
> > TIMEOUT 45 \
> > OK ATDT019231760 \
> > CONNECT ''"
>
>
> Perhaps I am missing something here, but where is your username and password
> given to the remote host in the above?

You don't need to give those with CHAP and PAP authentication.
The user option tells pppd where to look for the password.

> Is there any reason you can't use something like kppp to setup your scripts
> for you?

I don't know kppp (from the name I could probably also say I don't use
KDE(, but I suppose it's similar to wvdial? I tried that and it broke
even before it began...

Jens

jensgr@gmx.net (Jens Granseuer) writes:

]Philip Bailey <pbailey10@nospam.hotmail.com> wrote in message news:<HH1A8n.1Jq@bath.ac.uk>...
]>
]> > /etc/ppp/peers/freenet:
]> > noauth
]> > user freenet
]> > connect "/usr/sbin/chat -v -t 20 \
]> > ABORT 'NO CARRIER' \
]> > ABORT 'BUSY' \
]> > ABORT 'NO DIALTONE' \
]> > ABORT '\nRINGING\r\n\r\nRINGING\r' \
]> > '' '\rATQ0 V1 E1 S0=0 &C1 &D2 +GCI=42' \

These commands to the modem are probably wrong for your modem.
Especially the +GCI=42 (what is that supposed to mean), and maybe the &
commands. Read your modem manual.


]> > 'OK-+++\c-OK' ATH0 \
]> > TIMEOUT 45 \
]> > OK ATDT019231760 \
]> > CONNECT ''"

You almost never want to have this You want
CONNECT '\d\c'
instead.

The carriage return which '' implies triggers the far end not to go into
ppp but into a logon script, while your side is trying to run ppp. This
almost always leads to miscommunication and failure.

Clifford Kite <kite@see.signature.id> wrote:
> In a previous post you mentioned "debug 1," which won't work; the 1 will
> almost certainly be interpreted as the pppd-to-modem speed. A simple
> "debug" might produce something of value, but even that's doubtful for a
> modem that needs a software driver. You may have had "kdebug 1" in mind,
> but that (or kdebug 7) won't produce a hex dump in pppd 2.4.1 or later.
> Moreover the hex dump is very seldom needed for debugging.

Right. So should I get 2.4.0 and give that a try?

> Except for adding the pppd debug option and posting an exact copy
> (including timestamps) of the PPP negotiations log messages, the only
> other things I have to suggest is first, to try ending the chat script
> with CONNECT \c , and second, to get (and use) an external modem.

The log output with or without debug doesn't differ at all.
Sending \c after connect doesn't help, and yes, I'm really close
to getting an (external) hardware modem. *sigh*

> BTW, to the original poster: I didn't see any "NO CARRIER" message
> from the modem in the *chat* output.

Well, that's because it doesn't appear in the log. Whatever the
reason. It _does_ appear in the transcript taken with the
record option in pppd, though.

Jens

jensgr@gmx.net (Jens Granseuer) writes:

]Clifford Kite <kite@see.signature.id> wrote:
]> In a previous post you mentioned "debug 1," which won't work; the 1 will
]> almost certainly be interpreted as the pppd-to-modem speed. A simple
]> "debug" might produce something of value, but even that's doubtful for a
]> modem that needs a software driver. You may have had "kdebug 1" in mind,
]> but that (or kdebug 7) won't produce a hex dump in pppd 2.4.1 or later.
]> Moreover the hex dump is very seldom needed for debugging.

]Right. So should I get 2.4.0 and give that a try?

No. It had problems of its own. Stick with 2.4.1
There is nothing in anything you have posted which suggests that kdebug
would help, and it almost always hinders (voluminous useless posting)


]> Except for adding the pppd debug option and posting an exact copy
]> (including timestamps) of the PPP negotiations log messages, the only
]> other things I have to suggest is first, to try ending the chat script
]> with CONNECT \c , and second, to get (and use) an external modem.

]The log output with or without debug doesn't differ at all.
]Sending \c after connect doesn't help, and yes, I'm really close
]to getting an (external) hardware modem. *sigh*

Uh, I posted how to get the debug output. you must edit syslog.conf.



]> BTW, to the original poster: I didn't see any "NO CARRIER" message
]> from the modem in the *chat* output.

]Well, that's because it doesn't appear in the log. Whatever the
]reason. It _does_ appear in the transcript taken with the
]record option in pppd, though.

syslog.conf needs to be set up.


]Jens

Jens Granseuer <jensgr@gmx.net> wrote:
> Clifford Kite <kite@see.signature.id> wrote:
>> In a previous post you mentioned "debug 1," which won't work; the 1 will
>> almost certainly be interpreted as the pppd-to-modem speed. A simple
>> "debug" might produce something of value, but even that's doubtful for a
>> modem that needs a software driver. You may have had "kdebug 1" in mind,
>> but that (or kdebug 7) won't produce a hex dump in pppd 2.4.1 or later.
>> Moreover the hex dump is very seldom needed for debugging.

> Right. So should I get 2.4.0 and give that a try?

No, as both Bill Unruh and I have pointed out, it's very unlikely
that it would do any good. Also 2.4.0 had a few problems, and I
don't know that kdebug worked for it - that's why I said "pppd 2.4.1
or later," leaving out 2.4.0. I reiterate, add the pppd debug option
(no argument) and see what the PPP negotiation messages, which should
be in one of the logs in /var/log/, say. If they aren't in one of
those logs then follow Bill Unruh's suggestion to create a log for
pppd and chat messages.

I don't think those messages will help much because of the tcsetattr
message after the SIGHUP and the uncertainty about whether a modem that
uses a software driver works with the current kernel version or not,
but it's about the best you can do to get more information as to what
happened during the 4 minutes that elapsed between when the CONNECT
message appeared and the SIGHUP.

>> Except for adding the pppd debug option and posting an exact copy
>> (including timestamps) of the PPP negotiations log messages, the only
>> other things I have to suggest is first, to try ending the chat script
>> with CONNECT \c , and second, to get (and use) an external modem.

> The log output with or without debug doesn't differ at all.
> Sending \c after connect doesn't help, and yes, I'm really close
> to getting an (external) hardware modem. *sigh*

That would be a good move.

>> BTW, to the original poster: I didn't see any "NO CARRIER" message
>> from the modem in the *chat* output.

> Well, that's because it doesn't appear in the log. Whatever the
> reason. It _does_ appear in the transcript taken with the
> record option in pppd, though.

You might have mentioned that it appeared there. The record option
replaced kdebug. The code was moved from the kernel to pppd and the
output is different, and formatting it for human consumption requires
pppdump. I'd guess, but don't *know*, that it would appear in the stream
of octets sent by pppd to a file specified by "record" when the SIGHUP
caused the hang-up, but not in the chat output because chat no longer
had control of the ttySx.

The minicom "garbage" looks superficially like two initial PPP LCP link
negotiation messages, but I didn't try to translate them to something
more readable to find out for sure.

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

unruh@string.physics.ubc.ca (Bill Unruh) wrote:
> jensgr@gmx.net (Jens Granseuer) writes:
>
> ]> > connect "/usr/sbin/chat -v -t 20 \
> ]> > ABORT 'NO CARRIER' \
> ]> > ABORT 'BUSY' \
> ]> > ABORT 'NO DIALTONE' \
> ]> > ABORT '\nRINGING\r\n\r\nRINGING\r' \
> ]> > '' '\rATQ0 V1 E1 S0=0 &C1 &D2 +GCI=42' \
>
> These commands to the modem are probably wrong for your modem.
> Especially the +GCI=42 (what is that supposed to mean), and maybe the &
> commands. Read your modem manual.

I tried several strings but none seemed to make any difference.
The +GCI=42 comes straight from the Intel driver docs and is supposed
to set it up for Germany (whatever that means).

> ]> > 'OK-+++\c-OK' ATH0 \
> ]> > TIMEOUT 45 \
> ]> > OK ATDT019231760 \
> ]> > CONNECT ''"
>
> You almost never want to have this You want
> CONNECT '\d\c'
> instead.

Ok, the effect is the same in this case, though.

Jens

unruh@string.physics.ubc.ca (Bill Unruh) wrote:
> jensgr@gmx.net (Jens Granseuer) writes:
>
> ]The log output with or without debug doesn't differ at all.
> ]Sending \c after connect doesn't help, and yes, I'm really close
> ]to getting an (external) hardware modem. *sigh*
>
> Uh, I posted how to get the debug output. you must edit syslog.conf.

Sorry, I have to use Google and friends to access usenet right now,
so I'm always lagging behind. Anyway, I did set up syslog. In fact,
I had a *.* line active during all of this. There is no difference.
I don't know what I can do about it.

Jens

Jens Granseuer <jensgr@gmx.net> wrote:

> Just to make sure there is no misunderstanding: The 4 minutes (which
> is actually 1h 4m) could be any arbitrary amount. pppd does not hangup
> itself ever. The SIGHUP comes from me doing a killall -HUP pppd.

My bad. I didn't even look at the hour, and by now I should know
to expect the unexpected. :/

> The HUP did not cause the NO CARRIER. NO CARRIER appears about 20
> seconds after the CONNECT. There is no SIGHUP ever if I don't manually
> kill pppd. On the other hand, at the time of NO CARRIER, chat already
> seems to have terminated properly, so you are probably right about
> that.

Try the recipe for a chat/ppp log found in my signature, and if that
doesn't produce the PPP negotiation messages during that 20 seconds then
all I have left to suggest is to get the external modem.

-- Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* Recipe for a unified PPP debug log file: Add the line
" local2.*;*.=debug;*.=notice /var/log/ppp-debug.log "
to /etc/syslog.conf, and do " kill -HUP `pidof syslogd` "
so that syslogd rereads it. */

Jens Granseuer wrote:
> unruh@string.physics.ubc.ca (Bill Unruh) wrote:
>>]> > 'OK-+++\c-OK' ATH0 \
>>]> > TIMEOUT 45 \
>>]> > OK ATDT019231760 \
>>]> > CONNECT ''"
>>
>>You almost never want to have this You want
>>CONNECT '\d\c'
>>instead.
>
>
> Ok, the effect is the same in this case, though.

Looks like I was only partly correct here. '\d\c' indeed shows the same
symptoms. However, '\\d\\c' does not! I don't know why but '\d\c'
always gets sent as 'dc^M'.

So, with '\\d\\c' I finally got one step further. Now I
get LCP messages.

Connect: ppp0 <--> /dev/ham
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x13ab0e8f> \
<pcomp> <accomp>]
rcvd [LCP ConfReq id=0xad <asyncmap 0xa0000> <auth pap> \
<magic 0x4e51c3f6> <pcomp> <accomp>]
sent [LCP ConfRej id=0xad <auth pap>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x13ab0e8f> \
<pcomp> <accomp>]
rcvd [LCP ConfReq id=0xae <asyncmap 0xa0000> <auth chap MD5> \
<magic 0x4e51c3f6> <pcomp> <accomp>]
sent [LCP ConfRej id=0xae <auth chap MD5>]
rcvd [LCP ConfReq id=0xaf <asyncmap 0xa0000> <auth pap> \
<magic 0x4e51c3f6> <pcomp> <accomp>]
sent [LCP ConfRej id=0xaf <auth pap>]
rcvd [LCP ConfReq id=0xb0 <asyncmap 0xa0000> <auth chap MD5> \
<magic 0x4e51c3f6> <pcomp> <accomp>]
sent [LCP ConfRej id=0xb0 <auth chap MD5>]
rcvd [LCP ConfReq id=0xb1 <asyncmap 0xa0000> <auth pap> \
<magic 0x4e51c3f6> <pcomp> <accomp>]
sent [LCP ConfRej id=0xb1 <auth pap>]
rcvd [LCP TermReq id=0xb2]
sent [LCP TermAck id=0xb2]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x13ab0e8f> \
<pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x13ab0e8f> \
<pcomp> <accomp>]
rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x13ab0e8f> \
<pcomp> <accomp>]
sent [LCP ConfNak id=0x1 <magic 0x584c80b8>]
rcvd [LCP ConfNak id=0x1 <magic 0x584c80b8>]
sent [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0xd5ce3a80> \
<pcomp> <accomp>]
rcvd [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0xd5ce3a80> \
<pcomp> <accomp>]
sent [LCP ConfNak id=0x2 <magic 0x36be40b1>]
rcvd [LCP ConfNak id=0x2 <magic 0x36be40b1>]
sent [LCP ConfReq id=0x3 <asyncmap 0x0> <magic 0xa32ffd84> \
<pcomp> <accomp>]
rcvd [LCP ConfReq id=0x3 <asyncmap 0x0> <magic 0xa32ffd84> \
<pcomp> <accomp>]
sent [LCP ConfNak id=0x3 <magic 0x3274d8c>]
rcvd [LCP ConfNak id=0x3 <magic 0x3274d8c>]
sent [LCP ConfReq id=0x4 <asyncmap 0x0> <magic 0xd5e68ee> \
<pcomp> <accomp>]
rcvd [LCP ConfReq id=0x4 <asyncmap 0x0> <magic 0xd5e68ee> \
<pcomp> <accomp>]
sent [LCP ConfNak id=0x4 <magic 0x157e12dc>]
rcvd [LCP ConfNak id=0x4 <magic 0x157e12dc>]
sent [LCP ConfReq id=0x5 <asyncmap 0x0> <magic 0x9f207c88> \
<pcomp> <accomp>]
rcvd [LCP ConfReq id=0x5 <asyncmap 0x0> <magic 0x9f207c88> \
<pcomp> <accomp>]
sent [LCP ConfNak id=0x5 <magic 0x54b74a7f>]
rcvd [LCP ConfNak id=0x5 <magic 0x54b74a7f>]
sent [LCP ConfReq id=0x6 <asyncmap 0x0> <magic 0xa2f3d5b> \
<pcomp> <accomp>]
rcvd [LCP ConfReq id=0x6 <asyncmap 0x0> <magic 0xa2f3d5b> \
<pcomp> <accomp>]
sent [LCP ConfNak id=0x6 <magic 0xa99662e6>]
rcvd [LCP ConfNak id=0x6 <magic 0xa99662e6>]
sent [LCP ConfReq id=0x7 <asyncmap 0x0> <magic 0x930fb55a> \
<pcomp> <accomp>]
rcvd [LCP ConfReq id=0x7 <asyncmap 0x0> <magic 0x930fb55a> \
<pcomp> <accomp>]
sent [LCP ConfNak id=0x7 <magic 0xb742003f>]
rcvd [LCP ConfNak id=0x7 <magic 0xb742003f>]
sent [LCP ConfReq id=0x8 <asyncmap 0x0> <magic 0x3e65be4f> \
<pcomp> <accomp>]
rcvd [LCP ConfReq id=0x8 <asyncmap 0x0> <magic 0x3e65be4f> \
<pcomp> <accomp>]
sent [LCP ConfNak id=0x8 <magic 0xc5b4a12b>]
rcvd [LCP ConfNak id=0x8 <magic 0xc5b4a12b>]
sent [LCP ConfReq id=0x9 <asyncmap 0x0> <magic 0x88a2377a> \
<pcomp> <accomp>]
rcvd [LCP ConfReq id=0x9 <asyncmap 0x0> <magic 0x88a2377a> \
<pcomp> <accomp>]
sent [LCP ConfNak id=0x9 <magic 0x33b83f9>]
rcvd [LCP ConfNak id=0x9 <magic 0x33b83f9>]
sent [LCP ConfReq id=0xa <asyncmap 0x0> <magic 0x5a3b64bc> \
<pcomp> <accomp>]
rcvd [LCP ConfReq id=0xa <asyncmap 0x0> <magic 0x5a3b64bc> \
<pcomp> <accomp>]
sent [LCP ConfNak id=0xa <magic 0x4ab2b779>]
rcvd [LCP ConfNak id=0xa <magic 0x4ab2b779>]
Serial line is looped back.
sent [LCP TermReq id=0xb "Loopback detected"]
rcvd [LCP TermReq id=0xb "Loopback detected"]
sent [LCP TermAck id=0xb]
rcvd [LCP TermAck id=0xb]
Connection terminated.
Exit.

What's going wrong here?

Jens

Jens Granseuer <jensgr@gmx.net> writes:

]Jens Granseuer wrote:
]> unruh@string.physics.ubc.ca (Bill Unruh) wrote:
]>>]> > 'OK-+++\c-OK' ATH0 \
]>>]> > TIMEOUT 45 \
]>>]> > OK ATDT019231760 \
]>>]> > CONNECT ''"
]>>
]>>You almost never want to have this You want
]>>CONNECT '\d\c'
]>>instead.
]>
]>
]> Ok, the effect is the same in this case, though.

]Looks like I was only partly correct here. '\d\c' indeed shows the same
]symptoms. However, '\\d\\c' does not! I don't know why but '\d\c'
]always gets sent as 'dc^M'.

When I said '\d\c' I meant c'\d\c' incuding teh single quote signs.
But fine, if \\d\\c works then use it.


]So, with '\\d\\c' I finally got one step further. Now I
]get LCP messages.

Good. We have gotten a connnection.



]Connect: ppp0 <--> /dev/ham
]sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x13ab0e8f> \
] <pcomp> <accomp>]
]rcvd [LCP ConfReq id=0xad <asyncmap 0xa0000> <auth pap> \
] <magic 0x4e51c3f6> <pcomp> <accomp>]
]sent [LCP ConfRej id=0xad <auth pap>]

It looks like you forgot to set up the /etc/ppp/pap-secrets file or
forgot to use the
user username
option (where username is your username on the remote system.


]rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x13ab0e8f> \
] <pcomp> <accomp>]
]rcvd [LCP ConfReq id=0xae <asyncmap 0xa0000> <auth chap MD5> \
] <magic 0x4e51c3f6> <pcomp> <accomp>]
]sent [LCP ConfRej id=0xae <auth chap MD5>]

Or the /etc/ppp/chap-secrets file.

No way will they let you log on without authenicating yourself.



]What's going wrong here?

See above.


]Jens

Jens Granseuer <jensgr@gmx.net> wrote:
> rcvd [LCP ConfReq id=0xb0 <asyncmap 0xa0000> <auth chap MD5> \
> <magic 0x4e51c3f6> <pcomp> <accomp>]
> sent [LCP ConfRej id=0xb0 <auth chap MD5>]
> rcvd [LCP ConfReq id=0xb1 <asyncmap 0xa0000> <auth pap> \
> <magic 0x4e51c3f6> <pcomp> <accomp>]
> sent [LCP ConfRej id=0xb1 <auth pap>]
> rcvd [LCP TermReq id=0xb2]
> sent [LCP TermAck id=0xb2]

The peer sends a Terminate-Request and pppd Ack's it.

> sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x13ab0e8f> \
> <pcomp> <accomp>]
> sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x13ab0e8f> \
> <pcomp> <accomp>]
> rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x13ab0e8f> \
> <pcomp> <accomp>]
> sent [LCP ConfNak id=0x1 <magic 0x584c80b8>]
> rcvd [LCP ConfNak id=0x1 <magic 0x584c80b8>]

Ect. Here pppd is having a long conversation with itself; the ISP
has disconnected but pppd doesn't seem to realize it needs to exit.
That's odd since it Ack'ed the ISP's Terminate-Request. We'd be
interested in seeing what options are used. By temporarily adding
the pppd option dryrun and then running wvdial, the options should
be sent to standard output.

> sent [LCP TermAck id=0xb]
> rcvd [LCP TermAck id=0xb]
> Connection terminated.
> Exit.

> What's going wrong here?

Just configuring the {pap,chap}-secrets files, as suggested by Bill
Unruh, may do the trick.

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

Clifford Kite wrote:
> Bill Unruh <unruh@string.physics.ubc.ca> wrote:
>>It looks like you forgot to set up the /etc/ppp/pap-secrets file
>>or forgot to use the user username option (where username is your
>>username on the remote system.

[...]

>>Or the /etc/ppp/chap-secrets file.
>
>
>>No way will they let you log on without authenicating yourself.
>
> Absolutely.

Er, yes, that was stupid. I installed ppp 2.4.2beta to see
whether that would help, and in the process overwrote my
chap-secrets. Duh!

It's working now. Thanks a lot, guys. You've saved the life of
an (almost) innocent modem and probably quite a lot of hairs
on this end. Thanks!

Jens