Kevin Traas wrote: > > Just recently, I've implemented an ISDN connection to my ISP. However, I've > never been able to use more than one of the B channels at a time - i.e. no > MPPP. > > I'm using a Hayes Accura ISDN External TA attached to a Hayes ESP running at > 460Kbps. I've only been able to get the connection working using the V.120 > protocol. > > I've been talking with my ISP. They tell me that I won't be able to > "bundle" B channels using the V.120 (ATB20) asynchronous protocol and that > I'm going to have to use PPP Async-Sync (ATB40) in order to establish a > synchronous PPP connection. They tell me that they support this without any > problems; however, I'm going to have to use PAP rather than CHAP > authentication.
I use ATB40 (whoa! even the same AT command!) on my Zyxel TA128U with great success (I auth with PAP too). > The problem here is that I've never used PAP. I've tried many various > things to get this working, but I haven't been successful so far. I've been > reading the PPP-Howto and the PPP docs; however, they seem to deal mostly > with configuring *incoming* PAP authentication and don't get into any great > detail on setting up PAP for outgoing PPP connections. Yeah, wankers! > I've configured /etc/ppp/pap-secrets as per the PPP-Howto. I think it's now > a matter of getting the pppd options right. Right now, in testing, I'm > using minicom to establish the connection, doing Ctrl-A Q to exit without > reset, and then running: > > pppd -d -detach /dev/ttyP40 user <name-from-pap-secrets> & > > This is an example of my /var/log/ppp.log entry for this pppd session: > (It's probably pretty broken up due to line lengths....) I've included > comments as to my understanding of what is happening throughout the log > entries.... Ok, let's take a look. Just sit back and relax. This won't hurt a bit. > Aug 27 14:46:46 sally pppd[13583]: pppd 2.2.0 started by admin, uid 0 > Aug 27 14:46:46 sally pppd[13583]: Using interface ppp0 > Aug 27 14:46:46 sally pppd[13583]: Connect: ppp0 <--> /dev/ttyP40 > Aug 27 14:46:46 sally pppd[13583]: sent [LCP ConfReq id=0x1 <mru 1500> > <asyncmap 0x0> <auth pap> <magic 0xf0af33b0> <pcomp> <accomp>] > > ^^^ It looks like I'm requesting PAP in the line above, doesn't it? Yes, you *are* requesting PAP. This is what happens when you pass 'auth' to pppd, it *requires* the peer to authenticate itself. This is not what you want. > Aug 27 14:46:46 sally pppd[13583]: rcvd [LCP ConfRej id=0x1 <pcomp> > <accomp>] > > ^^^ The remote end doesn't like pcomp and accomp.... (What are these > anyway?) pcomp == Protocol-Field-Compression Each PPP frame has a 2-byte protocol field (we're not talking about protocols such as TCP/UDP here, more like LCP, CCP, IPCP, etc.). With pcomp the LSB of the first byte indicate whether or not a second byte follows. So, you can save a byte per frame by using this. accomp == Address-and-Control-Field-Compression PPP uses HDLC-like framing for its packets (otherwise to be referred to as frames rather than packets). This format uses an Address for the data-link layer (in this case, basically your modem). Since PPP is generally run between two points only, the address and control fields can be compressed and save some Bs. Their end doesn't support this compression: too bad but oh well. > Aug 27 14:46:46 sally pppd[13583]: sent [LCP ConfReq id=0x2 <mru 1500> > <asyncmap 0x0> <auth pap> <magic 0xf0af33b0>] > > ^^^ Here, my end is requesting the same as the first time, only without > pcomp and accomp.... Right? Exactly. Your pppd has agreed to not use accomp and pcomp. Note that it still insists on auth pap though! (bad in this case) > Aug 27 14:46:46 sally pppd[13583]: rcvd [LCP ConfReq id=0x3 <asyncmap 0x0> > <auth pap> <magic 0x891e22fb>] > > ^^^ Is this the other end requesting that I use PAP too? Or just > acknowledging receipt of my request? Not acknowledgement, a request (that's why it's a ConfReq, rather than a ConfAck). The peer is requesting that you authenticate with pap, which is as it should be. > Aug 27 14:46:46 sally pppd[13583]: sent [LCP ConfAck id=0x3 <asyncmap 0x0> > <auth pap> <magic 0x891e22fb>] > > ^^^ This looks like me sending an Ack on the PAP request.... Yes, your pppd is agreeing to authenticate itself using pap. > Aug 27 14:46:47 sally pppd[13583]: rcvd [LCP ConfNak id=0x2 <auth chap md5>] > > ^^^ And then, is this the remote end sending me a Nak on my request for CHAP > authentication? I haven't requested CHAP to this point - I'm wondering if > I'm somehow sending clear text across the synchronous link that the remote > end is taking to mean that I want to authenticate using CHAP....??? Your > thoughts? Weird. You never ConfReq'd for auth chap md5. Their end is buggy. What do I bet it's an Ascend Max! (I found another bug in the Ascend Max ppp impl.) > Aug 27 14:46:47 sally pppd[13583]: sent [LCP ConfReq id=0x3 <mru 1500> > <asyncmap 0x0> <magic 0xf0af33b0>] > Aug 27 14:46:47 sally pppd[13583]: rcvd [LCP ConfAck id=0x3 <mru 1500> > <asyncmap 0x0> <magic 0xf0af33b0>] > > As far as I can tell, these lines are just the two ends agreeing to use an > mru of 1500.... ??? This would generally indicate that the peer is happy with what you've requested from it. Interesting that auth pap wasn't requested this last time. > Aug 27 14:46:47 sally pppd[13583]: peer refused to authenticate > Aug 27 14:46:47 sally pppd[13583]: sent [LCP TermReq id=0x4] > Aug 27 14:46:47 sally pppd[13583]: Modem hangup > Aug 27 14:46:47 sally pppd[13583]: Connection terminated. > > Below occurred after I did a "kill 13583" to kill the "hung" pppd process. > > Aug 27 14:47:35 sally pppd[13583]: Terminating on signal 15. > Aug 27 14:47:35 sally pppd[13583]: Failed to open /dev/ttyP40: Interrupted > system call > Aug 27 14:47:35 sally pppd[13583]: Exit. > > Any help you can provide would be greatly appreciated. > Ok. First, get rid of the 'auth' option which is causing your end to dump the peer because it won't authenticate itself. If everything is right with PAP then all should be fine. Note that in order for PAP to work, it needs to know what your login on the remote end is. If this is not the same as the name of your machine, then you need to pass it to pppd with the option 'user <username>'. Then, you need to make sure the entry in /etc/ppp/pap-secrets has the same user name for your entry there. So, if your login/password on the ISP foo/bar, you need a line in /etc/pap-secrets with: foo * bar The '*' meaning match any peer where my user name is foo. Let me know how it goes. -- Jens B. Jorgensen [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
