jensgr@gmx.net (Jens Granseuer) wrote:
>Hi,
>
>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.
>
>This is an extract from the log:
>
>Jun 19 19:50:24 fizz pppd[329]: pppd 2.4.1 started by fizz, uid 500
....
>Jun 19 19:51:00 fizz pppd[329]: Serial connection established.
>Jun 19 20:55:07 fizz pppd[329]: Hangup (SIGHUP) <--- kill

This appears to indicate that your chat script is correct, and
that it does make a serial connection.

>
>/etc/ppp/options:
>115200
>/dev/ham
>modem
>crtscts
>lock
>defaultroute
>noipdefault
>auth
>idle 600
>noipx
>ipcp-accept-local
>ipcp-accept-remote
>usepeerdns
>mtu 576
>debug

Add a line to the /etc/ppp/options file:

debug 1

You might want to try something like "debug 7", although the
amount of information that supplies could well swamp you.

You will need to make another attempt at a connection, and then
take a look at your log files. Which log file has the info in it
will depend on how your syslog is configured, but look in /var/log
and see if there is a "debug" file. If so, that is probably where
you'll find it.

What you will see are a series of exchanges between your pppd
and the ppp process at the opposite end of your serial
connection. Below is an example with debug set to 1. I've
chopped off the initial part of each line (the date/time stamp,
the hostname, and the process name and PID), as only the tail
end of each line is interesting. Each line that is wrapped
is done so with '\' and indented.

Something like this, though possibly with different specifics,
is what you should find. Instead I expect you will find
multiple requests for something, for example either CHAP or PAP
authentication, are going unanswered, and after multiple
attempts one side or the other is aborting.

If what you find doesn't give you a clue, cut and paste it into
an article and post it.

sent [LCP ConfReq id=0x1 <mru 576> <asyncmap 0x0> \
<magic 0x3ebe3b07> <pcomp> <accomp>]

rcvd [LCP ConfReq id=0x13 <asyncmap 0xa0000> <auth pap> \
<magic 0xdc9f9f3> <pcomp> <accomp>]

sent [LCP ConfAck id=0x13 <asyncmap 0xa0000> <auth pap> \
<magic 0xdc9f9f3> <pcomp> <accomp>]

sent [LCP ConfReq id=0x1 <mru 576> <asyncmap 0x0> \
<magic 0x3ebe3b07> <pcomp> <accomp>]

rcvd [LCP ConfNak id=0x1 <mru 1500>]

sent [LCP ConfReq id=0x2 <asyncmap 0x0> \
<magic 0x3ebe3b07> <pcomp> <accomp>]

rcvd [LCP ConfAck id=0x2 <asyncmap 0x0> \
<magic 0x3ebe3b07> <pcomp> <accomp>]

sent [PAP AuthReq id=0x1 user="xxxxxx" password=<hidden>]

rcvd [PAP AuthAck id=0x1 ""]

sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> \
<compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]

sent [CCP ConfReq id=0x1 <deflate 15> \
<deflate(old#) 15> <bsd v1 15>]

rcvd [IPCP ConfReq id=0x6 <compress VJ 0f 00> \
<addr 209.124.156.3>]

sent [IPCP ConfAck id=0x6 <compress VJ 0f 00> \
<addr 209.124.156.3>]

rcvd [IPCP ConfNak id=0x1 <addr 209.124.156.226> \
<ms-dns1 209.124.156.9> <ms-dns3 198.51.13.3>]

sent [IPCP ConfReq id=0x2 <addr 209.124.156.226> <compress VJ 0f 01> \
<ms-dns1 209.124.156.9> <ms-dns3 198.51.13.3>]

rcvd [LCP ProtRej id=0x14 80 fd 01 01 00 0f 1a 04 78 00 \
18 04 78 00 15 03 2f]

rcvd [IPCP ConfAck id=0x2 <addr 209.124.156.226> <compress VJ 0f 01> \
<ms-dns1 209.124.156.9> <ms-dns3 198.51.13.3>]

Script /etc/ppp/ip-up finished (pid 20424), status = 0x0


--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.com

Floyd Davidson <floyd@barrow.com> wrote:
> jensgr@gmx.net (Jens Granseuer) wrote:
>
> >/etc/ppp/options:

[...]

> >debug
>
> Add a line to the /etc/ppp/options file:
>
> debug 1
>
> You might want to try something like "debug 7", although the
> amount of information that supplies could well swamp you.

That gives me an error message
speed 1 not supported
in the log (speed 7 if I use debug 7). Looks like debug
doesn't take an argument (isn't given in the manpage either).
This is the pppd from http://www.samba.org/ppp/.
Is there another one which has those logging facilities?
Where can I get it?

> What you will see are a series of exchanges between your pppd
> and the ppp process at the opposite end of your serial
> connection. Below is an example with debug set to 1. I've
> chopped off the initial part of each line (the date/time stamp,
> the hostname, and the process name and PID), as only the tail
> end of each line is interesting. Each line that is wrapped
> is done so with '\' and indented.
>
> Something like this, though possibly with different specifics,
> is what you should find. Instead I expect you will find
> multiple requests for something, for example either CHAP or PAP
> authentication, are going unanswered, and after multiple
> attempts one side or the other is aborting.

I really expect the user setup to be correct. After all,
the same setup did work with my old modem (which broke
recently; that's why I need to go through all this).

Jens

jensgr@gmx.net (Jens Granseuer) writes:

]Floyd Davidson <floyd@barrow.com> wrote:
]> jensgr@gmx.net (Jens Granseuer) wrote:
]>
]> >/etc/ppp/options:

][...]

]> >debug
]>
]> Add a line to the /etc/ppp/options file:
]>
> debug 1

NO. debug takes no argument. Just use debug.
Note that you must also set up /etc/syslog.conf to direct the output for
daemon.* to some file.
eg
daemon.*;local2.* /var/log/daemonlog

and then do
killall -1 syslogd

The local2 is for the chat -v output, and daemon for the pppd output.


]Is there another one which has those logging facilities?
]Where can I get it?

no. He got confused with the old kdebug which did take an argument. It
was however almost useless except in very particular circumstances (not
yours).



]I really expect the user setup to be correct. After all,
]the same setup did work with my old modem (which broke
]recently; that's why I need to go through all this).


That probably means that your modem setup is wrong (wrong initialisation
stuff being sent to the modem) Every modem manufacturer makes up their
own modem commands, so you have to tailor your init script for the modem
to the modem. The place for this is in the chat script.