modem

[MarcusKracht]

I have posted this question before, maybe this time someone answers.

I have Cacko 1.0.5 installed and a Socket 56K CF modem card. I am trying
to connect to the university, and I get until it says  something like
connection established:     ppp0 <--> ttyS3.
Then there is a communication with the server and the log says that the
 connection was terminated due to authentication failure. But I used the
 correct name and password.  I used \"AT\" as init string. There is a log
which I can show you if you need to know.

Is anyone else using this card? Can someone give me a hint as to how to
get this to work?

-- Marcus

[lardman]

Did you put the username & password combo in pap-secrets or chap-secrets?


Si

[MarcusKracht]

In both. I used the user interface, and it did that for me. -- Marcus

[lardman]

Post the log and the (suitably editted) script and I\'ll see if I can remember back to when I had troubles ;-) .......

Si

[MarcusKracht]

OK, here we go. I retyped the log since there is no file chat.log even though the
file ppp-on-sldialer has a line \"rm /etc/ppp/chat.log\". Now, retyping is slow.
I did my best. Here is the protocol:

abort on (NO CARRIER)
abort on (NO DIALTONE)
abort on (BUSY)
send (AT^M)
expect (OK)
AT^M^M
OK
-- got it

send (ATDT2068311^M)
expect (CONNECT)
^M
ATDT2068311^M^M
CONNECT
-- got it

