Re: Dialup PPP fails after new server, admins at ISP

[Mike Spencer]

Thanks, Old Guy, for your thoughful reply. For now, I'm going to
stick with the technical stuff and leave your other remarks, however
cogent ;-), for a later reply.

One part of the problem has been indentified: When Fibernetics took
over the actual servers for ca.inter.net, they screwed up part of the
authentication database. That's been dealt with and now my wife's
Win-XP box can connect via dialup and PPP to the new server.

Still no luck with Linux. More details up-thread on
comp.os.linux.networking.

Moe Trin <ibup...@painkiller.example.tld.invalid> wrote:

> Mike Spencer wrote:
>
>> Does anyone know enough about configuring the ISP end of dialup to
>> tell me what I need to tell the Fibernetics guys so that they can
>> get their house in order? I am seriously vexed at this point.
>
> Yes, but he doesn't monitor this Usenet newsgroup - see if he
> responds in "comp.protocols.ppp". Also, to be helpful, he'll need
> to see the exact Login banner they send - so he knows _which_ of the
> many server implementations is in use.

(So: Cross posting to comp.protocols.ppp)

Since Win-XP can now connect, this is (probably?) no longer about
telling the Fibernetics admins what to do. I need to figure out how
to connect with Linux.

If I connect using Minicom, this is the banner I see:

atdt18442449946
CONNECT 24000/ARQ/V34/LAPM/V42BIS
C
; TOR01AD-AS54a.ne.fibernetics.ca 3/33 ^G


User Access Verification

Username: login: mspe...@ca.inter.net
Password: <passwd entered>

% Authentication failed

That's an actual control-G there that I've replaced with caret-G for
usenet context. And what's with that single 'C' character?
TOR01AD-AS54a.ne.fibernetics.ca has no DNS A record but is ID'd by
RDNS as 208.72.120.45.


Here are the the pppd script and chat script that I invoke:


#!/bin/tcsh -f

setenv TELEPHONE 18442449946

set LOCAL_IP = 0.0.0.0
set REMOTE_IP = 0.0.0.0
set NETMASK = 255.255.255.0
set DIALER_SCRIPT=/home/mds/bin/istar-dialer

eval /usr/sbin/pppd kdebug 7 debug lock modem crtscts /dev/ttyS0 115200 \
asyncmap 20A0000 escape FF ${LOCAL_IP}:$REMOTE_IP \
noipdefault netmask $NETMASK defaultroute \
remotename istar user mspe...@ca.inter.net connect $DIALER_SCRIPT &
--------------

#!/bin/sh

exec /usr/sbin/chat -e -v \
TIMEOUT 3 \
ABORT 'BUSY' \
ABORT 'NO ANSWER' \
ABORT 'NO DIALTONE' \
'' 'ATZ' \
'OK-+++\c-OK' "ATV1Q0&C1&D2X4S0=0H0S7=60" \
TIMEOUT 120 \
OK "ATDT$TELEPHONE" \
CONNECT "\d\c"
--------------------------------

I've tried variations of the last "send" string, "\d\c", "\\d\\c", "\c".
as well as adding

\
BIS "\c"

to the above.

After running the above, /var/log/ppp has this to say:

Dec 11 01:16:02 bogus chat[5452]: ATDT18442449946^M^M
Dec 11 01:16:02 bogus chat[5452]: CONNECT
Dec 11 01:16:02 bogus chat[5452]: -- got it
Dec 11 01:16:02 bogus chat[5452]: send (\d)
Dec 11 01:16:03 bogus pppd[5450]: Serial connection established.
Dec 11 01:16:03 bogus pppd[5450]: using channel 7
Dec 11 01:16:03 bogus pppd[5450]: Using interface ppp0
Dec 11 01:16:03 bogus pppd[5450]: Connect: ppp0 <--> /dev/ttyS0
Dec 11 01:16:04 bogus pppd[5450]: sent [LCP ConfReq id=0x1
<asyncmap 0x20a0000> <magic 0x7b6b2af6> <pcomp> <accomp>]
Dec 11 01:16:31 bogus last message repeated 9 times
Dec 11 01:16:34 bogus pppd[5450]: LCP: timeout sending Config-Requests
Dec 11 01:16:34 bogus pppd[5450]: Connection terminated.
Dec 11 01:16:34 bogus pppd[5450]: Receive serial link is not 8-bit clean:
Dec 11 01:16:34 bogus pppd[5450]: Problem: all had bit 7 set to 0
Dec 11 01:16:34 bogus pppd[5450]: Hangup (SIGHUP)
Dec 11 01:16:34 bogus pppd[5450]: Modem hangup
Dec 11 01:16:34 bogus pppd[5450]: Exit.


