Apr 17 13:27:52 giza pppd[11928]: sent [LCP ConfReq id=0x79 <mru 1500> <auth pap> <magic 0xe22f0878> <pcomp> <accomp>]
Apr 17 13:27:52 giza pppd[11928]: rcvd [LCP ConfNak id=0x79 <auth chap md5>]
Apr 17 13:27:52 giza pppd[11928]: sent [LCP ConfReq id=0x7a <mru 1500> <auth pap> <magic 0xe22f0878> <pcomp> <accomp>]
Apr 17 13:27:52 giza pppd[11928]: rcvd [LCP ConfNak id=0x7a <auth chap md5>]
[repeat 20 times per second for 60 seconds]
RFE: make the portmaster not NAK things that have not been
REQuested (unless current behavior is allowed by the PPP spec).
While I was browsing my entirely too voluminous portmaster-users
mail, I read a tidbit that led me to discover that the portmaster
refuses to do any kind of LCP authentication if a dial script was
used. I had configured my location entry to use a dial script that
merely dialed the number and then handed off to PPP.
RFE: give some kind of diagnostic when this misconfiguration is
discovered (maybe best to diagnose this only when "dial locname -x"
is used)
Theoretically, if I could remove the dial script from that location
table entry, I could get it to use the telephone, username, and
password I had set to do its own magical dial script. However, I was
unable to find out how to clear the dial script.
RFE: implement and document a way to clear the dial script.
So, I deleted the location and created a new one with the same
parameters and no dial script. SUCCESS. Mgetty, diald, and the
portmaster cooperate to make my Linux box demand dialed both
directions. Now to make it work with the house router (another linux
box with ISDN instead of analog).
I change the location's phone number to the ISDN number. I change
its dial group to the ISDN dial group. I rig multilink; 2 channel.
I "dial test1 -x" and watch as the LCP negotiation fails in a new and
strange way.
Apr 23 22:24:22 cairo pppd[2084]: rcvd [LCP ConfReq id=0xf <mru 1600> <asyncmap 0x0> <auth pap> <pcomp> <accomp>]
Apr 23 22:24:22 cairo pppd[2084]: sent [LCP ConfReq id=0x1 <mru 1500> <auth pap> <magic 0xbc37af6> <pcomp> <accomp>]
Apr 23 22:24:22 cairo pppd[2084]: sent [LCP ConfRej id=0xf <auth pap>]
Apr 23 22:24:22 cairo pppd[2084]: rcvd [LCP ConfRej id=0x1 <magic 0xbc37af6>]
Apr 23 22:24:22 cairo pppd[2084]: sent [LCP ConfReq id=0x2 <mru 1500> <auth pap> <pcomp> <accomp>]
Apr 23 22:24:22 cairo pppd[2084]: rcvd [LCP ConfReq id=0x10 <mru 1600> <asyncmap 0x0> <pcomp> <accomp>]
Apr 23 22:24:22 cairo pppd[2084]: sent [LCP ConfAck id=0x10 <mru 1600> <asyncmap 0x0> <pcomp> <accomp>]
Apr 23 22:24:22 cairo pppd[2084]: rcvd [LCP ConfAck id=0x2 <mru 1500> <auth pap> <pcomp> <accomp>]
Apr 23 22:24:22 cairo pppd[2084]: rcvd [IPCP ConfReq id=0x1 <addr 207.100.0.16>]
Apr 23 22:24:22 cairo pppd[2084]: sent [IPCP TermAck id=0x1]
Apr 23 22:24:25 cairo pppd[2084]: rcvd [IPCP ConfReq id=0x2 <addr 207.100.0.16>]
Apr 23 22:24:25 cairo pppd[2084]: sent [IPCP TermAck id=0x2]
Apr 23 22:24:28 cairo pppd[2084]: rcvd [IPCP ConfReq id=0x3 <addr 207.100.0.16>]
Apr 23 22:24:28 cairo pppd[2084]: sent [IPCP TermAck id=0x3]
Apr 23 22:24:31 cairo pppd[2084]: rcvd [IPCP ConfReq id=0x4 <addr 207.100.0.16>]
Apr 23 22:24:31 cairo pppd[2084]: sent [IPCP TermAck id=0x4]
It seems that when dialing out on an ISDN line the portmaster wants
the host it dials to authenticate itself. To paraphrase Livingston
employees: "our products will not authenticate themselves to a
machine which initiates the connection". I don't see why my Linux
box should do this either. Besides, I have no idea what kind of
authentication information the Livingston wants.
However, that may not be the problem. The Livingston seems to go
into the IPCP phase without authenticating itself despite the fact
that it ACKed the <auth pap>. Weird.
RFE: fix this broken shit (unless Linux PPPD or the external BSPro
is broken)
Anyway, use the contact information I gave in the previous mail on
this ticket and give me a call after 6pm EST. Or hell, email me an
answer. 1 week and still waiting for a call.
--
Bob Forsman thoth@gainesville.fl.us
http://www.gainesville.fl.us/~thoth/