Skip site navigation (1)Skip section navigation (2)
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?496818.3133090589>