[tlug] Broken PPP connection to GOL -> Fusion

[Dennis McMurchy <denismcm@example.com>]

  Hi All,

  Nice to see that many familiar names are still part of the TLUG group.
I haven't been able to keep up with the flow and have been off the list
for the last two years.

  Coming to the point:  I'm unable to make a PPP connection to the new
local GOL (now FUSION) ISP number that will be my only option come May
31.  I've been connecting happily for years to the old number with the
following script:

----------------------------------------------------
# look in /etc/pap-secrets for password info
# in /etc/ppp/options  only 'lock' is specified

/usr/sbin/pppd connect '/usr/sbin/chat -v "" ATDT7241745 CONNECT "" \
 ' /dev/ttyS1 115200 -detach debug crtscts modem \
 defaultroute noipdefault noccp nodeflate nobsdcomp user denismcm   > ~/pppd.logold &
----------------------------------------------------

  I'm connecting over POTS with a 56K modem, I should probably add. Anyhow,
I assumed that I could just change the number (and make a few adjustments
for the change in authentication procedures) and I'd be all set.  Wrong.

  From the 'pppd' logfiles, it seems that the GOL host is just not responding
to LCP requests, so I never do get a chance to try and authenticate myself
in CHAP (the new protocol):

Serial connection established.
using channel 2
Using interface ppp0
Connect: ppp0 <--> /dev/ttyS1
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x91584863> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x91584863> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x91584863> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x91584863> <pcomp> <accomp>]
Modem hangup
Connection terminated.

  At the old number, I get a response after the second of these 'sent [LCP'
lines.

  I've tried extending the timeout period with the 'local' option to 'pppd'.
This does produce - finally - some response from the GOL host, but eventually
everything times out again anyway:

Using interface ppp0
Connect: ppp0 <--> /dev/ttyS1
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xa4a2d3f3> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xa4a2d3f3> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xa4a2d3f3> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xa4a2d3f3> <pcomp> <accomp>]
# normally we time out right here, but persistence yields a response, after
# all
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xa4a2d3f3> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xa4a2d3f3> <pcomp> <accomp>]
sent [LCP ConfNak id=0x1 <magic 0x5d53644c>]
rcvd [LCP ConfNak id=0x1 <magic 0x5d53644c>]
sent [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0x4ea41884> <pcomp> <accomp>]
sent [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0x4ea41884> <pcomp> <accomp>]
sent [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0x4ea41884> <pcomp> <accomp>]
sent [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0x4ea41884> <pcomp> <accomp>]
sent [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0x4ea41884> <pcomp> <accomp>]
sent [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0x4ea41884> <pcomp> <accomp>]
sent [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0x4ea41884> <pcomp> <accomp>]
sent [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0x4ea41884> <pcomp> <accomp>]
sent [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0x4ea41884> <pcomp> <accomp>]
sent [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0x4ea41884> <pcomp> <accomp>]
# here we reach our maximum number of LCP configuration requests (the
# here we reach our maximum number of LCP configuration requests (the
# default of 10) and so time out
Terminating on signal 2.

  GOL support has dropped my case after concluding - obviously wrongly -
that my dialup software (RH7.1's 'pppd') was not capable of coping with
CHAP authentication.  Of course, that's ridiculous.  And from what I see in
the log files, I'm not even being given a chance to authenticate, anyway.

  I do hope that someone has an answer out there.  'noauth' seems to make
no difference, nor do any of the other options to 'pppd' that I have tried.
I actually gave up on this for a few weeks, assuming that the new GOL server
was grossly misconfigured and that they would fix the problem on their
end, but maybe I'm wrong.  And I do apologize if this has been covered
in TLUG  discussion already.  A Google search turns up nothing on this
problem and GOL, and I haven't been able to check the TLUG archive,
which is now password-protected.

  I think that on principle I'm going to part company with GOL, anyway,
but I really do want to solve this problem first.

  Cheers,  Dennis
-- 
Dennis McMurchy,
Sointula, B.C. / Tojinmachi, Fukuoka
Canada           Japan