Re: (PM) Strange ISDN Connection Problem...

Josh Richards (jrichard@livingston.com)
Sun, 25 Jan 1998 19:43:06 -0800 (PST)

On Tue, 13 Jan 1998 portmasters@one.net wrote:
> Greetings,
>
> We have a user that is trying to connect to a PM3 running 3.7.2 on a PRI
> with a Digi Datafire U card in a 95 box.
>
> When checking out the debugging on the PM3, the following is what is
> displayed:
>
> ---snip!---
>
> (all looks good up until this point)
>
> Sending LCP_CONFIGURE_REQUEST to port S15 of 14 bytes containing:
> 01 05 00 0e 05 06 eb ac de 9c 03 04 c0 23
> Sending LCP_CONFIGURE_REQUEST to port S20 of 14 bytes containing:
> 01 05 00 0e 05 06 a2 1a 4d b9 03 04 c0 23
> ppp_recv (S20): Bad PPP Address
> ppp_recv (S15): Bad PPP Address
> ppp_recv (S20): Bad PPP Address
> ppp_recv (S15): Bad PPP Address
> ppp_recv (S20): Bad PPP Address
> ppp_recv (S15): Bad PPP Address
>
> ---unsnip!---
>
> ...and this goes on ad-infinitum until the PM3 times out and hangs up the
> line. The connection is obviously unsuccessful. :)
>
> None of us here has ever seen the "Bad PPP Address" before... Can anyone
> shed any light on this situation?

This message is a bit old, but I don't think you got any responses yet.

It looks like the Datafire is trying to establish a two-channel
connection, I would attempt to get a single channel one going first--much
easier to debug. I don't know anything about the DataFire, so make sure
that it is not trying to use a proprietary 128K/bonding mode which some
TAs have.

We are sending out the LCP_CONFIGURE_REQUEST and not getting back a
response (or at least one that is invalid). The "Bad PPP Address" means
we received a packet with an invalid address byte in the PPP frame. This
should be set to 0xff but we are receiving something else from the remote.
The only time when this can be set other then to 0xff ("All-Stations
Broadcast") is if it has been pre-negotiated during the LCP_CONFIGURE
phase (which doesn't even appear to have started if the above output is
complete).

Try the suggestions in the first paragraph, turning off anything that
looks like a "non-standard" option and cutting it back to a single
channel. It is either has a really messed up LCP implementation or is
expecting something else of its own making on the other end.. ;)

>
> Thanks Much!
>
> Christopher Beck
> Network Engineer
> OneNet Communications, Inc.
> 513.554.1638 - cpbeck@one.net

----
Josh Richards - <jrichard@livingston.com>
Beta Engineer
Lucent Technologies (Remote Access Business Unit)
(previously Livingston Enterprises, Inc.)

-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.