Guys... saw this in linux-ppp mailing list... Has this patch been 
incorporated into the debian pppd??

---------- Forwarded message ----------
Date: Mon, 05 Aug 1996 19:58:33 +0200
From: Michael Lausch <[EMAIL PROTECTED]>
To: linux-ppp@vger.rutgers.edu
Subject: pppd2.2.0f Patch 

This is a patch which removes an error when using Linux as a server
and Windows for Workgroups as a client with PAP authorization.

Forwarded: Mon, 05 Aug 1996 17:57:13 +0200
Forwarded: [EMAIL PROTECTED]
Forwarded: [EMAIL PROTECTED]
Replied: Thu, 01 Aug 1996 10:53:49 +0200
Replied: [EMAIL PROTECTED]
Replied: Wed, 24 Jul 1996 08:18:57 +0200
Replied: [EMAIL PROTECTED]
>>From [EMAIL PROTECTED]  Wed Jul 24 02:36:19 1996
Received: from mario.gams.at (mario.gams.at [194.42.96.10]) by 
bononunu.gams.co.at (8.7.1/8.7.3) with ESMTP id CAA15680 for <[EMAIL 
PROTECTED]>; Wed, 24 Jul 1996 02:36:19 +0200
Received: from avago.anu.edu.au (avago.anu.edu.au [150.203.162.34]) by 
mario.gams.at (8.7.5/8.7.3) with SMTP id CAA28750 for <[EMAIL PROTECTED]>; Wed, 
24 Jul 1996 02:36:15 +0200
Received: (from [EMAIL PROTECTED]) by avago.anu.edu.au (8.6.12/8.6.9) id 
KAA00860; Wed, 24 Jul 1996 10:35:29 +1000
Date: Wed, 24 Jul 1996 10:35:29 +1000
Message-Id: <[EMAIL PROTECTED]>
From: Paul Mackerras <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
In-reply-to: <[EMAIL PROTECTED]> (message from Michael
        Lausch on Tue, 23 Jul 1996 12:09:15 +0200)
Subject: Re: FW: pppd2.0.2f and Trumpet Winsock
Reply-to: [EMAIL PROTECTED]

> You get more then requested :-). I'm including the whole debug trace.
> It's MIME encoded to preserve formatting.

Oops, looks like the NAK from Trumpet was perfectly OK, and the bug is
in pppd.  This is something I fixed a little while ago in ppp-2.3,
which is only in alpha release as yet, and its linux port needs some
more work.  So I've tried to isolate the necessary changes to
pppd/lcp.c and put them into the ppp-2.2.0f source.  I've included the
patch below.  Let me know if it works.

Paul.

--- lcp.c.orig  Wed Dec 27 13:25:51 1995
+++ lcp.c       Wed Jul 24 10:30:17 1996
@@ -792,19 +792,22 @@
      */
     if ((go->neg_chap || go->neg_upap)
        && len >= CILEN_SHORT
-       && p[0] == CI_AUTHTYPE && p[1] >= CILEN_SHORT) {
+       && p[0] == CI_AUTHTYPE && p[1] >= CILEN_SHORT && p[1] <= len) {
        cilen = p[1];
+       len -= cilen;
+       no.neg_chap = go->neg_chap;
+       no.neg_upap = go->neg_upap;
        INCPTR(2, p);
         GETSHORT(cishort, p);
        if (cishort == PPP_PAP && cilen == CILEN_SHORT) {
            /*
-            * If they are asking for PAP, then they don't want to do CHAP.
+            * If we were asking for CHAP, they obviously don't want to do it.
             * If we weren't asking for CHAP, then we were asking for PAP,
             * in which case this Nak is bad.
             */
            if (!go->neg_chap)
                goto bad;
-           go->neg_chap = 0;
+           try.neg_chap = 0;
 
        } else if (cishort == PPP_CHAP && cilen == CILEN_CHAP) {
            GETCHAR(cichar, p);
@@ -822,7 +825,7 @@
                /*
                 * Stop asking for PAP if we were asking for it.
                 */
-               go->neg_upap = 0;
+               try.neg_upap = 0;
            }
 
        } else {
@@ -831,25 +834,14 @@
             * Stop asking for what we were asking for.
             */
            if (go->neg_chap)
-               go->neg_chap = 0;
+               try.neg_chap = 0;
            else
-               go->neg_upap = 0;
+               try.neg_upap = 0;
            p += cilen - CILEN_SHORT;
        }
     }
 
     /*
-     * Peer shouldn't send Nak for protocol compression or
-     * address/control compression requests; they should send
-     * a Reject instead.  If they send a Nak, treat it as a Reject.
-     */
-    if (!go->neg_chap ){
-       NAKCISHORT(CI_AUTHTYPE, neg_upap,
-                  try.neg_upap = 0;
-                  );
-    }
-
-    /*
      * If they can't cope with our link quality protocol, we'll have
      * to stop asking for LQR.  We haven't got any other protocol.
      * If they Nak the reporting period, take their value XXX ?
@@ -869,6 +861,11 @@
              looped_back = 1;
              );
 
+    /*
+     * Peer shouldn't send Nak for protocol compression or
+     * address/control compression requests; they should send
+     * a Reject instead.  If they send a Nak, treat it as a Reject.
+     */
     NAKCIVOID(CI_PCOMPRESSION, neg_pcompression,
              try.neg_pcompression = 0;
              );
@@ -895,7 +892,7 @@
     while (len > CILEN_VOID) {
        GETCHAR(citype, p);
        GETCHAR(cilen, p);
-       if ((len -= cilen) < 0)
+       if (cilen < CILEN_VOID || (len -= cilen) < 0)
            goto bad;
        next = p + cilen - 2;
 
@@ -903,6 +900,9 @@
        case CI_MRU:
            if (go->neg_mru || no.neg_mru || cilen != CILEN_SHORT)
                goto bad;
+           GETSHORT(cishort, p);
+           if (cishort < DEFMRU)
+               try.mru = cishort;
            break;
        case CI_ASYNCMAP:
            if (go->neg_asyncmap || no.neg_asyncmap || cilen != CILEN_LONG)
@@ -1141,6 +1141,7 @@
            orc = CONFREJ;              /* Reject bad CI */
            cilen = l;                  /* Reject till end of packet */
            l = 0;                      /* Don't loop again */
+           citype = 0;
            goto endswitch;
        }
        GETCHAR(citype, p);             /* Parse CI type */

---
sysadm of g.a.m.s. edv dienstleistungen gmbh
finger [EMAIL PROTECTED] for PGP key
<http://www.gams.at/~mla>



Reply via email to