Serial connection established
Using interface ppp0
Connect: ppp0 <--> /dev/ttyS3
sent [LCP ConfReq id=0x1 <asyncmap
0x0><magic 0xeb06a6a><pcomp>
<accomp>]
rcvd [LCP ConfReq id=0x4f<asyncmap
0xa0000><auth pap><magic
0x373afe24><pcomp><accomp>]
sent [LCP ConfAck id=0x4f<asyncmap
0xa0000><auth pap><magic
0x373afe24><pcomp><accomp>]
rcvd[LCP ConfAck id=0x1 <asyncmap
0x0><magic 0xeb06a6a><pcomp>
<accomp>]
sent [PAP AuthReq id=0x1
user=\"<myusername>\" password =<hidden>]
rcvd [LCP ConfReq id=0x51
<asyncmap 0xa0000><auth pap>
<magic 0x373b0dd5><pcomp>
<accomp>]
sent [LCP ConfReq id=0x2 <asyncmap
0x0><magic 0xe66a74a><pcomp>
<accomp>]
sent [LCP ConfAck id=0x51 <asyncmap
0xa0000><auth pap><magic
0x373b0dd5><pcomp><accomp>]
rcvd[LCP ConfAck id=0x2 <asyncmap
0x0><magic 0xe66a47a><pcomp>
<accomp>]
sent [PAP AuthReq id=0x2
user=\"<myusername>\" password=<hidden>]
rcvd[PAP AuthNak id=0x2 \"Password
validation failure\"]
Remote message: Password validation
failure
PAP authentication failed
sent [LCP TermReq=id 0x3 \"Failed to
authenticate ourselves to peer\"]
rcvd [TermReq id=0x8b]
sent [TermReq id=0x8b]
Modem hangup
Connection terminated

And this is the file /etc/ppp/chat.script:
TIMEOUT         3
ABORT           \'nBUSYr\'
ABORT           \'nNO ANSWERr\'
ABORT           \'nRINGINGrnrnRINGINGr\'
\'\'              AT
\'OK-+++c-OK\'   ATH0
@1
TIMEOUT         @2
OK              ATD@3@4
CONNECT

And here the file /etc/ppp/scripts/winclient.chat:
# /etc/ppp/options/winclient.chat
TIMEOUT 3600
CLIENT CLIENTSERVERc

I hope I have supplied what is needed. Might it also be that files are in the
wrong place? First the file chat.script was called chat.script.tmp and I
renamed it. Maybe it needs to go into /etc/ppp/scripts, but I really do not
know. Thanks very much,

                        Marcus

[MarcusKracht]

Just to bring this up again. In an earlier message I have sent the printout
from my modem session. I get the modem to dial in but then I get
\"Failed to authenticate ourselves to peer\". Now, all you users of a
Socket 56K with Zaurus and pdaXrom, could you please help me solve
the problem? I have tried my best to understand the logic of the PPP dia-
ler, but I do not know where it goes wrong and where I could change
something to make it work.(The other side of the modem connection is
the University, which does not seem to use fancy protocols.)

-- Marcus

[Ling]

Marcus, I am no expert, but just from the look of it, I think you have selected (or been forced to use) an incorrect authentication method. The administrator of your dialin server should be able to tell you what type of authentication to use. PAP and CHAP are the two common ones, but they may be using SPAP, MSCHAP (yes, M$ had to create their own) or another proprietary method. If you can select another method from your PPP GUI, I would try that. I am nearly certain that it has nothing to do with your modem.

[lardman]

Sorry I dropped out for a while.

I agree with the above, it\'s not to do with your modem. However if, as you say, your username & password are in both pap-secrets and chap-secrets then I\'m not too sure. What kind of system are you trying to dial into?

Another thing you could try is altering the chat script something like this (a long time ago I had a similar problem to you and it was caused by my Z not waiting for ppp to start on the other end. It might work, it might not):

Code: [Select]

And this is the file /etc/ppp/chat.script:

TIMEOUT 3

ABORT \'nBUSYr\'

ABORT \'nNO ANSWERr\'

ABORT \'nRINGINGrnrnRINGINGr\'

\'\' AT

\'OK-+++c-OK\' ATH0

@1

TIMEOUT @2

OK ATD@3@4

CONNECT

~ \'\'

Si

[MarcusKracht]

No problem, I am patient. Only that it is important for me to get this working.
The connection is:  V.90 (protocol), 8 bit, no parity,
   Hardware Handshaking (no XON/XOFF),
PPP (PAP) and SLIP
just for completeness:
IP address dynamicall provided, Gateway provided at connection
time, Network class \"B\".

I shall try and tinker with the chat script, though I am really not in
the know about these things. I do not know if there are other
programs, I have no clue either. Could one perhaps install a
dialer from debian source if this fails?

-- Marcus

[MarcusKracht]

I still fail to see how the programs hang together. pppdealer looks at
/etc/ppp/peers/<peername>, and it has in it a line saying

connect \'/usr/bin/chat -s -v  ...\'

Trying that on its own didn\'t work, the -s option is not supported. I don\'t
understand this. Anyway, I tweaked the thing and it shows me the welcome
of the provider plus the username/password interaction. Then apparently
pppd starts and sends these messages: sent LCP [...] as shown in an earlier
message, this time without rcvd [LCP ...]. Then it terminates with

LCP: timeout sending Config-Requests
Connection terminated
Receive serial link is not 8-bit clean:
Problem: all had bit 7 set to 0

Now, this can mean several things: (a) it is sending without receiving,
( it sends too fast, or © the modem has somehow gotten into 7bit
mode. If © I do not know how to change things. If (a) or ( I am
hoping to use my Laptop settings for LCP to resolve the matter. The
suggestion to make it wait may be it, but how?

-- Marcus

[MarcusKracht]

Finally, I solved the problem. It is worth seeing how.

The icon \"ppp modem\" writes into several files, but the pppdealer (yes!,
that\'s how it is called) uses only one:

 /etc/ppp/peers/<your-providername>.

The name of the file appears top right of the window for \"PPP dealer\".
The file it looks like this:

/dev/ttyS3
115200
connect \'/usr/sbin/chat -s -v ABORT \"NO CARRIER\" ....\'
crtscts
noipdefault
modem
user \"<nusername>\"
password \"<password>\"
connect-delay 6000

Now, what happened in my case is that the program doesn\'t wait to the
provider to give it a prompt and keeps sending its data and therefore
gets mixed up. Thus, I got rid of the lines \"user ...\" and \"password ...\"
and instead continued in the third line:

/dev/ttyS3
115200
connect \'/usr/sbin/chat -s -v ABORT \"NO CARRIER\" [...]
CONNECT \"\" \"Username:\" <myname> \"Password:\" <mypassword>
\"ine>\" ppp \"\"\'
[continue with pppd-defaults]

(Additional advantage: it displays the negotiation.)
This is because the provider prompts with \"Username:\" (some suitable
postfix like \"ername:\" would have done the job too). So if your provider
has a different prompt, you need to use that (a postfix of the prompt
is sufficient). The \"\" before that take care of the welcom message. No
quotes for the login name. Then it prompts \"Password:\", whereupon it
gets the password (again no quotes) and, finally there is a prompt ending
in \"OnLine>\", so I have the chat-program wait for that and then issue
ppp (no quotes). An additional \"\" listens to the welcome message and
the pppd can take over and does so gracefully.

I hope that others will find that useful. Thanks to those that helped me
with this.

-- Marcus

[henrysviper]

I have the same problem with Marcus. My setup is RC9 + Targus cf modem.

I cannot log in to any dial-up account: I have two that use PAP and one that uses CHAP and always the final message is "Failed to authenticate ourselves to peer" although username/password are correct. I had a look at the files under /etc/ppp and they look ok.
I tried to use the solution that Marcus proposes but when I try to connect "manually" so that I can see the prompts of the dial-up server I see only "garbage".

The same dial-up accounts worked with Sharp/Cacko ROM.
Any help would be greatly appreciated, as having dial-up connectivity means I can leave the laptop at home when I travel and get only the zaurus.

[darmabum]

I have the same problem with Marcus. My setup is RC9 + Targus cf modem.

I cannot log in to any dial-up account: I have two that use PAP and one that uses CHAP and always the final message is "Failed to authenticate ourselves to peer" although username/password are correct. I had a look at the files under /etc/ppp and they look ok.
[snip]

It's even weirder than that.  Try this:  1.  Use the PPPDialer (it will fail as you described), 2. Then use a terminal program to manually enter the pppd command (it will also fail), 3. Now enter the same command in the terminal and it will probably succeed (enter route -n to verify).

I can't confirm the order, or the number of attempts, but basically the same command will usually succeed on the third try or so...

jb

[telemetric_au]

how i got the pdax86 cd to connect after giving the fail pap authentication blog:

copy my peers file to /etc/ppp (prob not necessary but this way leaves original backup in /peers

add/check the "peers" file for these lines:  uname "", password ""  (putting your data between the ""'s)

then from promt type # pppd file /etc/ppp/(**peers-filename**)

edit resolv.conf with values shown by prompt, and all good... fix it up from there...


also having to work out problem of disconnecting after very short innactivity...