From owner-freebsd-isdn  Wed Apr 14  6: 2: 6 1999
Delivered-To: freebsd-isdn@freebsd.org
Received: from mail.promo.de (mail.Promo.DE [194.45.188.65])
	by hub.freebsd.org (Postfix) with ESMTP id 6A4F114F96
	for <freebsd-isdn@FreeBSD.ORG>; Wed, 14 Apr 1999 06:01:49 -0700 (PDT)
	(envelope-from stefan.bethke@hanse.de)
Received: from d225.promo.de (d225.Promo.DE [194.45.188.225])
	by mail.promo.de (8.8.8/8.8.8) with ESMTP id OAA27138;
	Wed, 14 Apr 1999 14:56:35 +0200 (CEST)
Date: Wed, 14 Apr 1999 14:56:29 +0200
From: Stefan Bethke <stefan.bethke@hanse.de>
To: hm@hcs.de
Cc: Hauke Fath <hf@melog.de>, freebsd-isdn@FreeBSD.ORG
Subject: Re: win 98 / fritz && isdn4bsd workaround?
Message-ID: <496818.3133090589@d225.promo.de>
In-Reply-To: <m10XOos-0000EXC@hcswork.hcs.de>
Originator-Info: login-id=stefan; server=mail
X-Mailer: Mulberry (MacOS) [1.4.2, s/n U-301178]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Sender: owner-freebsd-isdn@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

I had fixed this privately, and forgot to sumbit a patch.

Hellmuth Michaelis <hm@hcs.de> wrote:

> From the keyboard of Hauke Fath:
> 
>> looking at the i4b-00.71.00-beta-010399.tgz snapshot, I saw that the
>> workaround for async map negotiation mentioned by Armin Gruner
>> <ag@devsoft.com> in his 981111 mail is not implemented [dropping line
>> 2071 from sppp/if_spppsubr.c]. 

> Can someone (one, please ;-) ) forward me that patch, seemed it got lost
> here ... 

I currently only can access CVSweb, so this is a manual patch:
In sppp_lcp_RCR(), in the second for loop, change:

        case LCP_OPT_ASYNC_MAP:
                /* Async control character map -- check to be zero. */
                if (! p[2] && ! p[3] && ! p[4] && ! p[5]) {
                        if (debug)
                                addlog("[empty] ");
                        continue;
                }
                if (debug)
                        addlog("[non-empty] ");
                /* suggest a zero one */
                p[2] =3D p[3] =3D p[4] =3D p[5] =3D 0;
                break;

to

        case LCP_OPT_ASYNC_MAP:
                /* Async control character map -- check to be zero. */
                if (! p[2] && ! p[3] && ! p[4] && ! p[5]) {
                        if (debug)
                                addlog("[empty] ");
                        continue;
                }
                if (debug)
                        addlog("[non-empty] ");
                continue;

This whole checking could be eliminated completely.  Because we are =
talking
synchronous PPP here, the async map is completely irrelevant. However, the
PPP RFC mandates that all PPP implementations must accept any async map,
even if the link layer used for the connection has no notion of
"characters."

The reason we see a non-null async map in this case is that the remote is
probably using an async-to-sync converter (as in an ISDN TA), and the PPP
implementation believes is has to escape some characters (i. e. "+".)

I believe that the source of the non-null async map is a badly designed
Windows modem INF file for the TA used.


Stefan

--
M=FChlendamm 12           |  Voice +49-40-256848, +49-177-3504009
D-22089 Hamburg         |  e-mail: stefan.bethke@hanse.de
Germany                 |          stb@freebsd.org



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-isdn" in the body of the message