Very different hardware but.....
I *might* be seeing something similar.
In my case, it is just an extra 3 sec to bring up the link.
I tried the 10288nnn-nnnn trick and sure enough the=20
link comes right up (1 sec).
I use an Ascend P75 to connect to my ISPs PM.
They recently upgraded to 3.3.3 & 4MB.
I've gotting debug output from both the PM and the P75
during several of these connects.
It seems to suggest (hedging) that the the PM 3.3.3 does not=20
see the first LCP request the P75 claims (in its debug output)
it sent. After a short time (~1 sec) the PM starts sending
what I have been told are SABMEs (V.120 startup packets?).
The P75 ignores these and retries the LCP req in about 3 sec.
Things proceed normally from there. =20
When the negotiations proceed normally (calling long distance
or dialing locally into a different PM that is still on 3.3.1) the
PM and P75 debug outputs agree on what is sent, no SAMBEs
are recieved by the P75, and the link comes up in about 1 sec.
So, why am I bothering you about this...
- both our problems started with 3.3.3
- both can be worked around by dialing long distance
- both our TAs are "fast"
- one other (suspect) coincidence....
...I have another TA (unfortuately running beta firmware so it is
suspect) that rejects these SABMEs as bad PPP frames and will
not bring up a second channel as a result.
To know if we are really seeing the same underlying problem,=20
getting the debug output of the PM during one of these
failed connection attempts is a start.
One telltail that the TA is seeing these SABMEs is a Protocol
Reject in the PM's debug 0x51 output. Unfortunately, this
is only indirect evidence as the PM doesn't log its sending of
the SABMEs when 0x51 only is on. You can see them being
sent if enable more debug levels (not sure which ones).
Hope this helps,
Bill
On Mon, 4 Nov 1996 21:00:36 -0800 (PST), you wrote:
>We have a Mac customer with a SAGEM internal Nubus ISDN adapter. They =
are
>fed from a remote office with 56KB channels, line on AT&T 5E, configured
>as National. No problems connecting to our Portmaster running 3.3.1c.=20
>
>We upgraded to 3.3.3 and 4MB RAM and this customer can no longer =
connect.=20
>The call comes up and innediately drops. I was at the customer's =
premise
>so couldn't see the Portmaster side of debug, but it looks as if the PM =
is
>immediately dropping the call. Customer sees a "Call failed-Link down"=20
>message.=20
>
>Here's the weird part: If the customer inserts a long distance carrier=20
>code in front of the (local) number, such as 10288nnn-nnnn, it connects=20
>reliably every time. Obviously, they don't want to pay LD rates for=20
>local calls, but by routing the call through AT&T, MCI, or Sprint, it=20
>works. =20
>
>Local telco (GTE) says the line checks out fine, and they can call=20
>another PM long-distance. =20
>
>So, what changed in 3.3.3 that would reject local ISDN calls, and only=20
>from this one type of TA?
>
>-- Jay Hennigan jay@west.net -- =20
>WestNet: Internet service to Santa Barbara, Ventura and the world.=20
> 805-892-2133 805-289-1000 805-578-2121
>