I'm not fuly confident in slsnif (does /dev stuff I don't fully
understand) but I used it to sniff the serial port and it appears that
the remote host is responding to my ConfReq packets with octets
similar to the ones I send except that all of them are 7-bit, tending
to confirm what pppd reports in the log. pppd would be correct in
ignoring that as not LCP packets.

At the point where pppd reports sending ConfReq packets, slsnif
reports that I'm sending:

7e 7d df 7d 23 c0 21 7d 21 7d 21 7d 20 7d 34 7d
22 7d 26 7d 22 7d 2a 7d 20 7d 20 7d 25 7d 26 ac
ba 83 7d 27 7d 27 7d 22 7d 28 7d 22 ba 7d 2c 7e

to which the server replies:

7e 7d 5f 7d 23 40 21 7d 21 7d 21 7d 20 7d 34 7d
22 7d 26 7d 22 7d 2a 7d 20 7d 20 7d 25 7d 26 2c
3a


My wife's Win-XP log reports (on a successful connection) how many
bytes exchanged but regretably doesn't report the actual octet values
exchanged in the LCP/PPP handshake. (I haven't used Windoes since
3.1. There may be helpful logs on her machine that I don't know
about. ??)

I might reiterate that I have two dialup ISPs; one is working fine for
both Win-XP and Linux; the failing one worked fine with PAP auth
until Fibernetics replaced the server with a new one and "out of the
box" software; now that one works for Win-XP but not Linux.

I'm stumped. I don't know how to trick the server into responding
correctly to my LCP packets.

Cross-posted to comp.protocols.ppp and comp.os.linux.networking.

Any guidance very welcome,
- Mike

--
Mike Spencer Nova Scotia, Canada

[Moe Trin]

On 11 Dec 2014, in the Usenet newsgroups comp.os.linux.networking and
comp.protocols.ppp, in article <871to63...@bogus.nodomain.nowhere>,

Mike Spencer wrote:

>One part of the problem has been indentified: When Fibernetics took
>over the actual servers for ca.inter.net, they screwed up part of the
>authentication database.

That really has happened before, and it drives people crazy.

>That's been dealt with and now my wife's Win-XP box can connect via
>dialup and PPP to the new server.

which puts us back into familiar territory.

>Since Win-XP can now connect, this is (probably?) no longer about
>telling the Fibernetics admins what to do. I need to figure out how
>to connect with Linux.

Exactly - and we revert to the classic problem that "something" you
are doing is sending text to the peer at the wrong time. It's going
to revolve around that 'chat' dialog. As you are aware, a text-based
attempt to log in is not going to work, and we've GOT to emulate what
windoze does exactly.

>Here are the the pppd script and chat script that I invoke:

> #!/bin/tcsh -f

Hold on a second, while I attempt to remember how a C shell works - I
haven't used one since about 1995 on SunOS 4.1.3 ;-)

COMMENT: You're making things more complicated than you need to.

> set LOCAL_IP = 0.0.0.0
> set REMOTE_IP = 0.0.0.0
> set NETMASK = 255.255.255.0

Not needed

> eval /usr/sbin/pppd

That giant crash you just heard is me trying to find my O'Reilly "UNIX
In A Nutshell" book... OK, I think.

>kdebug 7 debug

Not needed - The 'debug' depends on you setting up your logging
daemon (/etc/syslog.conf perhaps) to put "daemon.debug" messages into
a known file.

>lock modem crtscts /dev/ttyS0 115200

OK

>asyncmap 20A0000 escape FF ${LOCAL_IP}:$REMOTE_IP

PROBABLY not needed

>noipdefault

probably not needed. The peer is going to supply both addresses of
the link.

>netmask $NETMASK

Not needed

>defaultroute

OK

>remotename istar

PROBABLY not needed

>user mspe...@ca.inter.net connect $DIALER_SCRIPT &

OK

> #!/bin/sh
> exec /usr/sbin/chat -e -v

OK

> TIMEOUT 3 \
> ABORT 'BUSY' \
> ABORT 'NO ANSWER' \
> ABORT 'NO DIALTONE' \

I usually ignore dinking with the TIMEOUT - the default is 45 seconds
and if the modem takes any extra time at all, there's something else
that needs to be looked at.

