It is strange they closed the ticket on this.
I have been working with Theo in support on this; you might
call and ask for him.
My understanding of the problem is that the 3.3.3 is sending
SABMEs sooner than previous releases, while it waits for the
remote side to begin sending PPP packets. Many TAs ignore
these, some don't. The ProtocolReject that the PM recieves
is likely the SAGEM TA spitting up when it sees one (they
are not valid ppp frames).
I have one TA that fails to bring up its 2nd B because it
spits up on the SABME (first B comes up ok).
Since my ISP installed 3.3.3, my P75 takes longer to connect. =20
It sends its initial PPP packet, ignores the SAMBEs from the
PM, and then re-transmits itsfirst PPP packet. When I dial=20
long distance, the PM responds right away to the initial
PPP request and never sends any SAMBEs.
The real question is why the PM is waiting for a PPP packet
to arrive and why dialing long distance changes things.
My personal hallucination on this is that something in 3.3.3
causes it to miss the first PPP packet from some (fast?) TAs,
leading it to believe that the other end wants to be prompted
with the SAMBEs. (So far, we have not been able to verify
that the PM drops the first frame: the P75 debug output
shows the P75 thinks it sends it; no debug output that we
have tried on the PM indicates receiving it -- even mangled).
I got the impression that R&D was working on a patch
to improve things in this area.
Hope this helps,
Bill
On Fri, 29 Nov 1996 14:32:16 -0800 (PST), you wrote:
>> > S21: Sending Request Connect - 64Kbps / Data
>> > S22: Sending Request Connect - 64Kbps / Data
>> > S21: Received Connect - B2
>> > S22: Received Connect - B1
>> > Received LCP_PROTOCOL_REJECT on port S21 of 1 bytes containing:
>> > 08 01 00 05 7f
>> > Connection Failed
>> > S21: Sending Disconnect Request
>> > Received LCP_PROTOCOL_REJECT on port S22 of 1 bytes containing:
>> > 08 01 00 05 7f
>
>Now, the strange thing is that if the customer calls us _long distance_,=
=20
>it connects fine. =20
>
>Despite Livingston's protestations to the contrary, this is definitely a=
=20
>bug with 3.3.3. It worked on 3.3.1c1, failed on 3.3.3, worked again on=20
>3.3.1c1, and failed again on 3.3.3 . =20