On Wed, 26 Sep 2012, in the Usenet newsgroup comp.os.linux.hardware, in article
<
Pine.LNX.4.64.12...@darkstar.example.net>, Michael Black wrote:
>Moe Trin wrote:
>> They're nice, and don't take up all that much deskspace, but they
>> have one MAJOR disadvantage: no speaker. Second disadvantage is
>> that they may have few (if any) indicators.
>The speaker and lights mean less in this day and age, where someone is
>likely to be dialing one number, their ISP. In the old days you'd be
>calling various places, all those BBSs if nothing else, and the lights
>and speaker were useful because it helped you tell if that system was
>down at the moment or it was something at your end.
[fermi ~]$ dialin --help
Usage: /usr/local/bin/dialin script_number { [0-9] | [10-19] | next }
[fermi ~]$
TWENTY different phone numbers??? Yup. That's actually three
different ISPs and four business related connections. Looking at the
logs, I see about 30 different terminal servers answering the phone.
>Now, you're likely to dial only your ISP, and only occasionally will
>there be a problem. If you havent' touched your system for a while,
>then the problem has to be at the ISP end, something you can't fix.
Less of a problem now, but the local telco used to have quite horrible
lines here, static, squeals, and occasional echos. Until they added
local "Remote Access Multiplexers" for DSL in 2002, the modems would
have trouble negotiating a 28.8 connection, and I've got stats showing
the modems actually speed shifting down to 9600 on occasion. Now, it
varies, but I can usually get at least 44.0 and sometimes higher.
>That said, in this day and age, Linux gives a fairly good set of
>messages when there is a problem. Set "debug" in /etc/ppp/options
>and you get a better picture of what's happening. Though, when my
>ISP had an issue amonth ago, it wasn't authenticating, the extra
>debug messages didn't tell me anything more than the usual message,
>it wasn't authenticating.
Never mind that fewer people are using pppd today, most of those who
are are using some ``helper'' program that hides a lot of details.
Your syslog daemon has to know to stick the "daemon:debug" messages
in the right log file. Modem problems are detected by calling chat
with the "-v" option and having the syslog daemon stick "
local2.info"
someplace useful. That gets you the dialog between chat and the
modem. I'm running pppd from a command line, and have added
"REPORT CONNECT" to the dialing string. Way down near the bottom of
that "/user/local/bin/dialin" file, the actual dirty work is done by
a single 168 character line:
/usr/sbin/pppd $DEV ipparam $IPPAR user $USERNAME connect
"/usr/sbin/chat REPORT CONNECT ABORT \"NO DIALTONE\" ABORT BUSY
\"\" $INITSTR OK ATDT$PHNUM CONNECT \"\d\c\""
The "REPORT CONNECT" results in something like
chat: Sep 27 06:03:29 CONNECT 49333/ARQ/V92/LAPM/V44
and because one of the options I'm using is "nodetach", I also get
the "PAP authentication succeeded" (or CHAP depending). The indication
that the ISP has their head up and locked is either
Connect script failed
which means chat didn't see a "CONNECT" string, or
Serial connection established.
Using interface ppp0
Connect: ppp0 <--> /dev/ttyACM0
LCP: timeout sending Config-Requests
Connection terminated.
which means the modem made contact, but their terminal server didn't
respond properly. An authentication failure usually lacks that LCP
timeout message, or it can actually come back with the "authentication
failed" message.
>I just say the multiple attempts to get authentication with "debug".
You mean multiple lines like
Jul 3 09:55:27 gtech pppd[924]: sent [PAP AuthReq id=0x1
user=<hidden>password=<hidden>]
or
Jul 3 09:55:27 gtech pppd[924]: sent [CHAP Response id=0x1
<f3b2eb25b1bba6bf509effa489083d14>, name =<hidden>]
with incrementing "id=" numbers? That usually means the RADIUS server
(RFC2865 and friends) is either tits up, or the network connection
from the terminal server (what you're dialing into) and the RADIUS
server is b0rked. Happens occasionally. CHAP is supposed to send
a "challenge" to initiate the authentication exchange, perhaps
Jul 3 09:55:27 gtech pppd[924]: rcvd [CHAP Challenge id=0x1
<a472f238cbf7a415e39c26f0115269e4>, name = "
abc123.example.com"]
and if you don't receive that, CHAP will fail. The pppd daemon on
your end knows we'll be using PAP or CHAP because the initial LCP
packet from the terminal server will contain an "auth" token like
"<auth pap>" or "<auth chap 05>", and your pppd will ConfAck that.
Old guy