> '' 'ATZ' \
> 'OK-+++\c-OK' "ATV1Q0&C1&D2X4S0=0H0S7=60"

1. Check your modem manual - ATZ resets the modem to "some" stored
condition, and I normally use AT&Fn (where n may be 0 or 1 depending
on the brand) which resets things to "factory defaults".
2. The "OK-+++\c-OK" sequence makes no sense. Traditionally, this
was to expect the modem to respond with an "OK", and if it didn't,
send the Hayes command escape sequence to take the modem back to
command mode (under the assumption that it thought it was connected
and off-hook). It then sent a ATH0 which was supposed to hang up
the phone. If the modem is somehow in this weird mode, I'd rather
know about it now than at the end of the month when I get an enormous
phone bill from the modem keeping the line tied up.
3. The last command sequence is modem brand dependent, but normally
would be trying to set things to sensible conditions - which is what
the modem initialization/reset string "should" be doing.

> TIMEOUT 120 \
> OK "ATDT$TELEPHONE" \
> CONNECT "\d\c"

As above on the timeout - otherwise OK

>I've tried variations of the last "send" string, "\d\c", "\\d\\c",
>"\c". as well as adding

> BIS "\c"

This is the area where the problem lies.

>After running the above, /var/log/ppp has this to say:
>
> Dec 11 01:16:02 bogus chat[5452]: ATDT18442449946^M^M
> Dec 11 01:16:02 bogus chat[5452]: CONNECT
> Dec 11 01:16:02 bogus chat[5452]: -- got it
> Dec 11 01:16:02 bogus chat[5452]: send (\d)
> Dec 11 01:16:03 bogus pppd[5450]: Serial connection established.

OK, now _that_ says things worked.

> Dec 11 01:16:34 bogus pppd[5450]: Receive serial link is not
>8-bit clean:
> Dec 11 01:16:34 bogus pppd[5450]: Problem: all had bit 7 set to 0

And that says you're talking to a terminal server, rather than a ppp
daemon. "It was something that you said" - but I don't see you saying
anything. The "send (\d)" is ``normal'' as I just proved to myself by
connecting to a local ISP and seeing

CONNECT
-- got it
send (\d)
chat: Dec 11 11:31:33 CONNECT 45333/ARQ/V92/LAPM/V44
Serial connection established.
Using interface ppp0
Connect: ppp0 <--> /dev/ttyACM0
PAP authentication succeeded

The '/dev/ttyACM0' is a US Robotics 5637 USB modem, and I told chat
to "REPORT CONNECT" which shows the text that the modem returned.

>I'm not fuly confident in slsnif (does /dev stuff I don't fully
>understand) but I used it to sniff the serial port and it appears that
>the remote host is responding to my ConfReq packets with octets
>similar to the ones I send except that all of them are 7-bit, tending
>to confirm what pppd reports in the log.

The terminal server is (I think) just echoing what you sent.

>My wife's Win-XP log reports (on a successful connection) how many
>bytes exchanged but regretably doesn't report the actual octet values
>exchanged in the LCP/PPP handshake. (I haven't used Windoes since
>3.1. There may be helpful logs on her machine that I don't know
>about. ??)

I'm in the same boat - I have notes that say "go to Control Panel ->
Modems -> Properties -> Connection -> Advanced" and check Record a
log file" but I don't think it's going to help us here.

>I might reiterate that I have two dialup ISPs; one is working fine
>for both Win-XP and Linux; the failing one worked fine with PAP auth
>until Fibernetics replaced the server with a new one and "out of the
>box" software; now that one works for Win-XP but not Linux.

Are you using the "same" dialin scripts? Something your Fibernetics
script is doing is sending the peer into text mode. Let me see if
I can gather the pieces together here:

1. TEMPORARILY rename /etc/ppp/options to /etc/ppp/OPTIONS to get it
out of the way.
2. Run the following (enormous) one-line script. As long as you're
running a text-based shell, the actual shell shouldn't matter (i.e.
/bin/sh, /bin/bash, /bin/csh, /bin/dash or /bin/ksh should ALL work).

exec /usr/sbin/pppd user mspe...@ca.inter.net lock crtscts
nodetach defaultroute modem 115200 noipdefault /dev/modem connect
"/usr/sbin/chat -v ABORT BUSY \"\" AT\&F1 OK ATDT18442449946
CONNECT \"\d\c\""

That's 200 characters long. I think I've got the name and number
correct, and the rest is the minimum needed to get things going. Cut
and paste that as one line to a script, and try it.

