Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!husc6!cfa!ward
From: ward@cfa.harvard.EDU (Steve Ward)
Newsgroups: comp.protocols.tcp-ip
Subject: Bridge/Excelan VMS/TCP-IP problem
Message-ID: <578@cfa.cfa.harvard.EDU>
Date: Thu, 11-Jun-87 14:28:21 EDT
Article-I.D.: cfa.578
Posted: Thu Jun 11 14:28:21 1987
Date-Received: Sat, 20-Jun-87 10:30:49 EDT
Distribution: na
Organization: Harvard-Smithsonian Ctr. for Astrophysics
Lines: 74
Keywords: Bridge, Excelan, VMS, TCP-IP, Telnet




Help needed from TCP/IP, Telnet protocol experts!!!!!!!!

I have Bridge terminal servers talking to DEC MicroVAXes running VMS with
Excelan TCP/IP protocol/Ethernet interface boards.

Here is my most serious problem:  In order to run CAD/CAE graphics and other
applications, the Telnet session must be in binary mode.  The Excelan board
defaults to 7-bit(ASCII) mode.  The Excelan board is designed to expect the
remote client to request binary mode through some Telnet command/request
mechanism.  The Bridge Terminal Servers can easily be tailored by a user
to operate in binary mode, but have no user or system method to be made to
request binary mode on the part of a host.  This means there is no way for
the Excelan board to operate in binary mode when a Bridge terminal server
is used to interface the terminal or other remote client.

All that is needed is for the Excelan board to provide some host-based
method for configuring binary mode, or the Bridge terminal server must
implement some method for requesting binary mode from the host.  NOW FOR
THE REAL PROBLEM: 

Bridge says that they used to implement client request for host
binary mode, but it caused havoc with SUN workstations, so they
took out the command/request mechanism for host binary mode.
 Bridge further stated that the protocol specs are somewhat
ambiguous on whether the client or host is responsible for requesting
or implementing methods to enter binary mode, but at this point they feel
the host is burdened with this function, though they admit they felt
the opposite was true at an earlier point in time.  Bridge sympathizes
with my problem, but declines to do anything to fix it since their
position is that they are conforming to the TCP/IP/Telnet specs.

Excelan takes the same position, saying that per the specs it is clear
that the Bridge terminal servers must issue the appropriate request
for host binary mode, and their board will respond properly to the
request.  Now it is clear that one of these two products is broken, but
which one???  Bridge and Excelan sympathize, but in essence are saying
"nothing wrong with us or our stuff, go away kid, don't bother me."
What is disturbing is that neither outfit is interested in researching
and resolving the problem.  I would think that both companies would
be interested in helping clarify the situation, even perhaps indulging in
a three way conversation, but this interest was not shown.

I do not have RPC's or specs of any kind.  What I ask is that you network
protocol wizards out there discuss this issue and let's see if their is a
concensus as to whether Bridge or Excelan has a broken product in this case.
If the specs turn out to be truly ambiguous, can we initiate a clarification
to eliminate the confusion?

 Excelan, Bridge, are you listening?  I would appreciate a higher
level of concern and support whether you think your product
is broken or not. This problem will cause malfunctions with most,
if not all graphics terminals connected to Bridge terminal servers talking
to the Excelan TCP/IP board.  Are there other TCP/IP protocol boards out
there that assume that the terminal server or other client must request
binary mode?  If so, then using the Bridge terminal server is not wise
since it won't request the binary mode.  If the host must provide a
method for entering binary mode, then clearly the Excelan product is
broken and these problems could be encountered using the Excelan board
with any terminal server or other client.  This should concern all
present and potential customers for these two product lines.

Bridge and Excelan, if you are listening, replies to myself or Roger
Hauck should be e-mailed to me at:  {seismo|ihnp4}!harvard!cfa!ward
                                    or  ward@cfa.harvard.EDU (ARPA)

This topic should be of broad interest and concern, so replies to the
net are also appropriate, in my view.


Steven Ward, Harvard-Smithsonian Astrophysical Observatory
{seismo|ihnp4}!harvard!cfa!ward