OR-U -> BitsurfrPro/PortMaster 2E-10
I'm attempting to set up dial-out locations on either end and these appear
to be working, at least the dial-outs are being attempted. Either the
OR-U and the Bitsurfr are not handshaking, or authentication is failing
as far as I can tell.
Both the OR-U and PM2E are running ComOS 3.5.5
Here's my init string for the bitsurfr
at&f1&c1&d2%a2=95@b0=2%a4=0s0=1\r OK
which is attempting MLPPP 2B connections at 64k per channel. Note I've
also set %a4=1 (56k) with the same results.
1) when I dial from the portmaster to the office router, the connection is
established. The routes are all set up ok, etc. However, if I telnet to
the office router over the ISDN link I cannot execute commands. E.g. I
successfully log in and get the ComOS prompt, however, the first command
I type never executes (as far as I can tell). Then the telnet link freezes and
I have to escape out.
2) I have not been able to successfully dial out from the or-u to the portmaster.
I get a series of IPCP_CONFIGURATION_REQUEST lines until it just fails.
When you configure MLPPP on the bitsurfr, one option is to enable or
disable PAP within the modem. This however, does not make sense to me,
or at least only when used by Windoze clients that have INF files which may map the DUN username/password into the dial string. Should I be disabling
this feature and just let the PM and OR-U do PAP? Will this be a problem
when the second B channel attempts to reconnect?
Also, if I manually dial from the OR-U into the bitsurfr I get a bunch of
garbage with MLPP. My three theories are, based on my reading of the
"troubleshooting" second of my Bitsurfr Guide
1) this is because the rate adoption protocols are mismatched
-> however I have verified that MLPP is set on both ends. Also makes
no difference 56K or 64K
2) there is a mismatch between synchronous & asynchronous
-> I read about a "isdn asynchronous mode" in the release notes, but
cannot for the life of me determine how to set this up. yet MLPPP is
a synch to asynch mapping protocol, so it seems that it should be
dialing synchronously. I could use some pointers here.
3) this garbage is actually the OR-U sending PPP packets
-> if authentication is failing, its due to some other problem
Also, why is turning on debugging so flaky? I follow this procedure to
set up debugging output on the pm and the or-u
set console
set debug isdn on (on the or-u only)
set debug 0x51
and sometimes it works and sometimes it doesn't. Furthermore, sometimes
it works and then stops working. (by working I mean that I see info on the
PPP protocol LCP and IPCP exchanges).
Thanks in advance,
John Jamison
**************************************
John Jamison
Vice President of Technology
Sage Solutions, Inc.
353 Sacramento Street, Suite 1360
San Francisco, CA 94111
415 392 7243 x 306
john.jamison@sagesoln.com