I mentioned duplicating /etc/ppp/pap-secrets to /etc/ppp/chap-secrets
just to cover all bases. There's no sign that it's a problem here,
but I have a dial-up account with an ISP that has nine "local" access
numbers that actually connect to three different Point-Of-Presence
providers (much like Telus was for you), and one of them insists on
using CHAP, while another insists on PAP, and the third requests
CHAP but will fall back to PAP if I refuse CHAP, and this is all the
"same" ISP/account.

>I'm stumped. I don't know how to trick the server into responding
>correctly to my LCP packets.

The trick is to avoid sending it into text-mode by sending anything
with chat (or equal). Once the peer goes into text-mode, the game is
over, and there's nothing to do but hang up and try again more
carefully. ;-)

Old guy

[Mike Spencer]

Skipping ahead and, once again, beginning with the technical stuff,

Moe Trin <ibup...@painkiller.example.tld.invalid> wrote:

> Mike Spencer wrote:
>

>> I might reiterate that I have two dialup ISPs; one is working fine
>> for both Win-XP and Linux; the failing one worked fine with PAP
>> auth until Fibernetics replaced the server with a new one and "out
>> of the box" software; now that one works for Win-XP but not Linux.
>
> Are you using the "same" dialin scripts?

No. The other, still locally managed, ISP is still using text mode
auth.

> Something your Fibernetics script is doing is sending the peer into
> text mode. Let me see if I can gather the pieces together here:
>
> 1. TEMPORARILY rename /etc/ppp/options to /etc/ppp/OPTIONS to get
> it out of the way.

Not relevant if the connection is never getting far enough into LCP to
negotiate PAP (or CHAP or whatever).

>> remotename istar [in my pppd invocation]
>
> PROBABLY not needed

My pap-secrets file has:

<username> "istar" <password>

I think if I replaced "istar" with "*", then "remotename istar"
wouldn't be needed in the pppd invocation. Otherwise, it is needed.

> 2. Run the following (enormous) one-line script. As long as you're
> running a text-based shell, the actual shell shouldn't matter (i.e.
> /bin/sh, /bin/bash, /bin/csh, /bin/dash or /bin/ksh should ALL
> work).
>
> exec /usr/sbin/pppd user mspe...@ca.inter.net lock crtscts
> nodetach defaultroute modem 115200 noipdefault /dev/modem connect
> "/usr/sbin/chat -v ABORT BUSY \"\" AT\&F1 OK ATDT18442449946
> CONNECT \"\d\c\""

Bingo! That connects. I owe you a beer (or Laphroig or other
beverage of choice) should you be in Nova Scotia.

So: doing extensive, if not *quite* exhaustive, testing, it appears
that the source of the problem was the "escape FF" option to pppd.
The other item you flagged as "not needed",

>> set LOCAL_IP = 0.0.0.0
>> set REMOTE_IP = 0.0.0.0
>> set NETMASK = 255.255.255.0

>> [pppd ...] kdebug 7 debug
>> [pppd ...] netmask $NETMASK
>
> Not needed...
>
>> [pppd ...] noipdefault
>> [pppd ...] asyncmap 20A0000 ${LOCAL_IP}:$REMOTE_IP
>
> PROBABLY not needed

don't seem make any difference one way or the other. But removing or
inserting "escape FF" turns it on and off.

I have no recollection where that (or the other "not needed") elements
came from, lost in the distant past after several changes, alarums and
excursions.

So now I've ported your one-liner into a stripped-down script to call
pppd which in turn references another that runs your chat invocation.

An aside on the modem init: The Win-XP log *does* show the modem init
strings XP uses. I see some that don't appear in any of the Hayes or
USR docs I have:

+MR=2;
+DR=1;
+ER=1;
W2
+ES=3,0,2;
+DS=3;
+IFC=2,2;
#ud

All but the last produce ERROR responses from my modem. AT#UD produces
what appears to be cryptic diagnostic info. Dunno what *that's* about.

> ...I have a dial-up account with an ISP that has nine "local" access

> numbers that actually connect to three different Point-Of-Presence
> providers (much like Telus was for you), and one of them insists on
> using CHAP, while another insists on PAP, and the third requests
> CHAP but will fall back to PAP if I refuse CHAP, and this is all the
> "same" ISP/account.

Isn't that nice? :-\ With my two completely differentr ISPs, I have a
script, called from each of the scripts that starts a connection to
one or the other ISP, that swaps in the right version of
/etc/mail/mailertable.db so sendmail will go to the right smarthost
for outgoing mail.

In your previous post, you wrote:

> Sounds like it's time to find another ISP.

Easier said than done where I am. With a lot of bother (with
antennae, cables, poles, guys in the yard trying to get signal
somewhere) I could have wireless broadband, just one notch faster than
the very slowest of wired broadband services.

In any case, I've been with the offending ISP since they were a bunch
of guys I knew doing a startup in Nova Scotia in the mid-90s. IPO'd,
borged, spun off, mergered, sold, sold again but I'm a long-time
customer. Better the devil you know than the devil you don't. Frying
pan/fire etc. I'll have to bite the wax tadpole and do the Rural
Wireless one of these days.

>> [Quoting various stupid or false assertions by "support"...]
>
> Code speak for "we don't want your dial-up business - you must
> upgrade to our new Fiber service".

Oddly, Fibernetics (or their subsidiary Worldline) seems to be
advertising dialup. OTOH, their mojo seems to be centered around the
newest, cheapest, fastest (and dirtiest? No 911?) telecom tech. And
their fancy telecom service isn't available here in any case.


Thank you very much for your point-by-point attention. Now, if the
torrential rain will just stop, I can get out into the yard or the
blacksmith shop and do something more productive than try to fix
something that somebody else broke. (You're in Phoenix? Torrential
rain is probably not a problem there. :-)

Best & tnx,
- Mike

--
Michael Spencer Nova Scotia, Canada .~.
/V\
/( )\
http://home.tallships.ca/mspencer/ ^^-^^

[Moe Trin]

On 12 Dec 2014 22:34:50 -0400, in the Usenet newsgroups comp.protocols.ppp and
comp.os.linux.networking, in article <87r3w4s...@bogus.nodomain.nowhere>,

Mike Spencer wrote:

>Moe Trin <ibup...@painkiller.example.tld.invalid> wrote:

>>> Mike Spencer wrote:

>> Are you using the "same" dialin scripts?

>No. The other, still locally managed, ISP is still using text mode
>auth.

Wow! How do they get windoze boxes to connect? If they're using the
ordinary windoze Dial-Up-Networking app, that's a non-text mode, and
you're very lucky that the ISP went the extra mile to configure the
text mode.

>> 1. TEMPORARILY rename /etc/ppp/options to /etc/ppp/OPTIONS to get
>> it out of the way.

>Not relevant if the connection is never getting far enough into LCP to
>negotiate PAP (or CHAP or whatever).

Actually, it depends on what you've got in there. The file is read
when the pppd program starts, not when it needs a particular variable.
The idea was to avoid accidental confusion.

>> PROBABLY not needed

>My pap-secrets file has:

> <username> "istar" <password>

>I think if I replaced "istar" with "*", then "remotename istar"
>wouldn't be needed in the pppd invocation. Otherwise, it is needed.

Correct. I use the 'user' option to select the right secret to use
(like you, I have multiple ISPs, and my single dialing script takes
a number to specify which of <currently> 16 phone-numbers/ISPs to use
OR the word "next" to use the "next" number in rotation).

>> 2. Run the following (enormous) one-line script.

>Bingo! That connects. I owe you a beer (or Laphroig or other
>beverage of choice) should you be in Nova Scotia.

Haven't been there in maybe 35 years, but glad to be able to help.

>So: doing extensive, if not *quite* exhaustive, testing, it appears
>that the source of the problem was the "escape FF" option to pppd.

James? I _think_ that might work if you used "escape 0xff", but
the usual mantra is "if you don't KNOW you need it, don't use it". (My
"C" language skills are decidedly "emergency use only", and I don't
see the clues I need in the ppp-2.4.7/pppd/options.c source file.)

>I have no recollection where that (or the other "not needed")
>elements came from, lost in the distant past after several changes,
>alarums and excursions.

That's partly why I always recommend using that "one-liner" to see if
you can get things working.

>So now I've ported your one-liner into a stripped-down script to call
>pppd which in turn references another that runs your chat invocation.

That will work!

>An aside on the modem init: The Win-XP log *does* show the modem init
>strings XP uses. I see some that don't appear in any of the Hayes or
>USR docs I have:

Supposedly, microsoft did query the various modem manufacturers to try
to get "best" strings, to use, but that assumes windoze can ID the
modem (or the user manages to tell windoze the right stuff). I've
found using the factory defaults works every time. "A" problem about
using ATZ is that it may pull up a "saved" configuration (AT&Wn on USR
modems) that was b0rken accidentally. On the other hand, virtually
every modem knows ATZ, but not all have a AT&Fn or equal.

>I see some that don't appear in any of the Hayes or USR docs I have:

> +MR=2; +DR=1; +ER=1; +ES=3,0,2;
> +DS=3; +IFC=2,2;

Plus commands are often Rockwell chip-set, and refer to FAX modes.

> W2

Rockwell - report DCE speed on connect, rather than DTE (port) speed.

> #ud

Got me there - not in any of my books

>> ...I have a dial-up account with an ISP that has nine "local"
>> access numbers that actually connect to three different
>> Point-Of-Presence providers

>Isn't that nice? :-\ With my two completely differentr ISPs, I have a
>script, called from each of the scripts that starts a connection to
>one or the other ISP, that swaps in the right version of
>/etc/mail/mailertable.db so sendmail will go to the right smarthost
>for outgoing mail.

[fermi ~]$ wc /usr/local/bin/dialin
189 539 5055 /usr/local/bin/dialin
[fermi ~]$ wc /etc/ppp/ip-*local
31 167 984 /etc/ppp/ip-down.local
127 640 4492 /etc/ppp/ip-up.local
158 807 5476 total
[fermi ~]$

Lots of 'if elif else' and and a couple of case statements. ;-)

>> Sounds like it's time to find another ISP.

>Easier said than done where I am. With a lot of bother (with
>antennae, cables, poles, guys in the yard trying to get signal
>somewhere) I could have wireless broadband, just one notch faster
>than the very slowest of wired broadband services.

In 1996, we got transferred to Phoenix, Arizona, which is not all that
bad, though quite large. I'm about 21 miles North of city hall (but
still 6 miles South of the northern city boundary) which is a bit off
the beaten path. When we moved here, the only options were a not
very reliable (but expensive) wireless link, or the standard copper
telephones. We went with the latter (had three lines - one for phone,
one for "our" modem use, and one provided by my wife's employer for
business use). The local cable company (Cox) finally dragged in some
lines (everything here is underground - we see several thunderstorms
in the Metro area each year that blow down a half mile or so of pole
line). Not to be out-done, the local telco (US West, which was borged
into QWest, which has been bought by CenturyLink) pulled fiber far
enough to set up road-side Remote Access Multiplexers to permit DSL
in the area using existing copper. Currently, CenturyLink has pulled
fiber into the local streets, and is flogging that as the latest
greatest thing ever... (at exorbitant but wildly varying quoted
prices, plus taxes and fees).

>In any case, I've been with the offending ISP since they were a bunch
>of guys I knew doing a startup in Nova Scotia in the mid-90s. IPO'd,
>borged, spun off, mergered, sold, sold again but I'm a long-time
>customer. Better the devil you know than the devil you don't. Frying
>pan/fire etc. I'll have to bite the wax tadpole and do the Rural
>Wireless one of these days.

Yup - know the problem all too well.

>> Code speak for "we don't want your dial-up business - you must
>> upgrade to our new Fiber service".

and now you have an idea where I'm coming from with that. Verizon,
which now owns/operates the copper in the New York city region has
been pushing this one hard. See news://comp.risks/ such as Risks-
Forum Digest Volume 28 issues 01 ("When the Landline Is a Lifeline")
and 20 ("How Verizon lets its copper network decay to force phone
customers onto fiber") as examples.

>Thank you very much for your point-by-point attention.

Glad to be able to help!

>Now, if the torrential rain will just stop, I can get out into the
>yard or the blacksmith shop and do something more productive than
>try to fix something that somebody else broke. (You're in Phoenix?
>Torrential rain is probably not a problem there. :-)

Actually, we had a deluge a couple of weeks ago that flooded out the
Interstate 10 when several underpasses had their drains clogged. And
over this last night, I got 0.35 inches, which brings me to 11.33
inches for the year which is a bit over my 10-year average (10.90
inch). The official City of Phoenix average is 7.66 inch and the
current, 8.35 inches. Most of the rainfall here is thunderstorms
("Cloudburst" from "Grand Canyon Suite" by Ferde Grofe'), so rain
tends to be hit-or-miss. This shows up in the "standard deviation" of
the annual rates - in my case, it's 3.57", and I've seen years with
5.11 to 17.44 inches at the extremes. Phoenix has longer records than
I do, and their extremes are 2.82 (1956) to 19.73 (1905) inches for a
calender year. Hmmm... I hear thunder now... and it is spitting.

Old guy